Limiting the damage when an AssemblyLine goes wrong

By default, AssemblyLines stop when an error occurs. However, if you have put code into an error-hook to improve the error report or to attempt to recover from the error, then the line is likely to continue and try to process more entries. If your error-handling is less then perfect, this can do a lot of damage!

A lot comes down to AL design. One technique is to use Branches and Loops in order to control the flow. For example, take the example of a line that is reading data from an XML file, joining additional information from DB2 and writing the aggregated entry to TDS. TDS is only to be updated if the lookup in DB2 is successful. The logic of the AL is:

For-each Entry in the XML File, if a match is found in DB2 then Write to TDS

This can be expressed directly in an AssemblyLine with the following three components:

1. FileSystem Connector in Iterator mode (XML Parser)
2. Loop with a JDBC Connector in Lookup mode
3. LDAP Connector in AddOnly or Update mode

The Connector-based Loop will cycle once for each entry returned in the Lookup. If none are returned, the Loop does nothing. Note that TDI v.6.0 FP2 does not call the On Multiple Found Hook for Connectors in Loops, so if you need to safeguard against this you will need to do so by counting cycles in script code.

You can also check for the existence of the error object that is created when an exception occurs -- either TDI internal or an error in a connected system. This is easily done in the script for a Branch:

try {
   ret.value = (error != null);
} catch (e) {
   ret.value = true;
}

Since the script variable error may not exist, a try-catch block is used to swallow this possible exception.

Another way to limit the damage done by runaway AssemblyLines is to set an AL Config parameter to stop the line after a certain number of errors. This is done in the AssemblyLine's Config tab.

In the same tab, you can also place a limit on the number of items that will be processed by the line before it stops: the Max number of Reads (Iterator) parameter. This can be particularly useful when testing a line that will process many thousands of entries.

-- AndrewFindlay - 07 Nov 2005

-- EddieHartman - 07 Nov 2005