An AssemblyLine (AL) is a set of components strung together to move and transform data The AL describes the "route" along which the data will pass. The data handled through that journey is represented as an Entry object. The AssemblyLine works with a single entry at a time on each cycle of the AssemblyLine, with a flow of information from data sources to targets.
Components retrieve data from connected systems and "feed" the AssemblyLine one Entry at a time. Entries carry Attributes with values coming from...
Each entry carries Attributes that hold the data values read from fields or columns in the source system. These Attributes are renamed, reformatted or computed as processing flows from one component to the next in the AssemblyLine. New information can be "joined" from other sources and all or parts of the transformed data can be written to target stores or sent to target systems as desired.
Other components, like Script Components and Functions, can be inserted in the AssemblyLine to perform operations on the data in work.
The AssemblyLine is designed for working with one item at a time. To do multiple updates or deletes, write AssemblyLine scripts. This kind of processing can be implemented using JavaScript, Java libraries and IBM Directory Integrator functionality, such as pooling the data to a sorted data store, for example with the JDBC Connector, and then reading it back and processing it with a second AssemblyLine.
AssemblyLines are built, configured and tested using the IBM Tivoli Directory Integrator Config Editor (CE), see The Configuration Editor for more information. The AssemblyLine has a Data Flow tab in the Config Editor. This is where the list of components that make up this AssemblyLine are kept.
All components in an AssemblyLine are automatically registered as script variables. So if we have a Connector called ReadHRdump then we can access it and its methods directly from script using the ReadHRdump variable. As a result, you will want to name your AssemblyLine components as you would script variables: Use alphanumeric characters only, do not start the name with a number, and do not use special national characters, separators (apart from underscore '_'), white space, and so forth.
There is always an alternative method for accessing an AssemblyLine component (for example, the task.getConnector() function) but a conscious naming convention is always advisable.
Starting an AssemblyLine in TDI is a fairly costly operation, as it involves the creation of a new Java thread and usually sets up connections to one or more data sources. Consider carefully if the solution design could be made to work with fewer, rather than more, distinct AssemblyLines, where each AssemblyLine does more work; for example, by using Branches or Switches to define multiple operations handled by a single AssemblyLine. Note that each operation can still be implemented as a separate AssemblyLine, but these can be embedded "hot-and-ready" into a single AssemblyLine that dispatches work to them by using the AssemblyLine Connector or AssemblyLine Function. This also allows us to leverage features like Global Connector Pools to manage resource usage and boost performance and scalability.
AssemblyLines can include the following components:
Additionally, Connectors can have Parsers configured; also, at System, Config, AssemblyLine, Attribute map and Attribute level there are options to configureNull Behavior.
Each AssemblyLine component is available as a pre-registered script variable with the name you chose for the component.
Note that we can dynamically load components with scripted calls to functions like system.getConnector(), although this is not for inexperienced users.1
There are three ways for data to get into an AssemblyLine:
If we want to start an AssemblyLine with parameters from another AssemblyLine, then we have a couple of options:
These options are provided for compatibility with earlier versions.
Parent topic: General Concepts
1 The Connector object you get from this call is a Connector Interface object, and is the data source specific part of an AssemblyLine Connector. When you change the type of any Connector, you are actually swapping out its data source intelligence (the Connector Interface) which provides the functionality for accessing data on a specific system, service or data store. Most of the functionality of an AssemblyLine Connector, including the attribute maps, Link Criteria and Hooks, is provided by the kernel and is kept intact when you switch Connector types.
2 An Iterator is a shorthand notation of a Connector in Iterator Mode.