Recently I was working on an issue with the SAP HR driver for Identity Manager 3.5.1, and ran into a problem.

The specifics of the problem are complicated, and I will be writing a series of articles on the issue, and at least two totally different possible solutions.

However, I think the way the problem was resolved can really demonstrate the power of the community.

How many people have implemented the SAP HR driver so far? Dunno, but I am sure the number is reasonably low, as SAP is a fairly complex system, usually used at larger sites. While I am sure Novell sells enough licenses of the driver, the actual number of sites out there is still pretty small compared to say the Active Directory driver. So where can you turn too for resources to help out?

Well if you are not aware of the Novell Support Forums, at http://forums.novell.com or via NTTP in a news reader (like Thunderbird, or inside a mail program like GroupWise, etc) at forums.novell.com, go no further, and take a look. There are forums on topics for most Novell products, and there are four setup for Identity Manager issues.

novell.support.identity-manager.engine-drivers
novell.support.identity-manager.analyzer
novell.support.identity-manager.designer
novell.support.identity-manager.userapp-workflow

The Designer and Analyzer forums are great, the developers writing the actual Designer and Analyzer tools read the forum, offer solutions, and if you find a real bug that they can reproduce, will usually enter a bug into Novell's bug tracking software, Bugzilla (Into which everyone can submit bugs or enhancements, at the page: http://bugzilla.novell.com and log in with your Novell account before you can submit bugs). Once it is entered, you can go track it in Bugzilla, and see when it gets fixed. Often soon after it is reported, and they will usually add a comment as to which nightly build has the particular bug fix in it.

Then you can go and download the nightly build and test to see if it is really fixed. Amazing feeling, how well that entire feedback loop works. Best of all, sometimes they do not fully understand the problem, and the fix is not quite sufficient, so you can go back in either the forum or Bugzilla to update the developer that he was close, but not quite with the fix.

In the end Designer or Analyzer becomes a better tool, the specific problem you ran into is fixed, and everyone is happy. This can be immensely satisfying.

The User App forum is critical if you are working on the User Application, as while the documentation is pretty good, there is so much complexity and depth to the product that it is almost impossible to find every thing you need to know about it. A couple of the developers and support guys for User App will respond to questions, which is great! Even better is that the problem you are running into has very likely been run into by someone else, so you can search to find a previous discussion on the topic.

The Engine-drivers forum is even better. There is a great community of people who post questions and answer. People in the field working with Identity Manager, some Novell support guys (in their personal spare time), and some of the developers as well. You can get answers to real tough questions that there really is no other way to discover.

Using a News reader, you can easily download all the headers, and search them for your topic. Often you can find the answer already asked and answered. Other times it can help you find people who have worked on similar issues to discuss the problem with.

On the SAP HR topic, I was able to ask some questions, and discovered a lot. Heck, even wrote a bunch of articles about it:

• • Troubleshooting iDOC Issues in the SAP HR Driver for Identity Manager

• • Using the SAP HR Driver for IDM on a 64-bit OS

• • Decoding iDOCs with the IDM SAP Driver

• • IDM SAP HR Driver: Where to Get the JConnect Libraries

• • Some thoughts on XPATH in Novell Identity Manager

That worked pretty well. But this issue transcended that level of problems. I had to open an incident with Novell Support, and they were trying really hard, and did in fact find a couple of issues. (One ironically that someone in the forums had posted about earlier that week (Thanks Lothar!)).

But in the end, it was discussing this issue with three other people working on the issue, talking about solutions and approaches (often being told I was daft, and being silly with my approach). We were able to come up with the solution.

It turns out the default configuration for the SAP HR driver really only supports one model of organizational management (Supervisory model), and that each SAP HR implementation can choose from other models. My example site of course had chosen a different model, so it was not working with the default configuration. The documentation makes no reference to this possibility, only to suggest you might have to modify the defaults to match your environment.

One of the neat things I really enjoy with Identity Manager is that I get to learn all sorts of interesting things about the connected systems. I mean, what do I know about Lotus Notes or AS400 systems. Well, once you start working on a driver to connect those systems, there is quite a bit of learning that must go on. The thing is that most system administrators for the connected system don't ever think about the kind of issues needed to do an Identity Manager driver. How many of them consider how the passwords are actually encrypted and stored. They know how to set passwords, change them, set policies to control password complexity and what not, but usually have no idea of how the underlying system stores them. Yet in an Identity Manager implementation that is exactly the kind of thing you need to know.

Additionally, the local system administrators often use the tools provided to manipulate the system. So they might select the type of group in the GUI tool while creating a group in Lotus Notes, but when you synchronize that to Identity Manager, you need to know what the actual system values that store the groups type mean.

(Configuring Lotus Notes Group Types for IDM )

Thus being an experienced system administrator of the target connected system might be really helpful, but there is still so much more to learn about it. Much of it is learnable by seeing what comes across in Dstrace, and through experimentation, but I find that entire process really helpful. Often the best way to learn how the connected system behaves is to try all the combinations, read through the trace and derive the underlying information from the results.

In the case of the SAP HR driver, the three other guys (Names redacted to protect the innocent) and I were able to piece together the various bits of information that we had each figured out so far, and help each other take a step forward. Each of us had some information that the other did not. Some of it overlapped, and some was unique to each of us. Once we had all shared the little tidbits we each saw different ways to approach the problem.

For example there is an field in an infotype value on each user in SAP HR, in infotype 0001, called MSTBR (Stands for something in German. Everything in SAP stands for something in German. My German is a bit rusty, being based on Yiddish actually, though my wife does speak, read and write German. I asked her, but it was not a word she could remember off the top of her head) and it looks like it holds the Manager's PERNUM (PERNUM is something like Personell number, basically an employee ID, that we store in eDirectory as workforceID, but is basically the unique identifier for a user in SAP. Other objects in SAP get the same format number, but it is called OBJID, Object ID for those other classes). Well, I thought that would be good enough, and built a rule that built the Manager and Direct Report relationship from that one attribute. However I was able to find out from one of the guys that the MSTBR field is not actually useful, and is not automatically maintained, and if it is maintained, it is done by hand, and therefore is not reliable, and is usually outdated. So I went down the wrong path, but it was a useful exercise since it made me think about how to the build the relationship between Manager and Direct Reports, which I was able to use later to actually resolve the issue, once I found out where to really look.

I was able to get some explanation and sample code from the other guys that lead me in the right direction. In the end I worked on one approach to the issue (DirXML Script based, because I hate XSLT, and really, DirXML Script is way easier to maintain, read, and understand! Look at this article, Open Call: What Can You Do in XSLT that You Cannot Do in DirXML Script? for some of my thoughts on the topic. I personally am trying to find ways to do each of those things in DirXML Script, rather than XSLT if possible. I have a couple of solutions so far!), and one of the other guys (in the Netherlands of all places!) was able to figure out an entirely different approach using XSLT. This is great, because now we have two workable approaches to a problem, that takes a fair bit of understanding to even know exists!

There are a couple of articles about the specific topic, the problem, and each of the solutions that we will be writing to help the next person who runs into this issue.

What this entire incident really reinforced to me is the power of the community. I tried the Novell Support approach, and because this is a hugely specialized problem, there are not a lot of people with a great deal of expertise in the support organization. They can go back to the developer, so they do have access to the resources they need, but you cannot get this kind of answer from most of the levels of support.

The same is true for many other extremely focused issues. There are many drivers that the level of expertise at this extreme level of details is lacking. There may not be much to be done about it, but it is nice that we are able to work around the problem, by working together.

This example showed how four of us working together were able to figure out the complicated issue, and build working solutions. We started with using the Support forums, corresponding privately via email, (taking it offline, from the forums as we worked on details) reading and writing Cool Solutions articles, and basically sticking together to help each other out. Sounds like a nice community to me!

What have you done lately to help out? Take a look at the forums and see if there are any questions you know the answer too and can answer. Heck, just posting questions on interesting topics will usually bring out interesting answers.

If you run into an interesting problem write it up and submit it to Cool Solutions. You never know when your problem will be encountered by someone else, and help them solve it. I will bet that somewhere in your Identity Manager implementation you ran into something, anything, that was not bog standard and out of the manual.

If you ran into it, then obviously someone else might run into it, so write it up, and submit it to Cool Solutions. You can earn points for all sorts of fun things! They offer great rewards for the points you earn, and if you start writing, you will be amazed how fast you can rack up the points! Take a look at the Rewards page, to see what sort of things they offer, at http://www.novell.com/communities/rewards.

Even better, Google spiders and indexes both the Support forums and Cool Solutions, so any content you contribute will be findable via Google. This means that for most people searching for information on a problem, who will probably use Google to search for it as some point, will be able to find it!