Skip to content

Mapping Messages in WebSphere Message Broker V8

by on July 12, 2013

Mapping Messages in WebSphere Message Broker v8

One of the most common tasks for a message flow is transforming a message to  a different format. Websphere Message Broker offers six different ways to perform this mapping function; Mapping Node, Compute Node, Java Compute Node, .NET Compute Node, PHP Compute Node, and XSL Mapping Node.  Below is an example showing all six in a message flow.   The goal of this simple flow is to give the message a unique filename and format the phone number with dashes. The input message has an additional field that determines which mapping node is to be used.

Mapping_All_Nodes

1.      Mapping Node

A Mapping Node is the simplest way to map a message.  To use it, the project needs to reference message models.  The mapping node uses them to map the data fields from the input to the output.  The input model will be shown on the left and the output model on the right.  To map the fields to their new model, simply click and drag the input fields onto the proper output fields.  If the data needs to be transformed, this can be done with xpath functions.  To use these functions, click on the box on a connection between two data fields and change it from “move” to any one of the functions.  Arguments for these functions are found in the properties submenu, which can include other xpath functions and the values of other fields from the input model.

Below is an example of a mapping node.  It can be clear where the data is moving to and from.  You can see that we have moved the LocalEnvironment property over to the output to keep the change we made to the file name in the previous node.   Instead of just moving the phone number, a concat function is used to reformat the number.  However, we cannot see what arguments are being used at a glance; to do this, we would have to look in the properties menu.

Mapping

The advantage of the mapping node is that it makes it easy to visualize where the data is going. You can clearly see what data is going where and what’s being transformed.   It is also convenient when the message models you are mapping between are very similar in structure.

The disadvantage is that xpath functions are harder to use than code.   In order to see how data is being transformed, you need to look through all of the arguments in the properties tab.  For complicated transformations, this can be cumbersome, inconvenient, and difficult to maintain.

Websphere Message Broker offers a few different Compute nodes that each use a different programming language to map or create a message. We will be covering the Compute Nodes that use ESQL, Java, .NET, and PHP.

2.       Compute Node (ESQL)

The Compute Node is a simple way to programmatically define or transform  a message using ESQL.  ESQL also has two functions that are automatically generated for mapping messages.  CopyMessageHeaders() is a function that will copy over everything except the body of the message.  CopyEntireMessage() will copy everything (headers and body).   ESQL references the input and output trees by name.  Below is an example of how our message could be mapped with ESQL.

Mapping_ESQL

ESQL is very straightforward and simple. The biggest potential for a mistake in this code would be in the calls to the OutputRoot or InputRoot variables.   A typo referencing the output tree would create a new node, while a typo on the input would reference a non-existent node.

3.      Java Compute

The Java Compute Node is a bit more complicated than the ESQL node because it uses objects to create a message model.  Java code that does the equivalent to ESQL code will usually be longer and more verbose.  Instead of referencing parts of the message tree by name, Java uses functions to create or remove children from the tree.  It also uses functions to reference individual nodes of the tree. Code that would transform our message might look like this:

Mapping_Java

This is much more verbose than the equivalent ESQL Code.  In addition, it is much harder to keep track of where in the tree your variables are referencing.  Keep in mind that although it is harder to write the Java code, there is no chance of a typo causing an error later in the flow.

ESQL is very useful when the structure of the messages is known.  Unlike the Java Compute Node, ESQL directly references parts of the message tree by name.  A Java Compute Node uses Objects, which can get more complicated than a mapping may need to be.

When using ESQL, you may find it troublesome that you need to know exactly what the message model needs to be.  It is also less readable and more difficult to maintain more complicated areas of the code.  For example, trying to read the CopyMessageHeaders() function is a bit difficult – compared to the Java equivalent, it is much less clear as to what exactly is happening. Take a look at how both languages implement this feature.

ESQL:

Mapping_ESQL_CMH

Java:

Mapping_Java_CMH

Although our first example suggested that ESQL would be easier to read and write than Java, the CopyMessageHeaders() function showed us how ESQL can be difficult to read.  The Java code is a simple, readable loop that will be much easier to maintain in the future. Imagine writing a complicated loop such as this in ESQL and trying to maintain it six months later.  This is the big advantage of using Java – although the code will be more verbose, it will be easier to write dynamic code that is readable and easily maintained in the future. Objects are a good tool to manage complexity.

The biggest advantage of using Java is also the biggest disadvantage.  Objects have to be used for even the smallest transformation, adding what may be unnecessary complexity to your program.  If the change you need is small, it may be easier to use ESQL to avoid using objects. If speed is a necessity, Java scales better for larger messages. ESQL is faster for a small change, but scales poorly compared to the other mapping options.

The ESQL and Java compute nodes are the most drastically different. The PHP Compute Node and the .NET Compute Node lie in between them in terms of complexity and ease of use.

4.      PHP Compute Node

The PHP Compute Node handles the input and output structures much like how the ESQL node handles them.  PHP is a dynamic scripting language, so it is much easier to make small changes to the message than a Java Compute Node.  Of the languages that can be used in a message flow, PHP is the only one that does not require variable names and types to be declared.  It can also be easier than in ESQL because variable types are not enforced.  However, dynamic languages like PHP can be difficult to debug because typing is not enforced.  Like other scripting languages, PHP is not very fast when compared to compiled languages.  If you are familiar with scripting languages and speed is not a priority, a PHP Compute Node may be a good choice. Below is an example of how our message can be transformed in PHP.

Mapping_PHP

5.      .NET Compute Node

The last type of compute node is the .NET Compute Node. Unlike the other compute nodes, the development of a .NET Compute Node is not done in the Toolkit.  It is done through Microsoft Visual Studio.  A .NET Compute Node will have a property that points to a .dll or.exe file, and a property that specifies the class name to be used.  Any .NET language can be used with the .NET Compute Node, which makes it easy to integrate other Windows applications.  In addition, an update to the .dll or .exe file can be made without needing to redeploy the message flow. The following code is an example of mapping the message in C#.  It is most similar to Java, but the references to individual nodes of the message tree are easier to read.

Mapping_CSharp

C# is most similar to Java in how it structures the message as an Object.  It also allows you to refer to children either by name or through referential functions.  A .NET Compute node would be most useful if you have experience developing with Visual Studio or want to integrate another Windows application into your message flow.  It also boasts similar speeds to Java.  However, you need to have Visual Studio in order to develop this node.  You also cannot use this node in a flow that runs on a non-Windows machine.

6.      XSL Transformation

The last way to map a message is to use XSL.  XSL is a tool often used to turn an XML file into HTML for a webpage, but we can also use it to transform to a new XML file.  If you have worked with PHP and HTML, you will find that XSL is similar to embedding PHP in HTML.  As you define the new messages structure, you can set the value of fields to be XSL functions.  These functions are very similar to the xpath functions in the mapping model.  There is also support for iterating through multiple children of an element.

Mapping_XSL

XSL has an advantage over the Mapping Node because it is easier to read the functions and it is slightly faster.  It is dynamic and flexible; this allows it to easily be used for any size message.  Additionally, there is no setup required to write the message.  What you see above is the entire XSL file.  However, from a development standpoint, it is difficult to maintain and write because it assumes knowledge of the input XML message.  If you have no knowledge of the incoming message, it will be difficult to determine what the XSL is doing.  XSL is also very difficult and limited when dealing with non-XML messages.

Summary

Websphere Message Broker offers a lot of options for mapping messages.  Each type of node has its own advantages and disadvantages.  The Mapping Node is best for simple mappings where you can drag and drop easily and allows you to visualize the data.  However, mapping large, complex messages can become more cumbersome.  ESQL Compute Nodes are good for simple message transformations and for interacting with the database, but complicated code can be hard to read.   Java Compute Nodes are good for managing complexity, but make simple transformations more difficult than other nodes.  PHP Compute Nodes balance readability with simplicity, but can be difficult to debug.  .NET Compute nodes need Visual Studio to develop, but can integrate with Windows Applications and allow .NET supported languages to be used.  XSL Node functions are easier to read than functions from a Mapping Node, but can be difficult to maintain without knowledge of the incoming message.  Below is a chart that summarizes the advantages and disadvantages of each node.

Node

Advantage

Disadvantage

Mapping Node

  • GUI allows visualization of data
  • Simple mappings are easy
  • Large or complicated functions or transformations can be difficult to write and maintain

ESQL Compute Node

  • Simple transformations are easy
  • Can pull directly from database
  • Dynamic code is slow and hard to read and maintain

Java Compute Node

  • Objects manage complexity well
  • Dynamic code is fast and easy to read and maintain
  •  Small transformations are more complicated than other nodes

PHP Compute Node

  • Code is easy to write and maintain
  •  Debugging can be difficult
  • Performance is slow

.NET Compute Node

  • Can use any .NET supported language
  •  Development is done through Visual Studio

XSL Transform Node

  • Useful for quick and simple transformations
  •  Requires knowledge of input xml
  • Can be difficult to maintain
 
Advertisements

From → Integration

Leave a Comment

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: