Hardening your Integration Solutions

As you've seen, creating AssemblyLines can be a pretty quick business. However, a completed AssemblyLine run does not mean that your solution is ready for 'prime time'. Even simple integration tasks warrant a minimum of both forethought and outcome analysis.

Some pertinent questions to reflect on are:

• Is all source data being processed as expected? How can you confirm this?

• Are anomalies in data content and/or quality detected? Are they handled?

• Does processing affect other data sets, systems or ALs? How?

• Does the integration carry an audit burden?

• Who will be deploying the solution? Who will be using it, and who will administrate it, as well as how?

For long-running AssemblyLines, like those used for synchronizations and to power services, we can tack on additional considerations like availability and fault-tolerance, performance, scalability and security.

The goal of this last chapter is making you aware of these issues, plus a number of Tivoli Directory Integrator features and techniques that we can use to address them.

If you are new to Tivoli Directory Integrator then don't worry if this chapter seems complex and difficult to follow. Instead, come back and re-read these sections as your experience and comfort with the system grows.

• Legibility, re-use and configurability
  All development work requires troubleshooting, maintenance and extension. TDI solutions are no exception.

• Logging and auditing
  TDI uses log4j to provide flexible log management. We can choose between a number of standard Appenders including for Unix syslog, Windows eventlog, daily files and rolling logs. New Appenders can be created or downloaded and used as well.

• Connectivity problems
  Connectivity problems can generally be divided into two categories: initialization errors and lost connections.

• AssemblyLine availability
  Improving AssemblyLine availability means two things: 1) doing what we can to ensure that your AssemblyLines do not stop, and 2) restarting ALs that have stopped as quickly as possible. For scenarios like long-running migrations and synchronizations, restarted AssemblyLines may also need to continue where they left off at the point of failure.

• Scaling and performance
  

• Monitoring
  

• The AssemblyLine Debugger