About the Unique Name Token
With the release of IDM 3.5 we picked up a new really useful token, called "token-unique-name" in DirXML Script. In Argument Builder, it's known as the Unique Name token. This very cleanly solves a problem for which many of us wrote a solution on our own, in many different ways: How do you generate a unique name for new users, so that you avoid naming collisions?
The system-provided token is quite flexible and powerful. Like the Time Token (see the Cool Solutions article), it takes functionality everyone needs and provides a very nice UI on top of it.
You can specify the DN to search within for name collisions, the attribute to search on, the pattern to use for naming (anything you can build in Argument Builder, so very powerful!), and then a fair bit of flexibility in how you use counters.
You get to set the number of counter digits and where to start counting from. For example, you could start at 7 for some reason, so that jsmith exists, and the next one would jsmith7 then jsmith8 and so on, if you really wanted to). There are also many more controls. Overall, I would rate this token very highly and say it is great!
Feature - or Bug
However, I found an interesting feature or bug depending on your perspective. It is admittedly a fairly contrived case, but I can see how it might occur elsewhere.
In this case, we are using the Work Order driver. After the Work Order goes through the shim from the Subscriber channel and comes out as a Work Order To Do on the Publisher channel, we'll convert it (morph) to a User object create before we write it out to eDirectory.
We do a Unique Name token call, as shown below, to set the dest-dn of the new object (currently a DirXML-WorkOrderToDo) with a lot of global configuration values (GCVs) specifying paths in the tree. I highly recomend the use of GCV's. They seem to have little to no performance impact, they save you from typos, and if you decide to re-architect, it is quite easy if all path-to-object references can be changed en masse!
<token-unique-name counter-pattern="last" counter-start="2"
counter-use="fallback" name="CN" on-unavailable="error"
That generates the following event in trace:
[09/25/07 11:02:58.665]:MAGIC-WO PT: Action:
This unravels all the GCV's, gets all the values it needs to query from other objects, and whatnot, it finally generates this Query document to check for uniqueness.
<nds dtdversion="3.5" ndsversion="8.x">
<product version="126.96.36.19970719 ">DirXML</product>
<query class-name="DirXML-WorkToDo" dest-dn="ACMENY\EMPLOYEES"
The kicker is this: note the object class (class-name) that it is searching for! It is a DirXML-WorkToDo object, not a User!
Thus we reach the point of this article. It seems to me that the Unique Name token should allow you to specify the object class you are searching for uniqueness in, or by default, search for all names, regardless of object class.
Why search through all object class types? Well, it seems logical to me - since the token is being used to generate a Unique Name. eDirectory naming allows the same name, multiple times, as long as they are not in the same container. But it does not allow the same name twice in a container, even if they have DIFFERENT object classes! For example, a User named JSmith cannot exist in the same container as a Group named Jsmith or an OU named JSmith. The name needs to be unique within the container.
That is why I think it would make sense by default to search all object classes for uniqueness of naming with this token, unless told otherwise, since that is what would be needed to be truly 'Unique'. I would add the ability to limit it to one or more object classes for performance reasons as well, in cases where the designer knows that will be unique "enough".