Features that enable implementation of a TDI Adapter

We shall look a little deeper at the features that are utilized to create and use Adapters. Most of these features are not developed specifically for the Adapter concept, so they have many use cases for non-Adapter use as well.

AL Operations

Any number of operations can be defined in an AssemblyLine. They are similar to the pre-7.0 call-return schema of the AssemblyLine (this is now the so-called "Default" operation), but any number of operations can now be created. When AL's are called/executed through the API, from script, from the AssemblyLine FC, or from the AssemblyLine Connector, an operation may now be specified along with the required attributes for that operation. At run-time, the AssemblyLine will know what operation has been invoked; this can be queried, and the flow inside the AssemblyLine can be adjusted accordingly.

When you define operations for an AssemblyLine, then unless you also define a "Default" operation, you are now obliged to invoke the AssemblyLine specifying an explicit operation, otherwise the AssemblyLine will throw an exception.

These operations provide the entry points for the AssemblyLine Connector (described below in the section Using an Adapter in your AssemblyLine) to view and treat the Adapter as a Connector. The entry points are the same as when developing a Connector in Java or JavaScript, and are described in Appendix E. Implementing our own Components in Java as well as in a table in the section Mapping Adapter operations to Connector modes. For example, if the Adapter developer only wants to implement the "lookup" mode, then it's only necessary to implement the "findEntry" operation. More details are found in section The use of operations in a TDI Adapter below.

Switch/case component

The Switch component is an AssemblyLine component that is similar to switch constructs in traditional development languages. Basically, it's a variant of the If-ElseIf-ElseIf component. Within the Switch component, a number of Case's are defined that contain the AssemblyLine components to be executed when the Switch statement matches the value of the case. One benefit of the Switch component is that it can automatically populate the case statements based on the AssemblyLine operations that have been defined. That way one can easily ensure that code is implemented for all of the operations that have been defined.

Flexible connector initialization

In older versions of TDI, all Connectors in an AssemblyLine got initialized during the AssemblyLine initialization phase. Dynamic configuration of a connector usually required termination of a connection, modification of the connection parameters, and then a re-establishment of the connection - all through script. The alternative was to establish and use the connector solely through script.

In the current version of TDI, Connectors can optionally initialize:

On demand

Affectionately knows as "lazy". The connection is established not at AssemblyLine initialization, but as control the first time actually passes to this connector during the AssemblyLine execution phase (Flow). This means that a complex AssemblyLine will only initialize the connectors that are actually used.

Every time

The Connector initializes every time as control is passed to it. This is useful when the connection parameters (such as a file name or LDAP credentials) are part of the information passed into each call to the Adapter. A separate benefit is that this capability is also helpful when using pooled connectors, as "every time" will result in acquiring a connector instance from the pool at run-time, and then released after use. In essence, this implements a "shared/re-use" connector pool across AL's.

When config has changed

The Connection is re-initialized if the config parameters (or evaluations of parameter substitution) have changed since the previous initialization of the Connector. With the parameter substitution feature, connectors can be dynamically configured much easier than before. This facilitates changing the connection parameters of a connector - and forcing re-connection - from both inside the AssemblyLine as well as outside. For example, another AL, or a command-line modification of properties can result in an AssemblyLine automatically re-connecting to its targets with little effort.

Using an Iterator in Flow

Iterators have previously only been used in the Feed section to drive the entire AssemblyLine cycle, or within the Flow to power a Loop component. Now an iterator can be placed in the Flow itself to facilitate implementing Iterator mode in an Adapter. To understand this, a short review of how the iterator works is in order. First selectEntries() of a Connector (or for Adapters, the selectEntries operation as described below in "The use of operations in a TDI Adapter"), is called to create the result set, then getNextEntry() is called to read from the result set until it's empty. By limiting iterators to the Feed section, it would be very impractical to implement a getNextEntry operation that returned the next record from an iterator Connector in your Adapter. With an iterator in the Flow, your getNextEntry operation could utilize an iterator connector and make life a lot easier.

Packing an Adapter for consumption

The goal, in the scenario depicted in the introduction, would be to help Anne package her Adapter component and publish it for others to consume.

When the Adapter has been developed, the Publish command in the TDI development environment creates a Package of Anne's AssemblyLine. Publishing an AssemblyLine means resolving all inheritance and dependencies between the Adapter AssemblyLine and the rest of Anne's development environment. The Package consists of a standard stand-alone config XML file that only contains the Adapter code that can be sent to other TDI developers for inclusion in their resource library (more below).

The package can be saved anywhere, but the default location is the packages directory in Anne's TDI solution directory. When the Adapter is published, it shows up in the Adapter section of the resources library, in the connector list as an available connector, and can also be queried from the AssemblyLine Connector (see section Using an Adapter in your AssemblyLine).

At this stage you might be a bit confused about the difference between a Package and an Adapter. Basically, Adapters are Packages that are intended to be used as Connectors. Other Packages might just contain ALs that can be called with the AssemblyLine FC or other mechanism to run an AssemblyLine.

Using an Adapter in your AssemblyLine

The goal is to provide the interfacing mechanism so that Pete can utilize Anne's Adapter in his own AL's as any other Connector.

There are a number of mechanisms available when calling an AssemblyLine from another AssemblyLine. However, when an AssemblyLine has been developed as an Adapter, then the primary mechanism to use is the AssemblyLine Connector (AL Connector). This Connector can deal with Adapter-style ALs. In older versions (6.0 and earlier) of TDI, it could only be used to iterate on the output of another AssemblyLine. Currently, when the AssemblyLine Connector is used in an AssemblyLine, it is configured by specifying what Adapter it should call. The target Adapter is then inspected for operations, and that determines what Connector modes are made available to the developer.

As a convenience feature, TDI automatically wraps all Adapters so that they look like connectors in the connector list. Pete can therefore choose to insert an Adapter directly from his connector list, or can insert an AssemblyLine Connector and then specify the desired Adapter to call.

The configuration of the Adapter is done in the usual Connector config panel. All parameters displayed here are defined in the schema of the reserved operation "$initialization" of the Adapter. This provides the TDI developer with a mechanism to send configuration parameters to the Adapter for dynamic configuration of its Connectors.

The Flexible connector initialization is useful here, in that it can be used both in the AssemblyLine that calls the Adapter, as well as in the Adapter itself. Using "on demand" or "every time" initialization of the Adapter, the calling AssemblyLine can use information retrieved during its execution phase to configure the Adapter, rather than having to pre-configure this through more static mechanisms.