Troubleshooting IBM WebSphere ESB Development: Cannot retrieve information for class in XSLT

Working on a mediation module in IBM Integration Designer 7.5.1, I was testing my module continuously, and all of the sudden following stacktraces  were showing in the SystemOut.log

[12/02/13 15:10:23:802 CET] 00000047 StaticMethodI W com.ibm.xltxe.rnm1.xylem.instructions.StaticMethodInvocationInstruction typeCheck IXJXE0678E: [ERR 0614] The processor has encountered an internal error condition.  Please report the problem and provide the following information: Cannot retrieve information for class com.blogger.arendatwork.DateTool and method formatDate
java.lang.NullPointerException
at com.ibm.xltxe.rnm1.xylem.instructions.StaticMethodInvocationInstruction.typeCheck(StaticMethodInvocationInstruction.java:443)
at com.ibm.xltxe.rnm1.xylem.instructions.LetBaseInstruction.typeCheck2(LetBaseInstruction.java:245)
at com.ibm.xltxe.rnm1.xylem.instructions.LetBaseInstruction.typeCheck(LetBaseInstruction.java:224)
at com.ibm.xltxe.rnm1.xylem.instructions.ChooseInstruction.typeCheck(ChooseInstruction.java:247)
at com.ibm.xltxe.rnm1.xylem.instructions.LetBaseInstruction.typeCheck2(LetBaseInstruction.java:245)
at com.ibm.xltxe.rnm1.xylem.instructions.LetBaseInstruction.typeCheck(LetBaseInstruction.java:224)
at com.ibm.xltxe.rnm1.xylem.Function.typeCheck(Function.java:485)
at com.ibm.xltxe.rnm1.xylem.Function.ensureTypechecked(Function.java:981)
at com.ibm.xltxe.rnm1.xylem.Function.instantiate(Function.java:772)

Republishing or restarting the server brought no solace.

There was only one xslt map that used the specified java class, so I had a look at that map. 

Trying to test the map using the build in test map function,failed, giving a similar message. Now that I used test map, the compiler finally marked errors in the xslt map file. Turned out that by adding a submap in the map, the editor had deleted the import of the java class. Somehow this gave no errors, and the module could be deployed without problems. At runtime the class could not be found for the mapping, and stacktraces were printed. However, this does not fail your mediation.

It is a good practice to test your xslt mapping locally, this will compile and test your xslt file before deploying, and thus saves a lot of time debugging and troubleshooting the transformation.

Tips and tricks for WebSphere ESB development - Start Your Mediation Flow On Paper

Starting with this article: a new series of tips and tricks for WebSphere ESB development, in Integration designer.

I'm currently working in Integration Designer 7.5 on WebSphere ESB 7.5, in short ID75 en WESB75.

Creating mediation flows in the designer might seem simple when looking at a demo, or following some tutorial. But real life implementations are not always that easy, and ID75 has its own quirks.

So my first tip is about starting your mediation flow. The integration designer in Business integration perspective is a  tool that visualizes your flow, and the pitfall here is that you want to develop straight away. It gets harder and harder along the way, you add some fan outs, need extra variables in your shared and transient context. 

Integration Designer 7.5 does not like it when business object change all the time. Sometimes the changes are "detected" in the visual editors like the xsl transformation primitive or the message element setter primitive, but most of the time ID75 doesn't  recognize the extra fields in the auto-complete, and you are obliged to open the mediation flow in text mode to add the primitive settings to the XML manually.

It helps A LOT to draw your mediation flow ... on a piece of paper, before starting development in ID75. Draw the blocks you have in mind, detect fan outs, recognize where you will need variables in the different contexts.

• A fan out with a service call in it: copy the list over which you iterate to transient context
• If you fan out and need a result of each iteration, copy the result to a shared context variable

• And so on. Implement a few mediation flows, and you will automatically recognize the fields you will need.

Make a list of these variables, create a DataObject for each context in ID75 and add the variables as fields.

Define your context DataObjects in the details properties of the input node, for easy recognition and auto-complete during implementation.

Drawing a flow on paper speeds up your development, you make less mistakes, you have less hassle with ID75 not recognizing added fields, and you will have less rework because you forgot a loop somewhere.