Display SMO Contents using Custom Mediations and the BOXMLSerializer

Updated 2010-01-15: There is now a better way of doing this in WebSphere v7 and above.

Updated 2007-08-28: incorporated Art’s suggestion, which makes the code simpler.

Sometimes you might want to display the contents of a message that’s being processed in a WebSphere ESB mediation flow. One option is to use the Message Logger mediation. However, this has some limitations: it can only log to a database, and by default, this is an embedded Cloudscape database, which is hard to access whilst the server is running. The WebSphere Integration Developer debugger is another option, but this isn’t always suitable if you want to do this repeatedly.

Often, a lighter-weight way is to use the BOXMLSerializer class inside a custom mediation. This enables you to serialize the entire Service Message Object (which contains the body of your message, the headers, and so on) that is being processed in the flow, and output it as XML. This also has the advantage of clearly illustrating the structure of the SMO. Here’s some example code that you could put in a method inside a custom mediation to do exactly that (you’ll probably want to do this using the ‘Invoke’ method to invoke an external Java SCA component, although you could use the ‘Java’ snippet method instead):

public DataObject mediate(
        DataObject input1) {
    BOFactory factoryService = (BOFactory)
            new ServiceManager()
            .locateService
            ("com/ibm/websphere/bo/BOFactory");
    BOXMLSerializer xmlSerializerService
             = (BOXMLSerializer) new ServiceManager()
            .locateService
            ("com/ibm/websphere/bo/BOXMLSerializer");
    try {
        xmlSerializerService
                .writeDataObject(
                        input1,
                        input1.getType().getURI(),
                        "",
                        System.out);
    } catch (IOException e) {
        e.printStackTrace();
    }

    return input1;
}

The code above prints the contents of the SMO onto standard out – which should appear in the SystemOut.log file for your WebSphere ESB and in the Console view of Websphere Integration Developer. The SMO will look something like this:

<?xml version="1.0" encoding="UTF-8"?>
<ServiceMessageObject:ServiceMessageObject
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ServiceMessageObject=
      "http://www.ibm.com/websphere/sibx/smo/v6.0.1"
    xmlns:info="http://mm1/getPartInfo">
    <context />
    <headers>
        <SMOHeader>
            <MessageUUID>
                BE73C754-0112-4000-E000-61EE09B4A5D7
            </MessageUUID>
            <Version>
                <Version>6</Version>
                <Release>0</Release>
                <Modification>2</Modification>
            </Version>
            <MessageType>Request</MessageType>
        </SMOHeader>
    </headers>
    <body xsi:type="info:operation1RequestMsg">
        <operation1>
            <partNumber>23</partNumber>
        </operation1>
    </body>
</ServiceMessageObject:ServiceMessageObject>

You can see in the SMO above both the headers and the body, and the operation name defined by the interface I was using (operation1), as well the data structure I was using (which was just a single integer called partNumber).

This trick can be very useful for problem diagnosis, or just to keep an eye on what’s going on.

Advertisements

8 Responses to Display SMO Contents using Custom Mediations and the BOXMLSerializer

  1. Art says:

    The tricky part with the namespace can be solved using the following in stead of the literal namespace: input.getType().getURI(). In the same way you can get the root element using input.getType().getName(). This way it is very easy to create a reusable static utility method to dump any data object.

  2. Phil Fritz says:

    Have you tried using the Tivoli Custom Mediations in ITCAM for SOA? You can use these to log the entire message, just the header or just the body, and view the results on the Eclipse-based Web Services Navigator tool provided by the product.

  3. Art, thanks. That’s a helpful pointer.

  4. Pingback: Displaying BO/SMO contents in WebSphere ESB 6.1 « SOA Tips ‘n’ Tricks

  5. Amir says:

    Hi All,
    I am using this method to display the SDO contents. However, I do not see the WS-Addressing tags (To,From, Action etc.)
    The message gets printed out prior to this method via JMS MDB generic print out (as soon as its picked up by the Listener object) and all WS-Addressing tags are there in the incoming message. This method worked fine in WPS 6.0.2.5 but its not working in WPS 6.1. I am running this in a Test server within WID 6.1.
    Thanks for your help.

  6. @Amir,

    Unfortunately, accessing WS-Addressing headers in a mediation is not supported directly (with version 6.1), as they are normally accessed by the Web Services code itself, and handled there.

    If you definitely do need to get access, you could try this trick:

    https://soatipsntricks.wordpress.com/2008/09/09/accessing-ws-addressing-headers-inside-a-mediation-flow/

    Understand it’s not a supported technique.

    Accessing WS-Addressing headers directly is supported in version 6.2:

    https://soatipsntricks.wordpress.com/2009/02/05/ws-addressing-headers-in-websphere-esb-v62/

  7. Allen says:

    This works great if the XML matches the schema. What if we are receiving a response from a third party service provider and their XML does not match the schema (their dates are not valid xsd.date elements)? When we serialize, it blows up but if it doesn’t match, WID serializes and returns the XML just fine! So, obviously the serialization can be done! I know we should transform to our response document and invoke a formatter but we would like to log the original XML first!

  8. @Allen,

    It sounds to me like it might be an idea to validate whether the message matches the schema before you process it further. In V7, this is very easy, as there is a Message Validator mediation primitive for this purpose, but in earlier versions, you can still do it other ways (https://soatipsntricks.wordpress.com/2008/07/17/pattern-validation/).

    It probably goes without saying that messages that don’t match their schema are generally something you should reject. In general, it’s a good idea to consider the schema as part of the contract between the service provider and consumer.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: