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.

8 comments:

z said...

we can also use TIM API to import the OUs. There are a lot of reasons why one should not directly operate on the LDAP level. Just a few of them
1. Audit
2. Workflows
3. Although for sure nobody will change the internal LDAP structure, you newer know what will be in the next release
4. Is it really supported by IBM?

Charles Ahart said...

True the TIM API can also be used. In fact initially I had a use for simply importing some 10,000 OU's because they were a known quantity to me and since it wasn't necessary to do this more than once there was no need to write code.

In another case we desired a method to be reusable many times over in which case it was then better to write a web service which calls the TIM API to create an OU.

There are many things which IBM does not support simply because it is custom, yet they are always willing to help. Obviously best practices should prevail, yet that is not always the real world.

Thom Anderson said...

My English teacher always said that once I know the rules, I am allowed to break them. Some just call it poetic license. There are certain things that are done more efficiently by going directly to the LDAP but there is always a question of what did NOT get done. For example, I often use TDI to add a user to a static role (which is actually a dynamic group from the TDS perspective. This does not reevaluate the role and any formerly disallowed resource will still show that it is disallowed . . . at least until the next reconciliation. You just need to know the rules before breaking them.

BTW, erglobalid generation is documented to be any unique value. IBM uses either 19 or 20 digits, so avoiding a clash is easy. Alternative, one can do a looking use ldap://host:port/suffix??sub?erglobalid=potentially_unique_value to test any value for uniqueness (should get zero hits).

Anonymous said...

As a best practice you should refrain from using non-numeric erGlobalIDs. In later ITIM 4.6 fixpacks and in ITIM 5.0 the reconciliation code was changed to have a smaller memory footprint for all-numeric erGlobalIDs (they're stored as 64-bit numbers instead of strings). Using non-numeric erGlobalIDs requires falling back to the string-only approach. Internally we use your first practice (erglobalid=11111111110000000001 and then just increment it from there) when doing large-scale testing in the lab.

Anonymous said...

bcbs county pharmacy service http://usadrugstoretoday.com/#third future of pharmacy profession [url=http://usadrugstoretoday.com/products/noroxin.htm]noroxin[/url]
mercer school of pharmacy http://usadrugstoretoday.com/products/zestril.htm pharmacy membership [url=http://usadrugstoretoday.com/products/lasix.htm]irvington pharmacy nj[/url]

Anonymous said...

Hi Charles,

I have a doubt regarding ITIM's LDAP directory schema. I searched but I didn't find why there is ou=0 under ou=accounts and ou=people?

Regards,
Riya.

Thom Anderson said...

The ou=0 is an artifact from the early versions of the product where there were multiple hash buckets ou=0, ou=1, . . . ou=n. They probably save 50 cents by not taking more time to cleanup once they decided they no longer needed the hash buckets.

Unknown said...

I am working on a requirement to create a procedure which will add new ou's to ITIM.
(in case of the structure of organization is modified)
What kind of AL do I need to create in TDI? How will it be different from user feed AL?
Please help.