Monday, March 08, 2010

ITIM Provisioning with SPML

I had an interesting day last week playing with IBM Tivoli Identity Manager and IBM Tivoli Directory Integrator. The brief was to send provisioning requests from ITIM via ITDI as SPML requests to a target credential store. Sounds easy, doesn't it?

SPML parsing support has been available within ITDI since v6.1.1 (Fix Pack 1) and dropping the openspml2-toolkit.jar into ITDI's JAR directory should've been enough for me to get motoring with the requirement. And there is a certain amount of truth in that statement in that it was easy to put together a Proof Of Concept showing an ITDI Assembly Line sending SPML formatted provisioning requests to a SPML listener.

That was fine until I elevated the Assembly Line into ITIM. Sending the AL to an ITDI RMI Dispatcher as part of an ITIM provisioning request has been a feature of the ITIM setup since its v4.6 days and there hasn't been any reason to suspect that ALs invoked via the dispatcher mechanism would behave any differently than ALs invoked from either the command line or through the ITDI GUI.

But there is...

Unfortunately, I had created an Assembly Line that was made up the following:
  • Parser Function (to parse my work entry into SPML format)
  • HTTP Client Connector (to send my SPML formatted string to a SPML listener)
  • Parse Function (to parse the response to my connector above)

There's nothing wrong in what I did. I could've attached the SPML parser to the HTTP Client Connector, but I didn't. I wanted to build up my AL slowly and show what was happening during the SPML creation process.

The AL worked fine through the GUI. But it did not work when "dispatched" as it throw a nullPointerException during the attempt to call the parser. My RMI Dispatcher had all the required JARs at its disposal and the environment variables were identical to my GUI environment. I even tried to use the CSV parser rather than SPML (thinking that maybe a parser introduced as part of a Fix Pack may not have full support) but I got the same result.

If only I had attached the parser to my HTTP Client Connector because guess what? You guessed it. That worked! It seems that (in my environment) parser functions cannot be instantiated when the AL is invoked by the RMI Dispatcher. NOTE: I did upgrade my RMI Dispatcher code to the very latest version during my investigations.

So a note to all - Parser Functions may not behave as you expect when dispatched!

No comments: