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

Conditional mapping in an XSLT in WID

In this tutorial we want to map a value only if it is not empty. If it is empty, we want to use another value.

The input data of our datamap will have 2 fields: cban and iban.  If the iban field is empty, use cban.

Drag a connection from the iban field to the bankaccount field (our target). Change the "move" to "if"

Click in the little blue box of your transformation and make sure you see the Properties view of your transformation. In the Condition tab of the properties, enter the following expression:

$iban!= ''

This states this transformation will only be executed if the iban field does not equal an empty string. Now to define the actual transformation, we need to click the "If" in the blue box of the transformation. This will open a new transformation editor, where you can specify that the iban field should be copied tot the  bankaccount field.

Now how  do we add the "else" clause? Hover your mouse over the blue box of our conditional transformation again (you can reach it by clicking XSLTransformation1_req_1 as seen in the screenshot above).

The first icon will create a new condition (else if), the second one an else.  Click on the "else" icon.
You will see a new blue box appearing beneath your "if" box. This new "else" box needs to be connected as well. Connect the icban value to the "else" box, and the "else" box to the bank account. Also create an actual mapping by clicking on the "else" word.

Don't forget to regenerate your XSLT files!

Regenerate xsl resources in WID

As an update to my post about the xsl resources that could not be found, the generation of xsl mapping files seems even more stubborn than I first thought. The xsl file is indeed generated when the map is tested, but it does not change after you change your actual mapping in the editor. If you test the map again, the previously generated file is used. Even at runtime this is the case.

The one way to regenerate the xsl file for sure is to right-click on the mapping editor, and click "Generate XSLT" (or use the keyboard shortcut Ctrl+Shift+G)

Could not find or load xsl resource in WID testing WebSphere ESB component

When testing a mediation component in WebSphere Integration Developer 7 (WID), my xsl transformation failed with this message in the exception trace:

Caused by: com.ibm.wsspi.sibx.mediation.MediationConfigurationException: CWSXM3110E: Exception while initializing the XSL transformation engine with stylesheet 'xslt/MapInput_req_1.xsl'. This has been reported by the following entity: com.ibm.wbiserver.transform.exceptions.TransformServiceConfigurationException: CWSXM3108E: XSLTransform primitive could not find or load the resource 'xslt/MapInput_req_1.xsl'. This has been reported by the following entity: {1}

at com.ibm.ws.sibx.mediation.primitives.util.ExceptionHelper.newMediationConfigurationException(ExceptionHelper.java:96)

at com.ibm.ws.sibx.mediation.primitives.xslt.XSLTMediation.obtainTransformer(XSLTMediation.java:1380)

at com.ibm.ws.sibx.mediation.primitives.xslt.XSLTMediation.init(XSLTMediation.java:574)

at com.ibm.ws.sibx.scax.mediation.component.ESBFlowBuilder.createJavaMediationPrimitive(ESBFlowBuilder.java:1047)

... 54 more

Refer to the server logs for more information.

And in the systemout.log this trace was available:

 

[17/03/11 13:51:57:880 CET] 00000033 MFCImplementa E   CWSXM0202E: An unexpected exception occurred when processing mediation flow for component AuthenticationMediation in module AuthenticationMediation: CWSXM1025E: An unexpected exception occurred when the flow was called: CWSXM0111E:  Service runtime exception calling an import from mediation component AuthenticationMediation in module AuthenticationMediation: CWSXM0206E: An unexpected exception occurred.: com.ibm.ws.sibx.scax.mediation.component.FlowBuildException: CWSXM1007E: Mediation primitive MapToMember in mediation component AuthenticationMediation in module AuthenticationMediation encountered a problem during initialization.

CWSXM3108E: XSLTransform primitive could not find or load the resource 'xslt/MapToMember_res_1.xsl'.

 When opening the project the Enterprise Explorer, I could see that the xsl file was not there for MapToMember_Res_1.map. Normally the xsl file s are generated when building.

Luckily I found a workaround:

I could force WID to generate the xsl file by testing the transformation in the mapping editor of the transformation.

 Hitting the Test Map button (second from the right), made WID generate the xsl file! Sometimes it was not generated. Then I had to really execute the test before the xsl file was generated...

When deploying the module and testing the component, the xsl file was picked up, and the mediation completed successfully. One the problem persisted. The good old remove, restart, re-add of the project gave the final breakthrough.

Publishing failed in WebSphere Integration Developer

When publishing my Module to a brand new created ESB profile in WebSphere Integration Developer (WID), everything runs fine. But hitting the publish button after a change to republish the project was less fun.

"The publish encountered some problems and the application may not have been installed or it may have been successfully installed but was unable to start."
The reason being "Failure uploading archive to server"

I found 2 articles giving a different solution:
This technote 1414552 explains that the hostname verification service should be disabled to make sure the publishing does not mind any unresolved hostnames.


This blogpost on www.soa.si tells you that you can change to hostname in the server configuration, to make the publishing work.

None of the 2 methods worked for me. But thinking about why the hostname could not be resolved, I sudddenly saw the light: I configured a proxy in WID to access the online help system. Adding the hostname of the local machine to the "No Proxy For" list made the publishing successful.
You can find these settings in the preferences screen (window > preferences) in the general section, Network connections.