"Magic map" in WESB mediation flows

IBM's Integration Designer (I'm using version 7.5.1) has many quirks, which you will soon discover as you start making large and complex mediation flows.

With trial and error I learned that for a certain type of errors, a "magic map" helps. What is this magic map you say? Nothing more than an xsl transformation that moves the root elements to the root elements:

Magic map, sounds nice! Suits well with my flowers and unicorns.

But what kind of errors does it solve then? It seems that after executing an xslt, the esb's internal dataobject representation can go corrupt.

When does this happen? I don't know. Sometimes with simple maps, sometimes complex maps,  sometimes when the message enters the flow and gets deserialized.

How do I know when it happens? Well, let me show you some examples.

Example 1: when you test your component with the integration test client, and you have a fine-grained trace running, you can see the result of each primitive in this "mediation message" window on the right. If you click on a a primitive in your trace, and you are missing an SMO element (context, headers or body), you know something is wrong with the DataObject:

If you try to print the DataObject with a trace primitive, or you do anything else with it that causes serialization, you will get:

CWSXM3154E: Mediation primitive java.lang.RuntimeException: Error serializing BO

Putting a magic map right after the primitive that "looses" one of the SMO's root elements, will fix the DataObject.


Example 2: Take a look at this mediation flow

How simple can it be? The map just moves the input. However, this exception ruins the fun when executing:

CWSXM0202E: An
unexpected exception occurred when processing mediation flow for component
MyService_MED in module mymodule: CWSXM1025E: An unexpected exception occurred
when the flow was called: IXJXE0920E: [ERR API0136] Execution terminated
because of the following error: 'IXJXE0465E: [ERR 0414][ERR XTDE0410] The
result sequence used to construct the content of an element node contains a
namespace node or attribute node named 'xsi:type' that is preceded in the
sequence by a node that is neither a namespace node nor an attribute node.  Attribute and namespace nodes must precede
all other kinds of nodes in the sequence used to construct the content of an
element.; SystemID: xsltcl:/xslt/MyService/myOperation/map_req_1.xsl; Line#:
96; Column# 149'
Refer to the server logs for more information.

Indeed, the input type is actually an abstract type, and an inheriting type should be used. In the xml of the message, xsi:type indicates the instance's "class". Hmm, so somehow the internal representation is wrong? Magic map!

With the magic map the mediation flow works like a charm. Pun not intended.

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.