CrashTestChix

By Marie Scott and Thomas “Duffbert” Duff

Before we get started with the nuts and bolts of Tivoli Directory Integrator, we figured it might be a good idea to introduce you to many of the concepts and vocabulary you’ll run into when learning about TDI.  That way, when you see terms like “assemblyline”, you‘ll know what is going on.  There’s nothing worse than trying to learn how to use a new technology when you don’t even know what the main terms mean! 

So, you’ve got Domino directories, you’ve got Domino databases, you’ve got data that resides outside of Domino – in say Active Directory, or LDAP, or SQL.  Now what? Well to bring these systems together to merge or update data in either direction, we can use TDI. 

To get started we’re going to build an AssemblyLine – just like a factory assembly line for manufacturing, the AssemblyLine in TDI is used to identify, move, transform, push, pull or synch data between various Data Sources.  

A Data Source is the data system or group of data objects that you are going to connect via the AssemblyLine.   And a Connector acts as your means of setting up a logical connection to the Data Source. 

Connectors use authenticated processes like LDAP, DIIOP, JDBC, AD, etc., that provide dialog boxes for configuring exactly how the Data Source will be accessed.

Within the Data Source are Entries. These are the data objects themselves.  And each entry has Attributes – or sub parts.  Attributes describe and or contain the data values from the various data sources that you’re linking together in the AssemblyLine.  Values are the objects that contain the actual data values that are being stored and transported through the AssemblyLine.

These are batch or event-driven processes that handle the identification, routing, and transformation of data between data sources.  TDI can run any number of these AssemblyLines at any given time.  These AssemblyLines are what the developers and administrators of TDI will put together to accomplish their data needs. [Marie – I think of the AssemblyLine as similar to workflow in Domino.]

Here’s a somewhat oversimplified diagram of the TDI process:

Some more advanced terms include:

EventHandlers – These are actions that are monitored by TDI, and that will trigger an AssemblyLine process.  This might be an LDAP change, a SOAP call, or a calendar event.

Scripting – Scripting languages are used to create AssemblyLine steps that go beyond the built-in functionality provided in TDI.  JavaScript is the language supported in TDI for this function.

Work Entry – an object created by TDI to move data throughout the AssemblyLine process, that is, the process that moves and/or transforms data from one data source to another.

Delta Detection – When a data source has changed and the system needs to figure out what exactly has changed and what needs to be passed to other data sources that should remain synchronized. This is the first of three steps in the Delta operation.

Delta Tagging – Once the Delta Detection has occurred, the data source needs to be annotated to flag exactly what has changed and how it has changed.  This helps the synchronization run efficiently.  It is the second part of the Delta operation.

Delta Application – This reads the Delta Tagging (also known as Operation Codes) and makes the changes to synchronize the data sources. This is the final step in the Delta operation.

Change Detection Connectors – used by TDI to find changes in standard data sources, such as LDAP, Active Directory, SQL databases, and Lotus Notes.

Delta Engine – Used by TDI to compute changes for data sources that don’t flag updates in any other way.  This uses a Snapshot database to track prior values to determine if changes have occurred.

Obviously, there’s far more to TDI than just this.  But if you understand these basic concepts, many things will start to drop into place when you start using TDI to move your own data around.