One of the cornerstones of understanding Tivoli Directory Integrator is knowing how data is stored and transported within the system. This is done using an object called an entry. The entry object can be thought of as a "Java bucket" that can hold any number of Attributes: none, one or many.
Attributes are also bucket-like objects in Tivoli Directory Integrator. Each Attribute can contain zero or more values, these being the actual data values that are read from, and written to, connected systems. Attribute values are Java objects as well; they can be strings, integers and timestamps; whatever is needed to match the native type of this data value. A single Attribute can readily hold values of different types. However, the values of a single Attribute will tend to be of the same type in most data sources.
Although this entry-attribute-value paradigm matches nicely to the concept of Lightweight Directory Access Protocol (LDAP) directory entries, this is also how rows in databases are represented inside Tivoli Directory Integrator, as are records in files, IBM Lotus Notes documents and HTTP pages received over the network. All data, from any source that Tivoli Directory Integrator works with, are stored internally as entry objects with Attributes and their values.
Contrary to earlier versions of Tivoli Directory Integrator, from v7.0 hierarchical Entry objects are supported, in the AssemblyLine and by some of the components that can be part of an AssemblyLine. The Entry object is extended to provide several convenient methods for dealing with hierarchical data, although by default, this is hidden and only comes into play if you explicitly enable it, or use it with components that require the hierarchical features. It also implements org.w3c.dom.Document, which makes it the top level Node in the hierarchy. For more information on this, see Working with hierarchical Entry objects.
There are a handful of entry objects that are created and maintained by Tivoli Directory Integrator. The most visible instance is called the Work entry, and it serves as the main data carrier in an AssemblyLine (AL). This is the bucket used to transport data down the AL, passing from one component to the next.
The Work Entry is available for use in scripting through the pre-registered variable work, giving you direct access to the Attributes being handled by an AssemblyLine (and their values). Furthermore, all Attributes carried by the Work entry are displayed in the Config Editor, under the Work Attribute header in the Attribute Maps area in the AssemblyLine Editor window of an AssemblyLine.
There are a number of data objects that reside in AssemblyLines that follow the Entry data model. These are:
Parent topic: General Concepts
1 When the AssemblyLine you are working with is not called with an Initial Work Entry, then the work object is not available until after the Prolog hooks. In the Prolog hooks we can have code as follows:
if (work != null) {
// An Initial work Entry has been provided, we can get values from there
.... some code
} else {
// No initial work Entry has been provided
... some other code
}