Understanding SOAP Action in Mediation Modules

Questions often arise around the SOAPAction header used during Web Service interactions. Despite the name, this is an HTTP header (not a SOAP header) that is sometimes transmitted with SOAP messages to give extra information to the consumer of the service (i.e. the server) about the intention of the Web Service request. The SOAP specification describes the SOAPAction header, but although it gives some examples, leaves the exact usage open to interpretation.

Inside Mediation Modules, the header is used according to these rules:

  • If a SOAPAction header is set in the inbound SOAP request (through a Web Service export), its value will be placed into the /headers/SMOHeader/Action stanza of the Service Message Object (which is used inside the mediation flow to represent the request). Otherwise, the value in /headers/SMOHeader/Action is not set.
  • When an outbound SOAP request is performed (through a dynamic callout, not through a Web Service import), the value placed in /headers/SMOHeader/Action will be used if it is present (so you could set this value, with a Message Element Setter, for example, if you want it to be overridden). Otherwise, it is set to the namespace of your WSDL file, concatenated with the operation name being used – which is a convention frequently used for the contents of SOAPAction: e.g. http://myhost/mynamespace/myoperation.
  • When an outbound SOAP request is performed (through a Web Service import), a soapAction attribute might be specified in the <wsdl:operation>/<soap:operation> section of the Web Service Port WSDL attached to the import. If so, that value will be used as the SOAP Action.

Thanks for Matt Roberts and Jens Engelke for the help with this tip.


Using Message Logger for Lazy Logging in WebSphere ESB and Process Server 6.2

If you’re creating a mediation flow in WebSphere ESB and Process Server 6.2, it’s now even easier to do ‘lazy’ (drop-and-forget) logging for debugging purposes (Note: I’m calling it ‘lazy’ deliberately. I am not suggesting you should do this in a production system – it’s for quick-and-dirty testing).

Simply drop a Message Logger primitive onto the mediation flow, and change the type from ‘Database’ to ‘Custom’:


The default handler, formatter, and filter classes shown will be used to do the logging. This means that files named MessageLogN.log will appear in your system’s temporary folder (on Windows, for example, this is normally C:\Documents and Settings\YourUsername\Local Settings\Temp). These will contain lines like this:

3/9/09 3:08 PM,EBC7634C-011F-4000-E000-02BCC0A80A8A,MessageLogger1,LogTest,<?xml version="1.0" encoding="UTF-8"?>
<body xsi:type="i1:operation1RequestMsg" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:i1="wsdl.http://LogTest/i1" xmlns:i1_1="http://LogTest/i1">
    <input1>some data</input1>

The six fields you see in the comma-delimited line are:

  1. Timestamp
  2. Service Message Object message ID
  3. Mediation primitive name
  4. Module name
  5. Actual message itself – i.e. the Service Message Object serialized as XML.
  6. Service Message Object version

This can be really handy for quickly instrumenting a mediation flow.

If you want to get more sophisticated, you can override the handler, formatter, and filter classes with your own, and in any production system, you’d probably want to do that. This document from the Java documentation explains more.

Understanding the Service Invoke Primitive

I find that folks are sometimes confused by the Service Invoke primitive available in WebSphere ESB Mediation Modules. It’s best to explain this with a bit of history.

In the first two versions of WebSphere ESB (6.0.1 and 6.0.2), only one invocation of a back-end reference (i.e. an import or an outbound adapter) was possible per mediation flow – at least without some custom coding. The part of the mediation flow that is executed before the invocation is done is called the request flow, and looks like this:


The part of the mediation that is executed after the invocation is called the response flow, and looks like this:


The response flow is visible once you’ve dragged the arrow across to define which back-end operation and partner reference is to be used:


However, as of WebSphere ESB 6.1, a Service Invoke primitive was also made available. This allows invocations ‘in-line’ inside a flow. It looks like this:


This means that more than one invocation can be made per mediation flow, by using multiple Service Invoke primitives. However, it is also still possible to use the request and response flows as well. This can lead to confusion, where one of invocations is done via the request/response mechanism, and one or more other invocations via Service Invoke primitives. It’s important to remember that the Service Invoke is essentially the equivalent of the Callout node on the request flow combined with the Callout Response node on the response flow.

In general, I would recommend using either the request / response style of invocation, or the Service Invoke node with no response flow (the response to the original invoker going into the Input Response node on the request flow). If you are determined to mix both, try to make the request / response invocation your ‘primary’ one, conceptually.