Novell Identity Manager has a large number of available drivers, ready to go out of the box. The problem that arises is that many of the connected systems are complex, and there is no single or even common way to configure them.
Thus when Novell first released the product as DirXML 1.0 they said you could not buy it, without a consulting contract to implement it, since the possibilities were effectively infinite for how it might need to be set up.
Over time, that attitude changed, as the product matured, and as Novell got better at writing driver configurations we got default configurations that were more flexible.
The extreme counter example would be the fact that ZENworks 6.5 and higher included a bundled version of Identity Manager, meant to be simply installed to synchronize eDirectory to Active Directory. The Active Directory driver is a great example of how far the driver configurations have come along in terms of simplifying the process. Now it is quite straight forward to use the Active Directory driver. My favorite example of that is naming the objects in Active Directory. Active Directory has at least four possible naming like attributes, sAMAccountName, userPrinipalName, Full Name, and Display Name. With the current default driver configuration, you select a setting in the Driver configuration as to which model you want to use, and the work is done for you, no custom coding required.
Others, like the Lotus Notes drivers have a huge amount of flexibility in the driver configuration to handle some of the many possible cases that might need to be implemented. The different approaches are controlled via Global Configuration Variables and are used through out the rules in the driver to modify its behavior.
The SAP HR driver is probably not as commonly implemented as the Active Directory driver, nor even the Lotus Notes driver, and it somewhat shows in the maturity level of the default configuration. However the implementations of the SAP HR driver are generally a bit bigger than other driver implementations. SAP is currently pushing into the SMB (Small-Medium Size Business) market quite heavily, but short of that approach, it is rare to see an SAP HR implementation for a small company. (Small being relative of course)
SAP is an interesting product ('interesting' of course is meant in the Chinese proverb/curse sense: "May you live in interesting time"), in that it is sufficiently diverse and complex (and just plain BIG!) that most organizations that use it, will end up with different teams, that run different aspects of it, and often there is little cross over between the groups. The most amazing thing is to work in a company which is using SAP and trying to get in touch with the right people to resolve issues. There seems to be a lot of passing the buck, where each person seems to think that is the other teams issue to look at. The combination of the sheer size and complexity of the SAP system, and the odd specialization in the support group can really detract from implementing this driver.
Just to make it interesting it turns out that almost all system level things (like Infotype values names that you will have to deal with as you work on this driver) are based on nicknames or abbreviations from German (SAP is a German company, or at least has a huge German influence in its design). I know this is a hugely English centric view of the world, and is quite ironic, since most software is the opposite and usually uses English abbreviations. Now that the shoe is on the other foot, I will admit it is quite a pain. I feel for those of you who do not use English as your first language, when you have to deal with software written in English. It is more than learning the language, it is about learning the abbreviations and obvious nick names for things.
It is worth mentioning that there are two very different SAP drivers. This discussion is all about the SAP HR (Human Resources) driver, that is used to provision users as they are hired, fired, transferred, retired, and whatnot into your Identity Vault. This connects specifically and only to the SAP HR module. (SAP has dozens if not hundreds of modules, that do all sorts of interesting things).
There is another driver known as the SAP UM (User Management) driver, which is used to provision users into the SAP system, so that they can login and use the SAP system itself. The SAP UM driver works pretty much exclusively with the BAPI interface which makes things a little bit easier. SAP itself has a module called the CUA (Central User Access?) that if you provision users into CUA, as a module, via the SAP UM driver then the CUA module can create and synchronize the users to other SAP modules internally. The downside to this is that the SAP CUA system module does not provision nor synchronize passwords, which makes it somewhat annoyingly useless. (It is most annoying as it is so close to being useful, and it looks like just what you need, except it doesn't do what you need.) What most people end up doing is setting up a CUA driver to provision the user once, and then a separate SAP UM driver instance for each module, just to synchronize passwords into the SAP system.
For some other articles about the SAP HR driver, you could look at:
This driver is more than a little tricky to wrap your head around, mostly because it turns out that the Publisher and Subscriber channel do not use the same communication method. That is, the Subscriber channel uses BAPI (as does the SAP UM driver) which allows writing data back to the SAP HR database, but the Publisher channel relies on iDOC handling and the data is there or not. In addition to the data needing to be in the iDOC, there is an additional set of data (the infamous RELATIONSHIPS) that is never queryable after the fact, because it is only available for the duration of the operation, while the iDOC is still being processed.
Once you get past that issue, the driver is fairly straight forward, except that a fair bit of it is still written in XSLT as opposed to DirXML Script, but it is well commented and very readable.
The biggest issue revolves around the organizational structure, and if it matters to you, to get that into your Identity Vault.
SAP HR has a very complex Organizational Management model and can do almost any model you can imagine. By default, the driver maps the four SAP objects involved, P (person), O (Organization), C (Job), and S Position to objects to eDirectory objects.
P, the Person object in SAP maps quite obviously to the User object in eDirectory.
O, the Organization object in SAP maps quite obviously as well to the Organizational Unit object in eDirectory.
C, the Job object in SAP maps to CommExec in eDirectory, which is not a very common object class to use at all.
S, the Position object maps fairly common sensically to the Organizational Role object.
This set of mappings that the driver comes with is somewhat arbitrary, and configurable to whatever you like, if you have a better approach. A friend in Europe chooses to use Groups for the O object mapping, which actually has a lot going for it, once you start thinking about it. There is however a logical consistency to much of the mappings. Well, at least for everything except the Jobs, I have no idea what a CommExec object is supposed to be, but that is the mapping.
The general downside to customization and moving far far away from the default driver configuration is that when it comes time to get support, or to upgrade, the more you have customized it, the harder it gets. While Novell Support can support the SAP HR driver (I just had a really good experience with Novell Support in regards to an issue on the SAP HR driver, and it helps that we had not yet customized it heavily).
One of the more common reasons for using an Identity Manager driver into SAP HR, beyond the actual user provisioning is to enable the SAP Portal, which does LDAP authentication against eDirectory. If you want to do that, it is critical to be able to identify who is a manager, and who is not. The driver by default appears to have code to do this, but this is where the complexity comes in.
The default driver configuration (at least as of Identity Manager 3.5.1, I admit to not having looked in detail in the IDM 3.6 driver configuration yet to see if this is all magically fixed, but somehow I doubt it!) is setup to handle a pretty specific model of organizational structure, which the SAP guys here tell me is called the Supervisory model.
In that case, the driver looks basically only at S (Position) objects, and looks for a RELATIONSHIPS query result, that links this S to its parent S object that it reports too (RSIGN = A, RELAT = 002 much much more on this in a later article, if you know SAP HR, this makes sense, but I will get to it!). From that link, it calculates who the manager is, since the manager is the Holder (RSIGN = A, RELAT = 008) of the Position and it can infer the directReports by reading all the bottom up linkages (RSIGN = B, RELAT = 002).
This I am told works really well when your SAP HR implementations OM (Organizational Management) module is using the Supervisory model. As soon as you diverge from that, you are basically on your own.
I have to be critical of the current documentation (and I have pushed back via Novell Support to get it updated, I have composed an alternate text to describe this issue and submitted it as a comment on the documentation page) and I am quite disappointed that this entire issue is not discussed. There is nothing I was able to find, that mentioned that this is how the driver is implemented. I had to work it out on my own. The process of working it out was quite interesting, and is itself the subject of another article I wrote, about the power of the community, since on my own, I do not know if I ever would have figured this one out. You can read more about that at, The Power of the Community where I discuss some of the process we went through, via the Novell Support Forums, and Cool Solutions to try to identify and resolve this issue. One of the people involved is working on an article describing his approach to resolve this via an XSLT approach. I personally do not like XSLT and prefer to use DirXML Script wherever possible, so I decided to approach solving it without using XSLT.
A more common approach (I don't doubt there are many others models out there) is to link the O (Organization) objects into a hierarchy of O objects. Thus each O exists in a tree of Organizations. Then at each O level, there are S objects (Position) as leaf nodes there, that belong to that Organization. As before each S object has a P (Person/User) object that is the Holder (RSIGN = A, RELAT = 008) of that position. One of those S objects will be the manager of the O object (RSIGN = A, RELAT= 012) and thus all Holders of all the S's that belong to that O are the directReports of the P that is the Holder of the S that is the Manager of the O.
Phew, what a run on sentence! I think I need some pictures to try and explain that! I wanted to get some of the background out, and break into easier to digest chunks, so stay tuned to for part 2 of this series as I continue to explain in more detail how this other model (Whose name I cannot get my SAP guys to tell me, I suspect they do not actually know what the name for it is!) works.
Support
Documentation
Training
Partner Portal