Cloud Integration mapping: Your options explained and compared
One of the core functions of any integration platform, is to translate between different message formats. These transformations are colloquially known as mappings, and every integration platform offers its own set of tools for building them.
Cloud Integration is SAP’s integration platform in the cloud. In this blog post, I’d like to introduce you to the mapping options provided by Cloud Integration, namely:
- Message mapping
I will give you an overview of each option, and discuss their pros and cons. Plus a one-sentence TL;DR summary for the busy reader 🙂
The TL;DR version: Message mapping is easy to learn, and can be a very effective tool, but beware that if you apply it to the wrong problem, things can get ugly.
Message mapping is a graphical mapping tool, that doesn’t require any coding. Unlike the other two mapping options, the message mapping tool is built right into the Cloud Integration web application. You construct a message mapping by connecting source structure fields to target structure fields via drag and drop, and possibly inserting functions in between.
The image above is an example of fields being mapped in a message mapping. When the mapping runs, the
concat function will concatenate the contents of the
LastName source fields, and the result will be copied into the
FullName target field.
The tool has a library of built-in functions for doing calculations, string handling, conversions etc. In addition to those, you can add your own, custom functions written in the Groovy scripting language.
A very similar message mapping tool ships with SAP PI, so developers coming from that background will feel right at home with Cloud Integration’s version. The Cloud Integration web application also supports importing existing message mappings from an on-premise SAP PI system via Cloud Connector.
Initially, message mapping supported only XML to XML transformations, but support for JSON (specifically Open API service definitions) was added recently. Support for JSON in general via JSON Schema is on the roadmap.
Pros and cons
The message mapping tool is exceedingly easy to pick up and get started with; you can learn the basics in a very short amount of time. It excels at solving mapping problems of low to medium complexity. For that category of problems, message mapping can be a very effective tool.
However, solving highly complicated mapping problems with message mapping tends to result in mappings that are overly large, messy and disproportionately hard to test and maintain. In other words, be mindful of whether message mapping is a good fit for the task at hand.
The TL;DR version: For XML to XML mapping, XSLT is the most powerful of the three mapping options, but that power comes at the cost of a steep learning curve.
Extensible Stylesheet Language Transformations (XSLT for short) is an XML language for transforming XML documents into other XML documents, HTML or text. An XSLT transformation is called a stylesheet (not to be confused with Cascading Style Sheets, which describe the presentation of HTML documents). XSLT is a standard maintained by the World Wide Web Consortium (W3C). Cloud Integration supports XSLT 3, the latest version of the standard.
XSLT development revolves around writing templates. A template creates a part of the stylesheet’s output. It can match parts of the input document, or it can be called by name from another template. The XPath query language (another W3C standard) is used to navigate the input XML document. XPath enables the developer to pinpoint locations in the input in a very succinct way. Using XPath, extracting a value from a deeply nested, complicated XML structure can be trivial.
The stylesheet in the image above performs a so-called identity transformation, i.e. its output is identical to its input.
The Cloud Integration web application offers a rudimentary XSLT editor, but its functionality is very limited. If you want conveniences like debugging and stylesheet validation, you need a separate tool (typically an XML editor such as XMLSpy or Oxygen).
Pros and cons
Of the three mapping options offered by Cloud Integration, XSLT is without a doubt the most powerful for XML to XML mappings. Faced with a complicated transformation, like mapping a large IDoc to a deeply nested XML structure, XSLT should be your first choice.
However, the language has a steep learning curve, that must be climbed, before one becomes productive. Also, if you want to get serious about XSLT development, you will need an XML editor, and that means one more tool to learn.
One additional benefit of XSLT, is that stylesheets are text files, that you can store in a version control system like Git.
The TL;DR version: If the developer is willing to manage all aspects of a mapping herself, scripting offers more flexibility and more control over input processing and output generation than message mapping and XSLT.
Scripts serve multiple purposes in Cloud Integration, and one of those purposes is mapping. The image above is an example of a simple mapping performed in Groovy. It transforms a CSV-formatted message into an XML document. While the code is simplified for the sake of brevity, it does demonstrate the two main tasks performed by all mapping scripts:
- Process the input message
- Generate the output message
If you are handling plain text or XML, the built-in classes will go a long way. To process, say, an Excel spreadsheet attachment, you need an external library.
As is the case with XSLT, the Cloud Integration web application offers a very basic script editor. However, most developers opt for external editors or IDEs with a much richer feature set.
For a very comprehensive look at Groovy mappings in Cloud Integration, please see the blog post I *heart* Groovy mapping by SAP Mentors alumnus Eng Swee Yeoh.
Pros and cons
Mapping in script code gives you full control over how the input is processed and how the output is generated. This is obviously great, and it lets you write, for instance, advanced text processing that goes well beyond the built-in capabilities.
An added benefit is that scripts are text files, that you can store in your version control system.
Thanks for the great post on the comparison between the different mapping options available.
A few points from my own experience:-
Message mapping - yes, complex mappings can get real ugly as the developer needs to understand the queues & context concept that is inherited from PI. I've seen too many PI mappings gone horribly wrong, that I sometimes wish CPI would start afresh without this legacy baggage! Plus currently there's no way to run automated unit tests on these mappings - the simulate functionality in WebUI is very rudimentary.
XSLT - totally agree with the steep learning curve. I've always struggled with it (and still do), and only use it sparingly when it seems to be the best choice for a specific use-case. Do any of the tools support running a suite of unit test cases?
Scripting (Groovy in particular) - given that I have a bias towards coding, this is my favorite. But IMHO, any integration developer will at some point need to write some codes, so why not pick up this lovely-to-use language early on? Plus, there's a trick to unit test the scripts locally on your computer 🙂 Furthermore, XML is no longer the de-facto medium for data transfer - JSON's popularity is growing, as well as other binary or unstructured data formats. So there are times where this is the only option available.
Hi Eng Swee
Thank you for your always interesting comments 🙂 You bring up a very good point about non-XML formats, and scripting being pretty much the only option in many of those cases.
Very well written and structured blog, thank you for this summary and comparison as well as for valuable highlights of advantages and disadvantages of each of techniques!
In my opinion, history repeats itself to some extent here: PI / dual stack started with support of variety of mapping techniques - graphical mappings, XSLT (with ABAP and Java based XSLT processors), ABAP and Java mapping programs. This was followed by elimination of ABAP based techniques due to migration to Java-only installation options. And now, in CPI, remaining techniques experience second breath:
Nice thing here is that CPI comes with native support of XSLT 2.0 processor, while in PI/PO, we need to make use of custom XSLT transformer - good step forward for those who have to deal with many XSLT mappings on a regular basis and need some more recent and advanced capabilities.
Thank you for your insightful comment!There’s probably an interesting blog post there, waiting to be written, about migrating SAP PI skills to Cloud Integration. On that note, I much prefer CPI’s scripts to PI’s Java mappings. They’re much more versatile, and you can script wherever you want.
Thank you, it is a nice explanation about maping.
Thank you, that's very kind.
great overview of the different mapping options.
On the PI/PO I used to use XSLT Mapping when it was complex. However, as I just tried it is not possible to upload a ZIP XSLT mapping with multiple XSL-files. I like to separate segments etc. in different files. Therefore, you need to have the whole mapping in one file.
Thank you! You can have multiple stylesheets that refer to each other, but you do need to upload them separately, unfortunately. I've written about xsl:import in Cloud Integration here.
Thank you! Now I switch 🙂
Thanks Morten Wittrock for sharing this document. I am new to SAP CPI, any leads to learn Groovy Scripting for SAP CPI?
Sorry about the (very) late reply. Check out this blog post by Eng Swee Yeoh about Groovy mappings.
For simple mappings (XML to JSON) I've been using the Content Modifier (ie. use XPATH to retrieve value into a Property then use that property in the Body). Understand that there are significant limitation here eg. repeating elements. But for a simple static output message format I think it is (perhaps) the simplest method.
Is there a reason this method isn't mentioned as one of the options here?
That's a perfectly viable approach. It's not in this blog post because it's not generally considered one of the supported mapping options, in the sense that it's not transforming an input payload to an output payload.
But as you say, for simple, static messages it's absolutely fine.
It's been on my list of topics to blog about for a while by now. I should probably get around to it soon 🙂
Thanks for this fine blog. I am wondering if there has been any performance considerations since this was written?. The state of the cloud system is maybe always up and with an infinite memory recourse. But that is not the case in clound on onpremise systems.
I can see it is often StringWriter that is used to move the output of the groovy mapping to the Camel message. But to me this looks like a potential memory problem if the payload is very big > 10 MB.
Do you have any ideas how to adress the memory problem on big size payloads ?.
// here you would have XmlSlurper og some other Sax-parser code
//and then.. this ugly statement