Novell IdM Local Variables

This is a post that is really going to make sense only to those of you who work with building policies with Novell's Identity Manager system. I ran into this problem recently, and wanted to get it out into the ether in case others run into the same issue.

In Novell policies, it is possible to create local variables. One typically uses these local variables in order to temporarily store information about a user. There are two different types of scope that you can use: policy or driver.

The policy scope I was already well versed with. It is available to any other rule within the policy, allowing you to transfer information from one rule to the other.

The driver scoped local variable was, I assumed, a way to transfer information between policies about a particular transaction. What I have discovered, though, is that driver scoped means that the variable remains set for as long as the driver is running, across all transactions.

This came to bite me due to how I was using the variable. Inside of the Create Rule, I was setting a local variable "genCN", which is a generated CN value. I was then setting this to be the default value for the CN attribute. Note that I was not setting the Operation Attribute CN, but rather the default value for CN - thus I can not access Operation Attribute CN later in the transaction.

Later, in the Command Rule, I needed access to "genCN" if it had been set earlier. So I did an if local variable is set call, expecting that for updates the genCN would not be set, and I would need to query the meta tree to obtain the object's CN. Come to find out, though, that I was picking up a CN value from that local variable when an object was being updated - but unfortunately for me it had the value of a prevous entry's CN. Oops.

Why in the world driver-scoped local variables would function like that, I have no idea. They basically now take on the role of GCVs that you can update dynamically. Furthermore, there is no way to pass information about a particular transaction from one policy to another, unless you are sure to be setting that variable each time through the driver.

Oh well, such is a Novell user's life, I suppose. I was able to come up with a work around for my issue, and no harm done. Basically, I just added a policy at the front of my driver that sets that local variable to an empty string, and instead of doing an is set check, I do a check that it is not equal to empty string. Just wanted to throw this out there in case anybody else was having a similar issue.