Article

(View Disclaimer)

I recently was working with an Identity Manager driver that was 100% XSLT. There is nothing wrong with that, but I much prefer to work with DirXML Script. Much of that is because I am lazy, and DirXML Script is so much easier to use. That, of course, is not true if you are fluent in XSLT, in which case you probably are completely comfortable using XSLT for pretty much anything.

First, an explanation of terms ...

About XSLT, XSL, and DirXML Script

XSLT is the XSL Transform language, and XSL is the eXtensible Stylesheet Language.

When Novell first released DirXML, they initially said that it would require a consulting contract to implement it. That is, they were not intending to sell the product as a boxed product. If you looked at the product back then, you could probably understand very quickly why they felt that way. Everything was done in XSLT stylesheets (which is as redundant as saying RAM Memory, but whatcha gonna do?) and if you understand XSLT, wonderful. It is not that hard to read, but if you need to do detailed troubleshooting, it is a much bigger problem.

With NSure Identity Manager 2.0x they introduced the DirXML Script language (I think - it might have been in earlier versions). This is a language defined by Novell that the engine knows how to interpret. The beauty of DirXML Script is that it reads easily and is very powerful.

DirXML Script is made up of nouns (local variable, attribute, operation), actions (do-set-dest-attribute, query), and tokens (also with nouns and verbs, such as token-text, token-src-attribute) that when put together lets you do much of what you need. (I am sure there is a much more formal way to have said that, but I think you get the idea.)

One thing to note is that much of the upgrades and updates Novell has been doing to the Identity Manager project usually include new verbs or tokens. do-set-sso-credential is pretty new as a verb, which lets you set a Single Sign On credential on a user, when provisioning them. Doing this before was fairly complex. Now with a prebuilt verb it's pretty easy, and it is wrapped in a nice user interface that mandates and validates the information you need to provide.

An example of that action would be:

<do-set-sso-credential app-id="ApplicationID" store-def-dn="path\to\repo">
  <arg-dn>
    <token-src-dn/>
  </arg-dn>
  <arg-string name="String1">
    <token-text xml:space="preserve">Some value</token-text>
  </arg-string>
  <arg-string name="String2">
    <token-text xml:space="preserve">Other value</token-text>
  </arg-string>
</do-set-sso-credential>

This is much easier to read than the XSLT equivalent, which to be honest, I do not even know how to do. I think you would have to call a Java class in the Secret Store SDK with the correct parameters to do this action.

Convert Time is one of my favorites. This is quite possible using the Java time functions, but that is a bit messy. The DirXML Script is pretty easy and has a very nice user interface.

<token-convert-time dest-format="yyyy MMM dd hh:mm:ss" dest-lang="th" dest-tz="Asia/Yekaterinburg" src-format="!CTIME" src-tz="UTC"/>

This silly example takes time in CTIME (eDirectory's native time format) in the UTC time zone and converts it to whatever time zone Asia/Yekaterinburg is, and displays in the Thai language format as "2008 Jan 12 12:22:12" (Hey, I never said it was a GOOD example; it is, however, a weird example of what you can do ...)

Another great example is Unique Name token. It used to be if you wanted to be sure the target system's name you want to use is unique, you needed to write your own routine to do this. Basically, you would decide on what your format for the name would be - say, first initial of the first name, then the last name. Next, you would use the Java srcDestCommandProcessor to (or destCommandProcessor. depending on what your goal is) to test for that name. If it is found, you could add a 1 or something, and then try again. It's not that hard to do, but pretty much everyone was reinventing the wheel to do this. So in Identity Manager 3.5 they added the new token Unique Name. Here is an example snippet that will do the first letter of the first name, then a period, a dash, and a period (b.-.smith for Bob Smith), and test for uniqueness. (Again, it's not a very smart example, but it is a silly example.)

<token-unique-name counter-pattern="last" counter-use="callback" name="CN" on-unavailable="error">
  <arg-string>
    <token-substring length="1">
      <token-attar name="Given Name"/>
    </token-substring>
    <token-text xml:space="preserve">.-.</token-text>
    <token-attar name="Surname"/>
  </arg-string>
</token-unique-name>

There are numerous examples of DirXML Script commands that are very useful and powerful. I could go on for hours!

But the main point is that with each Novell release of Identity Manager more power is being added to DirXML Script and tasks that used to be some work to do, are becoming easier and getting useful interfaces on top of them.

What Can You Do?

Now to my question. What can you do in XSLT that you cannot yet do in DirXML Script? Or to put it another way, why would you continue to write Identity Manager rules in XSLT? It's understandable in the case of older drivers written to DirXML 1.1a, that were incrementally updated to each succeeding version. A change to DirXML Script would require a full run of the test suite to validate it again. So if the option is ripping and replacing an existing driver, I can understand why you would continue using what you have. It also makes sense to me that new development would continue in DirXML Script policies. (An example of this would be the SAP HR driver, where clearly some components are still the original DirXML 1.1a code that continues to just work, and the new features are using DirXML Script).

Something that is easier to do in XSLT is this: if you need to dump some specific XML nodes and values into the current document, you could easily add the raw XML into the current document. In DirXML Script, this is a bit more work using the Add XML Element and Append XML text actions.

Calling a Java class or the like is just as simple in DirXML Script now, where you define a namespace. There is a UI for it in iManager or Designer, or you can just type it in by hand in the XML. It goes in the <policy> tag. Then you use an XPATH expression, using the namespace you defined with the correct parameters. It's much the same as how you would do it in XSLT.

What else? Are there any real practical things that can be done only, or better, in XSLT than in DirXML Script?

I would be very interested in seeing examples and a discussion of what else cannot be done. The goal, of course, is to get the answer to be "nothing." This may require Novell to add features to DirXML Script, but since that seems to be their direction already, it may help to identify examples for them.

Disclaimer: As with everything else at Cool Solutions, this content is definitely not supported by Novell (so don't even think of calling Support if you try something and it blows up).

It was contributed by a community member and is published "as is." It seems to have worked for at least one person, and might work for you. But please be sure to test, test, test before you do anything drastic with it.