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