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:
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
Hi Fatih,
Is it possible to reuse java mappings without adding the extra lines of codeĀ or do you have to configure new methods within each old java mapping ?
Hi Dale,
It can be possible in different ways. Basically, if your Java classes have a method with InputStream and OutputStream you can achieve your goal without editing those classes:
But, if your Java mappings use the relatively new PI/PO API AbstractTransformation without a separated method which only takes InputStream and OutputStream. You have to edit your classes to add a method.
Regards,
Fatih
Hi Fatih,
which IDE do you use and how to bundle the JAR together with the Groovy Scripts?
Regards,
Simon
Hi Simon,
Actually, I only bundle Java code as a JAR. I write Groovy bits -which depends on this JAR- on CPI editor.
Regards,
Fatih