Mapping as a Service in HCI

Those who are familiar with PI would know that we could expose an operation mapping as a service by enabling AEX on BPM with NetWeaver 731 on wards. In this blog, I will show how to expose a mapping as a service in HCI

A little bit of background. I have more than a decade of experience with SAP NetWeaver PI, was fortunate enough to work on all most all releases starting with XI 2.0 to the latest 7.5. Since last couple of years, I have been working with HCI and I am primarily responsible for Cloud for Customer integration content for PI and HCI. From my limited experience, I can say from a developer and an end user perspective HCI really signs mainly with its ease of use and a very flexible pipeline. I am totally in love with HCI 🙂 , Sorry NetWeaver PI/PO.  More on this bit later

So now, how do I expose a mapping as a service? Turns out to be very simple, I just need to have an Integration Flow with a sender and a mapping as shown below

The sender system here is the tenant on which I will deploy the Integration Flow project.  The sender system uses a SOAP sender adapter with message protocol set to 1.x and a service path over which we can later consume the mapping as a service.

Import to note do not specify a WSDL in the sender channel else it will be treated as an asynchronous scenario and the consumer will not receive a response back.

For the mapping, I am using Groovy script, another reason I am in love with HCI. Groovy makes building and parsing XML very simple. Once you are familiar with Groovy trust me you will not use JAVA for working with XML. Groovy is shorter and dynamic. Add to it you can run any java code inside Groovy

For this demo, I am using a very simple mapping, which will simply add two values and return us the result. But same can be done via a message/graphical mapping as well.

The Script code to achieve the same is:

import com.sap.gateway.ip.core.customdev.util.Message;

import java.util.HashMap;

import groovy.xml.StreamingMarkupBuilder

def Message processData(Message message) {

  def body = message.getBody(java.lang.String);

  def root = new XmlSlurper().parseText(body);

  def outputBuilder = new StreamingMarkupBuilder()

  outputBuilder.encoding = “UTF-8”

  def outxml = {

  mkp.declareNamespace(‘ns0′:’http://xiTest.com/xi/COD‘)

  ns0.Target{

  outarg(root.arg1.toInteger() + root.arg2.toInteger())

  }

  }

  String result = outputBuilder.bind(outxml)

  message.setBody(result)

  return message;

}

As you can see here in Groovy, we have a nearly 1:1 ratio of code to XML.

As a last step, we deploy the Integration Flow project and test it. The result of a test run from SoapUI is, shown below for reference.

To call this mapping from another integration project we can simply configure a service call as we call any other SOAP service.

Now why do we need to expose a mapping as a service, well simple answer is reusability. In 1611 release, we plan to ship a new way of replication employees from SuccessFactors employee central to SAP Hybris Cloud for Customer and there we are using this mapping as a service to convert the source format to target format. I will explain this later in a different blog once we have the official release in place.

As a disclaimer, the views expressed here are based on my personal experience.