As already explained, we use script whenever we 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.
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, we 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 we 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 transform attributes for the sake of a single output source, then we 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 our 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 1 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 the 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 our 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 we want to keep in mind while building solutions:
It is worth mentioning again that although the methods outlined previously are best practices, you might encounter situations where we have to deviate from established convention. If this is the case, the solution documentation is vital for maintaining and enhancing your work over time.
Parent topic: Scripting in TDI
1 To
others, as well as yourself when we have to revisit your code some time later!