Introduction: Java Mapping
Java mapping is one of the commonly used mapping types in SAP Process Orchestration.
Essentially, a Java mapping is a special Java class that implements the Java Mapping API (Package com.sap.aii.mapping.api), to process XML documents, use Java API for XML Processing (JAXP), for example. The JAXP supports the Document Object Model (DOM) and the Simple API for XML (SAX). This gives you great flexibility for mapping-programming with Java.
The diagram below depicts how Java mapping works in SAP Process Orchestration.
The Use Case: Migrate Java Mapping to Cloud Integration
In SAP Cloud Integration, which is a core capability of SAP Integration Suite, a Java mapping cannot run inside an integration flow directly. The most similar integration flow step (artifact) is a transformation script, either JavaScript or Groovy script.
Unlike the Java mapping in SAP Process Orchestration, the Groovy script can be directly assigned to the SAP Cloud Integration flow, without explicitly compiling to other formats or embedding into other artifacts.
The diagram below depicts how Groovy script works in SAP Cloud Integration.
To reuse the business logic of the Java mapping in SAP Cloud Integration, some migration works are required.
For example, you can:
- wrap the original Java mapping code inside a Groovy script (mix Groovy and Java code)
- upload the compiled Jar file to integration flow, invoke the Java mapping via additional (customized) adapter code
- re-implement the same logic from scratch, using either Groovy or JavaScript language
The Idea: Generate Groovy from Java via Generative AI
In the blog, we will try from a new perspective: Leverage the emerging generative AI to migrate SAP Process Orchestration Java mapping to SAP Cloud Integration Groovy script.
The core of the idea is: Provide the Java mapping code as the raw input, plus integration domain-specific prompts as instruction, to guide the generative AI to produce Groovy code by "translating" existing Java code.
The diagram below depicts the main steps of the solution.
Let us dig into these steps one by one.
Preparation
Before the generation, you should collect the following artifacts from the SAP Process Orchestration system:
- Source code of the Java mapping
- will be used as part of the input for the generative AI call.
- Sample input XML document of the Java mapping
- will be used as input for the generated Groovy script, which then produces an output XML.
- Sample output XML document of the Java mapping
- will be used for evaluation, by comparing it with the XML produced by the generated Groovy script.
Note: Normally, the Java mapping developer can provide the Java mapping source code directly.
If this is not true for your case, you can export the Java mapping archive from your Process Orchestration system. The exported archive is a Java archive (with extension .jar). This Java archive contains the compiled Java class (with extension .class). You can use a Java decompiler tool such as jd-gui to decompile the Java class file to Java source code
Generation
Craft Prompt
In the context of generative AI, a well-crafted prompt is crucial for obtaining accurate and useful results from the language model.
In our case, the prompts should be crafted with SAP Process Orchestration, Cloud Integration relevant domain knowledge.
For example, the following prompt contains integration relevant context and very specific requirements:
- Please convert this SAP Process Orchestration Java mapping code to Cloud Integration Groovy script, fulfill following requirements:
- Use Groovy 2 syntax, must compatible with JDK 8
- Generate def Message processData(Message message), don't wrap it in any class
- Remember to import necessary packages
- Run the generated code by yourself, make sure no syntax error
- Just provide code, don't say anything else
Use Generative AI
With the Java mapping source code and relevant prompt being prepared, the next step is to send the complete prompt text to the Large Language Model (LLM).
You can do this:
- directly via the provider company's website UI
- programmatically via their (rest) API call.
Depending on the AI provider you chose, the quality of the prompt, and the complexity of Java mapping, the quality of the generated Groovy code may vary significantly.
Note: The LLM we used is described in the Disclaimer section.
Evaluation
How can you evaluate the quality of generated Groovy code? Is it correct, both syntactically and logically?
There are different options/aspects to do the evaluation.
For example, you can:
- use/build a local tool (e.g., IDE like IntelliJ IDEA) to validate the syntax of the generated Groovy code
- build a local simulator to run the generated Groovy code
- use/build a tool to compare the Groovy-produced XML with the expected XML
However, a very straightforward way is to run the generated Groovy script into a real integration flow:
- create an integration flow
- upload the generated Groovy code to the integration flow
- send the prepared input XML to the integration flow
- the generated Groovy script will run the mapping logic, and then generate the output XML
- compare the expected XML with the output XML of the integration flow message.
Conclusion
Sometimes, the generated code just works perfectly, you don't have to change anything. Sometimes, the generated code has small syntax or logical issues, you need to verify and fix them manually.
Nevertheless, in general, the generated code can be used as a very good starting point for the migration.
The generative AI can help accelerate the migration of SAP Process Orchestration Java mappings.
You can use it as your copilot of the migration.
Next Step
In the part 2 of this blog series, we will try the idea with a sample Java mapping scenario.
Disclaimer
Generative AI and Large Language Model (LLM)
In the blog, we use the terms generative AI and LLM interchangeably.
In theory, the idea is LLM-independent, but at the time of this blog, we only tried the idea with OpenAI's GPT-3.5 and GPT-4 models.
Security
When you invoke the generative AI, you have to send your source code to the AI provider. This implies the business logic is completely exposed to the AI provider, this can lead to security/IP-related issues if the AI provider is not reliable.
So please always keep this in mind, and only use the AI provider you TRUST.
Support
This idea described in the blog is not an SAP officially released feature, SAP will not formally support any implementation of this idea.
AI Limitation
The AI-generated content is not predictable, you may get a different response every time even you feed it with the same input, and there is no chance to debug why the response is different.
Generative AI is incredibly good at generating code, but AI-generated code is not always correct, sometimes the generated code has syntax issues, sometimes it has logical issues.
So you cannot use the generated code for production use directly.
Depending on the size of your Java mapping code, the AI token consumption could go beyond the token limitation, this cloud lead to higher costs, and even worse, a low-quality code (the generated code might be truncated due to token limitation).
Suitable Scenario
The most suitable scenario for this idea is: The Java mapping does not have too many dependencies.
If the Java mapping class (which implements the Java Mapping API) itself has too many dependency Java classes, you will have to do the generation not only for the main Java mapping class, but also for its dependency Java classes as well.
This will increase not only the cost of AI token consumption but also the complexity of code integration (combining different codes together).
- SAP Managed Tags:
2 Comments
