Five Tivoli Identity Manager 5.1 Workflow Tips

August 24, 2012

The Tivoli Identity Manager 5.1 workflow engine can be punishing for beginners, so I’ve put together a list of handy hints to get you started. I spent hours banging my head into the desk working some of these out, but at least now you don’t have to!

1. External Script Files for Development

Based on the glorious suggestion from this Stephen Swann’s blog, it’s so much easier to externalise your Javascript nodes during development. It means you don’t need to interact with the workflow editor as much, and you can quickly test your changes. I’ve attached below a sample Javascript function which reads in an external Javascript file from the filesystem, and then executes it.

function externalWorkflow(fileName)
{
   // Systems new line component
   var newLineChar = java.lang.System.getProperty("line.separator");
 // Open the external JavaScript file
    var scriptFile = new java.io.BufferedReader(new java.io.FileReader(fileName));
  var lineOfCode = null; var code = "";
  // Read the file and add each line of code we find to a variable.
  // Needs to append the new line character which the readLine function is removing.
  while ((lineOfCode = scriptFile.readLine()) != null)
    { code += lineOfCode + newLineChar; }
   // Close the file scriptFile.close();
   // Execute the code that we have gathered together
  eval(code);
}
externalWorkflow("D:/Workflows_KE/A20010_parseRequest.js");

2. POJO is the new Black

The IBM JSEngine allows you to access plain old Java objects (POJOs) from within your workflow. This allows you to reuse your existing Java classes with your TIM workflows, and it allows you to access some of the more advanced Java features, such Java XML bindings. It’s important, however, not to use Java as a crutch, particularly if you come from a Java background. It’s sometimes very tempting to jump into banging out Java classes, when the same outcome can be achieved a little differently with a lot less Javascript. With great power comes great responsibility.

3. JS Objects != Java Objects

I learnt this lesson the hard way. Although TIM 5.1 has the ability to interact with Java objects (by referencing them in the scriptframework.properties file), the implementation of the IBM JSEngine appears to have its own “String” object. The following script example, throws a “Script interpreter error” because the IBM JSEngine doesn’t implement the getClass() method:

var example1 = new java.lang.Integer(0);
var example2 = new java.lang.String("Hello");
activity.auditEvent("Integer: " + example1.getClass());

activity.auditEvent("String: " + example2.getClass());

So be careful with your String manipulation, you never know what’s missing.

4. Consistent Logging

One thing that really bugs me (pun intended) when reviewing workflow code, is the inconsistent use of TIMs logging functions. There are two approaches to logging, and both have their place.

Enrole.log() — An error message logged to the msg.log file. Great for detailed technical errors.
Activity.auditEvent() — As the name suggests, a great way of logging audit events which are visible in the GUI. Log events like state changes, and email destinations, not stack traces.

5. Automated Unit Testing

As I mentioned in my previous post, it always pays to automate your workflow unit testing as much as possible. It can be very tedious manually entering a lot of data into TIM, so if you can automate it then you’re a step closer to making your life a lot easier. A lot of TIM developers gloss over this, and it shows when it comes to QA