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:
- FileSystem Connector in Iterator mode (XML Parser)
- Loop with a JDBC Connector in Lookup mode
- 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