Previous |
Next
The internal Tivoli Directory Integrator architecture is based on a kernel and component design, which is a type of design that there is a central part of the system (kernel) which communicating with the external applications through adaptors (Connectors). The data inside of the kernel of Tivoli Directory Integrator is represented as Java objects and can be manipulated using JavaScript (c). However, because the external applications data can be represented in different types, kernel needs Connectors that will get or put data to or from the external system in a most appropriate type.
The data flow inside the kernel organized as an assembly line, moving data from one Connector to another, defines the sequence of Connectors and how the data is transformed during the process. Inside the assembly lines, data is structured using the Tivoli Directory Integrator object (a Java™ data container) called
work entry. This object holds the data using its attributes and each Connector has a configurable mapping from the source system to the work entry attributes (or just "work attributes").
For example, if you have an HR database and an LDAP server and need to retrieve the job title for all employees form the HR database and place them into the appropriate attribute of the user account inside LDAP, you need two Connectors:
- An LDAP Connector to read and write the data from and to LDAP server.
- JDBC Connector to read data from HR database.
The following figure depicts the data flow.
The first LDAP Connector works in the iterator mode. It goes through all the records in LDAP one by one, get appropriate attribute from user's LDAP object, for example a user ID (UID), might perform some manipulations with it, and then put it into the work entry. The work entry with UID value from an LDAP user account then is moved to the JDBC Connector.
Note: It is important to have an unique ID, which will be the same for the user records in different repositories. This allows to make a "link" between user accounts or person records in different systems. Good examples of such UIDs are: user's e-mail, employee number, or some other unique person record identifier.
The JDBC Connector has to obtain the current employee's job title. It makes a look-up first inside the HR database and find the record according to the value of the user ID (UID) from LDAP. After that, JDBC Connector puts the job title into another attribute of work entry, and then the work entry goes to LDAP Connector. The LDAP Connector on this stage should be configured to use the update mode so that it is be able to find the user record with the same UID attribute value of the current work entry in LDAP server and put the value of the job title attribute into the user object inside the LDAP server. This assembly line stops when the LDAP Connector does an iteration with the last user object in LDAP, produces the last work entry with UID, and have this last work entry goes through the assembly line.
Next steps
Continue with section
4.2 Accessing IBM Connections from a custom Tivoli Directory Integrator assembly line.
Parent topic:
4.0 Tivoli Directory Integrator