Directory Integrator, Version 7.1.1

Integrating scripting into your solution

As already explained, you use script whenever you need custom processing in your integration solution. Best practices with IBM® Tivoli® Directory Integrator divide this custom processing into two categories: attribute transformation and flow control.

Note: This is convention, and not a limitation or rule enforced by the system. The need for custom data processing inevitably comes at some identifiable point in the flow of data (for example, before any processing begins, before processing a particular entry, after a failure, and so forth), so by placing your code as close to this point as possible, you can make solutions that are easier to understand and maintain.

The logical place to do the attribute transformations is in your Attribute Maps, both Input and Output. If you need to compute a new attribute that is required by scripted logic or other Connectors downstream in the AssemblyLine, best practice is to do this in an Input Map if possible. Alternatively, if you must transform attributes for the sake of a single output source, then you can avoid cluttering the work entry object with output-specific transformations by putting these in the Output Map. of the relevant Connector.

The other category of custom logic, flow control, is best implemented in the Hooks that are invoked at that point in the automated workflow where the logic is needed. These control points are easily accessed from the Config Editor. Implementing custom processing is simply a matter of identifying the correct control point and adding your script in the appropriate edit window.

AssemblyLine Script Components, independent blocks of scripted code, also provide you with a place to create your own custom processing, and then enable you to reposition your code within the AssemblyLine. Although Script Components are frequently used during test and debugging, they can also serve an important role in a production Config. Just remember to name your components clearly and to include some documentation in the script itself to explain ¹ why you implemented this logic in a Script Component, and not in an Attribute Map or Hook.

While it is important to both correctly identify the appropriate control point where you input your script, it is equally important to limit the scope of your script to cover just the single goal associated with the control point. If you keep your units of logic independent of each other, then there is a greater chance that they will be reusable and less of a chance that they might break when components are reordered or reused in other contexts. One way to build reusable code is by creating your own functions in your Script Library (or a Prolog Hook) to implement frequently used logic, instead of copying and pasting the same code into multiple places.

To sum up some of the best practices that you want to keep in mind while building solutions:

Do attribute manipulation in Attribute Maps.
Put flow control (filtering, validation, branching, and so forth) in Hooks, and where necessary, AssemblyLine script components.
Use the automated behavior as much as possible; for example, AssemblyLine workflow and Connector modes.
Simplify your solution by keeping AssemblyLines short and focused.
Put often used logic in discrete blocks; for example, Scripts in your Resources section.
Think reuse.

It is worth mentioning again that although the methods outlined previously are best practices, you might encounter situations where you have to deviate from established convention. If this is the case, your solution documentation is vital for maintaining and enhancing your work over time.

¹ To others, as well as yourself when you have to revisit your code some time later!

[ Terms of use | Feedback ]

IBM Tivoli Directory Integrator 7.1.1