"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.