Cybersecurity
DevOps Cloud
IT Operations Cloud
SAP HR Driver, error messages:
Table of Contents:
Novell Identity Manager has a list of various pre built drivers for a variety of systems. For example, Active Directory, Lotus Notes, SAP UM, SAP HR, PeopleSoft, BMC Remedy, and so on.
There are a couple of generic drivers as well, that handle a large number of different systems. These include the JDBC driver, which can connect to most databases that have a JDBC interface available. There is the LDAP driver that connects to a large number of LDAP systems, There is the SOAP driver which can connect in principle to any SOAP (SPML or DSML) based web service. There are the Delimited Text driver, for when all else fails, as long as you can you get a text file (CSV perhaps) dump of the data you can use this driver. You could always write your own, using the Java API to connect to the target systems native interfaces, or when available you can use the Scripting driver to do the same, but in a simpler fashion.
Between all these options you should be good to connect most systems as needed.
Once you have a nice system set up, troubleshooting is always entertaining. One criticism I have of the Novell provided documentation is that it does not have sufficient documentation of possible error codes that can occur for each driver. Now to be fair, this is a pretty hard task, as many of the error codes are not actually generated on the Novell Identity Manager engine side, and rather are often system specific to the connected system. Nonetheless I think it would be very beneficial to include such error codes and cases. I have noticed that the troubleshooting section of the driver docs have been getting filled in, with at least some minor amount of details in the latest revisions of the documentation, which is a very good thing. But as always, I encourage more content from the writers.
Rather than just be a blow hard and annoy people, I decided to try and work on this issue myself.
I have a series of articles along this train of thought. For the JDBC driver I wrote:
These articles list the error message, showing trace, and the error itself, and where I knew an answer, explain what went wrong, and how to fix it. My hope is that the next person who encounters this error in trace, will copy and paste into a Google search, and whammo, find at least one possible suggestion on how to resolve it. Should it not be the exact error case, needing a different solution, at least they will have a hint on how it affected someone else and a thought on how to proceed.
I did the same for the Active Directory driver in this series of articles:
For the eDirectory driver there is: Error Codes of the eDirectory Driver for Identity Manager - Part 1
I have more content stored up, that I need to finish up writing, like this article on the SAP HR driver error codes. I have a bunch of error messages from the GroupWise, and eDirectory drivers I need to write about.
I highly recommend that when you work with a new driver, keep a nice text editor open, and as each error occurs, paste it into a continuing file, and as soon as you figure out the problem, write down a couple of lines explaining the issue. Then when you have some time, write it up in this sort of format and submit it to Cool Solutions. This way everyone benefits!
Additionally, if you are not aware of it, the Novell Support Forums do an excellent job of supporting Novell products for free. The community works to answer the questions, and Novell does encourage people by selecting some of the more common contributors to be Novell Knowledge Partners. I personally follow the Identity Manager forums and lightly watch some of the others. You can find the Novell Support Forums at http://forums.novell.com or you can use NNTP in a news reader like Thunderbird or the GroupWise client as well. I personally prefer NNTP over a web interface, but the web interface is more easily searched and indexed, so different strokes for different folks.
Before we get to the error codes, a few quick points about the SAP HR driver, SAP as a system is HUGE! It has many many components and systems, and lots of people involved in getting it going. There are actually several SAP drivers from Novell. The original two are the SAP UM, and HR modules. The SAP UM lets you synchronize users in and out of SAP, as users of the system. That is, as users in SAP, who can log in to a module and do work. Alas, the way passwords work in SAP, they are per module. There is a specific SAP module called the CUA (Central User Agent?) which the SAP UM driver can connect too, and push users into, and then the CUA within SAP can push those users to other modules, but it does not push passwords. In which case, you might have a standard SAP UM driver connecting to the CUA to synchronize users, but need additional drivers for all the systems you wish to synchronize passwords too, that only sync passwords, and no other attributes.
Novell has since released a couple of SAP drivers for GRC, and Netweaver that I have not had time to look at, but sound interesting.
The SAP HR driver is meant to synchronize employees out of the HR system, as they are hired, transferred, and withdrawn (nobody is terminated in SAP, they are withdrawn). These are used to create user objects in the Identity Vault to populate and control users in all the other systems.
This article is just about the SAP HR driver. This driver is somewhat peculiar in at least three ways.
The Subscriber channel uses BAPI, which needs the Jconnect libraries, (here are a couple of articles related to that:
Error on bad iDOC format:
DirXML: [10/02/08 14:01:10.232]: TRACE: ParseIDoc: IDoc file opened successfully.
DirXML: [10/02/08 14:01:10.258]: TRACE: ParseIDoc: Exception in IDoc Parsing: java.lang.NumberFormatException: For input string: " ". File processing terminated.
DirXML: [10/02/08 14:01:10.268]: TRACE: ParseIDoc: File '/idm/idocs/O_400_00000000115871645' renamed to '/idm/idocs/O_400_00000000115871645.proc' successfully.
DirXML: [10/02/08 14:01:10.750]: TRACE: SAPPublicationShim: Setting 'success' status on eventObject 'P 00011188'
DirXML: [10/02/08 14:01:10.751]: TRACE: ParseIDoc: Status of Published document 'O_400_00000000115871645' is 'bad'
DirXML: [10/02/08 14:01:10.763]: TRACE: ParseIDoc: File 'O_400_00000000115871645.proc' renamed to '/idm/idocs/O_400_00000000115871645.bad' successfully.
As I was learning about iDOCs I tried editing one myself, to cut it into pieces and make it smaller, into a single event I could follow and troubleshoot. Well looks like I made a typo.
The formatting is VERY constrained and non tolerant of errors. Extra carriage returns or line feeds are a definite no no, and with everything being based on placement of the character in a very long line, you can imagine all the possible errors inadvertent editing could cause.
The good news is that vi or vim are great editors as they do not line wrap on you, munge carriage returns or line feeds, or otherwise do things that many Windows based editors will do to your file.
There are actually two different classes of this kind of error. This first one, just gets caught by the shim and treated as an error.
Then next class of error is much more fatal to the driver shim (whether it be running local or in a remote loader. Though as always, a remote loader is probably a better idea).
Fatal iDOC processing error:
This is the remote loader side trace of the event, as it reads the file, and sees an error. Finally it decides it is a fatal error.
DirXML: [10/01/09 10:49:06.017]: TRACE: ParseIDoc: No Character Set Encoding specified. Using default encoding: ISO8859_1
DirXML: [10/01/09 10:49:06.018]: TRACE: ParseIDoc: IDoc file opened successfully.
DirXML: [10/01/09 10:49:06.019]: TRACE: ParseIDoc: IDoc to parse: /idm/idocs/O_400_0000000019079301a
DirXML: [10/01/09 10:49:06.020]: TRACE: ParseIDoc: Segment EDI_DC40
DirXML: [10/01/09 10:49:06.025]: TRACE: ParseIDoc: Unable to read specified byte count from array. Bad line in input file.
DirXML: [10/01/09 10:49:06.027]: TRACE: ParseIDoc: Segment E2PLOGI
DirXML: [10/01/09 10:49:06.028]: TRACE: ParseIDoc: Object type S found in filter.
DirXML: [10/01/09 10:49:06.028]: TRACE: ParseIDoc: Parsing object type S segment
DirXML: [10/01/09 10:49:06.029]: TRACE: ParseIDoc: Object identifier: 00030928
DirXML: [10/01/09 10:49:06.029]: TRACE: ParseIDoc: Operation: I
DirXML: [10/01/09 10:49:06.030]: TRACE: ParseIDoc: E2PITYP found
DirXML: [10/01/09 10:49:06.030]: TRACE: ParseIDoc: Parsing infotype: 1000, subtype:
DirXML: [10/01/09 10:49:06.031]: TRACE: ParseIDoc: GSA segment 'E2P1000001'
DirXML: [10/01/09 10:49:06.032]: TRACE: ParseIDoc: Skipping history item - Type: P1000, timestamp: 20050418-20050801
DirXML: [10/01/09 10:49:06.033]: TRACE: ParseIDoc: E2PITYP found
DirXML: [10/01/09 10:49:06.033]: TRACE: ParseIDoc: Parsing infotype: 1001, subtype: A003
DirXML: [10/01/09 10:49:06.035]: TRACE: ParseIDoc: GSA segment 'E2P1001001'
DirXML: [10/01/09 10:49:06.035]: TRACE: ParseIDoc: Skipping history item - Type: P1001, timestamp: 20050418-20050801
DirXML: [10/01/09 10:49:06.036]: TRACE: ParseIDoc: Unable to read specified byte count from array. Bad line in input file.
DirXML: [10/01/09 10:49:06.037]:
DirXML Log Event -------------------
Driver = \ACME-EDIR\acme\services\idm\IDMSet\SAP-HR351
Thread = Publisher
Level = error
Message = Exception caused by PublicationShim.start()
java.lang.NullPointerException
at com.novell.nds.dirxml.driver.SAPShim.ParseIDoc.startparse(ParseIDoc.java(Compiled Code))
at com.novell.nds.dirxml.driver.SAPShim.SAPPublicationShim.getOutboundIDoc(SAPPublicationShim.java(Compiled Code))
at com.novell.nds.dirxml.driver.SAPShim.SAPPublicationShim.start(SAPPublicationShim.java(Compiled Code))
at com.novell.nds.dirxml.remote.loader.Driver.run(Driver.java:851)
at java.lang.Thread.run(Thread.java:570)
DirXML: [10/01/09 10:49:06.049]:
DirXML Log Event -------------------
Driver = \ACME-EDIR\acme\services\idm\IDMSet\SAP-HR351
Thread = Publisher
Level = fatal
Message = Exception caused by PublicationShim.start()
java.lang.NullPointerException
at com.novell.nds.dirxml.driver.SAPShim.ParseIDoc.startparse(ParseIDoc.java(Compiled Code))
at com.novell.nds.dirxml.driver.SAPShim.SAPPublicationShim.getOutboundIDoc(SAPPublicationShim.java(Compiled Code))
at com.novell.nds.dirxml.driver.SAPShim.SAPPublicationShim.start(SAPPublicationShim.java(Compiled Code))
at com.novell.nds.dirxml.remote.loader.Driver.run(Driver.java:851)
at java.lang.Thread.run(Thread.java:570)
You can see the Log Event, that it is a Fatal type event, meaning the driver will shut down.
Then you see the driver shut down event. Nice that it ended so gracefully in this case.
DirXML: [10/01/09 10:49:06.068]: TRACE:
<input>
<status event-id="report status" level="warning" type="remoteloader">Remote driver stopped</status>
<init-params event-id="write-state"/>
</input>
</nds>
Watching trace on the engine side shows, the following error, basically the same error the Remote Loader reported, bubbled back to the engine side.
This is useful, as often you may not have easy access to the Remote Loader side to watch the trace, nor might you be running it with trace enabled, as it can eat up disk space quickly, and reduce performance.
[10/01/09 10:49:06.061]:SAP-HR351 :Remote Interface Driver: Received.
[10/01/09 10:49:06.061]:SAP-HR351 :
<nds dtdversion="3.5" ndsversion="8.x">
<input>
<status event-id="report status" level="fatal" type="remoteloader">Exception caused by PublicationShim.start()
java.lang.NullPointerException
at com.novell.nds.dirxml.driver.SAPShim.ParseIDoc.startparse(ParseIDoc.java(Compiled Code))
at com.novell.nds.dirxml.driver.SAPShim.SAPPublicationShim.getOutboundIDoc(SAPPublicationShim.java(Compiled Code))
at com.novell.nds.dirxml.driver.SAPShim.SAPPublicationShim.start(SAPPublicationShim.java(Compiled Code))
at com.novell.nds.dirxml.remote.loader.Driver.run(Driver.java:851)
at java.lang.Thread.run(Thread.java:570)
</status>
<init-params event-id="write-state"/>
</input>
</nds>
In the first case of a bad iDOC file, I no longer remember what and how I edited the file to cause the non fatal error, that was nicely handled by the shim. In the case of the fatal error, I am pretty sure all I did was leave a trailing empty line, carriage return in VI. Sort of like when you paste in, and the cursor does not have a ~ on the last line, rather there is a blank line in the view in VI. A simple dd to delete the line clears it up, but leaving it behind seems to have caused the issue.
The actual error, on the Remote Loader side that seems to get us in trouble here is: Unable to read specified byte count from array. Bad line in input file.
I wonder if this is a bug versus normal behavior, as it would seem this would be an excellent case, where the shim should quietly handle it as an error, rename the file to .bad as it does above in the previous example and get on with its life. But for some reason, this specific error is fatal. I don't really have the time to report it as a bug, but it leaves me wondering.
Bad Password for account in SAP:
<nds dtdversion="1.0" ndsversion="8.5">
<source>
<product build="20070918_0739 " instance="SAP-HR351" version="3.5.1">DirXML Driver for SAP/HR</product>
<contact>Novell, Inc.</contact>
</source>
<output>
<status level="fatal" type="app-authentication">
Error authenticating to SAP host: RFC_ERROR_LOGON_FAILURE
</status>
<init-params event-id="write-state"/>
</output>
</nds>
[10/08/08 12:58:47.684]:SAP-HR351 PT:Applying schema mapping policies to input.
[10/08/08 12:58:47.685]:SAP-HR351 PT:Applying policy: % CCMapping Policy%-C.
[10/08/08 12:58:47.682]:SAP-HR351 PT:Resolving association references.
[10/08/08 12:58:47.687]:SAP-HR351 PT:
DirXML Log Event -------------------
Driver: \ACME-DEV\acme\services\idm\IDMSet\SAP-HR351
Channel: Publisher
Status: Fatal
Message: Error authenticating to SAP host: RFC_ERROR_LOGON_FAILURE
This is a nice clear error. Logon Failure. Yay. The best kind. The password was wrong for the account in SAP, used on the Subscriber channel for the BAPI calls. This happened to me, as they refreshed our QC environment and lost my SAP account, recreated it with a different password. I am curious, is this normal for SAP people to do? They did this to me about 4 times over the course of the project. It has to be the most annoying thing to come on site and find out that nothing is working. Takes about half a day to find out what they changed without mentioning it to me, and then to fix it.
Oh, did we not tell you we refreshed that machine, and upgraded it, and threw away any changes we made for your lab? Do I sound bitter? It truly was annoying, especially when it kept happening!
Anyway, easy enough to detect and figure out once you know what to look for.
I think that is enough for now, stay tuned for part 2 where we tackle a bunch more errors that may help you out when deploying this driver in your environment.
As always, I highly recommend that you try to do this sort of article yourself and publish any error codes you might find. The more we get into Google the easier it will be for others searching for help on the topic to help themselves!