Tivoli Directory Integrator, Version 7.1.1

Script Components

The Script Component (SC) is a user-defined block of JavaScript code that you can drop any place in the AssemblyLine data Flow list, alongside your Connectors and Function Components, causing the script code within to be executed for each cycle at this point in the AL workflow.


Unlike Hooks, Script Components are easily moved around in the AssemblyLine flow, making them very powerful tools for everything from debugging to prototyping and implementing your own flow logic. Also, unlike the other types of AL components, the Script does not have any predefined behavior or mode; you can implement behavior and mode with your script. A library of Scripts can be stored under the Scripts library folder in the Config browser.


For example, if you want to test and debug only part of an AssemblyLine, you could put the following code in an SC to limit and control AL flow.
task.dumpEntry( work );

When placed at the appropriate point in the flow of an AssemblyLine, this SC then displays the contents of the work object by writing it to log output and then skip the rest of the AL for this cycle. By moving the SC up and down the component list, you control how much of the AL is actually executed. If you swap out the system.skipEntry() call with system.skipTo("ALComponentName"), you directly pass control to a specific AL Component.

You can also use SCs to drive other components. A typical scenario when doing directory or database synchronization is having to handle both updated and deleted information. Since Connectors powered by the built-in AL workflow can only operate in one mode at a time (Update or Delete) you will need to extend this logic a bit with your own code. One method is to add two Connectors, one in Update mode and one in Delete mode, and then put code in the Before Execute Hook in each Connector's to tell it to skip change operations that it should not handle. For example, in the Before Execute Hook of the Update Connector you would write something like this:
// The LDAP change log contains an attribute called "changeType"
if (work.getString("changeType").equals("delete"))
This will cause your Update mode Connector to skip deleted Entries. You would have complementary code in the Before Execute Hook of your Delete mode Connector, skipping everything but deletes.
However, if you are synchronizing updates to multiple targets, this would require you to have two Connectors per data source. Another approach is to have a single Connector in Passive state that you power from script. As an example, let's say you have a Passive AL Connector called synchIDS. You can then add an SC with the following code to run it:1
if (work.getString("changeType").equals("delete"))
	synchIDS.deleteEntry( work )
   synchIDS.update( work );
As long as you label your SC clearly, indicating that it is running Passive Connectors, this approach will result in shorter AssemblyLines that will be easier to read and maintain. This is an example of having to choose between two best practices: keeping the AL short, and using built-in logic versus custom script. However, in this case the goals of legibility and simplicity are best served by writing a little script.

The Script Component also comes in handy when you want to test logic and script code. Just create an AssemblyLine with a single Script Component in the data Flow list, put in your code and run it.

See Also

Scripting in TDI.
1 Since Passive Connectors are not run by the AL logic, it does not matter where they appear in the Data Flow list.

[ Terms of use | Feedback ]
(C) Copyright IBM Corporation, 2003, 2012. All Rights Reserved.
IBM Tivoli Directory Integrator 7.1.1