Thursday, June 20, 2013

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


Monday, April 22, 2013

Encrypt Message Using WS-Security in Websphere 7: InvalidKeyException

I tried to encrypt a soap message using WS-Security with an SSL certificate I got from the service provider.

My runtime is a WebSphere ESB 7.5.1.1 running on WAS 7.0.0.27

After configuring the policy set and the client policy set binding, I couldn't get rid of the following exception when executing the web service client:

Exception:
javax.xml.ws.WebServiceException:
com.ibm.wsspi.wssecurity.core.SoapSecurityException: CWWSS5612E: Encrypting the
data produced the following exception: Wrong length: 162:
java.security.InvalidKeyException: Wrong length: 162 Message: com.ibm.wsspi.wssecurity.core.SoapSecurityException:
CWWSS5612E: Encrypting the data produced the following exception: Wrong length:
162: java.security.InvalidKeyException: Wrong length: 162

After trying a lot of configuration changes (which is very tedious because each change in a policy set or client policy set binding requires a appserver restart), I finally found the cause: in the encrypter configuration I assumed "Data encryption" was the correct setting for encrypting the data of the message, but the infocenter clearly states that "Data encryption" is used for symmetric encryption only.


Changing the setting to "Key encryption" solved the InvalidKeyException!

Information center info about the setting:

Usage of key information reference
This field is available on this panel if you are configuring encryption protection and it specifies that the encryption key information is either data encryption key information or key encryption key information. Select Data encryption for symmetric algorithms and Key encryption for asymmetric algorithms.