Really Easy Logging in WebSphere ESB v7.0 with Weakly-Typed Subflows and the Trace Primitive

I’ve been experimenting with the new release of WebSphere ESB and WebSphere Integration Developer – v7.0. David has already done a good job of describing the new features, but we can combine two of them – untyped subflows and the Trace primitive – to create a very powerful and easy-to-use logging feature.

First, we create a new Mediation Subflow. The best practice is to create this in a Business Integration Library so that it can be re-used between different Modules or Mediation Modules – I placed mine in a Library called LoggingSubflowLib. As of V7, by default the terminal types of this are untyped, which means they don’t expect any particular type of message to flow through, and it can be re-used in any mediation flow. In the middle of this subflow, we place one of the new Trace primitives. The subflow then looks like this:

We leave the settings for the Trace primitive at the default:

These default settings mean that it will output the entire SMO (Service Message Object) that flows through the flow/subflow to the server log. On Windows, if you accept all the default paths during install, this can now be found at C:\Program Files\IBM\WID7_WTE\runtimes\bi_v7\profiles\qesb\logs\server1\SystemOut.log – note that this is changed slightly from the V6.2 location.

Now we can create a mediation flow to try out this logging subflow with. For my tests, I created a mediation flow called ConvertCustomer, which converts between two slightly different customer interfaces – a frontend and a backend – using an XSLT mediation in the both the request and the response flow to do the mapping. I then inserted the subflow by simply dragging it from the library onto the mediation flow, and placed it in both the request flow:

and the response flow:

I then tested it with the Integration Test Client in WID, by right-clicking on my Mediation Flow Component and selecting “Test Component in Isolation” (I manually emulated the front-end and the back-end). In the Events sequence, you can see where the interaction passes through the subflow and the Trace primitive, in both the request and response directions:

Looking at the SystemOut.log file, you can see the output:

<Se:smo xmlns:xsi="" xmlns:Se="" xmlns:in="wsdl.http://ConvertCustomerLib/GetCustomerInterface1" xmlns:in_1="http://ConvertCustomerLib/GetCustomerInterface1">
 <body xsi:type="in:getCustomerRequestMsg">
</Se:smo>, 7

<Se:smo xmlns:xsi="" xmlns:Se="" xmlns:in="wsdl.http://ConvertCustomerLib/GetCustomerInterface2" xmlns:in_1="http://ConvertCustomerLib/GetCustomerInterface2">
 <body xsi:type="in:getCustomer_backendResponseMsg">
</Se:smo>, 7

What this now means is that we have a powerful and re-usable subflow that we can place in any mediation flow to do logging. Of course, in this case, this is by itself of only limited value – since we didn’t configure the Trace primitive beyond the defaults, it would be almost as easy just to place the Trace primitive in every mediation flow instead of the Subflow. However, had we done any configuration of the Trace primitive to alter the output location, written our own custom logging logic, or made the subflow more complicated in any way, it would then mean that this development effort only needs to be carried out once.

Very broadly speaking, what the weakly-typed subflows now allow you to do is build your own mediation primitive, very simply (this was always possible, but required some knowledge of the WebSphere ESB SPIs and Eclipse programming). This is an extremely powerful feature.

All of the above also applies to WebSphere Process Server, as it is a functionality superset of WebSphere ESB.


6 Responses to Really Easy Logging in WebSphere ESB v7.0 with Weakly-Typed Subflows and the Trace Primitive

  1. Pingback: Display SMO Contents using Custom Mediations and the BOXMLSerializer « SOA Tips ‘n’ Tricks

  2. Rajesh says:


    could you tell us how to invoke the subflow from within a custom mediation.


  3. Mats Faugli says:


    Have you tried to build a module that contains a subflow with serviceDeploy? We’re using WPS 7fix4, and it doesn’t work.


  4. Bandari says:



    I have a clarification: I would like to persist SOAPMessage instead of SMO Object using Message Logger with Logging type = Database.

    Please advise.

    Thank You

  5. Konrad says:

    Yes very easy but a lot buggi too, under load scenario log not every message.

  6. Sirish SAxena says:

    the problem with this approach is that you will not be able to Disable logs from Admin console if needed. but if you put the Trace primitive directly in Mediation Flow and then make all properties promotable, you can enable disable log from admin console which is very helpful in production.

    I know that Trace is not ideal to put in production and you probably want to create a Centralized logging infrastructure,

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: