Directory Integrator, Version 7.1.1
The Generic Log Adapter Connector processes log files and transforms them to Common Base Event (CBE) objects, which are then fed into the AssemblyLine.
It uses Generic Log Adapter (GLA) technology, part of IBM®'s Autonomic Computing Toolkit, to process log files and transform their contents into Common Base Event format. The IBM Redbook A Practical Guide to the IBM Autonomic Computing Toolkit contains information on how to configure and use Generic Log Adapter.
An adapter configuration file, prepared externally using the Adapter Configuration Editor Eclipse plug-in is used in conjunction with the Generic Log Adapter Connector. It provides the tooling to create the specific parser rules that are used by the Generic Log Adapter Connector at runtime to create Common Base Event objects, that is, the configuration file contains information about the log file which will be processed. From this file all the CBE objects will be later created. The logic for parsing the objects is also implemented in the adapter configuration file. In the Eclipse GLA plug-in there are several examples of such configuration files, made to process some well known application log files. You can also create your own configuration files using the Eclipse's user interface.
In both cases, either using an already created configuration file or creating a new configuration file, you should note that a specially made outputter called TDIOutputter needs to be configured. This should be done because when the CBE objects are created, the TDIOutputter sends these CBE objects to the Generic Log Adapter Connector (which can then send them into the AssemblyLine using the ordinary mapping mechanism ).
It is not possible to use more than one TDIOutputter. If two or more TDIOutputters are configured in the adapter configuration file an Exception will be thrown when the Generic Log Adapter Connector tries to get the correlation ID from the TDIOutputter. When there is more than one TDIOutputter configured, the Generic Log Adapter Connector which uses the configuration file does not know which of the multiple TDIOutputters to use-- it is not possible to get the CBE Objects from the correct TDIOutputter.
However, it is possible to define more than one outputter as long as it is not a TDIOutputter. For example, you could combine the TDIOutputter with a FileOutputter. This will cause all CBE objects to be sent (and saved) both to a file and to the Generic Log Adapter Connector.
To configure the Generic Log Adapter Connector you must have a valid adapter configuration file. The path to the file must be set in the Connector Config File Path parameter. The configuration file is being checked for validity and if this is not a valid adapter configuration file an Exception will be thrown.
In order to configure the adapter file to use the TDIOutputter you use Eclipse's GLA user interface (the Eclipse GLA plug-in). Below a description of how to configure the outputter using the Eclipse user interface:
To configure the Generic Log Adapter Connector you must have a valid adapter configuration file. The path to the file must be set in the Connector Config File Path parameter.
When the Generic Log Adapter Connector starts, a GLA instance is started in a separate thread inside the Connector. Starting the adapter in a separate thread makes it possible to start iterating through the entries before GLA has completed processing the entire log file. When the Connector receives CBE objects it stores them into a queue, which orders the elements in FIFO (first-in-first-out) manner. When there are no elements in the queue and the Connector wants to take an element from it, it will not return null value but will wait until an element is available (that is, it blocks). On the other side of the queue when it is full and an element needs to be added to it, it will block until there is available space in the queue.
Conditions like end-of-data, GLA adapter errors etc. are handled by special messages in the queue, enabling the Connector to work in the manner expected of a Tivoli® Directory Integrator Connector.
When iterating, CBE objects are read one by one from the queue, and delivered to the Generic Log Adapter Connector. The CBE object itself is stored into an Attribute called "rawCBEObject" of the work Entry. The CBE attributes are also set in the work Entry.
In order to be able to handle the situation when more than one Connector instance is running simultaneously a mechanism to send the correct CBE objects to the correct Generic Log Adapter Connector is required. This is achieved by using a unique correlation ID parameter in the TDIOutputter configuration. Before a Generic Log Adapter Connector starts the adapter configuration file it gets the correlation ID from the TDIOutputter configuration (the Connector actually parses the adapter configuration file). Then it registers it in an internal TDIOutputter table. When the TDIOutputter is ready to send the generated CBE object it gets its correlation ID and takes the Generic Log Adapter Connector which is registered with this ID in the table.
The unprocessed, raw CBE object read from the TDIoutputter queue object is available in the following attribute, ready to be mapped into the work entry:
| Attribute Name | Description |
|---|---|
| $rawCBE | This attribute holds a single CBE object which is a result of the processed application log file. The number of the CBE objects depends on the configuration of the parser in the adapter configuration file. |
The remaining attributes follow the specification as outlined in the output map schema definition in the documentation for the CBE Parser.
The example demonstrating the processing of a DB2 log file, in the TDI_install_dir/examples/glaconnector directory,