To map, or not to map, that is the question

Transforming between message formats – usually referred to as mapping – is a big part of pretty much every integration project out there. How you choose to implement a mapping is influenced by the mapping problem at hand, any local guidelines that might be in place and your own skillset and preferences.

In a previous blog post, I covered the three mapping options currently offered by SAP Cloud Integration:

• Message mapping
• Scripting in JavaScript and Groovy
• XSLT

In some corner cases, however, you have a fourth option: not mapping at all. If the structure of the target message is fixed, with a number of values inserted from the source message, you can do away with the mappings and instead use our old friend the Content Modifier step and Apache Camel’s Simple expression language.

Before going into the details of how, let’s talk briefly about why you might want to consider this option. Adding a mapping to your integration flow carries a cost: The new mapping must be developed, tested, documented and later maintained. This requires effort. Also, adding a mapping invariably increases the overall complexity of your integration flow. A simpler solution with fewer moving parts means fewer headaches – figuratively and sometimes literally.

Now, let’s move on to how you implement this technique. It involves two straightforward steps:

1. Extract the values you need from the source message
2. Insert those values into a template to create the target message

If the source message is XML, step 1 can be accomplished with a Content Modifier step. Create a property of type XPath for each value you want to extract:

If the source message is JSON or another non-XML format, you might be able to extract the values you need using only built-in flow steps, but doing so in a script is probably the easier option. Here is a simple Groovy script that extracts three values from a JSON payload using Groovy’s JsonSlurper class and stores them in properties:

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.json.JsonSlurper

/*
 * Expects a JSON payload like the following:
 *
 * {
 *   "values": [1, 2, 3]
 * }
 *
 */

def Message processData(Message message) {
    // Create a new JsonSlurper
    def slurper = new JsonSlurper()
    // Parse the message body as JSON
    def object = slurper.parseText(message.getBody(String))
    // Extract the three values and store them in properties
    message.setProperty("ValueOne", object.values[0])
    message.setProperty("ValueTwo", object.values[1])
    message.setProperty("ValueThree", object.values[2])
    // All done
    message
}

Once you have the values you need ready to go in properties, it’s time for step 2. We create the output message in a Content Modifier step in which the newly created properties are inserted into a template using Simple expressions. Here’s an example:

Note how the type of the message body is set to “Expression”. This means that Simple expressions like ${property.ValueOne} will be evaluated and the result inserted into the payload in the expression’s place. If the type is instead set to “Constant”, Simple expressions will not be evaluated.

The full power of the Simple expression language is available to you in the message body. This means that you can, for instance, change a value to upper case using ${property.SomeProperty.toUpperCase()}. To learn more about Simple expressions, please see this blog post of mine.

(By the way: If you extracted the values from the source message in a Content Modifier step, you can reuse that step to also create the target message, since the properties will be created before the payload. If you are interested in the details, I’ve blogged about them here.)

That’s it! You’ve created a target message by using a template and Simple expressions instead of a mapping. Do keep in mind, though, that this technique has some obvious limitations. If you need to, for instance, do branching logic (some parts of the message should only be included if an expression is true) or loop over a number of values and generate output for each one, you still need one of the three mapping options offered by Cloud Integration.

If your problem is a good fit, however, the approach described in this blog post can help reduce the complexity of your integration flow while still producing the output you need.

Have fun with CPI!