TDI Null Entries

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.

First thing you’ll want to do is assign the assembly line default behavior for Null Value Entries. You do this by opening your assembly line, then selecting Options -> AssemblyLine Settings & Scrolling down to “Null Value Behavior”.

This will pull up the options for “Null Behavior”. We have two columns: The action to take (behavior) & the definition of what is considered a null.

“Default Behavior” here, is the default for TDI which is to return an empty string which would be copied to the work object. This will result in the new data source receiving the attribute with no value and this is what I usually try to avoid. I normally select the “Delete attribute” option. Don’t worry; this is not as scary as it sounds! It won’t delete the attribute out of your schema, what it actually does is removes it from the object you’re working with. Be aware though, this will only work on attributes that are marked as optional for your object class in the schema. Required attributes cannot be deleted in this way & will error out in TDI.

For the “Definition of null” column, I usually select “Empty attribute (plus above)”. This will cover attributes with the null value & attributes with a blank value. The stricter option of “Single empty string or null value (plus above)” will include multi value attributes with a blank/null in any of the value “slots”. Always be mindful of what’s being defined as null, it’s a good exercise to enable detailed logging & verify that attributes you expect to come through aren’t being marked as null instead.

Finally, one more powerful feature in TDI is the ability to set null behavior on specific mappings. We can do this in any iterate, lookup or update component but I think it’s best to get it out of the way as soon as you bring the attribute in. That way custom script won’t cause problems further down in your TDI & you won’t forget about it. To do this, right click on the mapping you have in mind & select Null Behavior. Here, the default behavior will be the assembly line null value settings we just set.