Logging in IBM Directory Integrator

Introduction

I've been creating a bunch of AssemblyLines in IDI/TDI/ISVDI recently, and wanted to share a trick to help you set up logging to a file whose path includes BOTH the name of the project and the name of the AssemblyLine.

Quick and Dirty

1. In the Log Settings for the AL, make sure to add a log. I prefer FileRollerAppender, but you choose whatever you want. 

2. Click on File Path and set it to Advanced (JavaScript)

3. Set the value to the following:

var logName = "TOBEREPLACEDATRUNTIME";

try {

    logName = task.getParent().getName() + "/" + task.getShortName();

} catch(e) {}

return "/opt/IBM/TDI/logs/" + logName + ".log";

4. Click OK and you're ready to go. The logfile for the AL will be:

/opt/IBM/TDI/logs/project_name/AL_name.log

Longer and More Details

The Quick and Dirty section above is for advanced/experienced users who have been working with the product for a while and have been beating their heads against a wall trying to find this solution (maybe a handful of people out there). This section is for everyone else.

Background

IDI has tons and tons and tons of logging options. So many, in fact, that most customers will just stick with the default, which logs everything to ibmdi.log, which can make life difficult because all ALs are logged in the exact same file, with their messages intertwined. There can absolutely be benefits to that (i if you're using something like Splunk for centralized log storage, for example). To me, it's much easier to have a different log file for each AssemblyLine. And because you can easily end up with hundreds of ALs in your implementation, it makes sense to me to have one directory per Project, just to make it easier to work through the directory structure.

Walkthrough

Here's an animated GIF walking you through the process of adding a log to an AL, then configuring that log to have a name that includes the project and AL name.

Explanation

There are a couple of interesting parts that I think deserve a little more detail.

try/catch

Without the try/catch block in the code, you'll see an error when going to edit the logger, like this:

This is true for any form element in IDI that you implement as JavaScript. If you reference the task or work or conn objects, you'll get a big red error similar to the one above. That's why I first declare the variable logName with a string value. Then inside the try block, I set it to the value I want to see at runtime. The catch block does nothing, but syntactically it's required.

getParent()

So where did I find the getParent() method of the task object? It's in the API javadocs, which you can find on your own system in YOUR_TDI_INSTALLDIR/api or you can find them online here. The task object is described in the AssemblyLine class (com.ibm.di.server.AssemblyLine specifically; there is another one named AssemblyLine, but it is com.ibm.di.api.jmx.mbeans.AssemblyLine, which is not the same). 

Why did you change the Pattern for the logger?

I removed "[%c]" from the pattern because this information takes up a TON of visual space and is 100% unnecessary when using a different log file for each AL. 

What to do next?

So here's a bonus strategy that can save you a lot of time as you create new ALs. Set this for all of your existing ALs (or at least those for which it makes sense). Then, when you copy any AL, the log will already be dynamically set for you in your new AL. In my experience, this is extremely useful because I end up creating quite a few "utility" ALs for performing one-off operations. I always start by copying an existing AL, then giving it a new name and modifying it as appropriate for the task at hand. I generally keep these utility ALs in a single project named something like "CLIENT_NAME_Utilities".

Comments

In every one of my ALs, I enable the Prolog - Before Init hook specifically as the place where I provide some documentation for the AL for the next sucker developer that comes along and has to maintain it.

Parting thoughts

If you got something out of this, please share the link to get it more exposure.