80 Robust Data Synchronization with IBM Tivoli Directory Integrator
Considering the AssemblyLine mechanisms, no additional effort is required to
integrate multiple servers. Each AssemblyLine is designed to work on different
data. Different AssemblyLines integrate different data sources regardless of
whether these AssemblyLines reside on the same server or on multiple servers.
With AssemblyLine Pool you can build high performance solutions that won’t
incur connection costs to the target systems for each processed event. Also, the
AssemblyLine pool will automatically enable an AssemblyLine to service a
number of simultaneous requests, and not execute the requests serially. You can
configure Pool options from the Show Dialog button next to the Define ALPool
Options on the Config tab of an AssemblyLine as shown in Figure 3-19.
Figure 3-19 AL Pool
The parameters you need to provide are:
Number of prepared instances - How many instances of the Flow part of
this AssemblyLine to instantiate, power up and then keep in the Pool, ready
Maximum concurrent instances - What is the maximum number of current
Flow instances that you want created at any one time.
See the IBM Tivoli Directory Integrator 6.0: Users Guide, SC32-1718 for more
IBM Tivoli Directory Integrator enables you to customize and size logs and
outputs. It relies on
log4j as a logging engine. Log4j is a very flexible framework
Note: pooling is only available if you have a Server mode Connector in the
Feeds section of your AssemblyLine.
Chapter 3. Directory Integrator component structure 81
that lets you send your log output to a variety of different destinations, such as
files, the Windows EventLog, UNIX Syslog, or a combination of these. It is highly
configurable and supports many different types of log appenders and can be
tuned so it suits most needs. It can be a great help when you want to
troubleshoot or debug your solution. In addition to built-in logging, script code can
be added in AssemblyLines to log almost any kind of information. If the logging
functionality will not suffice, then there are additional tracing facilities.
The log scheme for the server (ibmdisrv) is described by the file log4j.properties
and elements of the Config file, while the console window you get when running
from the Config Editor (ibmditk) is governed by the parameters set in
executetask.properties. Logging for the Config Editor program itself is configured
in the file ce-log4j.properties.
You can create your own appenders to be used by the log4j logging engine by
defining them in the log4j.properties file. Additional log4j compliant drivers are
available on the Internet, for example, drivers that can log using JMS or JDBC. In
order to use those, they need to be installed into the IBM Tivoli Directory
Integrator installation jars directory after which appenders can be defined using
those additional drivers in log4j.properties.
Configuring the logging of IBM Tivoli Directory Integrator is done globally using
the files log4j.properties and/or External Properties or specifically, using the
ibmditk tool, for each AssemblyLine, EventHandler, or Config File as a whole.
Logging for individual AssemblyLines and EventHandlers is applied in addition to
any specification done at the Config level.To provide this level of flexibility and
customization, the Java log4j API is used.
All log configuration windows operate in the same way: For each one you can set
up one or more log schemes. These are active at the same time, in addition to
whatever defaults are set in the log4j.properties and executetask.properties files.
In Figure 3-20 on page 82 you can see an example of the Syslog scheme, which
enables IBM Tivoli Directory Integrator to log on UNIX Syslog.
Note: Any of the aforementioned properties files can be located in the
Solutions Directory, in which case the properties listed in these files override
the values in the file in the installation directory.