With the release of Novell Identity Manager 3.5 a number of new features were added. Big things like the (Work Order Driver, WorkOrder Details), the Null driver, and engine cache statistics
(Driver Cache Stats in the IDM 3.6 iManager Plugins).

Some more low level features were added, like the Unique Name token (Unique Name Token Functionality in IDM 3.5, Things I think IDM needs support for...), the Time and Convert Time tokens (Using the Time Tokens in IDM 3.5 ), and many more.

One of my favorite tokens that got added (ok fine, I will admit it, if you read any of my other articles it seems all the new tokens are my favorite at the moment I am talking about them, but it is true, I like ALL the new tokens, ALOT! Thank you engine design team! You guys have done some great work!) is the Map token.

You get at the Map token via Argument Builder, when you are trying to build an argument, whether that is a string, a Distinguished name (DN), an integer, or some other value. You need two things available to use the token, a value to provide it as input, and a Mapping table object to read for the resulting output.

Mapping tables being the other half of the new function are another of my favorite new features in Identity Manager 3.5. In the past, we would build large complex structures, or really subtle Regular expressions to try and fork the code so that some with the Location Code of 21, gets a DN of \ACME\EMPLOYEES\NYC\FIN and some one with a Location Code of 22 gets a DN of \ACME\EMPLOYEES\NYC\ACCT. There were many approaches and none of them were truly great.

With a mapping table, you get an object that is a spreadsheet like construct, which can be really useful. Start with the first column with say your location code (call it LocationCode), and then in the second column fill in the DN values you need for placement (call it Path). Then the Map token takes the distinguished name of the Mapping table, the Source column (LocationCode) and then the destination column (Path). Link the Map token to some source of a value, perhaps a Source Attribute of L (Location in Console One) or maybe some custom attribute.

See the image of the Map token's fields as shown by iManager. The Designer view has it looking pretty much the same, the biggest difference is that there is a selection button by the Source and Destination fields to let you select the name of the fields as read from the mapping table.

Click to view.

When you select the Mapping Table to reference, you use an object selection tool, like you would to select a User or Container elsewhere in iManager. This would be the normal way of doing it. Interestingly enough the Map token has an extra option, "Render browsed DN relative to policy" which would change the path from something like TREE\ACME\SERVICES\DriverSet\DriverName\MappingTableName to something like ..\MappingTable

This is actually a very powerful feature, because if you want to move a driver from development or test lab environments to the production environment, you do not have to go in and change the reference to the Mapping table, since the relative reference does not store the value of the tree or container structure.

Another way to have approached this would be to be have used a Global Configuration Value to store the name of the mapping table, but since you potentially would have multiple mapping tables in a project it does not make a great deal of sense to use a GCV for each mapping table you need.

But no need to go that way, since you can just set the Render browsed DN relative to policy option and away you go.