Novell IDM Entitlement DN & Stylesheets

Entitlements can be a bit quirky in driver policies. Drivers have the ability to add an entitlement from that driver to an object but they don’t have the ability to add a different driver’s entitlement or remove an entitlement through policy. When a situation occurs where entitlements have to be added or removed that can’t be done through policy that’s when you call in stylesheets. Stylesheets are flexible and powerful tools in the driver’s toolbox but they are not as user friendly and require advanced developer knowledge over standard policies.

Entitlements can be a bit quirky in driver policies.  Drivers have the ability to add an entitlement from that driver to an object but they don’t have the ability to add a different driver’s entitlement or remove an entitlement through policy.  When a situation occurs where entitlements have to be added or removed that can’t be done through policy that’s when you call in stylesheets.  Stylesheets are flexible and powerful tools in the driver’s toolbox but they are not as user friendly and require advanced developer knowledge over standard policies.

Stylesheets can suffer from an annoying issue if they contain hard coded object DNs in the XML.  The issue is that when the stylesheet is migrated from one environment to the next the object DN(s) aren’t detected correctly after migration.  I have seen it a number of times where an object DN is the same in a QA and Production environment, the stylesheet tests fine in QA, but when migrated to Production the stylesheet doesn’t execute correctly. And the odd thing is in this situation that when you review the driver logs the DN is correct in both the input doc and the stylesheet.

The quick and dirty fix is just to copy the desired object DN from the input doc in the log, paste it in the stylesheet, and restart the driver.  Even though the values are the same this process corrects the issue and after a driver restart the stylesheet will operate as expected.

There is a better approach to avoid this issue. As with most values, it is better to use variables instead of hard coding values like object DNs in your logic.  The cleaner, more reliable solution is to create a Global Configuration Variable (GCV) on the driver, or driver set depending on your needs, for each of the DNs and then just reference the GCVs in the stylesheets.  This allows the stylesheet to be migrated between environments without risking the DN values should they be different between environments or DN value recognition for hard coded values.

Below is an example of how to reference a GCV in a stylesheet:

<xsl:when test=”(component[@name=’volume’] = ‘~Entitlement_DN_GCV~‘)”>

Notice that the GCV is within the single set of quotes ( ‘ ).  This is a string value so when the GCV is translated to the actual value it will need to be treated as a string.  The key symbol here is the tilde ( ~ ) that encapsulates the GCV name.  This character symbolizes the use of a GCV so the driver engine knows to substitute the GCV name with the value stored in that GCV on the driver or driver set.

And regardless of whether you are using stylesheets or policies it is always better to use GCVs for these types of values and avoid hard coding values.  It just makes life easier.

As always, questions, comments or concerns?  Feel free to reach out to us at IDMWorks.