Introduction

On a current IDM project, identity information from an authoritative source, specifically Given Name, Surname and Full Name attributes was found to be very inconsistent. Some entries were all lower case, some were all upper case and some were Title Case. Whilst arguably merely cosmetic, it was considered desirable to have these attributes set to Title Case in the Identity Vault as the data would ultimately be migrated into AD and be visible within the Global Address Book on an Exchange 2007 installation.

So what is Title Case? In simple terms it is the capitalisation of the first character at a word boundary. In the context of a Full Name, JOHN SMITH is upper case, john smith is lower case and John Smith is Title Case. Easy isn’t it!

What isn’t so easy, or more accurately, what isn’t so elegant, is developing a rule in a policy to reformat an attribute to Title Case. Having been looking for an excuse to investigate ECMA scripting since IDM v3.5.1 was released, this article briefly examines the other methods for achieving Title Case reformatting and fully illustrates how to achieve the same result using ECMA.

It should be noted that the author presupposes the reader has some familiarity with ECMA /Javascript/JScript, Designer and the creation of IDM policy rules.

Title Case using standard IDM verbs

On the Cool Solutions WIKI, there is a code example posted that shows how you can achieve Title Case using nested Replace All verbs. A regular expression detects if a word boundary starts with each letter of the alphabet in turn and replaces it with the upper case version of the character. It requires a preceding action that forces the passed string to lower case.

These constructs are very useful (see an article I wrote on the subject) and prior to the introduction of mapping tables, about the only way to achieve advanced conditional processing in policy rules.

This code works, but the downside is processing efficiency. Try it using the simulator in Designer and have a look at the trace!

Title Case using ECMA scripts

A more efficient approach is to develop an ECMA function and call this function from a policy rule to handle the processing. Lets dive straight in. An simple example ECMA script is shown below:

function toTitleCase(str){
	
	var out;	
	out = String(str).toLowerCase().replace(/\b[a-z]/g, upper);
	
	return String(out);
	
	function upper() {
    		return arguments[0].toUpperCase();
    	}
} 

There’s very little to it as you can see. The core processing is handled by the line …


	out = String(str).toLowerCase().replace(/\b[a-z]/g, upper);

The string that is passed to the function via the variable str is forced to lower case with the toLowerCase() method, which in turn has the word boundaries detected and passed to a nested function upper by the .replace(/\b[a-z]/g, upper) method.

Thus, any string passed to this function will have the first character of each word component capitalised in the returned string.

Note that the regular expression \b[a-z] allows the detection of all word boundaries rather than having to detect each character possibility individually as in the WIKI example.

Calling ECMA script functions from within policy rules

In this script example, the ECMA function toTitleCase() needs to be accessed from within a rule. In the illustration below I have shown this in Designer.

Click to view.

Figure 1 – Policy rule calling an ECMA function

As can be seen, this is performing a reformatting operation on the Surname attribute of User objects. You can also see that the script is called via the XPATH noun. Of interest here are the contents of the argument. Clicking the icon to the right of the field opens the Argument Builder as seen below.

Click to view.

Figure 2 – Configuring an ECMA function call in Argument Builder

If you were to click on the ECMA Expression Builder icon, the Expression Builder dialog is opened as shown in the illustration below.

Click to view.

Figure 3 – Configuring an ECMA Expression Builder

You will note that the functions added to the driver library object are visible, as are the local variables. This dialog effectively builds the call to your function for you by pointing and clicking the required function and variable as can be seen.

For those who prefer, the XML for this rule looks like this:

<rule>
<description>User: Data cleansing - Title Case for 'Surname'</description>
 <conditions>
  <and>
   <if-class-name mode="nocase" op="equal">User</if-class-name>
   <if-op-attr name="Surname" op="available"/>
  </and>
 </conditions>
  <actions>
   <do-reformat-op-attr name="Surname">
    <arg-value type="string">
     <token-xpath expression="es:toTitleCase($current-value)"/>
    </arg-value>
   </do-reformat-op-attr>
  </actions>
</rule>

There you have it. Give it a try for yourselves. As a final note, the more eagle eyed amongst you will have noted a function toCamelCase in my library. For every rule there are exceptions. Scottish surnames beginning with ‘mc’ are generally capitalised again after the ‘c’, so for example ‘Mcbride’ should be ‘McBride’. The more you look at this the more complex it becomes. Some Scottish names beginning with ‘mac’ are again capitalised after the ‘c’, for example ‘MacLeod’, but not all. I developed this function to handle such exceptions such that names such as ‘de La Haye’, ‘de Souza’, ‘van der Root’ are handled correctly as Title Case exceptions

Conclusion

The introduction of ECMA Script support in IDM clearly provides a simple, but no-less powerful way of expanding the built in functionality provided by verbs without having to pass calls to standard Java library functions, or to develop custom Java class libraries to handle more complex requirements.

0 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 50 votes, average: 0.00 out of 5 (0 votes, average: 0.00 out of 5)
You need to be a registered member to rate this post.
Loading...Loading...
Categories: Uncategorized

Disclaimer: As with everything else at NetIQ Cool Solutions, this content is definitely not supported by NetIQ, so Customer Support will not be able to help you if it has any adverse effect on your environment.  It just worked for at least one person, and perhaps it will be useful for you too.  Be sure to test in a non-production environment.

Leave a Reply

Leave a Comment

  • iammi says:

    Hello!

    How about custom IDM Token-Unique-Name?

    I mean I would like to implement this algortithm

    unique_name = Surname+ “-” +Substring(1, GivenName)

    exmaple : if (givenName,Surname)=(Ismail, AMMI) –> unique_name = AMMI-I

    if name already exists we will substring 2 positions, if substring take 3…

    example if (givenName,Surname)=(Imad, AMMI) –> unique_name = AMMI-IM

    And so forth

    The mechaniqme provided by IDM out of the box is incremental. how to implement this algorithm

    Please reply

By: 9556613
Aug 6, 2008
11:46 am
Reads:
1,815
Score:
Unrated