Tips and tricks for WebSphere ESB development - Always use xsl transformations on root level

I'm currently working in Integration Designer 7.5 on WebSphere ESB 7.5

Creating xsl maps I always end up having trouble with xsl transformations that specify a different root path. For example, a transformation with message root  "/context" works fine locally using "test map", but running on the server it fails with this error:

MyService_MED in module mymed: CWSXM1025E: An unexpected exception occurred when the flow was called: 
com.ibm.ws.box.bomodel.impl.BusinessObjectImpl incompatible with com.ibm.websphere.sibx.smobo.ContextType

Remaking the transformation with root "/" solved the issue (no other modifications were made).

New xsl transformation file dialog

 

I had other similar issues with xls transformations on "/body" or "/context" message root level before, so I made it a best practice: always define the root "/" as message root!

Besides, if you only need to modify the context, it is very easy to copy the body element with one move transform statement!

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.