Processing Multiple Attribute Values with the TDI 7.1 FOR-EACH Attribute Connector

/0 Comments/in , , , , , /by

In previous versions of the IBM TDI product the task of processing a report or directory integration has been a challenge when working with attributes that may have more than one value.

One such example that we see frequently with the ISIM product is the erroles attribute assigned to the ISIM Person record. Luckily with IBM TDI 7.1 we have a new connector type that allows us to easily process these called the FOR-EACH Attribute loop. The following is a demonstration of how this function connector works in a simple report generating TDI.

In this example we will be Iterating all Person records contained in ISIM. The connector looks like this:

image1top

The Search Base & Search Filter should something along the lines of:

image2

(Note: with a Search Filter of (erroles=*) only Person Records that contain at least 1 role will be selected).

The next step is to make use of the FOR-EACH Attribute connector. The iterator has already loaded the work.erroles object which may contain multiple values. This attribute contains the DN of the role assigned to the ISIM Person which we will need to translate into a Role Name (errolename).

We will need to define a Work Attribute Name & a Loop Attribute Name. The Work attribute is the incoming multi-value attribute from the iterator, in this case erroles. The Loop Attribute Name is the single value attribute at the coordinate for the current loop count.

image3

Once this has been defined, we can add connectors below to lookup & then record the data for each pass of the Role Loop. First we do a lookup using the DN of the role (loopRole) to resolve the role’s name (errolename).

image4

image5

Since the work.errolename value will be over-written with each pass of the Role Loop, we will need to store, or write the value to file before finishing the loop & moving on to the next value of erroles. In this example I have inserted a File Connector to write the report as it is being passed through the loop. However there are other options available such as storing the values in an array eg. work.errolename & then looping through them using JavaScript in a connector further on in the TDI.

image6

Tivoli Directory Integrator – Before Initialize – Add Date to File Name

/0 Comments/in , , , , /by

I wrote a different TDI blog discussing the Before Initialize Hook.  That blog discussed setting the filter in an Iterator.  Here is another use for the Before Initialize Hook, this time in a File System Connector.  As I mentioned in prior PathMaker Group blogs Tivoli Directory Integrator (TDI) is a pretty neat tool that comes packaged with IBM Tivoli Identity Manager (ITIM) with a bunch of Connectors. This blog will relate to the File System Connector.

Have you ever wanted to build create a File System Connector that creates a file that has a unique value so the process can run multiple times a day or week and you don’t have to worry about overlaying the file?  This can be accomplished with the Before Initialize.  In this case the process will only run once a day so only the date is added to the end of the file name. Read more

TDI Null Entries

/0 Comments/in , , , /by

Tivoli Directory Integrator is a powerful tool that we often use as part of an ITIM migration or rollout. What makes it great is its unique ability to translate data from one source of almost any type into another. It really doesn’t matter if you’re using something as a primitive XLS maintained manually by HR or a complex set of relational databases. TDI can get the data, do any number of out of the box or even custom translations that are necessary to get your data into the form you want it.

Through this data “smoothing” process there will inevitably be some odd-ball data that you find. Whether it is a random string value when you expected a Boolean true/false or a legacy attribute that’s only assigned to 25% of the objects you’re migrating.

And then there’s the “null” entry, which will come up often as well. Null values are pesky because we don’t always know why they’re there, sometimes it’s important that the attribute is moved over whether there is a value assigned or not. Other times we want to clean up our data while we’re moving it, and pull out all any attributes assigned with no value. Luckily for us, TDI has a feature built in to assist with this. Read more

Tivoli Directory Integrator – Before Initialize

/2 Comments/in , /by

As I mentioned in prior PathMaker Group blogs Tivoli Directory Integrator (TDI) is a pretty neat tool that comes packaged with IBM Tivoli Identity Manager (ITIM).  TDI comes out of the box with a multitude of connectors that are used to as the name says, connect to different sources.  One of the most common business processes where TDI is used is to extract data, transform the data and then load the data into different data source (ETL).  For an example, it is common to use TDI to extract account data from Active Directory using an LDAP connector.

Have you ever wanted to build a dynamic iterator filter that can be created when the assembly line is executed?  In the following example the assembly line uses an LDAP connector to iterate Active Directory.  The requirement is to find AD accounts where the “whenChanged” is in the last 5 days and AD entry should be a user account or a user contact and have a mail attribute.
Read more

Tivoli Directory Integrator – On Multiple Entries

/1 Comment/in , , /by

Tivoli Directory Integrator (TDI) is a pretty neat tool that comes packaged with IBM Tivoli Identity Manager (ITIM).  TDI comes out to the box with a multitude of connectors that are used to as the name says, connect to different sources.  One of the most common business processes where TDI is used is to extract data, transform the data and then load the data into different data source (ETL).  For an example, it is common to use TDI to extract Human Resources data and using a DMSL connector, send the data over to the ITIM Application for processing.

One of the main considerations in extracting data from different sources is the data.  The data values, the data relationships and attributes do not always exist as advertised.

For example:  The process pulls the employee information from SAP and then does a lookup to Active Directory using the employee number.  Active Directory is only supposed to have one entry for each employee.  “Supposed to” is the key word.  In some cases, there are multiple AD accounts for one employee. Read more