Understanding the Message Manipulation Primitives

Version 6.1 of WebSphere ESB has introduced the BO Mapper primitive, which brings the total number of primitives designed to manipulate or modify messages to three. People sometimes ask about the differences, so here they are:

  • The Message Element Setter primitive is the simplest. It can be used to set an element in a message, copy a value from one part of a message to another, or delete an element of a message. In fact, the actions it performs are listed in a table, so you can perform an arbitrary combination of these if you wish. It also has the advantage that you can promote the values you use. If you wanted to set a field to a particular value, but you might want to change this later without redeploying the application, this primitive is probably the right one. The Message Element Setter primitive operates directly on the SMO (Service Message Object) flowing through the mediation flow. This primitive cannot change the type of a message.
  • The BO (Business Object) Mapper primitive is similar, in that it operates directly on the Service Message Object, but it is designed to be able to map from one message type to another. It is therefore slightly more complicated (and different) to define, as you need to construct an entire mapping, but it effectively provides a superset of the functionality of the Message Element Setter – except that you cannot promote part of a BO Map. It also has the handy added bonus that it shares the BO Map format with that used by the BO Map component in WebSphere Process Server – so you can reuse maps if they are appropriate. BO Maps are turned into Java code for execution directly on the SMO.
  • The XSLT Primitive is similar to the BO Mapper in look and feel – in version 6.1 of WebSphere Integration Developer, the tool used to define the maps for both is almost identical. The underlying implementation of the primitive is quite different, however – it instead converts the map you define into XSLT code. When an XSLT primitive is executed at runtime, your SMO is flattened into XML, it is passed through the XSLT, and then the XML is ‘deserialized’ back into a new SMO. In theory, therefore, the XSLT primitive and the BO primitive are very similar in their capabilities – although there are some subtle differences that I won’t cover here. You also have the scope to modify or use your XSLT map if you need to do something advanced – although you should strongly consider your options before doing this, as this isn’t for the faint of heart. Additionally, there are some performance differences between the XSLT and BO Mapper primitives. The exact details are subject to change over time, but as with all performance questions, the details depend on the exact scenario you have, so it is best to test them out yourself in your environment.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s

%d bloggers like this: