Using Java Mappings in SAP Cloud Platform Integration (CPI)

Give me the code

You may have complex mappings and you don’t want to implement them in Groovy again. So what is the solution? Enter the archive functionality.

For existing Java Mappings that use InputStream&OutputStream, adding a method to get a String and return a String is enough. This is just an example that can be improved based on your needs. You can choose to use InputStream, methods can be static etc.

public String processString(String msg) throws Exception {
    ByteArrayInputStream bais = new ByteArrayInputStream(msg.getBytes(Charset.forName("UTF-8")));
    ByteArrayOutputStream baos = new ByteArrayOutputStream();
    process(bais, baos, true);
    return new String(baos.toByteArray(), Charset.forName("UTF-8"));
}

I intentionally preserved diff to change your mapping class here:

https://github.com/fatihpense/JavaMappingExampleCPI/commit/eff0128f40cde673f5d9e96a38f9bf4d85b87958?diff=unified

This class has the benefit of testing Java mappings locally easily with the main function. You can find all code examples in the repository:

https://github.com/fatihpense/JavaMappingExampleCPI

Here is the simple Groovy script that uses Java mapping class:

import com.sap.gateway.ip.core.customdev.util.Message;
import com.medepia.pi.education.simple1.SimpleJavaMappingCPI;


def Message processData(Message message) {
	
	//Body as string
	def body = message.getBody(String.class);
	
	def javaMapping = new SimpleJavaMappingCPI();
	def result = javaMapping.processString(body);
	message.setBody(result);
	
	return message;
}

If you want to handle more functionality like properties in pure Java you can pass Message class directly to Java function. There is a Script API Jar for this purpose. Search on the page: https://tools.hana.ondemand.com/#cloudintegration

Let’s chat for a bit

I didn’t understand when I look into the CPI and there is no mention of Java Mappings. I wonder the reason behind this design decision.

-“Use only Groovy instead of Java?”

Groovy is really fine. However many people would like to use (or reuse PI) Java mappings. The causes can be familiarity, desire to not invest in another language, reuse of the existing code, affection for verbosity.

-“XSLT is enough?”

I love XSLT 1.0. It has a simple spec and a niche in mappings when writing XSLT is way easier than anything else.

XSLT 2.0 and onwards brings too many features, they are more like a programming language and harder to implement processors for them. This causes XSLT 2 to be less cross-platform/language for now. There goes the portability argument. I have always thought if I was going to write XSLT 2.0 or 3.0 I would seriously consider writing Java DOM mapping instead. (or Groovy now)

-“What about performance?”

There can be no argument for performance also. Groovy XmlSlurper is like Java SAX, but it also has XmlParser which is like Java DOM. Script gets an InputStream, String or byte[] as input. So the message is already in the memory if you choose String. Whereas in SAP PI Java Mapping gets only InputStream and OutputStream. So the decision on memory load is yours to make anyway.

So why there is XSLT 2.0 and Groovy support and no Java option? I can’t understand.

Thanks for reading.

Fatih