Posts
- Error handling
- Log handling
- Auto-reconnect
task.dumpEntry(error);
The 'error' Entry holds a number of Attributes that indicate the error message and exception class, as well as where and when the error occurred. The 'exception' Attribute of the 'error' Entry is the Java exception itself, and you can print out the stacktrace using script like this:
var sw;
var pw;
var ex = error.getObject('exception');
if (ex != null) {
try {
sw = java.io.StringWriter();
pw = java.io.PrintWriter(sw);
ex.printStackTrace(pw);
pw.close();
} catch (ex2) {
var sw = ex
}
task.logmsg("ERROR", sw.toString());
Note also that if you enable Error Hooks then execution will continue in the AssemblyLine as if nothing had occurred. So you will want to deal with the error yourself, for example by issuing a call like system.exitFlow() to stop the current cycle, or system.skipEntry() to pass control to the Feed Iterator in order to read the next entry. Or you may wish to re-throw the exception in some situations:
throw error.getObject('exception');
Log Handling means making conscious decisions about how your ALs perform logging. Of course all log messages are added to the TDI Server's logfile (ibmdi.log). However, this can make it difficult to find and isolate messages, particularly if your solution has several AssemblyLines. Instead each AL should likely have its own log. My favorite LogAppender is the FileRollerAppender, which maintains a set of historical log files, rolling these by appending a number to the file extension each time the AL is run.
You may also want to provide a couple of log files for each AssemblyLine - one Appender set to log at INFO or DEBUG LEVEL, while another that only captures error messages - e.g. by setting the LogAppender level to WARN, which will include WARN, ERROR and FATAL.
I typically have my own scripted log() function that includes information about where in my solution the logging is taking place.
function log(lvl, msg) {
var toConsole = false;
if (typeof lvl === 'undefined') { // if no arguments
lvl = 'INFO';
}
if (typeof msg === 'undefined') { // if only one argument
msg = lvl;
lvl = 'INFO';
}
// In case the log level is not in uppercase
lvl = lvl.trim().toUpperCase();
// CONSOLE level = print to console
if (lvl.startsWith('CON')) { // 'CONSOLE' log message
toConsole = true;
lvl = 'INFO';
}
// All error messages also go to the console
if ('WARN'.equals(lvl) || 'ERROR'.equals(lvl) ||
'FATAL'.equals(lvl)) {
toConsole = true;
}
// Now to determine where log was called from.
// First get the AL name
var where = '[' + task.getShortName();
// Afterwards comes the current component (if not an AL Hook)
try {
var compName = thisComponent.getName();
where += '/' + compName;
} catch (ex) {
// was not in an AL component
}
// Now add the Hook name (if inside a Hook)
try {
var hookName = thisScriptObject.HookName.getValue();
where += '/' + hookName;
} catch (ex) {
// was not in a Hook
}
// Log the message
task.logmsg(lvl, where + '] ' + msg);
// Print some messages to console as well
if (toConsole) {
java.lang.System.out.println(lvl + " - " + msg);
}
}
I have this function defined in a Resources > Scripts Script that is tagged to be implicitly included for all ALs.
Finally, Auto-Reconnect is a feature of Connectors and Function components found in the Connection Errors tab. Here you enable the reconnect feature typically only for when a connection is lost. The Number of Retries parameter is set to an adequate value, with the Delay Between Retries in seconds. In this way, if the connection goes down then the component can attempt to reconnect and then continue.
Note that the Reconnect rules must be set for this component. If you don't see built-in rules here then you will need to define your own, as described here.
