Transforming messages inside WSO2 ESB 5.0.0

Amongst all the features any ESB might or might not have, one of the fundamental features any ESB must have is the ability to transform messages from one format into another format. Other fundamental features are of course message routing, protocol conversion, message validation and not to forget security!

In this blog, I’d like to focus on Transforming messages inside WSO2 ESB 5.0.0. The WSO2 ESB offers you out of the box multiple mediators to transform a message from one format into another:

• XSLT Mediator, uses good old XML to transform an XML message into another format. (Can also be used to transform XML to/from JSON.)
  See also: https://docs.wso2.com/display/ESB500/XSLT+Mediator
• FastXSLT Mediator, applies the XSLT transformation on the Message stream instead of the message payload (as the standard XSLT Mediator does). It should be faster but comes with some limitations as a drawback.
  See also: https://docs.wso2.com/display/ESB500/FastXSLT+Mediator
• PayloadFactory, uses a template with placeholders. The placeholders will be replaced by values retrieved from for instance the original message, using XPATH expression, JSON expression or variables and literals.
  See also: https://docs.wso2.com/display/ESB500/PayloadFactory+Mediator
• Data Mapper Mediator, this is the new kid on the WSO2 ESB block. It needs three confirmation files: An input schema file, an output schema file and a mapping configuration file, which can be generated using a graphical tool. The schema’s are defined in a custom-defined JSON schema and the mapping configuration file is in fact a Javascript file. The actual transformation is performed in the Javascript engine that’s included on the JVM. (Jave7 and Java8 use different Javascript engines, therefore a Data Mapper configuration which runs perfectly on Java8 might fail to execute on Java7.) See also: https://docs.wso2.com/display/ESB500/Data+Mapper+Mediator

If that is not enough, besides these four mediators, the WSO2 ESB provides more means which can be used to transform/alter a message:

• The Enrich Mediator allows you to enrich the message by adding more elements to an existing XML message. See also: https://docs.wso2.com/display/ESB500/Enrich+Mediator
• Using the Script Mediator, you can modify the XML and JSON messages using Javascript, Grovvy or Ruby.
  See also: https://docs.wso2.com/display/ESB500/Script+Mediator
• The Smooks Mediator can be used to apply lightweight transformations on messages in an efficient manner. Smooks is a powerful framework for processing, manipulating and transforming XML.
  See also: https://docs.wso2.com/display/ESB500/Smooks+Mediator

With all these options, you might wonder which Mediator you should use in when, well the answers to such a question is not always that simple, or maybe sometimes it is?

For this blog, I’ll look at the XSLT, FastXSLT, Payload Factory and Data Mapper Mediator, as I consider them to be the ‘real transformation Mediators’ which allow you to transform a message into a completely different message, where the Enrich Mediator and the Script Mediator more or less meant to slightly modify a message. The Smooks Mediator certainly really transforms messages, but in the ESB it is mostly used for very special transformations like CSV to XML, XML to CSV, EDI to XML, XML to EDI, …

XSLT Mediator and Fast XSLT Mediator

These two mediators both use XSLT to create a new message out of an existing message. XSLT offers you a great deal of flexibility, I won’t go in detail into the features of XSLT, but I want to emphasize on the ability of an XSLT transformation to iterate over repeating items.

A drawback of the XSLT mediators can be the complexity of an XSLT transformation, which can make it hard to find out where to change/fix a complex transformation when needed.

Payload Factory Mediator

The beauty of this mediator is that the result message is very well visible in the configuration. One drawback is that when you use the Payload Mediator to construct a large message using many placeholders, this means the list of arguments gets very long too, it is not possible to see in one look which value is inserted where in the resulting message. Adding comments is almost mandatory then in order to keep it clear what is  happening and why.

A bigger drawback is the fact that the payload mediator does not support repeating elements.

Data Mapper Mediator

The beauty of this Mediator lies in the Data Mapper Tool which is part of the ‘WSO2 ESB tooling’ and offers a visual editor which allows you to create a mapping by drawing lines from a source field to a destination field, optionally via one or more function blocks in between (which allow you to manipulate the transferred value).

Just like the Payload Factory Mediator, the current version of the Data Mapper Mediator does not support the transformation of repeating elements.

Performance tests

What about performance? Is one Mediator faster than another? Is it always faster or does it depend on … on what?

Test setup

I created a very simple API project, in which I transform one XML message into a very similar JSON message, using all four mediators. For each mediator, I transformed the message with and without repeating elements, which made me use the ForEach Mediator to transform the repeating elements by repeatedly invoking the Mediator of choice, and another transformation to transform the non-repeating elements.  After the message is transformed, it is returned to the caller by a Respond Mediator. All sequences contain no validation, no logging, no sanity checks or other stuff that is necessary in a real service, but have influence on the performance.

Test sets

All tests are executed with two different input files:

• purchaseOrder-small.xml, which contains 3 items
• purchaseOrder-large.xml, which contains 186 items

Test data

The (3 items version of the) xml input and JSON output:

Test results

I used JMeter to invoke the eight transformations 200 times using multiple threads, so a performance dip in my local VM should influence all measurements equally, which makes it valid to compare the numbers with each other.

Observations

Let’s have a look at the average response times of the mediators:

• Fast XSLT, XSLT and Payload Factory mediators perform equally when the repeating fields aren’t included in the transformation.
• The Data Mapper mediator is slower, even when the repeating items are not transformed. It is only fait to mention again, the Data Mapper mediator always validates the input and output messages, which of course takes time.
• For the Fast XSLT and XSLT mediators, mapping the repeating fields makes the transformation take approximately 10% longer to process the messages.
• Also, transforming the repeating fields using the Payload Factory or Data Mappers mediator, makes the transformation much slower. This can be explained by the fact that instead of one transformation, n + 1 transformations are performed. Including 2n + 2 validations of the message for the Data Mapper.

When to use which mediator

When you choose your transforming only on performance, you just have to look at the table to see you should always use the FastXSLT mediator, but … next to performance, other criteria can play an important role in this decision, for instance the lack of knowledge on writing performant XSLT style sheets.

Just looking at the performance, tells us:

• For smaller messages, use either the Fast XSLT, XSLT or Payload Factory mediator.
• When you must transfer messages with repeating items, the XSLT mediators are the easiest to use, the other two mediators require you to iterate over the repeating items yourself what makes them much slower

• The current version of the Data Mapper mediator turns out to be slower, it does not support transformation of repeating items. So, when to use it?
  • When you must show a graphical representation of your mapping to your manager (just kidding )
  • When you want to do a quick mapping of messages
  • When your technical skills, like XPath/JSON expressions, are not good enough (yet).

If you have any questions about this blogpost contact us via the comments section of this blog. View also our WSO2 Tutorials, webinars or white papers for more technical information. Need support? We do deliver WSO2 Product Support, WSO2 Development Support, WSO2 Operational Support and WSO2 Training Programs.