SAP Community - SAP Process Orchestration

Managing keys and certificates using KeyStore Explorer

2024-01-02T12:12:01+01:00

This blog explores the fundamentals of cryptography, a vast subject that cannot be comprehensively covered in a single entry. For precise details, it is recommended to refer to the official documentation. The KeyStore Explorer application offers a user-friendly solution for creating, managing, and inspecting keystores, keys, certificates, and certificate requests. It serves as a viable alternative to OpenSSL commands.

Using Generative AI to Migrate Java Mapping to Cloud Integration - Part 1: The Concept

2024-01-31T10:34:17.740000+01:00

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).

Using Generative AI to Migrate Java Mapping to Cloud Integration - Part 2: A Sample

2024-01-31T10:37:59.023000+01:00

Introduction: Sample Java Mapping Scenario

In the part 1 of this blog series, we introduced the idea at the conceptual level.
In this part, we will try the idea with a sample Java mapping that maps flight booking data.

Note: This sample is a fictitious scenario, it's used for demo purpose only.

The diagram below depicts the data model and logic of the Java mapping in SAP Process Orchestration.

It implements the following mapping logic:

Determine the field "Preferred_Language" based on the field "Customer_Country"
- If the preferred language is already provided, use the original value, no further logic for this field
- Find the value from a mapping list, e.g., if the customer country is DE, then the preferred language is German
- If no value is found from the mapping list, use the default language "English"

Determine the field "Discounted_Price" based on the fields "Flight_Date" and "Full_Price"
- If the flight date is within a peak season (April 1 to October 31), no discount
- If the flight date is NOT within a peak season, apply a 10% discount

Determine the field "Total_Price"
- Sum up the field "Discounted_Price" of each flight, and assign the total value to the field "Total_Price"

Keep original values for other fields

Migration Process

Recap: The diagram below depicts the main steps of the solution.

Let us follow these steps one by one.

Preparation

Source Code of the Java Mapping

The Java mapping is a Java class that extends the AbstractTransformation abstract class.
Its source code is as below.

package com.sap.poc.java.mapper;
import com.sap.aii.mapping.api.AbstractTransformation;
import com.sap.aii.mapping.api.StreamTransformationException;
import com.sap.aii.mapping.api.TransformationInput;
import com.sap.aii.mapping.api.TransformationOutput;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import java.io.*;
import java.util.HashMap;
import java.util.Map;

public class BookingDataMapper_DOM extends AbstractTransformation {
    private Map<String, String> countryToLanguageMap;
    public void transform(TransformationInput transformationInput, TransformationOutput transformationOutput) 
    throws StreamTransformationException {
        InputStream inputstream = transformationInput.getInputPayload().getInputStream();
        OutputStream outputstream = transformationOutput.getOutputPayload().getOutputStream();
        mapBookingData(inputstream, outputstream);
    }
    public void mapBookingData(InputStream inputstream, OutputStream outputstream) {
        try {
            DocumentBuilder docBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
            Document inDoc = docBuilder.parse(inputstream);
            Document outDoc = docBuilder.newDocument();
            outDoc = inDoc;

            setPreferredLanguage(outDoc);
            calculateBookingPrice(outDoc);

            Transformer transformer = TransformerFactory.newInstance().newTransformer();
            transformer.transform(new DOMSource(outDoc), new StreamResult(outputstream));
        } catch (Exception e) {
            e.printStackTrace();
            this.getTrace().addDebugMessage(e.toString());
        }
    }
    private void setPreferredLanguage(Document outDoc) throws Exception {

        Element preferredLanguageElement = (Element) outDoc.getElementsByTagName("Preferred_Language").item(0);
        if (preferredLanguageElement.getTextContent().isEmpty()) {
            loadCountryToLanguageMap();
            // Find the Customer_Country element
            Element customerCountryElement = (Element) outDoc.getElementsByTagName("Customer_Country").item(0);

            // Get the customer country value
            String customerCountry = customerCountryElement.getTextContent().trim();

            // Find the corresponding language in the map
            String language = countryToLanguageMap.get(customerCountry);

            if (language != null) {
                // Update the Preferred_Language element with the found language
                preferredLanguageElement.setTextContent(language);
            } else {
                preferredLanguageElement.setTextContent("English");
            }
        }
    }

    private boolean isSlowSeason(String date) {
        int iData = Integer.parseInt(date.substring(4));
        int iStartDate = 401;
        int iEndDate = 1031;
        return !(iData >= iStartDate && iData <= iEndDate);
    }

    private void loadCountryToLanguageMap() throws Exception {
        countryToLanguageMap = new HashMap<>();
        countryToLanguageMap.put("DE", "German");
        countryToLanguageMap.put("CN", "Chinese");
    }
    private void calculateBookingPrice(Document outDoc) {
        NodeList flightsList = outDoc.getElementsByTagName("Flight");

        int totalDiscountedPrice = 0;

        // Loop through each "Flights" element
        for (int i = 0; i < flightsList.getLength(); i++) {
            Element flightElement = (Element) flightsList.item(i);
            Element flightDateElement = (Element) flightElement.getElementsByTagName("Flight_Date").item(0);
            Element fullPriceElement = (Element) flightElement.getElementsByTagName("Full_Price").item(0);
            Element discountedPriceElement = (Element) flightElement.getElementsByTagName("Discounted_Price").item(0);

            // Get the values
            String flightDate = flightDateElement.getTextContent();
            int fullPrice = Integer.parseInt(fullPriceElement.getTextContent());

            if (isSlowSeason(flightDate)) {
                // Calculate the discounted price as 90% of the full price
                int discountedPrice = (int) (fullPrice * 0.9);
                discountedPriceElement.setTextContent(String.valueOf(discountedPrice));
                totalDiscountedPrice += discountedPrice;
            } else {
                totalDiscountedPrice += fullPrice;
                discountedPriceElement.setTextContent(String.valueOf(fullPrice));
            }
        }

        // Update the Total_Price element with the sum of discounted prices
        Element totalPriceElement = (Element) outDoc.getElementsByTagName("Total_Price").item(0);
        totalPriceElement.setTextContent(String.valueOf(totalDiscountedPrice));
    }
}

Sample Input XML

The sample XML data contains two flights, the first flight is in the peak season, and the second one is not.
It will be sent to the integration flow in later chapters.

<ns0:Ext_FlightBooking_MT xmlns:ns0="http://www.aif.com">
    <Agency_ID>1001</Agency_ID>
    <Customer_ID>100</Customer_ID>
    <Customer_Name>SAP Manager</Customer_Name>
    <Customer_Country>DE</Customer_Country>
    <Preferred_Language></Preferred_Language>
    <Total_Price />
    <Flight>
        <Airport_From>FRA</Airport_From>
        <Airport_To>SHA</Airport_To>
        <Flight_Date>20231001</Flight_Date>
        <Flight_Number>LH770</Flight_Number>
        <Seat_Class>B</Seat_Class>
        <Full_Price>1000</Full_Price>
        <Discounted_Price />
    </Flight>
    <Flight>
        <Airport_From>SHA</Airport_From>
        <Airport_To>FRA</Airport_To>
        <Flight_Date>20231201</Flight_Date>
        <Flight_Number>LH780</Flight_Number>
        <Seat_Class>B</Seat_Class>
        <Full_Price>1000</Full_Price>
        <Discounted_Price />
    </Flight>
</ns0:Ext_FlightBooking_MT>

Sample Output XML

The sample output XML is produced by the Java mapping.
It will be used to compare with the XML produced by the Groovy script in later chapters.

<ns0:Ext_FlightBooking_MT xmlns:ns0="http://www.aif.com">
    <Agency_ID>1001</Agency_ID>
    <Customer_ID>100</Customer_ID>
    <Customer_Name>SAP Manager</Customer_Name>
    <Customer_Country>DE</Customer_Country>
    <Preferred_Language>German</Preferred_Language>
    <Total_Price>1900</Total_Price>
    <Flight>
        <Airport_From>FRA</Airport_From>
        <Airport_To>SHA</Airport_To>
        <Flight_Date>20231001</Flight_Date>
        <Flight_Number>LH770</Flight_Number>
        <Seat_Class>B</Seat_Class>
        <Full_Price>1000</Full_Price>
        <Discounted_Price>1000</Discounted_Price>
    </Flight>
    <Flight>
        <Airport_From>SHA</Airport_From>
        <Airport_To>FRA</Airport_To>
        <Flight_Date>20231201</Flight_Date>
        <Flight_Number>LH780</Flight_Number>
        <Seat_Class>B</Seat_Class>
        <Full_Price>1000</Full_Price>
        <Discounted_Price>900</Discounted_Price>
    </Flight>
</ns0:Ext_FlightBooking_MT>

Generation

Prompt

For this sample, we use the following prompt:

Please convert this SAP Process Orchestration Java mapping code to Cloud Integration Groovy script, 
fulfill following requirements:
   1. Use Groovy 2 syntax, must compatible with JDK 8
   2. Generate def Message processData(Message message), don't wrap it in any class
   3. Follow the code pattern below:  
       def inputstream = message.getBody(InputStream) // get input stream  
       def outputstream = new ByteArrayOutputStream() // create output stream  
       transform(inputstream, outputstream) // transform data  
       message.setBody(outputstream) // set the output payload
   4. Prefer DOM to process XML 
   5. Import necessary packages, classes and interfaces 
   6. Import com.sap.gateway.ip.core.customdev.util.Message 
   7. Run the generated code by yourself, make sure no syntax error
   8. Just provide code, don't say anything else

Note: In this sample prompt, we prefer DOM to process XML, just because DOM is also used by the original Java mapping.
In your scenario, DOM might not be the right choice, especially when the XML payload size is big.

In the context of generative AI, the prompt is crucial for obtaining accurate and useful results. You can also try a tailored prompt that fits your specific requirements.

Use Generative AI

We use OpenAI's ChatGPT-3.5 model and invoke it via the official website UI.

Combine the prompt and the Java mapping source code together, the complete input message should be as below:

Please convert this SAP Process Orchestration Java mapping code to Cloud Integration Groovy script, 
fulfill following requirements:
    1. Use Groovy 2 syntax, must compatible with JDK 8
    2. Generate def Message processData(Message message), don't wrap it in any class
    3. Follow the code pattern below:
        def inputstream = message.getBody(InputStream) // get input stream
        def outputstream = new ByteArrayOutputStream() // create output stream
        transform(inputstream, outputstream) // transform data
        message.setBody(outputstream) // set the output payload
    4. Prefer DOM to process XML 
    5. Import necessary packages, classes and interfaces 
    6. Import com.sap.gateway.ip.core.customdev.util.Message 
    7. Run the generated code by yourself, make sure no syntax error
    8. Just provide code, don't say anything else
 
import com.sap.aii.mapping.api.AbstractTransformation;
import com.sap.aii.mapping.api.StreamTransformationException;
import com.sap.aii.mapping.api.TransformationInput;
import com.sap.aii.mapping.api.TransformationOutput;
import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.w3c.dom.NodeList;

import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;
import java.io.*;
import java.util.HashMap;
import java.util.Map;

public class BookingDataMapper_DOM extends AbstractTransformation {
    private Map<String, String> countryToLanguageMap;

    public void transform(TransformationInput transformationInput, TransformationOutput transformationOutput) throws StreamTransformationException {
        InputStream inputstream = transformationInput.getInputPayload().getInputStream();
        OutputStream outputstream = transformationOutput.getOutputPayload().getOutputStream();
        mapBookingData(inputstream, outputstream);
    }


    public void mapBookingData(InputStream inputstream, OutputStream outputstream) {
        try {
            DocumentBuilder docBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder();
            Document inDoc = docBuilder.parse(inputstream);
            Document outDoc = docBuilder.newDocument();
            outDoc = inDoc;

            setPreferredLanguage(outDoc);
            calculateBookingPrice(outDoc);

            Transformer transformer = TransformerFactory.newInstance().newTransformer();
            transformer.transform(new DOMSource(outDoc), new StreamResult(outputstream));
        } catch (Exception e) {
            e.printStackTrace();
            this.getTrace().addDebugMessage(e.toString());
        }
    }
    private void setPreferredLanguage(Document outDoc) throws Exception {

        Element preferredLanguageElement = (Element) outDoc.getElementsByTagName("Preferred_Language").item(0);
        if (preferredLanguageElement.getTextContent().isEmpty()) {
            loadCountryToLanguageMap();
            // Find the Customer_Country element
            Element customerCountryElement = (Element) outDoc.getElementsByTagName("Customer_Country").item(0);

            // Get the customer country value
            String customerCountry = customerCountryElement.getTextContent().trim();

            // Find the corresponding language in the map
            String language = countryToLanguageMap.get(customerCountry);

            if (language != null) {
                // Update the Preferred_Language element with the found language
                preferredLanguageElement.setTextContent(language);
            } else {
                preferredLanguageElement.setTextContent("English");
            }
        }
    }

    private boolean isSlowSeason(String date) {
        int iData = Integer.parseInt(date.substring(4));
        int iStartDate = 401;
        int iEndDate = 1031;
        return !(iData >= iStartDate && iData <= iEndDate);
    }

    private void loadCountryToLanguageMap() throws Exception {
        countryToLanguageMap = new HashMap<>();
        countryToLanguageMap.put("DE", "German");
        countryToLanguageMap.put("CN", "Chinese");
    }
    private void calculateBookingPrice(Document outDoc) {
        NodeList flightsList = outDoc.getElementsByTagName("Flight");

        int totalDiscountedPrice = 0;

        // Loop through each "Flights" element
        for (int i = 0; i < flightsList.getLength(); i++) {
            Element flightElement = (Element) flightsList.item(i);
            Element flightDateElement = (Element) flightElement.getElementsByTagName("Flight_Date").item(0);
            Element fullPriceElement = (Element) flightElement.getElementsByTagName("Full_Price").item(0);
            Element discountedPriceElement = (Element) flightElement.getElementsByTagName("Discounted_Price").item(0);

            // Get the values
            String flightDate = flightDateElement.getTextContent();
            int fullPrice = Integer.parseInt(fullPriceElement.getTextContent());

            if (isSlowSeason(flightDate)) {
                // Calculate the discounted price as 90% of the full price
                int discountedPrice = (int) (fullPrice * 0.9);
                discountedPriceElement.setTextContent(String.valueOf(discountedPrice));
                totalDiscountedPrice += discountedPrice;
            } else {
                totalDiscountedPrice += fullPrice;
                discountedPriceElement.setTextContent(String.valueOf(fullPrice));
            }
        }

        // Update the Total_Price element with the sum of discounted prices
        Element totalPriceElement = (Element) outDoc.getElementsByTagName("Total_Price").item(0);
        totalPriceElement.setTextContent(String.valueOf(totalDiscountedPrice));
    }
}

Submit the message, after a few seconds, ChatGPT will return code similar like below:

import com.sap.gateway.ip.core.customdev.util.Message
import org.w3c.dom.Document

import java.io.ByteArrayOutputStream
import java.io.InputStream
import javax.xml.parsers.DocumentBuilder
import javax.xml.parsers.DocumentBuilderFactory
import javax.xml.transform.Transformer
import javax.xml.transform.TransformerFactory
import javax.xml.transform.dom.DOMSource
import javax.xml.transform.stream.StreamResult

def Message processData(Message message) {
    def inputstream = message.getBody(InputStream) // get input stream
    def outputstream = new ByteArrayOutputStream() // create output stream
    mapBookingData(inputstream, outputstream) // transform data
    message.setBody(outputstream) // set the output payload
}

def mapBookingData(InputStream inputstream, ByteArrayOutputStream outputstream) {
    try {
        DocumentBuilder docBuilder = DocumentBuilderFactory.newInstance().newDocumentBuilder()
        def inDoc = docBuilder.parse(inputstream)
        def outDoc = docBuilder.newDocument()
        outDoc = inDoc

        setPreferredLanguage(outDoc)
        calculateBookingPrice(outDoc)

        Transformer transformer = TransformerFactory.newInstance().newTransformer()
        transformer.transform(new DOMSource(outDoc), new StreamResult(outputstream))
    } catch (Exception e) {
        e.printStackTrace()
        this.getTrace().addDebugMessage(e.toString())
    }
}

def setPreferredLanguage(Document outDoc) throws Exception {
    def preferredLanguageElement = outDoc.getElementsByTagName("Preferred_Language").item(0)
    if (preferredLanguageElement.getTextContent().isEmpty()) {
        loadCountryToLanguageMap()

        def customerCountryElement = outDoc.getElementsByTagName("Customer_Country").item(0)
        def customerCountry = customerCountryElement.getTextContent().trim()
        def language = countryToLanguageMap.get(customerCountry)

        if (language != null) {
            preferredLanguageElement.setTextContent(language)
        } else {
            preferredLanguageElement.setTextContent("English")
        }
    }
}

def isSlowSeason(String date) {
    def iData = Integer.parseInt(date.substring(4))
    def iStartDate = 401
    def iEndDate = 1031
    !(iData >= iStartDate && iData <= iEndDate)
}

def loadCountryToLanguageMap() throws Exception {
    countryToLanguageMap = new HashMap<>()
    countryToLanguageMap.put("DE", "German")
    countryToLanguageMap.put("CN", "Chinese")
}

def calculateBookingPrice(Document outDoc) {
    def flightsList = outDoc.getElementsByTagName("Flight")
    def totalDiscountedPrice = 0

    for (def i = 0; i < flightsList.getLength(); i++) {
        def flightElement = flightsList.item(i)
        def flightDateElement = flightElement.getElementsByTagName("Flight_Date").item(0)
        def fullPriceElement = flightElement.getElementsByTagName("Full_Price").item(0)
        def discountedPriceElement = flightElement.getElementsByTagName("Discounted_Price").item(0)

        def flightDate = flightDateElement.getTextContent()
        def fullPrice = Integer.parseInt(fullPriceElement.getTextContent())

        if (isSlowSeason(flightDate)) {
            def discountedPrice = (int) (fullPrice * 0.9)
            discountedPriceElement.setTextContent(String.valueOf(discountedPrice))
            totalDiscountedPrice += discountedPrice
        } else {
            totalDiscountedPrice += fullPrice
            discountedPriceElement.setTextContent(String.valueOf(fullPrice))
        }
    }

    def totalPriceElement = outDoc.getElementsByTagName("Total_Price").item(0)
    totalPriceElement.setTextContent(String.valueOf(totalDiscountedPrice))
}

Note: Don't expect you will get the exact same code as above.
Usually, you will get (slightly) different code every time. And it is very possible that the code you get has syntax issues. You can copy the code into your IDE to check the syntax issues.

The most common issues could be:

The org.w3c.dom.Document class is not imported, you need to add the import statement manually
Other used classes not imported, you need to check and import the missing classes manually

Alternatively, OpenAI also provides rest API and even programming libraries, you can also programmatically invoke it.

Evaluation

Create Testing Integration Flow

After verifying the syntax of the generated Groovy script, we will run it in a testing integration flow, which contains the following steps:

a HTTPS sender adapter

a Groovy script to log the input XML payload

Sample code:

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

def Message processData(Message message) {
    def body = message.getBody(java.lang.String);
    def messageLog = messageLogFactory.getMessageLog(message);
    messageLog.addAttachmentAsString("In_Payload", body, "text/plain");
        
    return message;
}

a Groovy script that contains the generated Groovy code

a Groovy script to log the output XML payload (produced by the generated Groovy code)

Sample code:

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

def Message processData(Message message) {
    def body = message.getBody(java.lang.String);
    def messageLog = messageLogFactory.getMessageLog(message);
    messageLog.addAttachmentAsString("Out_Payload", body, "text/plain");
        
    return message;
}

The diagram below depicts the main steps of the integration flow.

Copy the generated Groovy code to the middle Groovy script step, deploy the testing integration flow, we can get a URL to receive new message.

Next, we send the input XML using an HTTP client tool such as Postman or Insomnia.

<ns0:Ext_FlightBooking_MT
	xmlns:ns0="http://www.aif.com">
	<Agency_ID>1001</Agency_ID>
	<Customer_ID>100</Customer_ID>
	<Customer_Name>SAP Manager</Customer_Name>
	<Customer_Country>DE</Customer_Country>
	<Preferred_Language></Preferred_Language>
	<Total_Price/>
	<Flight>
		<Airport_From>FRA</Airport_From>
		<Airport_To>SHA</Airport_To>
		<Flight_Date>20231001</Flight_Date>
		<Flight_Number>LH770</Flight_Number>
		<Seat_Class>B</Seat_Class>
		<Full_Price>1000</Full_Price>
		<Discounted_Price/>
	</Flight>
	<Flight>
		<Airport_From>SHA</Airport_From>
		<Airport_To>FRA</Airport_To>
		<Flight_Date>20231201</Flight_Date>
		<Flight_Number>LH780</Flight_Number>
		<Seat_Class>B</Seat_Class>
		<Full_Price>1000</Full_Price>
		<Discounted_Price/>
	</Flight>
</ns0:Ext_FlightBooking_MT>

Note: To send a message to the HTTP sender adapter, you need to generate a service key and obtain the authorization token.
How to create the service key and get the token is out of scope of this blog.

Alternatively, you can use the simulation feature to test the Groovy script step before you deploy the integration flow.

Verify Output

After sending the new message to the integration flow, we can check the message status in the monitor of Integration Suite.
We can see both input and output payload have been saved as attachments.
Check the content of the output payload, it should be the same as the XML produced by Java mapping.

Note: It is not uncommon that the messages run into error status.

Sometimes, it complains syntax-related issues, sometimes it complains logical issues.
In any case, you can iterate the process. I.e., copy the error message, send it to ChatGPT (in the same session you generate the code), ask it to fix the issues, and then do the evaluation again.
Of course, you can also check the code and fix the issues by yourself.

Disclaimer

Generative AI and Large Language Model (LLM)

Security

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.

Suitable Scenario

The most suitable scenario for this idea is: The Java mapping does not have too many dependencies.

This will increase not only the cost of AI token consumption but also the complexity of code integration (combining different codes together).

What's New for SAP Integration Suite - January 2024

2024-02-12T12:43:09.193000+01:00

The new year has started already with big steps, and it is time to present the January highlights of SAP Integration Suite. Detailed presentations and a Q&A section with helpful questions by you, you find in the recording of our Monthly Updates webinar that happened last week.

SAP Integration Suite highlights are:

AdvancedEventMesh adapter for event mediation
Simply search for a flow step in complex integration flows
Manual configuration of proxy settings for some adapters in Edge runtime
Reminder: Upgrade to new version of third-party connectors before March 2024
Simplified mass-maintenance in TPM via extended agreement template configuration
Support for custom SOA messages in Integration Advisor
New Tradacoms message standard
New rules for Migration Assessment
Message mapping and function library integration in migration tool
Virtual host information as part of the API for Edge Integration Cell
New pre-built integration content by our partners

Cloud Integration

AdvancedEventMesh adapter for event mediation

We have recently published the AdvancedEventMesh adapter connecting the Cloud Integration with advanced event mesh brokers through the Solace message format (SMF) message protocol. You may consume in Cloud Integration guaranteed messages from queues or non-persistent messages using a topic subscription. And you can send messages to queues or topics. The adapter is designed to handle large-scale event processing, making it suitable for enterprise-level applications. It is available with the SAP Integration Suite, standard and premium editions. See the initial version of the sender and receiver adapters at the SAP Business Accelerator Hub and check the details within the documentation.

Simply search for a flow step in complex integration flows

The integration flow editor in Cloud Integration has been extended offering you a search for an existing flow step. Within the palette you can search the step by its type, name, or ID. This search is also available for deployed integration flows and accessible from the runtime views (Monitor and Inspect). This extremely helpful feature helps you e.g., to easily identify a step causing an issue like memory exhaustion as you can copy a step ID in Inspect and navigate to the flow view. Refer to the documentation.

Manual configuration of proxy settings for some adapters in Edge runtime

We have enabled the following adapters to support the proxy type manual in case you have set the Edge Integration Cell as runtime profile. With this setting you can configure the proxy host and port by yourself. Supported are the adapters ELSTER receiver, SFTP sender, SFTP receiver, and SFTP sender adapter used with the poll enrich step.

Reminder: Upgrade to new version of third-party connectors before March 2024

As per SAP note 3001980 the following previous adapter versions are deprecated since end of 2020: Salesforce, Amazon Web Services, Microsoft Dynamics, SugarCRM. There haven't been any new features or enhancements for these previous adapter versions. As of March 1st, 2024, the previous adapter versions will no longer run.

Action is urgently required from the customer side. Please either migrate to updated new adapter versions and benefit from new features (request access to migration documentation by annemarie.kiefer@sap.com) or purchase new Advantco adapter versions from Advantco with support from Advantco only. Additionally, you must delete integration flows using the adapters that are no longer in use and undeploy the adapters.

B2B Integration

Simplified mass-maintenance in TPM via extended agreement template configuration

Minimize the efforts required to establish trading partner scenario by reusing a common mapping across multiple agreements. Additional to copying an agreement from a template it is also possible now to create a new trading partner agreement by referencing to the template. With this new option you may change the common mapping and do a refresh for all bound trading partner agreements. For more information refer to the documentation.

Support for custom SOA messages in Integration Advisor

We are more and more extending the set of supported a third custom type system. It is already possible to upload custom messages as XSDs or custom IDocs (refer to recently published blog post). Now you may upload also proprietary or modified SAP S/4HANA SOA messages as a WSDL file. With this new feature you may add new nodes or reorder nodes in standard SAP S/4HANA SOA messages or create your own SOA messages. Migration of existing standard message MIGs to a custom message MIG is supported. And the proposal service of the Integration Advisor will use MIGs based on these messages and enrich its knowledge graph. For more information refer to our documentation.

New Tradacoms message standard

The new message standard Tradacoms has been introduced in December already. GS1 Tradacoms was the core message standard from early days in Retails for EDI. Therefore, important to have it in the Cloud now. A new blogpost has been published detailing out how to use it.

API Management

Edge Integration Cell API shows virtual host information

When using the wizard for designing an API for the Edge Integration Cell runtime, the selected runtime profile now shows the virtual host information for this API. For more information, see the documentation pages create an API artifact using URL and create an API using an imported API definition.

Migration Assessment and migration tool

New rules for Migration Assessment

We have released a couple of new rules for improving the assessment results of the Migration Assessment capability that is used to assess the effort and the feasibility of the migration of SAP Process Integration / SAP Process Orchestration scenarios to the Cloud Integration capability of SAP Integration Suite.

Message mapping and function library integration in migration tool

Customers moving their integration projects to SAP Integration Suite can now import Integrated Configuration Object (ICOs) that contain message mapping objects with dependent resources such as function library objects. In Cloud Integration, reusable message mapping artifacts are created. Within the migration wizard you have also the option to import only supported message mapping objects and skip the unsupported ones.

Additionally, new migration templates such as for multicast and for recipient list with order at runtime have been shipped. And an AS2 adapter with preset parameters is now generated in Cloud Integration if you have a scenario with AS2 adapter in SAP Process Orchestration.

SAP Business Accelerator Hub

New pre-built integration content has been published by our partners to our public central content catalog, the SAP Business Accelerator Hub. For customers from the B2B sector, PROCLANE has published Salesforce and PAYONE adapters. Effective People A/S offers an event-driven integration to generate employee initials within the SAP SuccessFactors EC. Pricefx comes with new integrations with SAP S/4HANA and Degreed with SAP SuccessFactors integration packs. Check out the blogpost New partner content on SAP Business Accelerator Hub (Q4 ’23) and access the partner listing on SAP Business Accelerator Hub that is going along with all published content. In case you are interested in partnering with us see the details of our partner program.

How to stay tuned on recent and upcoming innovations?

The SAP Road Map Explorer is your one-stop shop for all SAP Integration Suite innovations. You can easily check out the latest innovations and follow what is planned for the following quarters. All recent innovations also cover under the tab Features further links to blogposts or documentation.

We also refer to the complete list of new releases in our documentation: What’s New in SAP Integration Suite.

And if you have not heard of our monthly webinars, I suggest you sign up to get an invitation to the upcoming ones. Our team of Product Management experts host these webinars to showcase the latest and greatest updates regarding all SAP Integration Suite capabilities. The webinars are hosted on the last Tuesday of every month and the next one is already scheduled for February 27th.

In case you have missed our last monthly webinar, don’t worry. Visit 2024 Learning Sessions for SAP User Groups on SAP Integration Suite for all recordings, presentations, and Q&As.

Are you aware of the Release Navigator for SAP BTP? It consolidates release information across SAP BTP products and services easing you the way to find product release related notes, blogposts, and webpages. For your convenience use the direct link to the SAP Integration Suite section of the Release Navigator.

SAP Integration – Make your SAP Migration Assessment for SAP PO more accurate with the aRC Analysis

2024-02-13T09:37:51.826000+01:00

The maintenance of SAP Process Orchestration expires at the end of 2027 – this should no longer be news to most integration managers. From this point on, support must be provided by each customer themselves (extended support). In addition, innovations will no longer be implemented in the on-premise SAP PO. So it´s really time to migrate to the SAP Integration Suite. Many of the components of the SAP Integration Suite (e.g. SAP Cloud Integration) have been on the market for a long time now and are well established. In addition, new functionalities such as the recently introduced Edge Integration Cell round off the functional scope of the SAP Integration Suite. A good summary of all the reasons to move to SAP Integration Suite can also be found here.

Apart from the functional point of view and the end of maintenance, there are also strategic reasons to start your migration now:

Correlation with SAP S/4HANA transformation projects – an S/4HANA project is no reason to postpone an SAP PO migration, but to utilize synergies here and migrate the interfaces at the same time
Use your migration project to clean up you legacy SAP PO systems and get rid of unnecessary interfaces and obsolete technology stacks
Depending on your migration approach (Greenfield, Brownfield, Selective) the migration project can be very complex and therefore take a lot of time

There are various tools on the market to support you on your estimation of your SAP PO to SAP Integration Suite migration project. In this Blog post I would like to outline the different advantages between the SAP Migration Assesment and the RealCore aRC Analysis tool.

SAP Migration Assement is part of SAP Integration Suite (availablity depending on service plan in SAP BTP Cloud Foundry environment). After enabilig the Migration Assesment capability in SAP BTP Cockpit and adding your SAP Process Orchestration System (7.31 SP28 and above, 7.40 SP23 and above, 7.50 SP06 and above), the migration assesment process can be done in two steps:

Data Extraction Request
Scenario Evaluation Request the receive evaluation results via .xslx oder .pdf file

aRC Analyse stands for Analyse Rate Cost and is also a tool based approach the estimate the migration effort for a SAP PO to SAP CPI migration project. Unlike the SAP Migration Assesment Check there is no need for a SAP Integration Suite Tenant in advance. After installing the tool and adding SAP PO System, we also start with the data extraction:

Analyse: Extract Data like all parties, business systems & components. communication channels, adapters and adapter modules, additionally analyse of all mappings (quantity and categorisation in types) and extraction of all unused objects
Rate: The rating is based on the analyses of the configration scenarios. Every CS element is checked for their migraiton capability and rated on a sacle from 0-10. Based on those ratings a individual roadmap for the migration and different reportings are generated.
Cost: We create for you not only a cost report for the migration effort but also a operating cost calculation based on the extracted message volumes

ARC-Analysis Loading Configuration Scenarios - Initial Screen

Both tools provide different types of advantages for your analysis:

SAP Migration Assesment Check	aRC Analyse
Efforts are calculated with learning effects (many identical interfaces) – certain number and fixed value without prices The migration capability is based on the possibilities of the tool (uses defined SAP templates). With new templates, the checks will be more precise and better in future With existing cloud integration simple execution. Deployable on Cloud Integration	Shows unused objects Presentation per scenario and therefore rather on a migration path Calculation of all costs (documentation effort, test effort, GoLive support,etc. ) Evaluation of message volumes and therefore information about license costs and costs per interface aRC Analysis is also possible without Integration Suite and Cloud Connector Deployable local

Both tools reports can be downloaded as .pdf and .xls files, so you can work with them offline.

The aRC Analyse gives you an overview about all unsed objects in your SAP PO, that means all objects that have no used. For example you get all mappings that where not used in ICOs or Operation Mappings. This not only makes the effort estimate more accurate, as these orphaned objects are no longer taken into account, but also provides an overview of objects that can be cleaned up before the project start.

A big advantage is that aRC analysis gives you an indication of the costs for using the running service. This means that there is a calculation on different metrics what the cost in operation would be. Expecially if SAP will take cost for message size and message count in future.

The presentation per scenario instead of considering only ICOs provides the possbility to look if ICOs are used multiple times. So the cost for migration could be more accurate.

ARC Analysis - Scenario-based Analysis

In the meantime you can also have a report on ICO level so you can have a look on szenario costs and can compare it on ICO costs.

Additonally the aRC analysis groups all Adapters and ESR objects on the categories based on their migration complexity.

So we have categories for easy, medium and hard to migrate objects.

Easy	Medium	Hard
ICOs without mapping, rules or conditions	adaptermodules and mappings also java and xslt	File Adapter, X400 Adapter
Adapters like SOAP, REST, SFTP, HTTP, AS2	Lookups	operation mappings with parameters own developed adaptermodules
here migration is possible with automatic tools	here migration is possible with manually work and automatic tools	here migration has to be done manually and maybe with redesign of interfaces

Example Report

One more advantage of aRC analysis is that you can work with parameters for the single tasks. This means you can configure via excel your parameter for the times of single tasks.

The aRC analysis has many advantages for the estimation of a project (volume, holistic effort) and helps to reduce the complexity of the SAP PO before the migration.
With this tried-and-tested procedure, both tools can be used and the results summarized to get a more accurate estimation result.

Furthermore the aRC analysis is continiuos improved, as well as the SAP Migration Assement Check tool.

Integration Advisor: Using the Pre-Transformation feature within a Mapping Guideline (MAG)

2024-02-15T17:09:35.581000+01:00

Introduction

Hello dear SAP Integration community,

In this Blog I want to show how to use one of the powerful features in Integration Advisor - the "Pre-Transformation". This feature allows to transform the source Message Implementation Guideline (MIG) structure which significantly simplifies the logic between source and target within the Mapping Guideline (MAG).

In this case a shipment based advanced shipping notification which is a key document in collaboration between suppliers and customers is exchanged. A SOAP message is send from SAP S/4HANA which must be transformed to UN/EDIFACT and send to the specific Trading Partner.

Please note that the scope of this blog does not describe how to create and qualify MIGs. As a starting point you can refer to this blog: Create a customized interface using MIG editor

Real world challenge

The shipment on the source side consists of multiple item segments, one with the gross details, multiple with package details and multiple with product details. They are all on the same segment level.
However, one package can contain multiple products. And that is how the target side is expecting the content.

Ideally, we should transform the source message in such a way that we group all products together which belong to one package.

Solution

Looking at the source payload, for each PRD item an additional segment <HierarchyRelationship> is created pointing to the relevant PKG:

And that is the information we need to do the Pre-Transformation.

In this case we have following relationship:

PKG ID	PRD ID
10	150, 200, 160, 220, 230
70	170
90	180
110	190
130	210

So 5 Packages and 9 Products whereas one of the packages contain 5 products.

Let's jump into the MAG:

What do we want to do exactly?
We want to copy the item segments qualified with PRD into the item segment qualified with PKG where the IDs are matching.
Which can be achieved by the following:

Simulation

Let's see what the result looks like.

Here on the right side (After Pre-Transformation) we can see that inside Item (Package) another node has been created - Item_gq_PRD_Copy. The first package with ID=10 has 5 Item_gq_PRD_Copy elements (see the yellow highlighted area). Inside the first package the first product has the ID=150. Now let's look at the second product:

Here we can see that it has the ID=200. And this matches with the table above.

Conclusion

In this blog article we showed the powerful and easy to use feature of the Pre-Transformation, where we transformed the source structure in such a way that it matches the structure of the target which expects to group all products belonging to one package.
Especially in this case, the Pre-Transformation helps to avoid building complex mapping logics which is also an essential aspect and which will be beneficial for operations.

Step by Step process to migrate B2B Inbound EDIFACT Interfaces from SAP PO to CI(CPI) w/o TPM

2024-02-19T08:08:39.884000+01:00

This blog provides a step by step process to migrate, simple, point to point B2B outbound EDIFACT interfaces from SAP PO to Cloud Integration (CPI) without TPM.

I have taken an example of an outbound invoice interface (Own system --> Trading Partner) to explain the process

System Type: UNEDIFACT

Message Type: INVOIC

Version: 96A

Introduction

When we talk about migrating B2B interfaces which are in SAP PO to cloud then there are below options.

Create MIGs, MAGs and implement the interface using SAP Trading Partner Management (TPM) and leverage B2B monitoring
Migrate the interface from SAP PO to Cloud Integration without using TPM.
Migrate the interface from SAP PO to Cloud using both Cloud Integration and TPM

Migrating by implementing the B2B interfaces via TPM comes with a lot of benefits and best practices. Please refer to the blog for more details but there are customers who wants to avoid time and effort in creating MIGs, qualifying the fields, redoing the MAGs, testing, and implementing via TPM. They want to reuse the existing simple B2B mappings done in SAP PO system.

Hence, in this blog, we will focus on the option #2 with step-by-step approach to easily migrate B2B outbound EDIFACT interfaces from SAP PO to Cloud Integration

Note: This approach works for message mapping with function libraries without imported archive. To import it to Cloud Integration, please refer blog .

Pre-requisite

Connection between SAP PO and Cloud Integration is already set up. Please refer blog

Steps to Migrate

In this case, we will concentrate on migrating a outbound INVOIC interface (Own system --> Trading Partner) from SAP PO to Cloud Integration

1. Create a package, Click on Edit --> Migrate

2. Select your already configured SAP PO system from the drop-down --> Next Step

3. Select Integrated Configuration (ICo) of the B2B interface you wish to migrate.

4. ICo selected will be reviewed dynamically by the tool and following template proposals are provided.

5. For Simplicity purpose, I will select the below template and click on Next Step

Update: For the list of supported templates available, please refer Supported Templates

6. Provide a name for your iFlow --> Review --> Migrate --> View Artifact

7. Click on Configure - to configure sender and receiver channels.

8. In the Local integration process, you can see the mapping migrated from SAP PO

9. If you have any fields, which is using $B2B_END_UEBNR for unique numbers which is a parameter in SAP PO then follow below steps.

1. Open another tab, to create NRO as below.

2. Add Content modifier before SAP PO mapping and set exchange property.

3. Click on create to create a custom function

4. Add the below code

import com.sap.it.api.mapping.*;
def String customFunc1(String P1,MappingContext context) {    
         String value1 = context.getProperty(P1);
         return value1;
}

Update:

Now, in CI we have standard function "getProperty" available. Hence, please use this function instead of above mentioned custom. In the property name maintain the the value as ICN_DEFAULT

5. Do the mapping as below for all the fields which is using SAP PO NRO parameter, $B2B_END_UEBNR, save and deploy the message mapping

10. If your mapping is using $B2B_SEG_COUNTER to count the number of segments which is the value for the field D_0074 under the segment, S_UNT, then we will make use of XSLT mapping

1. Add a property in the content modifier. This property will be called in the XSLT mapping.

2. Create a XSLT Mapping next to the imported message mapping and add the below code

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <!-- Declaring the Parameter -->
    <xsl:param name="MessageType"/>
    
    <!-- Matching the template -->
    <xsl:template match="@*|node()">
        <xsl:copy>
            <xsl:apply-templates select="@*|node()"/>
        </xsl:copy>
    </xsl:template>
    
    <!-- Matching the template for D_0074 under S_UNT where segment count is added -->
    <xsl:template match="S_UNT/D_0074">
        <xsl:copy>
            <!-- Use the parameter in the XPath expression -->
            <xsl:value-of select="count(//*[starts-with(name(), 'S_')][ancestor-or-self::*[name()=$MessageType]])"/>
        </xsl:copy>
    </xsl:template>
    
    <!-- Template to remove "_1" from node names -->
    <xsl:template match="*[substring(name(), string-length(name()) - 1) = '_1']">
        <xsl:element name="{substring-before(name(), '_1')}">
            <xsl:apply-templates select="@*|node()"/>
        </xsl:element>
    </xsl:template>
    
</xsl:stylesheet>

Parameter can be changed based on the message type used in the flow to make this XSLT mapping dynamic. Template to remove _1 from the node names is added to convert PO xml to CI (CPI) specific xml.

11. Final step would be to download the EDIFACT xsd from Integration Advisor. In this case it is “UN-EDIFACT_INVOIC_D96A.xsd”, add the XML to EDI converter and add the downloaded xsd.

Update: For steps to download the xsd from Integration Advisor, please refer blog

12. That’s it, save and deploy the iFlow!

Now, when an IDOC is triggered to this iFlow, you will be able to see that the IDOC gets converted successfully to EDI format and the unique values from NRO and segment counters are also populated correctly .

Unique values from NRO for the field D_0020

Segment counter for the field D_0074

Summary

These steps will help to easily and quickly migrate simple, point to point B2B outbound EDIFACT interfaces from SAP PO to CI. This will help in reusing the existing mapping done in SAP PO. This blog also explained how SAP PO parameters like $B2B_END_UEBNR and $B2B_SEG_COUNTER are replaced in SAP Cloud Integration.

Note: Inbound EDIFACT interfaces will require more modifications and it cannot be used directly from the EDI to xml converter in the imported PO mapping.

In my next blog, I will try to cover how to migrate inbound EDIFACT interfaces w/o using TPM.

Please feel free to discuss your experience with B2B migration from SAP PO to cloud in the comment section of this blog post.

PGP Encryption/Decryption using Java code inside payload

2024-03-01T10:51:37.554000+01:00

In this blog, I will retrace the steps that I have used to encrypt and decrypt payload coming inside message tags using PGP encryption/decryption. After many searches and tries, I was able to find a blog by Sandeep using Bouncy Castle,
https://community.sap.com/t5/additional-blogs-by-members/pgp-encryption-decryption-using-java-code/ba-p/12912768
This is an update to the same blog where I have worked around the mentioned trick without using Bouncy Castle to add the encrypted payload within the messages.

For OpenPGP encryption and decryption, the requirement that I had was to convert the generated message through BCM(Bank Communication Management) by first encrypting with PGP encryption and then converting to base64 while having this within the payload.

INBOUND flow

Download the necessary libraries required.
bcpg-lw-jdk15on-1.70.jar
bcprov-lw-jdk15on-1.70.jar
pgplib-3.2.3.jar
com.sap.xi.mapping.tool.lib_api.jar
com.sap.xpi.ib.mapping.lib.jar

You can get the first 3 libraries from the below link
https://didisoft.com/java-openpgp/
The other 2 libraries are sap standard libraries used in Java mapping or any UDF concerned, if required I will also try to attach the same on edit.
Next step, you have to generate your keys, I have used GPG4WIN 3.1.9 to generate keys

Post your keys generation, you will have 3 keys, one public key from the bank and 2 keys generated at your end, one public and one private.
You have to store the keys in the OS folder such that your Java code can access the keys, I have mentioned the path in which I have stored them for your reference. You have to use SKR for private keys and PKR extension for public keys.
```
/usr/sap/XXX/X00/<your_custom_folder>/privatekey.skr
```
I have used Eclipse for my Java code development, as currently NWDS is not available. Below is the reference path of the package I have used, I have inserted keys within the package and reference libraries which I have uploaded.
package content
reference libraries
Below is the encryption Java code that I have used, I have used many "getTrace" code which is for my reference, you can remove them or add additional ones based on what you prefer during testing.

package z001;

import java.io.InputStream;
import java.io.OutputStream;
import com.sap.aii.mapping.api.*;
import java.io.*;
import java.util.Base64;
import com.didisoft.pgp.PGPLib;
public class encrypt extends AbstractTransformation {
	 @Override

	    public void transform(TransformationInput transformationInput, TransformationOutput transformationOutput) throws StreamTransformationException {
		 try{     
		       
			    PGPLib pgp = new PGPLib();
			     String privateKeyFile = "/usr/sap/XXX/X00/<your_custom_folder>/privatekey.skr";
			     String privateKeyPassword = "<your_key_password>";

			     String publicEncryptionKeyFile = "/usr/sap/XXX/X00/<your_custom_folder>/bankkey.pkr";        
			     
		        InputStream inputStream = transformationInput.getInputPayload().getInputStream();
		        
		        BufferedReader inpxml = new BufferedReader(new InputStreamReader(inputStream));
		        getTrace().addInfo("input received");
		        StringBuffer buffer = new StringBuffer();
				   String line="";
				   while ((line = inpxml.readLine()) != null)
				   {
				   buffer.append(line);
				   }
				   String org_msg=buffer.toString();
				
				   OutputStream outputstream = transformationOutput.getOutputPayload().getOutputStream();
				   
				   getTrace().addInfo("encrypt");
				   
				   String signedAndEncryptedString = 
					          pgp.signAndEncryptString(org_msg,
					                                   privateKeyFile, 
					                                   privateKeyPassword, 
					                                   publicEncryptionKeyFile);
				   
				   getTrace().addInfo("encode");
				   
				   byte[] bytes = signedAndEncryptedString.getBytes(); 
				   String encodedString = Base64.getEncoder().encodeToString(bytes);
//					   int msg_length = org_msg.length();
				   getTrace().addInfo("finalstructure");
				   String target_msg = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>"+"<ns0:MT_bank_Pay_Request xmlns:ns0=\"http://x.com/bank_Payment\">"+"<paymentBase64>"+encodedString+"</paymentBase64>"+"</ns0:MT_bank_Pay_Request>";
				   outputstream.write(target_msg.getBytes());
//this is to get the final target message that we have converted
				   getTrace().addInfo("finalstructure"+target_msg);
		 }
		   catch (Exception ie) {
		  }
		      
	    } 
}

This will convert the final message below

<?xml version="1.0" encoding="UTF-8">
<ns0:MT_bank_Pay_Request xmlns:ns0="http://x.com/bank_Payment">

<paymentBase64>"your encoded and encrypted string"</paymentBase64>

</ns0:MT_bank_Pay_Request>

OUTBOUND flow
This is the response from the bank side that I was receiving, here in responsebase64 I had the original file content response, which needed to be decoded and decrypted.

<?xml version="1.0" encoding="UTF-8"?>
<ns0:MT_Vendor_Pay_Response xmlns:ns0="http://x.com/bank_Payment">
   <referenceId>1</referenceId>
   <profileId>2</profileId>
   <statusCode>3</statusCode>
   <statusDesc>5</statusDesc>
   <responseBase64>6</responseBase64>
</ns0:MT_Vendor_Pay_Response>

For decryption, in the below Java code, you can see the original content (which is encrypted and encoded) is within the responsebase64 tag, if blank I am generating a different XML response, but if non-blank I will be consuming the payload within SAP PO. Integration response will be generally provided by the bank side, you can add the dummy payload as same as the response you are having from the bank.

package z001;

import com.sap.aii.mapping.api.*;
import java.io.*;
import java.util.Base64;
import com.didisoft.pgp.PGPLib;

public class decrypt extends AbstractTransformation {
	@Override
	public void transform(TransformationInput transformationInput, TransformationOutput transformationOutput)
			throws StreamTransformationException {
		try {
			PGPLib pgp = new PGPLib();
			String privateKeyFile = "/usr/sap/XXX/X00/<your_custom_folder>/privatekey.skr";
			String privateKeyPassword = "<your_key_password>";

			InputStream inputStream = transformationInput.getInputPayload().getInputStream();
			OutputStream outputstream = transformationOutput.getOutputPayload().getOutputStream();

			BufferedReader inpxml = new BufferedReader(new InputStreamReader(inputStream));
			getTrace().addInfo("input received");
			String originalFileName = "";
			StringBuffer buffer = new StringBuffer();
			String line = "";
			while ((line = inpxml.readLine()) != null) {
				buffer.append(line);
			}
			String org_msg = buffer.toString();
			String s3 = org_msg;
			String isFound = "";
			String headerstatus = "";
			String headerdesc = "";
			String responsebase64 ;
			headerstatus = s3;
			headerdesc = s3;
			responsebase64 = s3;
//I have used index here as my response was having status code and message
//which i have capture in local variable.
			headerstatus = headerstatus.substring(headerstatus.indexOf("<statusCode>") + 12);
			headerstatus = headerstatus.substring(0, headerstatus.indexOf("</statusCode>"));
			getTrace().addInfo(headerstatus);

			headerdesc = headerdesc.substring(headerdesc.indexOf("<statusDesc>") + 12);
			headerdesc = headerdesc.substring(0, headerdesc.indexOf("</statusDesc>"));
			getTrace().addInfo(headerdesc);
//orginal response was coming after <responseBase64> tag which is capture here
			responsebase64 = responsebase64.substring(responsebase64.indexOf("<responseBase64>") + 16);
			
			getTrace().addInfo(responsebase64);
			
//I am checking here if response is there or not, if not i am making a custom xml
			if ( responsebase64.indexOf("</responseBase64>") == 0)
			{

				isFound = "N";
			}
			else
			{
				responsebase64 = responsebase64.substring(0, responsebase64.indexOf("</responseBase64>"));
				isFound = "Y";
			}
				
				
			getTrace().addInfo("truecheck" + isFound + responsebase64);
			if ( isFound == "Y" ) 
			{
				getTrace().addInfo("ifcheck");
				org_msg = org_msg.substring(org_msg.indexOf("<responseBase64>") + 16);
				org_msg = org_msg.substring(0, org_msg.indexOf("</responseBase64>"));
				getTrace().addInfo("beforedecoding" + org_msg);
				byte[] decodedBytes = Base64.getDecoder().decode(org_msg);
				getTrace().addInfo("decoded");
				String decodedString = null;
				// Get the string of decoded byte array
				String s = new String(decodedBytes);
//		  String encrypted = "";
				decodedString = s;

				getTrace().addInfo("beforedecryption");
//this is the decryption code, you can use it based on ur use case
				originalFileName = pgp.decryptString(decodedString, privateKeyFile, privateKeyPassword);
//end of decryption code
				getTrace().addInfo("decrypted" + originalFileName);
			}
			
			else 
			
			{
				getTrace().addInfo("elsecheck");
				String so = originalFileName;	
				if (so == "") {
///if the code is blank					
					originalFileName = "<?xml version=\"1.0\" encoding=\"UTF-8\"?>\r\n"
							+ "<ns0:Document xmlns:ns0=\"urn:http://x.com\">\r\n" + "<paymentresponseBase64>"+"FAILED"+"</paymentresponseBase64>"

+ "</ns0:Document>";
				}
			}
			String target_msg = originalFileName;
			getTrace().addInfo("finalstructure" + target_msg);
			outputstream.write(target_msg.getBytes());

		}

		catch (Exception ie) {
		}
	}
}

Note:
I have used the above code based on my use case, you can play around with the Didisoft libraries and choose what fits best. For the adapter level, many modules and blogs are available that can be used to do the encryption and decryption.
Keep track of the expiry of keys, would be helpful for you as a change in year-end activity.

Analyze Your SAP PI/PO System Before a Migration to Integration Suite

2024-03-05T14:30:56.817000+01:00

Before you can create any SAP PI/PO migration you need to plan and budget for a migration project. It is not an easy to do task and there are a lot of factors you should consider.

SAP has their migration assessment tool, that you can trigger to fetch data about your current system and landscape. I strongly encourage you to run it and get the details from it. The more perspectives you have on your integration, the better.

At Figaf we also have our report over your landscape. It does not come with any timeline on how long it should take to process each migration. It is something that is up to you to process with your landscape.

How Figaf collects data

Once you install Figaf and it connect to your SAP PI/PO system it collects a local version of all objects. Then it links all objects to so we got a tree of the objects. This is the same as SAPs tool does.

You can use our free migration edition, which will also help you test the migration and allow you to try our migration tool. You can install Figaf on a laptop for a PoC or on BTP for productive usage.

Figaf report

Once data is collected, you can generate a report like the following with all data.

You will need to go through and find:

The different types of adapters used. It is mainly the first time you connect with an adapter that it will cost you time.

Number of different modules you need to support and how critical it is

Number of EDI interfaces

Find problems that cannot be migrated

Once you have gone thru the list it becomes easier for you to estimate how many interfaces you need to migrate.

The small differences

With the projects we have been working with we have found that it is small details that makes or breaks if a migration will work. Some of the recent challenges we have come up with are:

Local function in a message mapping that are using Imported Archives

Message mapping that links to an Imported Message. Something we have only seen in old mappings.

And you will probably find a lot of other cases

In our latest release (2402) of Figaf we have created a option to callow you to create your own rules via Xpath or Regex. Then it will find all objects in your ESR or Directory that matches this. On a call we should the team in about 5 minutes how to create a new rule to cover checking for the second case. Then we could see less than 10 mappings were affected so no need to automate a workaround. If it was 20-50 we may have considered improving to fix this case.

For 1. Figaf allows you to extract the UDF to a groovy script as we do for Function Libraries. This gives you a way to edit and manage the content much more accessible.

To create a new rule check the following guide

I hope this will be a part of your migration toolbox.

Pilot project

The assessment is not something that can stand alone. Running a pilot project where you migrate some integrations with the different options SAPs, Figafs or manual migration will give you much more data about how to get started.

Also consider the effort of moving it into production and all the steps involved, like testing and go live considerations.

What’s New for SAP Integration Suite – February 2024

2024-03-12T09:22:05.281000+01:00

Before going into the highlights of our innovations, we are thrilled to inform you that SAP Integration Suite has been recognized as a Leader in the latest Gartner Magic Quadrant for Integration Platform-as-a-Service (iPaaS) for the fourth consecutive time. We are convinced that we have been received this recognition for our commitments to deliver a top-tier customer-centric integration solution, the ability to accelerate business outcomes through prebuilt content, ongoing innovation, the global geographic strategy, and readiness for the future. And a big thanks also goes to you in supporting us with all your great feedback. For more details checkout the blogpost and the SAP News article.

SAP Integration Suite highlights are:

JMS receiver adapter: property to identify sending integration flow
Inspect resource consumption through SAP Cloud ALM/SAP Focused Run
Call to action: Upgrade to new version of third-party connectors
Duplicate nodes on target side in a MAG
Definition of more complex code value mapping scenarios
Add metadata for OData-based API artifacts deployed on Edge Integration Cell
Enhancement of security standards in API Management
Policy templates in API Management
Distributed tracing in advanced event mesh
Direct consumption of SAP S/4HANA Cloud events in advanced event mesh

Cloud Integration

JMS receiver adapter: property to identify sending integration flow

We have extended the JMS receiver adapter by storing a new SAP_IntegrationFlowID property. It contains the ID of the integration flow that has sent the message through the JMS receiver adapter. The JMS consumer can use this property to define steps depending on the sending integration flow ID. Refer the documentation.

Inspect resource consumption through SAP Cloud ALM/SAP Focused Run

Inspection of your resource consumption has been available since the middle of last year. Now you may analyze the utilization of database and system resources through the health monitoring application of SAP Cloud ALM and SAP Focused Run. For troubleshooting bottlenecks caused by integration flows you may jump directly to the Inspect section of the Cloud Integration monitor.

Call to action: Upgrade to new version of third-party connectors

As per SAP note 3001980 the following previous adapter versions are deprecated since end of 2020: Salesforce, Amazon Web Services, Microsoft Dynamics, SugarCRM. There haven't been any new features or enhancements for these previous adapter versions. After the upcoming Apache Camel upgrade, the adapter versions will no longer run.

Action is required from the customer's side. Check all your tenants to see whether you have any kind of the above adapters still deployed. Please undeploy and delete the adapters. In case of question reach out to annemarie.kiefer@sap.com.

B2B Integration

We have extended the mapping functionality of the Integration Advisor capability to offer you more flexibility.

Duplicate nodes on target side in a MAG

When designing B2B integration scenarios you may have situations where certain information within the source structure needs to be mapped to only one node in the target structure. Now the mapping guidelines editor of the Integration Advisor capability enables you to duplicate group or leave nodes and map each source alternative to one of the reproductions. Refer to the documentation.

Definition of more complex code value mapping scenarios

You are now able to define local or global mappings of multiple code values at the source side to one code value at the target side. The value function now supports N:1 cardinality code value mapping ease e.g., situations where you have to map multiple partners or currencies.

API Management

Add metadata for OData-based API artifacts deployed on Edge Integration Cell

You can now supply an EDMX specification for API artifacts (API-led integration flows for deployment on Edge Integration Cell), that are based on OData APIs. This allows you to easily specify additional integration steps based on the resources of this API. See the detailed documentation.

Enhancement of security standards

As always, our intention is to offer the highest security standards to avoid attack vulnerabilities. Therefore, we encourage you to use strong certificates, and will no longer accept uploads to the Trust Store of weak customer-owned self-signed certificates or certificate chains used for mTLS handshakes. Consequently, the OpenSSL security level has been increased to level 2. See a comprehensive definition of security level 2 published on the OpenSLL site. For additional details please see note -3418201.

Policy templates

We have filled a small gap when applying policy templates to an API proxy. Default fault rules or post-client flows available within a policy template will now also be appended to the API proxy. Refer to the documentation.

Event-driven Integration

We have news regarding SAP Integration Suite, advanced event mesh our offering for distributed network of event brokers and sophisticated features.

Distributed tracing

We have extended SAP Integration Suite, advanced event mesh with a distributed tracing capability. Now you are able to trace the the lifecycle of events through OpenTelemetry, from the producing application across one or multiple event brokers to the receiving application.

Direct consumption of SAP S/4HANA Cloud events

We have an update regarding the event sources. We have enabled the direct consumption of SAP S/4HANA Cloud events into SAP Integration Suite, advanced event mesh without any intermediate hops. SAP S/4HANA Cloud customers may leverage SAP Integration Suite, advanced event mesh for very large projects, where performance is crucial. Read the documentation.

How to stay tuned to recent and upcoming innovations?

We also refer to the complete list of new releases in our documentation: What’s New in SAP Integration Suite.

In case you have missed our last monthly webinar, don’t worry. Visit 2024 Learning Sessions for SAP User Groups on SAP Integration Suite for all recordings, presentations, and Q&As.

Introducing the new pipeline concept in Cloud Integration

2024-03-19T13:17:59.760000+01:00

We have lately published the so-called Pipeline Concept for Cloud Integration as part of the Migration Guide for SAP Process Orchestration. This can be seen as another building block supporting you in your transition to the cloud. The pipeline concept has been a joint effort of development, consulting, Center of Excellence experts, product management, and selected customers with whom we have validated the concept at a very early stage.

In the Pipeline Concept documentation, we describe the concept in detail. Furthermore, you find an integration package with the set of integration flows and a groovy script collection on the SAP Business Accelerator Hub to setup your pipeline on Cloud Integration.

Feel free to apply the concept to your migration projects. You can use the material that we provide as template, feel free to adapt to your needs, hence we call it a concept and not a final solution. If you are a partner supporting your customers within their migration projects or if you even have your own migration tool in your portfolio, feel free to apply the concept for your own tool.

What are the benefits?

Cloud integration is very flexible in terms of modeling and running your integration scenarios allowing the design of a rich variety of integration patterns. SAP Process Orchestration in contrary has a very strict pipeline designed for reliable message processing providing decoupling, splitting and restarting capabilities out of the box guaranteeing Exactly Once processing. Those requirements are still valid for interfaces in Cloud Integration and are all addressed with the pipeline concept.

In a nutshell, key achievements of the pipeline concept are as follows:

Ensures decoupling and Exactly Once processing for asynchronous processing, also for split scenarios and in case of restart
Provides sophisticated restart capabilities, i.e., automatic retries as well as manual retry options
Simplifies operations by separating errors into different generic queues separated by routing, mapping and receiver system delivery
Requires lower number of JMS queues to take into account the resource limits of an SAP Integration Suite tenant which at the end also simplifies operations
Allows isolation and tuning of parallelization for individual receiver systems
Allows reusability of artifacts across multiple flows by using generic flow concept
Simplifies integration flow model especially for content based router and recipient list scenarios
Simplifies configuration on the backend sender side, e.g., just one ALE port on SAP S/4HANA system required
Supports packaging in IDoc and proxy, multi-message mappings, and maintain order at runtime in a generic manner

What is it all about?

The pipeline concept allows you to set up your asynchronous integration scenarios in Cloud Integration in a similar way how messages are processed in SAP Process Orchestration, namely in pipelines. Other than in Cloud Integration where you are very flexible in orchestrating the message flows, pipelines in SAP Process Orchestration are rather static, i.e., each pipeline consists of a fixed number of pipeline steps whereas the order is fixed, e.g., for a message processed within the SAP Process Orchestration runtime, first the receiver is determined, then the interface, and then the mapping is carried out.

The pipeline concept is mainly addressed to existing SAP Process Orchestration customers which plan to migrate their scenarios to the Cloud Integration capability of SAP Integration Suite. However, it can also be generally applied to any asynchronous integration scenario that you like to implement and run on Cloud Integration. In case of the migration use case, it can be seen as an alternative approach or in conjunction with the individual migration of single integration scenarios supported by the migration tool within SAP Integration Suite or migration tools provided by partners to overcome its shortcomings.

The pipeline concept may not apply to all customers, it depends on your individual situation, i.e., the number or the type of integration scenarios that you have. If you have a low number of integration scenarios to be migrated to Cloud Integration, then you may rather opt for creating individual integration flows for each of your source integration scenarios. If you have however a very large number of scenarios, the pipeline concept may help you to accelerate your migration project itself and to reduce effort and cost in terms of operating and monitoring your integration scenarios in the Cloud Integration.

One of the shortcomings that we address with the pipeline concept is the JMS queue handling in Cloud Integration for asynchronous integration scenarios. Resources on an SAP Integration Suite tenant are limited, so you need to properly model your integration flows in such a way to best suit the resource limits of your tenants, see Run an Integration Flow Under Well-Defined Boundary Conditions for instance. If you migrate your asynchronous integrated configuration scenarios in SAP Process Orchestration to integration flows in Cloud Integration one-by-one and use an own JMS queue for each integration flow to ensure exactly once delivery, you end up in a very high number of JMS queues. The pipeline concept reduces the number of JMS queues required to run your integration scenarios on Cloud Integration. A proper usage of JMS queues and ProcessDirect adapters and relying on the Partner Directory to be able to dynamically configure your integration flows, help to reduce the number of required JMS queues to four. If you count in four more JMS queues for the retry and dead letter handling, you end up at eight JMS queues required.

What’s the approach?

The pipeline concept defines a sequence of integration flows each representing a pipeline step. We distinguish between a set of generic integration flows which can be commonly used across all scenarios and scenario-specific integration flows. The generic integration flows are used across all integration scenarios and hence need to be deployed only once. The scenario-specific integration flows handle the scenario-specific message conversions and mappings. They can be created as copy of the templates provided.

In general, the integration flows are decoupled using JMS queues. This ensures that messages can be restarted which is a prerequisite for guaranteed delivery. To call the scenario-specific integration flows however we use the ProcessDirect adapter. Replacing the ProcessDirect connection with a JMS connection was not an option because then we would end up again in far too many JMS queues.

One key element of the pipeline concept is the usage of the Partner Directory. The Partner Directory on the one hand helps to define the message processing behavior, e.g., you can define scenario-specific maximum number of retries or receiver-specific outbound queues. On the other side, you use the Partner Directory to dynamically configure the generic integration flows. Latter helps to reduce the number of required JMS queues.

Another key element is the usage of XSLT mappings to carry out the receiver determination and interface split pipeline steps. The idea was nicked from the extended receiver determination capability in SAP Process Orchestration where you can run an operation mapping to determine your receivers in a content-based router or recipient list pattern. On the one hand, this dramatically simplifies the integration flow models of the receiver determination and interface split. Instead of a combination of multicast branches and multiple routers for all your content-based router xpath expressions which easily blows up your integration flow model, we simply run the xpath expressions within an XSLT mapping. So, the model becomes very neat and better readable. On the other side, we prefer XSLT over graphical message mapping because XSLT mappings are supported in the Partner Directory. So, the usage of XSLT in combination with the Partner Directory also contributes to the reduction of the number of required JMS queues.

If you like to learn more about the pipeline concept, check out the Pipeline Concept chapter as part of the migration guide for SAP Process Orchestration.

If you like to apply the pipeline concept, you find the integration package at the SAP Business Accelerator Hub.

Also check out my blog series where I describe how to apply the pipeline concept for a particular integration scenario. The first blog post covers a general use case with multiple receivers and multiple receiver interfaces.

And here's the complete list of blogs in the blog series:

Applying the pipeline concept for an integration scenario in general

2024-03-19T13:18:13.056000+01:00

In this blog post, I like to describe how to apply the pipeline concept on Cloud Integration for implementing an integration scenario containing multiple receivers and multiple receiver interfaces. I will first show you how the scenario is configured in SAP Process Orchestration, and then go through the main implementation steps to get the scenario run on Cloud Integration leveraging the pipeline concept.

For an introduction to the pipeline concept, see this intro blog post. If you haven't gone through the basics of the pipeline concept, I strongly recommend to first read the introduction blog post before proceeding.

Source Integrated Configuration Object in SAP Process Orchestration

The integrated configuration object example on SAP Process Orchestration combines both receiver determination with multiple receivers and interface determination with multiple interfaces. It defines a recipient list pattern whereas each receiver may receive multiple messages.

The message contains an item in JSON format like in the example message below.

{
    "ns0:Item":{
        "@PurchaseOrderNumber":"99202",
        "@OrderDate":"2019-05-06",
        "@ItemNumber":"10",
        "ProductId":"HT-1000",
        "ProductName":"Keyboard XX",
        "Category":"Keyboards",
        "Quantity":"10",
        "CurrencyCode":"EUR",
        "Price":"799.00"
    }
}

In a REST sender adapter, the JSON format is converted into XML.

<?xml version='1.0' encoding='UTF-8'?><ns0:Item xmlns:ns0="http://demo.sap.com/eip/recipient-list" PurchaseOrderNumber="99202" OrderDate="2019-05-06" ItemNumber="10">
  <ProductId>HT-1000</ProductId>
  <ProductName>Keyboard XX</ProductName>
  <Category>Keyboards</Category>
  <Quantity>10</Quantity>
  <CurrencyCode>EUR</CurrencyCode>
  <Price>799.00</Price>
</ns0:Item>

As you can see from the Integrated Configuration Object in the Integration Directory of SAP Process Orchestration, the sender communication component equals IFSplit_Sender_5 with sender interface si_item_async_ob.

The xpath condition depends on the product category whereas a context object named category of the service interface is used. The conditions may apply to multiple receivers. If no receiver is found, the message is sent to the default receiver RL_Receiver_1.

For the first receiver, three conditions are defined to determine the receiver interfaces. Depending on the message payload, the receiver may receive multiple messages.

For the second receiver, only one receiver interface with no condition is defined.

For the third receiver, three conditions are defined to determine the receiver interfaces. Depending on the message payload, the receiver may receive multiple messages.

For the fourth receiver, three conditions are defined to determine the receiver interfaces. Depending on the message payload, the receiver may receive multiple messages.

For the fifth receiver, only one receiver interface with no condition is defined.

Target implementation in Cloud Integration

We would like to model and run the scenario on Cloud Integration applying the pipeline concept. Prerequisite is that you have deployed all generic integration flows as well as the script collection from the integration package provided.

To set up the scenario using the pipeline, the Partner Directory entries need to be created as well as the scenario-specific integration flows. In our case, inbound conversion from JSON to XML is needed. So, we need to create the scenario-specific inbound processing, inbound conversion, and outbound processing integration flows as copies from the provided templates.

The partner ID to store the inbound conversion end point in the Partner Directory needs to be set to IFSplit_Sender_5~si_item_async_ob. During message processing, the generic integration flow Pipeline Generic Step02 - Inbound Processing reads the end point from the Partner Directory and dispatches the message to the very scenario-specific inbound conversion flow.

{
    "Pid": "IFSplit_Sender_5~si_item_async_ob",
    "Id": "InboundConversionEndpoint",
    "Value": "/pip/03/scenario1"
}

The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to IFSplit_Sender_5~si_item_async_ob as well. During message processing, the generic integration flow Pipeline Generic Step04 - Receiver Determination reads the XSLT from the Partner Directory and then runs it to determine the number of receivers the message should be sent to.

The XSLT mapping to determine the list of receivers is defined as follows whereas the context object of the service interface has been resolved:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
     <ReceiverNotDetermined>
       <Type>Default</Type>
       <DefaultReceiver>
         <Service>RL_Receiver_1</Service>
       </DefaultReceiver>
    </ReceiverNotDetermined>
    <xsl:if test="/*:Item/Category = 'Software'">
      <Receiver>
        <Service>RL_Receiver_1</Service>
      </Receiver>
      <Receiver>
        <Service>RL_Receiver_2</Service>
      </Receiver>
    </xsl:if>
    <xsl:if test="/*:Item/Category = 'Notebooks'">
      <Receiver>
        <Service>RL_Receiver_3</Service>
      </Receiver>
      <Receiver>
        <Service>RL_Receiver_4</Service>
      </Receiver>
      <Receiver>
        <Service>RL_Receiver_5</Service>
      </Receiver>
    </xsl:if>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

For the first receiver, the partner ID to store the interface determination XSLT mapping in the Partner Directory equals IFSplit_Sender_5~si_item_async_ob~RL_Receiver_1. During message processing, the generic integration flow Pipeline Generic Step05 - Interface Determination reads the XSLT from the Partner Directory and then runs it to determine the receiver interfaces.

The XSLT mapping to determine the receiver interfaces for the first receiver is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
    <xsl:if test="/*:Item/ProductName = 'Word'">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario1/rcvidx1/ifidx1</Service>
      </Interface>
    </xsl:if>
    <xsl:if test="/*:Item/Quantity = '10'">
      <Interface>
        <Index>2</Index>
        <Service>/pip/07/scenario1/rcvidx1/ifidx2</Service>
      </Interface>
    </xsl:if>
    <xsl:if test="/*:Item/Quantity != '10'">
      <Interface>
        <Index>3</Index>
        <Service>/pip/07/scenario1/rcvidx1/ifidx3</Service>
      </Interface>
    </xsl:if>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

For the second receiver, the partner ID to store the interface determination XSLT mapping in the Partner Directory equals IFSplit_Sender_5~si_item_async_ob~RL_Receiver_2. The interface determination contains one receiver only with no condition, so the XSLT mapping to determine the interfaces is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario1/rcvidx2/ifidx1</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

For the third receiver, the partner ID to store the interface determination XSLT mapping in the Partner Directory equals IFSplit_Sender_5~si_item_async_ob~RL_Receiver_3. The XSLT mapping to determine the interfaces is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
    <xsl:if test="(/*:Item/ProductName = 'Lenovo') and (/*:Item/Quantity = '1')">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario1/rcvidx3/ifidx1</Service>
      </Interface>
    </xsl:if>
    <xsl:if test="(/*:Item/ProductName = 'Lenovo') and (/*:Item/Quantity = '2')">
      <Interface>
        <Index>2</Index>
        <Service>/pip/07/scenario1/rcvidx3/ifidx2</Service>
      </Interface>
    </xsl:if>
    <xsl:if test="/*:Item/ProductName != 'Lenovo'">
      <Interface>
        <Index>3</Index>
        <Service>/pip/07/scenario1/rcvidx3/ifidx3</Service>
      </Interface>
    </xsl:if>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

For the fourth receiver, the partner ID to store the interface determination XSLT mapping in the Partner Directory equals IFSplit_Sender_5~si_item_async_ob~RL_Receiver_4. The XSLT mapping to determine the interfaces is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
    <xsl:if test="(/*:Item/ProductName = 'Lenovo') or (/*:Item/ProductId = 'HT-0001')">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario1/rcvidx4/ifidx1</Service>
      </Interface>
    </xsl:if>
    <xsl:if test="/*:Item/Quantity = '1'">
      <Interface>
        <Index>2</Index>
        <Service>/pip/07/scenario1/rcvidx4/ifidx2</Service>
      </Interface>
    </xsl:if>
    <xsl:if test="/*:Item/Quantity != '1'">
      <Interface>
        <Index>3</Index>
        <Service>/pip/07/scenario1/rcvidx4/ifidx3</Service>
      </Interface>
    </xsl:if>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

For the fifth receiver, the partner ID to store the interface determination XSLT mapping in the Partner Directory equals IFSplit_Sender_5~si_item_async_ob~RL_Receiver_5. The XSLT mapping to determine the interfaces is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario1/rcvidx5/ifidx1</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

You need to create a scenario-specific integration flow for the inbound processing as copy of the templates provided. Here, SAP_Sender and SAP_SenderInterface are maintained accordingly which are then passed to the next integration flows in the sequence of integration flows to read the Partner Directory information.

You need to create a scenario-specific integration flow for the inbound conversion as copy of the templates provided. In our case, we copied the template Pipeline Template Step01 - Inbound Processing At Least Once, see Pipeline Steps. Here, a JSON to XML converter is added.

For each interface index from the interface determination XSLTs, you need to create an integration flow with ProcessDirect sender adapter and endpoint as defined in the Service node of the XSLTs. According to the integrated configuration object above, the first receiver has three interfaces. For the first and the second index, the integration flow contains a message mapping which maps the item format to another item format. For the third index, the message mapping maps from item to an order format. Below, the outbound processing integration flow for the third interface index of the first receiver is displayed.

For the rest of the receivers and interfaces, similar outbound interfaces need to be created. We created all outbound integration flows as copies of the template Pipeline Template Step07 - Outbound Processing Point-to-Point, see Pipeline Steps.

That’s it. If you like to test the integration scenario, you can send the test message above to the entry point of the scenario-specific inbound processing.

In the next blog post, we will cover a special use case, namely a multicast scenario.

Applying the pipeline concept for a multicast integration scenario

2024-03-19T13:18:44.130000+01:00

The current blog is part of a blog series where I describe how to implement different asynchronous integration scenarios using the pipeline concept on Cloud Integration. In the previous blog post, I described a generic use case with multiple receivers and receiver interfaces. In this blog post, I like to describe how to apply the pipeline concept on Cloud Integration for implementing a multicast integration scenario, i.e., the messages are distributed to multiple receivers, no xpath condition is defined. I will first show you how the scenario is configured in SAP Process Orchestration, and then go through the main implementation steps to get the scenario run on Cloud Integration leveraging the pipeline concept.

For an introduction to the pipeline concept, see this intro blog post . If you haven't gone through the basics of the pipeline concept, I strongly recommend to first read the blog post before proceeding.

Source Integrated Configuration Object in SAP Process Orchestration

The integrated configuration object example on SAP Process Orchestration describes a Recipient List pattern with no xpath condition, i.e., a multicast pattern. Here, the sender communication component equals RL_Sender_5 with sender interface si_item_async_ob. An incoming message is delivered to three receivers whereas if no receiver is found, the message is simply ignored, so no error is raised.

For each receiver, only one interface is defined with no xpath condition. For the first receiver, the incoming message is mapped to an order format.

For the second receiver, the incoming message is mapped to an order format as well.

For the third receiver, the incoming message is mapped to an item format.

Target implementation in Cloud Integration

You need to create a scenario-specific integration flow for the inbound processing as copy of the templates provided. Here, we copied the template Pipeline Template Step01 - Inbound Processing At Least Once and maintained SAP_Sender and SAP_SenderInterface accordingly which are then passed to the next integration flows in the sequence of integration flows to read the Partner Directory information.

For each receiver/receiver interface, the scenario-specific outbound integration flows need to be created as copies from the provided templates. Below, the outbound processing integration flow for the first receiver is displayed. It’s based on the template Pipeline Template Step07 - Outbound Processing Point-to-Point, see Pipeline Step.

The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to RL_Sender_5~si_item_async_ob. The XSLT mapping to determine the list of receivers is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
      <ReceiverNotDetermined>
        <Type>Ignore</Type>
        <DefaultReceiver/>
      </ReceiverNotDetermined>
      <Receiver>
        <Service>RL_Receiver_1</Service>
      </Receiver>
      <Receiver>
        <Service>RL_Receiver_2</Service>
      </Receiver>
      <Receiver>
        <Service>RL_Receiver_3</Service>
      </Receiver>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

During message processing, the generic integration flow Pipeline Generic Step04 - Receiver Determination reads the XSLT from the Partner Directory and then runs it to determine the number of receivers the message should be sent to. Since there is no xpath condition, the resulting XML is always the same containing all three receivers.

For the first receiver, the partner ID to store the interface determination XSLT mapping in the Partner Directory equals RL_Sender_5~si_item_async_ob~RL_Receiver_1. The XSLT mapping to determine the interfaces is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario2/rcvidx1/ifidx1</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

During message processing, the generic integration flow Pipeline Generic Step05 - Interface Determination reads the XSLT from the Partner Directory and then runs it to determine the receiver interface. Since there is no xpath condition defined to determine the receiver interface, the resulting XML is always the same containing the end point of the scenario-specific outbound processing flow for the first receiver.

The XSLT mappings for the other two receivers are similarly defined and hence not explicitly displayed here.

Next, we will cover a special use case, namely a point-to-point scenario, see this blog post.

Applying the pipeline concept for a point-to-point integration scenario

2024-03-19T13:19:08.516000+01:00

The current blog is part of a blog series where I describe how to implement different asynchronous integration scenarios using the pipeline concept on Cloud Integration. In the previous blog post, I described a multicast scenario. In this blog post, I like to describe how to apply the pipeline concept on Cloud Integration for implementing a point-to-point integration scenario, i.e., one sender and one receiver with no condition at all. I will first show you how the scenario is configured in SAP Process Orchestration, and then go through the main implementation steps to get the scenario run on Cloud Integration leveraging the pipeline concept.

Source Integrated Configuration Object in SAP Process Orchestration

The integrated configuration object example on SAP Process Orchestration has one single receiver with no condition defined.

On the Receiver Interfaces tab, an interface with an operation mapping and no xpath condition is defined.

Target implementation in Cloud Integration

To set up the scenario using the pipeline, the Partner Directory entries need to be created as well as the scenario-specific integration flows. In our case, we assume that no inbound conversion is needed. So, we need to create the scenario-specific inbound processing as well as outbound processing integration flows as copies from the provided templates.

You have two options to implement the scenario in Cloud Integration, either running through all pipeline steps or bypassing most of the pipeline steps since receiver determination and interface determination are not needed anyway.

Option 1: Complete pipeline

In the first option, we run through all pipeline steps although most of the steps are not really needed. In this case, the XSLTs for the receiver determination and the interface determination always provide the same output with one and the same receiver and one and the same receiver interface, respectively, because no xpath conditions are carried out. You may opt for this option since those settings follow a common approach across all your integration scenarios

The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to PIMAS_Sender~SI_SalesOrder_Out.

The XSLT mapping to determine the list of receivers is defined as follows. In this case, no xpath condition is carried out, so the resulting XML is always fixed.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
      <ReceiverNotDetermined>
        <Type>Ignore</Type>
        <DefaultReceiver/>
      </ReceiverNotDetermined>
      <Receiver>
        <Service>PIMAS_Receiver</Service>
      </Receiver>
      <Receiver>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

For the interface determination XSLT mapping, the partner ID equals PIMAS_Sender~SI_SalesOrder_Out ~PIMAS_Receiver. Like for the XSLT mapping to determine the receiver, the XSLT mapping to determine the interfaces results into a fixed XML as well. It is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario3</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

The scenario-specific inbound integration flow looks as follows. It’s a copy of the template Pipeline Template Step01 - Inbound Processing At Least Once, see Pipeline Steps.

The scenario-specific outbound integration flow looks as follows. It’s a copy of the template Pipeline Template Step07 - Outbound Processing Point-to-Point, see Pipeline Steps.

Option 2: Bypassing most of the pipeline steps

In the second option, we can reduce the number of pipeline steps that are carried out to a minimum. We assume that no inbound conversion is needed, so we simply end up with three integration flows: the scenario-specific inbound flow, the generic outbound processing, and the scenario-specific outbound processing. In this case, the Partner Directory is not needed.

In the scenario-specific inbound flow, we configure the JMS receiver adapter pointing to the fourth and last queue so that most of the flows are bypassed. Since the Partner Directory is usually read in the generic flows that are bypassed, we need to ensure to maintain the headers which are needed to dispatch the message to the right outbound flow. So, in addition to the headers SAP_Sender and SAP_SenderInterface, the headers SAP_Receiver, maxJMSRetries, and SAP_OutboundProcessingEndpoint need to be maintained as well. In the header SAP_OutboundProcessingEndpoint enter the ProcessDirect end point of the scenario-specific outbound processing flow.

Since we entered here the fourth queue, the message is then picked up by the generic outbound processing and dispatched to the scenario-specific outbound processing flow.

Next, we will cover another special use case, namely an interface split scenario with one receiver message type, see blog post.

Applying the pipeline concept for an interface split scenario with one receiver message type

2024-03-19T13:19:33.687000+01:00

The current blog is part of a blog series where I describe how to implement different asynchronous integration scenarios using the pipeline concept on Cloud Integration. In the previous blog post, I described a point-to-point scenario. In this blog post, I like to describe how to apply the pipeline concept on Cloud Integration for implementing an integration scenario with interface split whereas all split messages are of same message type.

The scenario is like the point-to-point scenario except that the operation mapping splits the message into multiple messages. Here, we have an incoming message with an order and multiple items whereas each item should be sent to one and the same receiver individually. I will first show you how the scenario is configured in SAP Process Orchestration, and then go through the main implementation steps to get the scenario run on Cloud Integration leveraging the pipeline concept.

For an introduction to the pipeline concept, see this intro blog post . If you haven't gone through the basics of the pipeline concept, I strongly recommend to first read the introduction blog post before proceeding

Source Integrated Configuration Object in SAP Process Orchestration

The integrated configuration object example on SAP Process Orchestration has one single receiver with no condition defined.

On the Receiver Interfaces tab, an interface with a one-to-many operation mapping and no xpath condition is defined.

Target implementation in Cloud Integration

To set up the scenario using the pipeline, the Partner Directory entries need to be created as well as the scenario-specific integration flows. In our case, we assume that no inbound conversion is needed. So, we need to create the scenario-specific inbound processing and outbound processing integration flows as copies from the provided templates.

Like for the point-to-point scenario described in the previous blog post, the XSLT mappings for the receiver determination as well as for the interface determination result into fixed XMLs.

The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to IFSplit_Sender_7~si_order_async_ob.

The XSLT mapping to determine the list of receivers is defined as follows. In this case, no xpath condition is carried out, as said the resulting XML is then fixed.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
      <ReceiverNotDetermined>
        <Type>Ignore</Type>
        <DefaultReceiver/>
      </ReceiverNotDetermined>
      <Receiver>
        <Service>RL_Receiver_1</Service>
      </Receiver>
      <Receiver>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

For the interface determination XSLT mapping, the partner ID equals IFSplit_Sender_7~si_order_async_ob ~RL_Receiver_1. The XSLT mapping to determine the interfaces is fixed as well. It is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario4</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

The scenario-specific inbound integration flow looks as follows. It’s a copy of the template Pipeline Template Step01 - Inbound Processing At Least Once, see Pipeline Steps.

The scenario-specific outbound integration flow needs to be modelled as follows. It’s a copy of the template Pipeline Template Step07 - Outbound Processing One-to-Many with One Message Type, see Pipeline Steps.

In an XML Modifier step, you need to remove the XML declaration from the message body.

In a content modifier step, you need to wrap the body with the nodes required when running multi-mappings.

In a message mapping step, you run the multi-mapping that you can reuse from the SAP Process Orchestration system.

The mapped message needs to be split using an iterating splitter with expression type XPath and an xpath to split the message on Item level. By intention, we unselect the Parallel Processing flag, see below.

To ensure Exactly Once delivery, we need to assign each split message a unique ID, hence we concatenate the unique ID that we received from the generic parent flow with the Camel split index and store the value into the exchange property SplitMessageID. Since the split was done sequentially, each item always gets its same split index assigned in case that the message is retried.

In an idempotent process call, the actual receiver is called. The beforehand created SplitMessageID property is used to identify duplicates. If the idempotent process was successfully carried out before, a retry with the same ID will be skipped.

Next, we will cover another interface split scenario, this time with multiple receiver message types, see next blog post.

Applying the pipeline concept for an interface split scenario with multiple receiver message types

2024-03-19T13:20:27.646000+01:00

The current blog is part of a blog series where I describe how to implement different asynchronous integration scenarios using the pipeline concept on Cloud Integration. In this blog, I like to describe how to apply the pipeline concept for an integration scenario with interface split and multiple receiver message types. The scenario is like the previous interface split scenario except that the operation mapping not only splits the message into multiple messages but also different message types. Here, we have an incoming message with an order and multiple items whereas a header message with the order information and each item should be sent to one and the same receiver individually.

For an introduction to the pipeline concept, see this intro blog post . If you haven't gone through the basics of the pipeline concept, I strongly recommend to first read the introduction blog post before proceeding.

Source Integrated Configuration Object in SAP Process Orchestration

The integrated configuration object example on SAP Process Orchestration has one single receiver with no condition defined.

On the Receiver Interfaces tab, a one-to-many operation mapping and no xpath condition is defined. The one-to-many operation mapping splits the message into multiple message types.

Target implementation in Cloud Integration

To set up the scenario using the pipeline, the Partner Directory entries need to be created as well as the scenario-specific integration flows. In our case, we assume that no inbound conversion is needed. So, we need to create the scenario-specific inbound processing and outbound processing integration flows as copies from the provided templates.

Like for the point-to-point scenario or the split scenario described in the previous examples, the XSLT mappings for the receiver determination as well as for the interface determination result into fixed XMLs.

In our example, the partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to IFSplit_Sender_8~si_order_async_ob.

The XSLT mapping to determine the list of receivers is defined as follows. In this case, no xpath condition is carried out, as said the resulting XML is fixed.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
      <ReceiverNotDetermined>
        <Type>Ignore</Type>
        <DefaultReceiver/>
      </ReceiverNotDetermined>
      <Receiver>
        <Service>RL_Receiver_1</Service>
      </Receiver>
      <Receiver>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

For the interface determination XSLT mapping, the partner ID equals IFSplit_Sender_8~si_order_async_ob ~RL_Receiver_1. The XSLT mapping to determine the interfaces is fixed as well. It is defined as follows:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario5</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

The scenario-specific inbound integration flow looks as follows. It’s a copy of the template Pipeline Template Step01 - Inbound Processing At Least Once, see Pipeline Steps.

The scenario-specific outbound integration flow needs to be modelled as follows. It’s a copy of the template Pipeline Template Step07 - Outbound Processing One-to-Many with Multiple Message Types, see Pipeline Steps. You need to add as much branches as you have receiver message types, in our case two, one for the items and one for the header.

In an XML Modifier step, you need to remove the XML declaration from the message body.

In a content modifier step, you need to wrap the body with the Messages nodes required when running multi mappings.

In a message mapping step, you run the multi mapping that you can reuse from the SAP Process Orchestration system.

After the mapping, you add a parallel multicast.

In the first branch of the parallel multicast, the mapped message needs to be split using an iterating splitter with expression type XPath and an xpath to split the message on Item level.

To ensure Exactly Once delivery, we need to assign each split message a unique ID, hence we concatenate the unique ID that we received from the generic parent flow with the constant Branch1 for the first branch and the Camel split index and store the value into the exchange property SplitMessageID. Since the split was done sequentially, each item always gets its same split index assigned in case that the message is retried.

In the second branch of the parallel multicast, the mapped message needs to be split using an iterating splitter with expression type XPath and an xpath to split the message on Order level. Since we only have one single Order node, we could have used a filter instead.

For the second branch, we concatenate the unique ID that we received from the generic parent flow with the constant Branch2 and the Camel split index and store the value into the exchange property SplitMessageID.

Next, we will cover an interface split scenario with Maintain Order at Runtime flag set, see next blog post.

Applying the pipeline concept for an interface split scenario with order at runtime flag set

2024-03-19T13:21:05.206000+01:00

The current blog is part of a blog series where I describe how to implement different asynchronous integration scenarios using the pipeline concept on Cloud Integration. In the previous blog post, I described an interface split scenario resulting in multiple messages which may have different message types. In this blog post, I describe another interface split scenario, however here the split messages should be processed in order. A use case might be to store a message on a file system and only if successfully written, we like to add a trigger file which would then trigger subsequent processing steps. For this, in the interface determination, the Maintain Order at Runtime flag is set.

I will first show you how the scenario is configured in SAP Process Orchestration, and then go through the main implementation steps to get the scenario run on Cloud Integration leveraging the pipeline concept.

For an introduction to the pipeline concept, see this intro blog post . If you haven't gone through the basics of the pipeline concept, I strongly recommend to first read the introduction blog post before proceeding

Source Integrated Configuration Object in SAP Process Orchestration

The integrated configuration object example on SAP Process Orchestration has one single receiver with no condition defined.

On the Receiver Interfaces tab, two interfaces with no xpath condition are defined. The Maintain Order at Runtime flag is selected ensuring that the message of the second interface is processed only if the first message has been successfully processed.

Target implementation in Cloud Integration

To set up the scenario using the pipeline, the Partner Directory entries need to be created as well as the scenario-specific integration flows. In our case, we assume that no inbound conversion is needed. So, we need to create the scenario-specific inbound processing and outbound processing integration flows as copies from the provided templates.

The XSLT mapping for the receiver determination results into a fixed XML with one receiver only. The partner ID to store the receiver determination XSLT mapping in the Partner Directory needs to be set to IFSplit_Sender_6~si_item_async_ob.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
      <ReceiverNotDetermined>
        <Type>Ignore</Type>
        <DefaultReceiver/>
      </ReceiverNotDetermined>
      <Receiver>
        <Service>RL_Receiver_1</Service>
      </Receiver>
      <Receiver>
    </ns0:Receivers>
  </xsl:template>
</xsl:stylesheet>

For the interface determination XSLT mapping, the partner ID equals IFSplit_Sender_6~si_item_async_ob ~RL_Receiver_1. Although we have two interfaces, the XSLT mapping to determine the interfaces contains one interface index only. Since the messages should be processed in order, we only need to call one single outbound processing integration flow.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:template match="/">
    <ns0:Interfaces xmlns:ns0="http://sap.com/xi/XI/System">
      <Interface>
        <Index>1</Index>
        <Service>/pip/07/scenario6</Service>
      </Interface>
    </ns0:Interfaces>
  </xsl:template>
</xsl:stylesheet>

The scenario-specific inbound integration flow looks as follows. It’s a copy of the template Pipeline Template Step01 - Inbound Processing At Least Once, see Pipeline Steps.

The scenario-specific outbound integration flow needs to be modelled using a sequential multicast step. This way, you ensure that the messages are processed in sequence. It’s a copy of the template Pipeline Template Step07 - Outbound Processing Maintain Order At Runtime, see Pipeline Steps.

In the first branch of the sequential multicast, the message is mapped to the item format.

In the second branch of the sequential multicast, the message is mapped to the trigger file format.

Note: In Order using a Sequential Multicast is only supported if the receiver adapter doesn't persist and restart on its own. As an example, when using an XI receiver adapter with At Least Once or Exactly Once message delivery, the message is first persisted and then delivered. The moment the first branch successfully persists the message, the second branch will be processed even if the first branch hasn't successfully delivered the message. Especially in an error situation, i.e., if the first branch fails to deliver its message and the second branch successfully delivers its message, in order will be violated. But even if both branches run successfully, the second message may still overtake the first. So, if you like to implement In Order for the XI receiver adapter following the approach above, you need to switch to Best Effort message delivery.

This was the last blog in the blog series about the pipeline use cases. For a complete overview of all blogs, check out the intro blog post.

SAP PI/PO migration? Why you should move to the Cloud with SAP Integration Suite!

2024-04-02T11:57:06.272000+02:00

Are you among the thousands SAP customers using SAP Process Integration / SAP Process Orchestration?

If yes, you’re aware that this product is impacted by SAP NetWeaver 7.5 maintenance strategy, as explained in this blog post: indeed, the maintenance of SAP Process Integration and SAP Process Orchestration will be extended in accordance with SAP NetWeaver 7.5, with mainstream maintenance until end of 2027 with option of extended maintenance until end of 2030.

Let’s consider that it typically takes a year to get business case approvals and then it takes time to convince stakeholders and cooperate in development and productive cycles: you should start your move to SAP Integration Suite in 2024 to be sure to have the migration completed by 2027. That’s why I’m happy to guide you on the path that will let you adopt SAP Integration Suite, the modern way of integrating your SAP and non-SAP systems for the best business outcomes.

What is SAP Integration Suite?

SAP Integration Suite is an integration platform-as-a-service – iPaaS – that helps you quickly integrate on-premises and cloud-based processes, services, applications, events, and data. With SAP Integration Suite, you accelerate innovation, automate more processes, and realize a faster time to value.

SAP Integration Suite helps you quickly connect systems, automate business processes, and harmonize experiences across the extended enterprise. It comes with:

Prebuilt integrations managed and updated by SAP and by our valued partners
Harmonized access to popular third-party cloud applications
Tools for designing, publishing, and managing APIs
AI-assisted development and integration optimization
Tools-based, guided approach to define, document, and govern you>integration strategy

To get an overview, watch our 4 minutes video What is SAP Integration Suite

To delve deeper into SAP Integration Suite, read our 44 pages Feature Scope Description.

With SAP Integration Suite comes SAP Integration Solution Advisory Methodology, which defines your proven path toward integration excellence to successfully move from SAP Process Integration / SAP Process Orchestration.

What is SAP Integration Solution Advisory Methodology

SAP Integration Solution Advisory Methodology has been created by our experts to provide a standardized approach to integration. With SAP ISA-M, you can accelerate your digital transformation and become an integrated intelligent enterprise.

Our methodology offers a comprehensive framework that helps accelerate hybrid integration platform design, safeguard integration projects based on SAP best practices, and enable an agile integration practice across your organization. As you answer the assessment questions, you’ll learn more about the five levels of maturity and gain insight into where your business stands – and what to do next.

With SAP ISA-M you raise your organization's integration maturity level, moving from ad hoc integration to a systematic approach based on well-defined integration standards:

You will find all the links to resources related to this methodology in Katrin von Ahsen’s blog post.

What is Event Driven Architecture?

Event Driven Architecture is more and more popular simply because the world is more and more real-time.

Let me share just 2 business examples of this

Inventories must be updated as soon as sales happen
Maintenance teams need to know of breakdown as soon as possible

Let me go back to the very basics to quickly introduce Event Driven Architecture aka EDA:

An event is a significant change in the state of a system.
Notification events or data events can be sent from the event source to inform other counterparts of the change.
A message holding the event description in an encoded format is sent through an event broker, in charge of properly distributing the events.
Event consumers have registered with the event broker and are informed of the event, so they can appropriately react to it.

From a business perspective, with EDA you take advantage of

Improved reaction time and lower costs through full automation of real-time business processes

Smarter business decisions based on up-to-date information
Open ecosystem across vendor boundaries
Organizational empowerment through social-media communication style

From a technology perspective, you benefit of

Loose coupling for flexibility and scalability
Improved fault tolerance using suitable patterns
Incremental growth and higher-quality operations through step-by-step addition of event consumers and event sources
Real-time technical integrations and extensions

In SAP event-driven ecosystem as it is today, Event Sources can be

SAP S/4HANA
SAP S/4HANA Cloud
SAP ERP
SAP SuccessFactors solutions
SAP Marketing Cloud
SAP Data Intelligence
SAP CPQ
other SAP solutions
third-party solutions

and Event Consumers can be

SAP Integration Suite
SAP Build
SAP BTP services and apps
SAP S/4HANA
SAP S/4HANA Cloud
SAP ECC using add-on
SAP BTP, Kyma runtime
SAP Data Intelligence
other SAP solutions
third-party solutions

And as the most powerful and reliable event broker, we bring Advanced Event Mesh.;/p>

What is Advanced Event Mesh?

Advanced Event Mesh for SAP Integration Suite is a complete event streaming, event management, and monitoring platform that makes software event brokers available as a service. With advanced event mesh you can create event broker services in minutes, build a model of your event mesh to design and help implement it, and monitor your services and event mesh to ensure everything runs smoothly.

Learn more on Advanced Event Mesh technical concepts in this blog post from Luiz Guilherme Cerqueira Campos.

This cloud platform incorporates best practices, expertise, and technology for event-driven architecture (EDA) on a single platform. As a SaaS solution, it provides:

everything you need to accelerate your organization’s EDA adoption, allowing you to fulfill modern use cases that demand real-time, intelligent event streaming
an intuitive, unified interface to design, deploy, manage, monitor, and govern your event streaming infrastructure (including the events that flow over it) in the most secure manner.

To delve deeper on Advanced Event Mesh, browse our Help Portal content on SAP Integration Suite, Advanced Event Mesh and learn with the missions available in SAP Discovery Center.

What about Edge Integration Cell?

Edge Integration Cell is an optional hybrid integration runtime offered as part of SAP Integration Suite, which enables you to manage APIs and run integration scenarios within your private landscape.

The hybrid deployment model of Edge Integration Cell enables you to:

Design and monitor your integration content in the cloud.
Deploy and run your integration content in your private landscape.

To learn more about how hybrid deployment works using Edge Integration Cell, see Hybrid Deployment Using Edge Integration Cell.

To compare hybrid deployment with the standard deployment model of SAP Integration Suite, see Standard Deployment in the Cloud.

Edge Integration Cell supports the following use cases:

Security or compliance use cases

In many enterprises, sensitive data must be managed and controlled inside the enterprise's firewall. In addition, there could be strict architectural restrictions and you want to keep your data within your private landscape.

Getting a migration path for SAP Process Integration / SAP Process Orchestration customers

SAP Process Integration / SAP Process Orchestration is used by many customers for ground-to-ground integration scenarios. Edge Integration Cell allows these customers to benefit from the newest innovations that come with SAP Integration Suite, with the option to design and monitor integration content in the cloud, and deploy and run their scenarios exclusively in their private landscapes.

In both cases, we recommend using a hybrid integration approach for enterprise-wide connectivity.

For more information about the supported features and limitations of Edge Integration Cell, see Edge Integration Cell Runtime Scope. Read more from Piyush Gakhar, in his blog post “Announcement: Hybrid Integrations with Integration Suite”. Read also Finny Babu’s “Next-gen hybrid integration with SAP Integration Suite & Edge Integration Cell – Introduction & Setup” and Ashutosh Kumar Singh’s “Edge Integration Cell: Design, deploy and manage APIs”.

How to move?

To get the latest information on the migration from SAP Process Integration / SAP Process Orchestration to SAP Integration Suite, we prepared a dedicated web page. You will learn about SAP Integration Suite capabilities, and evaluate top business challenges to streamline processes, enhance productivity, and simplify the way people, data, and systems work together. You will also discover pre-built integrations available on SAP Business Accelerator Hub: indeed, you can connect and integrate applications and business partners with thousands of pre-built integrations, connectors, APIs and more.

For more information on the new tools and the established services you can also check out this blog post from our expert Arti Gopalan.

And to facilitate this move, we bring you a comprehensive Migration Guide for SAP Process Orchestration.

This online document describes what you need to know when you want to migrate from SAP Process Orchestration to SAP Integration Suite. It covers a variety of topics related to the migration process:

Introduction to SAP Integration Suite: Before you start your migration, get to know SAP Integration Suite, learn about its advantages, and get an overview of the migration process from SAP Process Orchestration to SAP Integration Suite.
Landscape: Assess your existing integration landscape and plan your target landscape.
Connectivity: Learn how to move your connectivity options to the connectors and adapters of the SAP Integration Suite.
Security: Get an overview of the security aspects you must consider while migrating and how to manage them in SAP Integration Suite.
Error Handling and Logging Strategy: Learn about cloud-based error handling and logging strategies and understand the different approaches available to you.
Interface Governance: Understand how interfaces are governed in the cloud and how to manage them across multiple landscapes.
Interface Migration: Discover the different aspects involved in moving interfaces from SAP Process Integration and SAP Process Orchestration to SAP Integration Suite, as well as scenario and object assessment and how testing can be automated.

We also provide you with

12 months free regression test tool
SAP Migration Factory with 2-3 weeks of free service
SAP Services and Support offered in our Preferred Success and MaxAttention programs

And our valued partners are bringing powerful migration tools such as FIGAF and INT4.

Keep in touch!

Now, you should have access to all the information you need to consider your migration from SAP Process Integration / SAP Process Orchestration toward SAP Integration Suite.

To stay updated throughout the year, regularly browse our public roadmap for SAP Integration Suite and… feel free to follow me here and/or on LinkedIn to be notified of my next blog posts! 😉

SAP PO- Remove Double Quotes From Sent Request

2024-04-29T13:14:50.771000+02:00

Introduction:

In this blog, we have a scenario where data sent from SAP to an external system is in the form of Proxy To REST. An external system provides us with a REST API. We will send a request to this API using the POST method. In the request sent according to the API of the external system, there are integer values corresponding to the IDs field. These values, after passing through the XML type at the mapping step and transitioning to the converter step in the adapter, have double quotes added to them by the adapter. Consequently, the service returns a 400 bad request response.

Typically, these fields within the array correspond to an IDs field. In other words:

[
"IDs":6913,
"IDs":6915
]

In contrast, during triggering, they are sending all integer values within an array with commas between them, like so;

[6913,6915...]

As a result, the adapter incorrectly interprets them as separate key-value pairs with the key "IDs", leading to the addition of double quotes during JSON conversion.

Firstly, defining the IDs field as an integer in the adapter did not work because the PO (Process Orchestration) converts this request to a string due to the commas between the values in the sent request.

When we inspect the logs, we observe that in the step where the adapter converts to JSON, it adds double quotes as follows:

Step 1. XSLT

I decided not to perform the conversion operation in the adapter because I believe the error stems from that conversion process. By default, the structure outputted from the mapping step is in XML format. If we convert this structure to JSON in the mapping step and specify that this structure is an array, the issue will be resolved. To achieve this, I have written an XSLT.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="text" encoding="UTF-8"/>
	<xsl:template match="/">
		<xsl:text>[</xsl:text>
		<xsl:apply-templates/>
		<xsl:text>]</xsl:text>
	</xsl:template>
	<!-- Process the IDs element -->
	<xsl:template match="IDs">
		<!-- Convert XML content directly to JSON -->
		<xsl:value-of select="."/>
	</xsl:template>
	<!-- Match the delimiters to add commas -->
	<xsl:template match="IDs[position() &gt; 1]">
		<xsl:text>,</xsl:text>
		<xsl:value-of select="."/>
	</xsl:template>
</xsl:stylesheet>

Step 2. XSLT Import in PO

Afterward, I imported this XSLT file into PO as an imported archive.

Step 3. XSLT Mapping

Then, in the operation mapping step, I provided the imported XSLT file to the request mapping.

Step 4. REST Receiver Adapter

In a default proxy to REST scenario, XML is expected to be output from the after mapping step, so we usually check the option "Convert XML payload to JSON" in the adapter. However, in our scenario, we are sending a JSON structure from the mapping step to the adapter. Therefore, we will not check this option. Instead, we will simply select JSON as the Data Format to indicate that our request is in JSON format.

Step 5. Testing

After completing all the PO steps, our service is now ready for testing. We can send a payload from the "Send Message" step to proceed.

How do we adapt the PATCH method in SAP PO

2024-05-13T12:54:11.101000+02:00

Hello everyone,

I will explain how to adapt a REST service called with the PATCH method for use in SAP PO.

In an integration scenario triggered from SAP, if we have a REST link on the receiver side and this link is called with the PATCH method in Postman, we can easily adapt it in PO. This is because not all methods may be available in every PO system. If the PATCH method is not available in your PO system, you can follow the steps below.

1- When configuring, first, we create a Rest receiver adapter.

If there is no authorization in our Rest link, we do not select Basic Authentication. However, if our service authenticates with a username and password, we must specify it in this section.

2- We use our link in the Target URL section in the REST URL tab.

3- We should select POST as the Static Value for our Rest Operation.

To send a service from SAP using the PATCH method through the adapter, we need to add two module configurations in the Module section of the adapter.

4- Module Configuration:

overrideHttpMethod - PATCH

useSAPHttpLibrary - apache

After adding these modules, we can complete the Integrated Configuration steps of the service and trigger it from SAP.

We can easily adapt a REST service triggered as PATCH in Postman to be used in the adapter with the POST method in SAP PO.