The Real Time Myth

I was talking to a colleague last week and the topic of real time provisioning came up.  This has always been a bit of an issue with me due to the use of the term "real time"  I've almost always found that by the time we discuss what is involved in the act of provisioning and what the requirements really are, it is impossible to have this happen in "real time".  The fact is provisioning takes time.  Always has, always will.  Writing the information to your authoritative store takes a certain amount of time.  As does provisioning to LDAP.  We know it takes at least 15 minutes for AD to begin replication, and regardless of type of Directory Service used, it takes time to replicate in an international setting.

In my experience most organizations are more concerned with improving performance over the old methodology and getting initial provisioning to happen in less that a day.  There's nothing that irritates a manager more than having to sit around and wait for the new person's accounts to be created.  If we can get that time period down to a reasonable wait, hopefully to about the time it takes to fill out the remaining new hire paperwork, tour the facility, get the briefing from HR and have that welcoming cup of coffee, we will have made progress.

In the best of all possible worlds, provisioning should have already been started as soon as HR receives a signed offer letter.  Creating essential accounts in a a disabled state gets a lot of the heavy lifting done and front loads the whole process. This way all that has to be done is wait for the start date to occur and then enable accounts via a regularly scheduled work flow. However, I recognize that even creating disabled, locked accounts poses something of a risk so it will not be for all organizations. 

In the end careful analysis of current state, target state environments is called for along with a thorough examination of compliance, legal and best practices as they relate to the organization's needs.

SELECTing from the Identity Store

Now I don't know about you, but I've always had some issues with looking up entries in the NetWeaver Identity Management Identity Store. I know there are built in scripting functions like uIS_Get, uIS_GetValue, uIS_sGet, uIS_sGetValue, etc, but they've just never worked well for me. So to compensate, I've developed my own methodology for searching and retrieving items from the Identity Store.

The basic use case is this: The Identity Management solution needs to do a look up between an incoming data feed and the Identity store. The basic idea is that if the value from the feed and the value from the Identity Store match then the entries match and updating/provisioning can proceed as directed by workflow. I'm sure you can imagine other use cases, looking up managers, phone numbers, and other frequently used attributes.

The feed processing job will use a script to evaluate the match. Most likely it will pass MSKEYVALUE but could also use some other unique attribute in the feed.

The first thing that is needed is to determine the MSKEY, if any, for the entry to be worked with. To this end, I created the following query which will be implemented by NW IDM's uSelect function, which can be used in a Provisioning Job or Reconciliation task. Following best practices for NetWeaver Identity Manager, I am using the JAVA engine and therefore JavaScript in this example.

//Create an uppercase version of Par for checking against the SEARCHVALUE
uPar = Par.toUpperCase();

MSKEYQuery = "select mskey from mxiv_sentries where (searchvalue = '" + uPar + "')";
MSKEYResult = UserFunc.uSelect(MSKEYQuery);

You'll notice one of the first things we need to do is make sure we access the searchvalue correctly. Elements in this column always have their text elements stored in Uppercase, so we need to make sure that for the purposes of searching, we have an uppercase value handy. The results of this query are stored in a variable called MSKEYResult. Now that this information is available, we can now search for needed values related to this entry.

EmployeeNumQuery = "select avalue from mxiv_sentries where (mskey=" + MSKEYResult + ") and (AttrName='HR_EMPNUM)";
EmployeeNumResult = UserFunc.uSelect(EmployeeNumQuery );

With this query I can now look for a specific attribute value for a specific user and store it in a variable. At this point we should plan on returning a more nicely formatted version of the attribute so we will return aValue rather than SearchValue which is the value for the attribute as it entered into and subsequently processed by NW IDM for use in screen output, reports, emails, etc. In this example we are returning the user's Employee number.

This process might also include another query to do a count of returned Employee Numbers to protect against potential "dirty data" entries (multiple identities for the user or to many users with the same name.) If this scenario occurs more detailed searching, involving more attributes might be needed.

Note: I don't necessarily claim that this is the best or most efficient methodology for accessing this information. All I know is that it works for me and the way that I think / process information. If anyone has ideas on making this better or properly using the embedded functions listed above, I'd love to hear about it.