Unique Name Token Functionality in IDM 3.5


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-global-variable name="acmeNewUserHolding"/>
    <token-text xml:space="preserve">\</token-text>
    <token-unique-name counter-pattern="last" counter-start="2"
counter-use="fallback" name="CN" on-unavailable="error"
    <token-global-variable name="acmeParentUserContainer"/>
    <token-substring length="1">
    <token-dest-attr name="acmeFirstName">
    <token-attr name="DirXML-nwoDN"/>
    <token-dest-attr name="acmeLastName">
  <token-attr name="DirXML-nwoDN"/>

That generates the following event in trace:

[09/25/07 11:02:58.665]:MAGIC-WO PT:      Action:
"\" token-unique-name("CN",counter-start="2",scope="subtree",arg-dn
("DirXML-nwoDN")))) token-dest-attr("acmeLastName",arg-dn

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=" ">DirXML</product>
<contact>Novell, Inc.</contact>
<query class-name="DirXML-WorkToDo" dest-dn="ACMENY\EMPLOYEES"
<search-class class-name="DirXML-WorkToDo"/>
<search-attr attr-name="CN">

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".

Updating a very old article, this was fixed in IDM

The DTD update says: Changed <token-unique-name> to allow searching of all objects for unique name construction.

There is a new setting, Test All Objects, which for compatibility defaults to false.  Change it to true as needed.


How To-Best Practice
Comment List
  • I was just working on a IDM 3.0.1 environment and noticed that the Unique Name token existed there. I was sure it was a 3.5 enhancement, so oops on me. Regardless it is an interesting discussion of the token anyway.
  • As you say, it is easy enough to work around. In my case, I moved the Unique Name token call to AFTER we morphed the object class from Work Order To Do to being a User object class.

    I think in one draft of my article I thought I had mentioned that solution. Guess I left it out.

    Also, since the token allows you to specify object class fixing it at least for the limited case is pretty easy.

    I still think that there ought to be a mode/flag/case where Unique Name () looks for ANY object class colliding, because those would really be collisions.

    Your workaround (and mine) is fine for Users class, but what about if you are (for whatever reason) need to set a Unique name in a container full of all sorts of object class objects? Say Groups, Users, and computers. I dunno why you would do that, but you COULD!

    You are back to writing your own with src or destCommandProccessor as the channel requires.

    This is why I think it is something DirXML Script needs to provide support for.
  • I agree that it is weird that it simply uses the current operations class-name for the function call, it's kinda goofy. However - I've done this exact thing and have had problems with it, because it didn't find a colliding user when it executed - due to it being Work-ToDo.

    I was told by IDM developers to set operation class name to user just before the token-unique-name, and then set it back to worktodo at the end (just to be clean) - this caused the token unique name to use the class-name of User for the unique, and fixed by bug!

    What are your thoughts?