Logging and auditing

Security Directory Integrator uses log4j to provide flexible log management. We can choose between a number of standard Appenders including for Unix syslog, Windows eventlog, daily files and rolling logs. New Appenders can be created or downloaded and used as well.

By default, only minimal Server logging is enabled. At the very minimum, you should define logging for the AssemblyLines using the FileRoller Appender, writing to the 'logs' sub-folder of your Solution Directory and naming the log-file the same as the AssemblyLine. So for your 'CSV2XML' AL you would define a set of rolling log-files based on this filepath: logs/CSV2XML.log.

Note that the logmsg() method lets you optionally define the log level for your message by passing one of the following keywords as the first argument just prior to your log message: DEBUG, INFO, WARN, ERROR, FATAL. Log levels are inclusive, so WARN will include ERROR and FATAL, and DEBUG means that messages of all levels are logged. For example, a message like:

task.logmsg("DEBUG", "Updated: " + conn);

will only be issued by Appenders set for DEBUG level logging. We can add audit messages to the solution that can be turned on and off from outside a running Server by prefixing calls to task.logmsg() calls with an IF-statement that checks the value of a property. For example, this script snippet might appear in a 'DataFlow - Update Successful' Hook:

if (system.getTDIProperty("MyProps","audit").equalsIgnoreCase("true"))
     task.logmsg("DEBUG", "Updated the following data: " + conn);  

By using the tdisrvctl command-line utility to change the value of the "audit" property in the "MyProps" Property Store, we can dynamically turn this type of audit message on or off for a running Server.

In general, it’s better to log too much information than too little. Although you ought not to flood the log output either. It can be difficult to locate messages of interest in cluttered log output.

Parent topic:

Hardening your Integration Solutions