Thursday, June 26, 2008

Interesting observation about the erglobalid

Most of the implementations I have worked on do not require a large complicated TIM Organizational structure, however every now and then it is a requirement to have many OUs. In fact you may have a requirement for many thousands of organizational units as bizarre as that might sound. So it's nothing new that you can import these objects. TDI is a handy tool for helping to pull this off by the way. There was a recent post on the developerworks web site about this:

http://www.ibm.com/developerworks/forums/thread.jspa?threadID=201930&tstart=-1

Since I have been on a recent project where we had a need to import several thousand OUs one of the questions we asked ourselves was how do we assign an erglobalid to all of these which we can be sure might not already be in use? One way might be to build in some random generator of our own and lookup to TIM to verify that it is not already in use before we choose that number. Another way we thought well we can just assign a sequential number because it is not likely that TIM will have an obvious pattern especially since we haven't yet put any users into TIM. We tried this method and it worked pretty well so we figure the first erglobalid we will use is say erglobalid=11111111110000000001 and then just increment it from there. No problem so long as we don't happen to stumble on one that is already in use. And if that happens the TDI assembly line bombs out and then we'll have to deal with it.

One of my IBM friends recently discovered that we could actually use any ASCII characters as our erglobalid. I never really gave it much thought, but it is really a string anyhow. Internally TIM will use a numeric string. Apparently TIM will never use any alpha or non-numeric characters in the erglobalid. So if you want to be sure that you generate an erglobalid that is sure to not already be in use, just use letters or something other than numbers. Or maybe even a combination of the two.

Just to try this out I threw together this ldif of two Org units and imported it into my TIM tree no problem:

dn: erglobalid=ABCDEFGHIJKLMNOPQRST,ou=orgChart,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
erparent: erglobalid=2989976714741706113,ou=orgChart,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
erglobalid: ABCDEFGHIJKLMNOPQRST
ou: Fred
objectclass: top
objectclass: organizationalunit
objectclass: erManagedItem
objectclass: erOrgUnitItem

dn: erglobalid=abcdefghi!@#$%^&*()_,ou=orgChart,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
erparent: erglobalid=2989976714741706113,ou=orgChart,erglobalid=00000000000000000000,ou=Largecorp,dc=largecorp,dc=com
erglobalid: abcdefghi!@#$%^&*()_
ou: Barney
objectclass: top
objectclass: organizationalunit
objectclass: erManagedItem
objectclass: erOrgUnitItem



At least if you create your OU's this way you can always tell which erglobalids were created by TIM and which ones were created by your import processes. Just thought this was interesting.