SAP Community - SAP Process Integration

Extensibility in the Age of AI: Why ABCD Is Easier (and Smarter) Than You Think

2025-10-03T20:04:58.498000+02:00

The CTO’s Concern

Not long ago, during a client conversation, a CTO expressed a concern that resonated deeply:

“We need to extend our system. But every time someone says ‘let’s customize this,’ I feel we’re piling risk. And now with AI coming, I’m afraid our mess gets worse.”

That statement captures the heart of a challenge many SAP customers face. Customization has been both the strength and the Achilles’ heel of enterprise landscapes. It allows us to adapt, innovate, and differentiate — but it often comes with technical debt, upgrade pain, and hidden complexity.

Why Extensibility Matters More in the AI Era

Let’s pause here. Ten years ago, if you added a Z-table or tweaked a user exit, the worst-case scenario was some testing pain during an upgrade. Today?

If your data model is inconsistent, your AI forecasts won’t align with reality.
If your logic is buried in old exits, Joule copilots can’t “see” your processes.
If your core is brittle, cloud updates feel like risks, not opportunities.

In other words: extensibility is no longer just about “making it work.” It’s about making AI possible.

And now, with SAP’s AI ambitions accelerating — embedded copilots, Joule agents, and business data clouds powering predictive intelligence — the messy customizations of the past risk becoming blockers for the future.

This is where ABCD extensibility comes in. Far from being abstract jargon, it’s a practical compass to guide enterprises on how to extend the system smartly, safely, and in a way that enables AI instead of hindering it.

The ABCD Levels: A Human Explanation

SAP’s ABCD framework doesn’t exist to confuse us — it exists to help customers navigate the grey space between innovation and stability.

Here’s the official breakdown, with real-world translation:

A Short Story: The MV45AFZZ Debate

Anyone who has worked in SAP Sales and Distribution knows the legendary include MV45AFZZ. For decades, it’s been the go-to spot for developers to implement custom sales order checks, validations, and logic.

At one client, a senior developer proudly said, “We’ve been using MV45AFZZ for 15 years, and it works just fine. Why change?”

And he wasn’t wrong. In many ways, that’s a Level B extensibility choice: small, controlled, and serving the business well. (In fact, SAP even documented this in SAP Note 3578329, proving that not all ‘old-school’ practices are bad.)

The problem comes when dozens of such exits pile up, undocumented, with overlapping logic — and suddenly the system feels like a house of cards.

Here’s the twist: ABCD extensibility is not about banning MV45AFZZ or exits. It’s about putting them in the right place, with the right intent.

The IDoc Question: Clean or Not?

One of the most common debates I hear is: “We use IDocs everywhere. Are they clean core?”

The answer: Yes, IDocs are safe — they fall under Level B.

SAP clarified this in the IDoc Clean Core blog.

Why? Because IDocs are:

Officially documented.
Supported by SAP.
Used for integration and still relevant in S/4HANA.

That said, if you’re starting a greenfield cloud project, you may want to move toward APIs and Event Mesh (Level A) instead. But if you’ve got an existing landscape with IDocs, don’t panic — they’re not “unclean.”

Real-World Scenarios: Which Level to Choose?

Why This Matters for AI

AI copilots like Joule don’t “guess.” They rely on:

Stable APIs (Level A).
Clear data models (A & B).
Trusted logic (not buried in Level C/D).

If your system is full of Level D hacks, AI copilots won’t understand your processes. But if you steer toward A and B (with C monitored), you create an AI-ready enterprise.

Closing Thought

Extensibility is not the villain. Misuse is.

The ABCD framework gives us a shared language:

A when we want innovation + AI without worry.
B when proven frameworks like IDocs or MV45AFZZ still serve us.
C only if there’s no choice — and we track it closely.
D only if we want to leave a headache for the next generation.

So next time someone says “let’s customize,” you don’t need to panic. You just need to ask:

Is this A, B, C, or D? And that one question can mean the difference between a system that blocks AI — and one that accelerates it.

#SAPCleanCore #SAPExtensibility #ABAPCloud #SAPAI #SAPBTP #S4HANACloud #IDoc

DIY JDBC Sender Adapter for SAP Integration Suite

2025-10-21T09:32:29.096000+02:00

DIY JDBC Sender Adapter for SAP Integration Suite

Introduction

Are you migrating from SAP PO to Integration Suite and missing the JDBC Sender Adapter for various integration scenarios? If so, I have just the solution for you! In this article I will show you, how to simulate a JDBC Sender Adapter using a smart design approach. My method allows both scheduled and manual triggering (without redeploying your IFlow). I'll guide you step by step through my implementation to enable you to do the same on your use case.

Core Insight

You can simulate a JDBC Sender Adapter by configuring the Request/Reply step and incorporating your needed triggers.

My Step-by-Step Implementation

Entire Integration Process

Part 1: Polling and Decoupling

Scheduler & Manual Polling
- I created two entry points for the integration flow:
  - A configurable scheduler for periodic database polls.
  - An HTTP endpoint for manual polling via Postman GET—perfect for testing or urgent triggers.
Manual and Scheduled Fetch ProcessPolling the Sender DB

Used a local subprocess with a Request/Reply step to fetch data from the source database.
The fetched data is safely written to a DataStore or a JMS Queue (choose what suits your tenant/scenario) for decoupling and most importantly(at least for me): Retry handling.

SELECT * FROM ${property.JDBC_Schema}.${property.JDBC_Table};

JDBC Poll Process

Part 2: Mapping and Writing to Target DB

Write Data to Target

Reading from DataStore/JMS Queue
- In a second integration process, the data is read from the queue or store.
- Exchange the sender adapter as needed.
Message Mapping in a Local Subprocess
- I placed mapping logic inside a local subprocess to isolate errors.
- If mapping fails, it sets a custom status MappingFailed.
- Mapping errors cannot be retried, so the message escalates directly.
  local Mapping Process
Insert into Target DB
- After a successful mapping, data is inserted into the target database.

Error Handling

Errors are sent to a global error handling process, which checks the Nr of retries against the configured max and then yields an end event.
- Automatic retries is triggered with an Error End.
- Max retries reached, the message was sent to a Dead Letter Queue (DataStore) and escalates.
  Retry Handling Process
Mapping errors escalate instantly. They need to be resolved manually.

Recommendations for Integration Developers

Decouple processes using DataStore or JMS Queue; which makes error handling and retries much easier.
Design your flow to be manually triggerable (e.g., via Postman or another IFlow) which comes in handy in an error case or for testing.

Personal Reflection

Honestly, I was surprised at how well this workaround performed, especially in terms of error handling and decoupling. While it’s not as plug-and-play as a native JDBC Sender Adapter in PO, I created a "template" IFlow based on this concept that I can reuse wherever needed. I have already migrated multiple scenarios using this approach, and it is almost as plug-and-play as in SAP PO. If you are interested in the template or have any questions regarding this topic, feel free to contact me!

SAP Integration Suite

Master Blog: SAP Process Orchestration to SAP Integration Suite Migration – Tool and Guidance

2025-10-30T07:00:00.777000+01:00

Migration Journey Overview: From Assessment to Tooling

Migrating from SAP Process Orchestration to the SAP Integration Suite represents a significant milestone in your organization’s cloud transformation journey. This master blog serves as a central hub for comprehensive information and guidance related to the Migration Tool and the broader migration process. It provides links to detailed blogs, documentation, and best practices to help you successfully plan and execute your migration to SAP Integration Suite.

Before beginning any migration activity, it’s crucial to start with the Migration Assessment - a key capability of the SAP Integration Suite. The assessment analyses your on-premises landscape, including existing integration configurations, mappings, custom adapters, and dependent objects. It provides detailed insights and a comprehensive overview indicating which scenarios can be migrated as-is, which ones require optimization, and which may need to be redesigned or modernized. This step establishes a clear, data-driven foundation for a successful and efficient migration journey.

Once your Migration Assessment is complete, the next big step is moving your integration content to the cloud - and that’s where the Migration Tool comes into play!

The Migration Tool, built into SAP Integration Suite’s Cloud Integration capability, helps you bring your existing integration scenarios from SAP Process Orchestration to the cloud with ease. Think of it as your Guided workflow for migration - it identifies what can be moved, converts integration artifacts into their cloud-ready counterparts, and helps you streamline the entire process with minimal manual effort.

Migration Tool – Offerings and Supported Components

The Migration Tool comes packed with a set of features to make your move from SAP Process Orchestration to the SAP Integration Suite smoother and faster. Here’s an overview of the key components it supports and automates.

Connectivity to On-Premise Systems: Choose the appropriate connection setup for securely linking your on-premise landscape with the SAP Integration Suite. For detailed configuration options, see Configuring Connectivity to an SAP Process Orchestration System

Object Types: The tool supports migration of integration artifacts such as Integrated Configurations, which define how messages are processed within the Java-only runtime of SAP Process Orchestration systems.

It also supports Receiver Determination, which is available in SAP Process Integration dual-stack installations (from release 7.5 onwards) where message processing takes place on both ABAP and Java stacks.

Patterns: The Migration Tool supports a variety of integration patterns to help you transition your existing scenarios to cloud-ready designs. These patterns provide flexibility for different integration needs - whether it’s point-to-point communication, content-based routing, or complex orchestration flows.

For the complete list of supported patterns, refer to the Migration Patterns

Migration Approaches: The Migration Tool offers two approaches - Standard Approach and Pipeline Approach to help you move your integration scenarios efficiently to the cloud. For more details, see Pipeline Concept

Communication Channels: The Migration Tool helps move your existing communication channels to the cloud, making sure your integration endpoints and related settings are mapped correctly. A few exceptions may apply, so some channels might need minor adjustments after migration. For more details, see Standard Adapter Migration.

Adapter Module Support: The tool automatically migrates PGP encryption and decryption modules to cloud-compatible configurations. Additional adapter modules are provided through the community package and can be leveraged as needed. The following list provides an overview: Adapter Modules

Decoupling and Ordered Message Processing with JMS Queues: The Migration Tool supports JMS queue configurations to enable decoupled communication between senders and receivers. In SAP Integration Suite Cloud Integration, internal JMS Adapter help separate asynchronous message processing from the sender, allowing messages to be handled independently and reliably.

To ensure messages are processed in the correct order - EOIO, the Access Type should be set to Exclusive, which ensures that only one consumer/worker processes messages from the queue at a time.

Note: This configuration is not applied automatically by the Migration Tool and must be set manually.

Idempotent at Receiver: The tool also provides idempotent message handling at the receiver side. This means it helps prevent duplicate message processing, ensuring that each message is delivered and processed only once - an essential feature for maintaining data consistency.

Reusing Artifacts for Efficient Migration: The Migration Tool provides options for users to reuse existing standalone artifacts - message mappings and function libraries, to their migrated scenarios. This flexibility allows message mappings and other artifacts to be reused across multiple integration scenarios, reducing redundancy and speeding up the migration process.

Example: Enable Reusable Artifacts

Migration Summary: After the migration, a detailed summary report provides an overview of all successfully migrated Integration Flow Configurations and their related objects in the cloud. If any object could not be migrated, this information is clearly highlighted in the summary, helping you identify follow-up actions easily.

The Migration Tool does offer a downloadable Summary Report that captures essential migration details - including the on-premise system details, integration patterns used, chosen migration approach, and other key information related to each migrated object, which you can review later if required.

Note: If you’d like to select an alternative runtime profile instead of the default Cloud Integration, you can manually set it in the Integration Runtime configuration after the successful migration of the Integration Flow.

Error Logs: When the Migration Tool cannot migrate to certain integration scenarios, it generates a detailed error log summary. This log provides insights into the specific issues encountered, helping you understand what went wrong and take corrective actions.

Hint: The error log is available to download as a .csv file. You can import it in Excel and use a delimiter as Comma (,) to transform the data, to review and analyse the migration errors effectively check columns ‘Status’ and ‘Message’.

For detailed, step-by-step instructions on using the Migration Tool, refer to the official tutorial: Use the Migration Tooling

Known Limitations of the Migration Tool

While the Migration Tool covers a wide range of integration scenarios, there are some known gaps and limitations. For the most up-to-date information, refer to Known Limitations of Migration Tooling

Disclaimer: The list of gaps and limitations may shorten as SAP expands coverage and implements features on its roadmap

Next in the Series

Stay tuned for the upcoming posts where we will dive deeper into specific migration scenarios, tips, and best practices to help you get the most out of SAP Integration Suite.

Published:

✅ Migrating Point-to-Point Asynchronous Scenarios Using the Migration Tool in SAP Integration Suite

✅ Migrating XSLT mappings from SAP Process Orchestration to SAP Integration Suite

✅Migrating Content-Based Routing Scenarios Using the Migration Tool in SAP Integration Suite

Up Next:

➡️ Extended Receiver Determination using the Pipeline Approach

➡️Operation-Specific Receiver Determination and Multi-Operation Scenarios

➡️Content-Based Routing (CBR) – Synchronous Use Cases

References - SAP Documentation and Blogs:

Migration Guide for SAP Process Orchestration

Get Started with Migration to SAP Integration Suite

Assessment Blog: How to use the Migration Assessment Application to get ready to migrate your SAP Process Orchestration Scenarios?

Migration Tool: Migration tool in Cloud Integration Capability of SAP Integration Suite

B2B Scenario Sender EDI to IDOC

2025-10-30T10:32:37.146000+01:00

Introduction

Hi SAP Community, In this blog post, we will explore how to implement a B2B Scenario Sender: EDI to IDOC. This blog provides a step-by-step procedure explaining the whole process in a simple manner. So let’s walk through this journey together!

First, we need to download the source and target structures (MIGs).

In my Scenario Source MIG is (EDIFACT-ORDERS) and Target MIG is (S4-IDOC Purchaseorder).

Go to Design → MIG → Message implementation guidelines → click on create

Search with EDIFACT and select (UN/EDIFACT)

Search with ORDERS and select purchase order as below

Select the required version in my case its D.93A S3

Select with envelope

Skip the sample payload upload step

Provide Name, Direction, Business process(it can be anything in my case I kept as
create order)

Click on create and MIG gets created as below

Now we need to download receiver MIG

Search with SAP S/4HANA On Premise IDoc and select it

In my case it’s (ORDERS.ORDERS05)

Select version as per your requirement

Skip the sample payload upload step

Provide Name, Direction, Business process(it can be anything in my case I kept as
create order)

Click on create and MIG gets created as below

Both Source MIG and Target MIG gets generated.

Now we need to create MAG (mapping guidelines)

Click on Design → MAG → Click on create

Select the source MIG

Select the target MIG

In the below screen click on create

MAG gets created as below

In MAG click on Export → SAP Cloud Integration Runtime Artifacts

ZIP files gets downloaded

pls unzip it.

Below are the files which we will use in further steps.

Go to Discover tab and search with ‘EDI’ and select Package EDI Integration Templates
for SAP Integration Advisor

My scenario is EDI to IDOC so I will be selecting EDI to SAP IDoc - Inbound as below

Click on download, zip file will be downloaded as below

Now we need to go to Design tab →Integrations and APIs → Add → Integration flow →
Upload → Select the iflow which was downloaded

Open the iflow which is uploaded

We need to upload total 4 files
1: In EDI to XML Converter upload (UN-EDIFACT_ORDERS_D93A.xsd)

2: In EDI - Qualifier Pre-Processing upload (TestingEDI_preproc )

3: In EDI to SAP IDoc - Mapping upload (Mapping_TestingEDI_to_TestIdoc)

4: In SAP IDoc - Qualifier Post-Processing upload (TestIdoc_postproc)

I will remove the unwanted steps (EDI Extended Validation (optional), Sender, Receiver, Validate and EDI Interchange steps)

I will use Timer to start the flow

I have used the EDI payload in Content modifier to test the flow in starting step.

Final IDOC output in body:

```xml
<?xml version="1.0" encoding="UTF-8"?>
<ZORDERS1>
    <IDOC BEGIN="1">
        <EDI_DC40 SEGMENT="1">
            <TABNAM>EDI_DC40</TABNAM>
            <MANDT>100</MANDT>
            <DOCNUM/>
            <DOCREL/>
            <STATUS/>
            <DIRECT>2</DIRECT>
            <OUTMOD/>
            <EXPRSS/>
            <TEST/>
            <IDOCTYP>ZORDERS1</IDOCTYP>
            <CIMTYP/>
            <MESTYP>ORDERS</MESTYP>
            <MESCOD/>
            <MESFCT/>
            <STD/>
        </EDI_DC40>
    </IDOC>
</ZORDERS1>
```

Once all the steps are completed then EDI will be converted to IDOC which can be sent
to the S4 system.

Conclusion

This method simplifies B2B integration through mapping and automation using SAP tools. It reduces manual labor and provides error-free data exchange. By executing these steps, you can manage EDI-to-IDOC scenarios seamlessly and enhance communication between your external partners and SAP system.

How to Implement Dynamic Throttling in SAP CPI Using Groovy Script

2025-10-30T10:34:48.763000+01:00

Introduction:

Managing API rate restrictions or avoiding backend system overloads are common problems in SAP Cloud Integration (CPI). When an API receives too many requests in a short period of time, some may reject them, while others may experience significant slowdowns.

In this post, I will demonstrate how to create a dynamic delay mechanism in CPI using Groovy Script, where the sleep duration varies according to request count(header value).

Problem Statement:

Rate-limiting is often necessary for backend or API services.
Standard CPI configuration does not offer a built-in dynamic sleep/throttle feature.
When the load increases, developers need a lightweight way to decrease request speeds.

Solution Approach:

We can use a Groovy Script in CPI to:

1 .Read a custom header (SAP_ApplicationID in this case).

2. Transform it into an integer request count.

3. Implement adaptive delay logic with different thresholds.

Proceed with processing after the determined sleep duration.

//Groovy script
import com.sap.gateway.ip.core.customdev.util.Message;
 
def Message processData(Message message) {
 
    def body = message.getBody();
 
    // Read SAP_ApplicationID
    def headerValue = message.getHeader("SAP_ApplicationID", String.class);
    def requestCount = 0;
 
    if (headerValue != null) {
        try {
            requestCount = headerValue.toInteger();
        } catch (Exception e) {
            requestCount = 0; // Default if not a number
        }
    }
 
    // Determine sleep time 
    def sleepTime = 0;
    if (requestCount >= 3500) {
        sleepTime = 1500;
    } else if (requestCount >= 2000) {
        sleepTime = 1000;
    } else if (requestCount >= 1000) {
        sleepTime = 500;
    } else if (requestCount >= 500) {
        sleepTime = 200;
    } else if (requestCount < 500) {
        sleepTime = 100;
    }
 
    // Apply sleep delay
    if (sleepTime > 0) {
        sleep(sleepTime);
    }
 
    message.setBody(body);
    return message;
}

How it works :

Step 1: Get SAP_ApplicationID from headers.

Step 2: Convert it into an integer(requestCount).

Step 3: Decide sleep time dynamically:

≥ 3500 - 1500 ms
≥ 2000 - 1000 ms
≥ 1000 - 500 ms
≥ 500 - 200 ms
< 500 - 100 ms

Step 4: Sleep for calculated time.

Step 5: Pass the original message forward.

Use cases:

1. For high-frequency situations, API rate restriction with shorter delays works perfectly.

2. Backend overload protection with millisecond-level throttling.

3. Testing integrations under various load conditions.

Conclusion:

This Groovy script provides a simple but effective way to dynamically throttle requests in SAP CPI based on header values. By introducing adaptive delays, you can protect backend systems, comply with API rate limits, and simulate controlled load behaviour.

Integration Between SAP CPI and SAP DataSphere (JDBC Connection)

2025-10-31T08:17:01.679000+01:00

Integration Between SAP CPI and SAP DataSphere (JDBC Connection)

JDBC – JAVA DATABASE CONNECTIVITY

Why Recommendation for JDBC Over OData API :
JDBC is recommended over OData when consuming large-scale records (e.g., 100,000+) because JDBC streams data directly from the database with better performance and less overhead, while OData is optimized for lightweight, paginated, service-based access.

Problem statement: 3337495 - OData API returns less records than expected due paging
Pagination limits in OData and Ariba APIs can be handled in SAP CPI using a looping process call. I’ll cover this with a clear explanation in an upcoming post.

Goal: Connect CPI to a database used by DataSphere (JDBC) and run a simple read data from the (Analytical Model / Table /View).

For the Write / Delete / Update method, the attached SAP Help Portal Link has syntax in the reference section.

Prerequisites:

SAP DataSphere – Subscribed account (⚠ Trial has limited features, JDBC not supported)
SAP Integration Suite – Subscribed or Trial (JDBC actions supported)

SAP DataSphere Step by Step Guide :

Step	Action / Notes
1. Create a Space	DataSphere → Space Management → New Space → Name it → Create.
2. Create Table / Analytical Model	Data Builder → In your Space → New → Table or Analytical Model → define fields & data types → Save & Publish. Verify Table/Model Deployed Successfully.
3. Prepare / Load Data	Load data manually for testing cases. Otherwise load CSV/import to table via Data Builder/Data Integration.
4. Note Schema & Object Names	Record schema name, table name, and view names for JDBC SQL use. * Created space name is the SCHEMA name and Collect Table / Model name *
5. Decide Where to Create DB User	If HANA Cloud → use HANA Cockpit/DB Explorer. If on-prem DB → use DB admin tools or contact DB Admin. * We are using the HANA cloud system for practical session*
6. Create JDBC DB User	DB admin tool → Security/Users → New User → set username & strong password → Save. Check Active status of User
7. Grant Privileges for the DB user	Assign only required privileges (e.g., SELECT for read; add INSERT/UPDATE/DELETE for CRUD). Best practice: create role JDBC_ROLE and assign.
8. Prepare JDBC Connection Details	Gather JDBC URL (e.g. sample URL from datasphere: z*********-abc.hana.prod-eu10.hanacloud.ondemand.com Format for CPI JDBC Material: jdbc:sap://<host>:<port>/?encrypt=true&validateCertificate=true

SAP Integration Suite Step by Step Guide :

Create a Package & Artifact

In CPI → Design → Create a new package → Add an integration flow artifact.
✅ Make sure your CPI user has the required roles to create and access design-time artifacts.

Go to Monitoring → JDBC Material

In CPI → Monitor → Integrations and APIs → Manage Security → JDBC Material
→ Add JDBC Data Source. → Select HANA cloud
Provide JDBC URL in the correct format (e.g., jdbc:sap://<hana-host>:443/?encrypt=true&validateCertificate=true).
Enter DB username and password (use the dedicated JDBC user created earlier in DataSphere).
Save and deploy the JDBC material.

Apply JDBC Material in iFlow

In your integration flow, configure the JDBC receiver adapter → select the JDBC data source created.
Use SQL queries (SELECT) in the Processing tab or provide XML query body. Here, I’m using SQL SELECT * to fetch all records from the table.

Step 1: Timer Start
In this iFlow, the Start Timer is configured with a Simple Schedule → None → On Deployment, which means the integration flow automatically triggers immediately after deployment.

Step 2: Content Modifier
Use this SQL query to fetch all records with the body operation.
SELECT * FROM "<Schema>"."<Model/TableName>"

Step 3: Request Reply & JDBC Receiver Adapter
→ Use the deployed JDBC Data Source alias in the JDBC Material in the previous step and set Max records count based on your requirement.
→ JDBC Maximum Records per call: 2,147,483,647

Sample data Response from JDBC Connection:

References :
same blog by me for clear picture quality: Integration of SAP CPI and SAP DataSphere using JD... - SAP Community
CPI JDBC – XML Query in Body for CRUD Operations (Syntax Guide)
link:
https://help.sap.com/docs/cloud-integration/sap-cloud-integration/payload-and-operation

ABAP Proxy generation support with SAP Integration Suite

2025-11-03T20:36:15.363000+01:00

Introduction

ABAP Proxies are one of the most widely used integration technologies in SAP landscapes. For years, they have been central to PI/PO-based integrations. Now, with the availability of ABAP Proxy support in SAP Integration Suite, customers can extend this capability to the cloud, accelerating their migration from PI/PO to Integration Suite. This closes an important gap for organizations transitioning from SAP Process Integration (PI/PO) to SAP Integration Suite .

This blog provides a technical overview and step-by-step setup guide for enabling generation of ABAP Proxies with Integration Suite.

What Are ABAP Proxies?

ABAP Proxies are generated classes in the SAP ABAP system based on service interfaces defined in the Enterprise Service Repository (ESR).
They allow ABAP developers to call or expose services without dealing with low-level communication protocols.
Proxies are commonly used for synchronous/asynchronous service calls, typically via SOAP adapters in PI/PO.

Why ABAP Proxy Support in SAP Integration Suite Matters?

Until recently, ABAP proxies were heavily tied to on-premise PI/PO middleware. With many customers moving their integration to the cloud, there was a strong demand for equivalent support in Integration Suite.

Key benefits of the new support include:

Cloud-first Enablement – Seamlessly connect SAP backends to Integration Suite using proxies.
Reuse of Existing Investments – No need to redesign all integration scenarios; existing service interfaces can still be leveraged.
Simplified Migration from PI/PO – Reduces the complexity of moving from legacy middleware to cloud-based integration.
Standardized Integration – Continue using ESR artifacts and ABAP proxies as standardized communication interfaces.

Prerequisites

Access to SAP BTP Cockpit with permissions to create service instances and service keys.
Access to SAP S/4HANA or SAP Backend with authorization for transactions SE80, OA2C_CONFIG, and SM59.
Service interface meant for proxy generation must already be present/imported inside an Integration Package of the SAP Integration Suite tenant

1. SAP BTP Subaccount Configuration

1.1 Create the Process Integration Runtime Service Instance

Log on to the SAP BTP Cockpit.
Navigate to your Subaccount.
Go to Services → Instances and Subscriptions.
Create a new Service Instance with the following parameters:

Service: Process Integration Runtime
Plan: api
Role: AuthGroup_IntegrationDeveloper.

Confirm and create the service instance.

1.2 Create a Service Key

Open the newly created Process Integration Runtime service instance.
Choose Service Keys and click Create.
Enter a name for the service key and confirm.
Once created, open the service key and copy the following values, which will be required later:

clientid
clientsecret
url
tokenurl

2. SAP S/4HANA Configuration

2.1 Create OAuth 2.0 Client Profile

Log on to SAP S/4HANA.
Execute transaction SE80.
Create a new OAuth 2.0 Client Profile with the following parameters:

Name: (choose a meaningful name)
Type: Default

Save the profile.

2.2 Create OAuth 2.0 Client

Execute transaction OA2C_CONFIG.
Create a new OAuth 2.0 Client.
Select the previously created OAuth 2.0 Client Profile.
Enter the following details:

Client ID: value copied from the BTP service key (clientid)
Client Secret: value copied from the BTP service key (clientsecret)
Token Endpoint: value copied from the BTP service key (tokenurl)
Grant Type: Client Credentials

Save the configuration.

2.3 Configure RFC Destination

Execute transaction SM59.
Create the RFC destination SAP_PROXY_ESR if it does not already exist.
Configure the destination with the following parameters:

Connection Type: HTTP Connection to External Server
Target Host: value copied from the BTP service key (url)
Path Prefix: /rest/api/v1/workspace/sproxy

Maintain the following settings:

OAuth 2.0 Settings: select the previously created OAuth 2.0 Client
Logon Procedure: Do Not Use a User
Logon Ticket: Do Not Send Logon Ticket
Certificate Logon: Do Not Use a Certificate for Logon
Security Options
- Select SSL Active
- Import CPI’s Server certificate into transaction STRUST (SSL Client → Standard).
- Assign it to the relevant SSL Client PSE so that HTTPS trust is established

5.. Save and test the connection.

Procedure to Generate ABAP Proxy

Log into the SAP ABAP backend system (ECC or S/4HANA).
Run transaction SPROXY.
- This transaction allows browsing and generating proxies from Service Interfaces present in the Integration Suite tenant that is configured in SM59 destination(SAP_PROXY_ESR)
- In the Enterprise Service Browser view, navigate to Source --> ESR --> SWCs to see the list of Integration Packages that contain atleast one of the proxy relevant artifacts(Datatypes,(Fault)Message Types,Service Interfaces) are listed.
- Locate the Integration Package containing the desired Service Interface (Inbound or Outbound).
- Drill down to Service Provider or Service Consumer.(Namespaces -->Choose the desire namespace -->Object Types)
- Choose the Inbound (server proxy) or Outbound (client proxy) interface.
- Right-click the selected Service Provider or Consumer → choose Generate.
- Proxy Generation Wizard opens. Provide:
- Prefix for ABAP Class Names (if needed).
- Package assignment (should be a transportable package, not $TMP if moving to QA/Prod).
- Transport request for recording the generated objects.
- The system creates ABAP proxy classes:
  - Inbound Server Proxy → ABAP Class implementing the interface with predefined methods (developer writes business logic here).
  - Outbound Client Proxy → ABAP Class to call external services (system generates methods to call the remote service).
  - Supporting DDIC structures, types, and message interfaces are also generated.
  - Save and Activate the generated proxies

Use the generated proxy class to implement the Business logic in Transaction SE80 or SE24 .

Current Limitations in the SPROXY Navigation Tree :

Folders are not visible in the SPROXY navigation tree
Datatype enhancements are not listed.
Classifications and Matching Service Interface details will be missing in the Proxy Editor of the Service Interface
...

Recommended view to be used - Enterprise Services Browser view.

Also please ensure to import the service interfaces and its dependants to the Integration Suite tenant from the PI/PO ESR system that was earlier configured in SM 59 destination to be able to retain the already generated proxies. Try maintaining SWCV to Integration Package mapping i.e. Avoid importing objects from multiple SWCV's to one Integration Packages.. Avoid having objects with same name and namespace in multiple Integration Packages.

Migrating Point-to-Point Asynchronous Scenarios Using the Migration Tool in SAP Integration Suite

2025-11-10T15:20:50.256000+01:00

This blog post is part of the series Master Blog: SAP Process Orchestration to SAP Integration Suite Migration – Tool and Guidance exploring how to migrate various integration patterns from SAP Process Orchestration to SAP Integration Suite using the Migration Tool. In this blog, we will focus on the Point-to-Point (P2P) Asynchronous pattern, which is one of the most common and fundamental integration scenarios.

Objective

The goal of this blog is to explain how the Migration Tool supports P2P asynchronous integrations, including:

Key configuration options and technical considerations
Best practices to ensure reliable and decoupled communication
How to implement JMS decoupling and Idempotent Processing effectively

Understanding the Point-to-Point Asynchronous Pattern

In a Point-to-Point (P2P) asynchronous integration, a message is sent from a sender to a receiver without a response message. This pattern promotes decoupling between systems, improves reliability, and allows retry mechanisms to ensure delivery in case you are using JMS queues. By default, the Migration Tool will enable JMS queues during migration.

If there are constraints on the limit of available JMS queues, the tool also supports direct communication without JMS, though this reduces decoupling and resilience. If you are migrating a high number of asynchronous interfaces, SAP recommends using the pipeline approach, which will not be covered in this blog. You can find more information in Pipeline Concept and Migration Tooling now supporting migration via the pipeline approach.

Migration Tool Support for P2P Asynchronous Scenarios using Standard Approach

The Migration Tool automates most of the effort by generating a ready-to-use Integration Flow (iFlow) and the corresponding configuration objects in SAP Cloud Integration.

Depending on your settings, the tool can generate Integration Flows that:

1. Decouple with JMS Queue: Use JMS queues for decoupling between sender and receiver systems (only shown for Asynchronous interfaces):

When you select this option, the Migration Tool creates two Integration Processes within the generated iFlow:

Inbound Process

Receives the message from the migrated Sender Component and Communication Channel
Forwards the message to the JMS queue

Outbound Process

Reads the message from the JMS queue
Performs any required processing (e.g., message mapping, data transformation)

Delivers the message to the receiver system

Please note that you need to maintain the name of the JMS queue post-migration using the already created external parameters:

2. Idempotent Process at the Receiver Side: Use the idempotent process call if you want to make sure that the message will be delivered exactly once to the target system:

When you select this option, the generated iFlow will include an Idempotent Process Call. This mechanism ensures that a message is delivered exactly once to the receiver system, avoiding duplicate postings.

The API call at the receiver system is wrapped then into this local integration process.

There are receiver adapters that do supports idempotency such as SOAP RM, XI and IDoc. In these cases, it’s preferable that you don’t use the Idempotent option on Migration Tool and choose to handle it directly in the adapter. You can find more information in Special Use Cases: SAP RM vs XI vs IDoc.

Post-Migration Activities and Special Scenarios

While the Migration Tool significantly accelerates the transition from SAP Process Orchestration to SAP Integration Suite, a few manual fine-tuning steps are typically required.

Generic Post-Migration Steps

After migrating a P2P Asynchronous interface:

Review and update external parameters for sender and receiver connectivity.
Define the JMS queue name to be used in both Integration Processes (in case checkbox is marked during wizard). This can be done in the external parameters’ configuration view.
Update
Review if you want to change the value of the header SAP_Sender according to the naming convention that will be adopted on SAP Integration Suite.

Manual Activities Depending on Integration Scenario

You can also find below few examples of manual activities post-migration that needs to be performed depending on the content of your integration scenario:

Functions like RFC Lookup or JDBC Lookup on Graphical Message Mapping are not automatically converted. Replace them with equivalent Integration Suite adapters or externalized APIs. Tutorials are available for JDBC lookups and RFC lookups.
If your interface is using any custom code (e.g., UDF, Function Library, Java Mapping) or XSLT that have additional dependencies, Therefore, you need to export them from SAP Process Orchestration and import into your Integration Flow
If your interface is using a fault message handling, this won’t be migrated using the Migration Tool. Therefore, you need to import the mapping using the standalone functionality and add an exception handling subprocess into the migrated iFlow

Please refer to the Known Limitations of Migration Tooling for additional insights into cases that may require manual adjustments after migration. we will explore specific topics in more depth, such as XSLT transformation differences between SAP Process Orchestration and SAP Integration Suite, custom code migration, fault message handling, and other advanced migration scenarios.

Async-Sync Bridge Support

The Point-to-Point Asynchronous pattern also covers scenarios using an Async-Sync bridge.

In SAP Process Orchestration, an asynchronous interface is converted into synchronous using the RequestResponseBean module, enabling a response message to be sent back to the sender asynchronously using a second interface object.

The Migration Tool can migrate this Async-Sync bridge scenario as well, ensuring that both asynchronous and synchronous steps are merged into a single iFlow.

Please note that the Sync-Async bridge scenario (the opposite from the above), is not supported as of today.

Conclusion

In this first blog of the blog series, we explored how to migrate Point-to-Point Asynchronous scenarios and how the Migration Tool simplifies this process by leveraging JMS decoupling and Idempotent Processing. These capabilities help ensure reliable, scalable, and fault-tolerant communication between systems.

Partnering for Progress: Accelerate Your Move to SAP Integration Suite

2025-11-17T21:08:53.578000+01:00

When I first started working with SAP’s Migration Factory program, I quickly realized just how big of a shift many organizations were facing.
For years, SAP Process Integration (PI) and SAP Process Orchestration (PO) have been the backbone of countless businesses’ integration landscapes. But with mainstream maintenance ending in 2027, the question everyone’s asking is: “What’s next?”

And the answer is clear — SAP Integration Suite on SAP Business Technology Platform (BTP).
It’s modern, scalable, and built to meet the needs of today’s connected, cloud-first world. But let’s be honest — migration isn’t just about technology. It’s about people, collaboration, and having the right partners by your side.

That’s where Migration Factory 2.0 comes in.

Building a Stronger Ecosystem — Together

What excites me most about Migration Factory 2.0 is that it’s not just a framework — it’s a movement.
We’re bringing together SAP and our partners under one unified goal: to help customers modernize with speed, confidence, and shared expertise.

Through this program, partners get the enablement and resources they need to deliver migrations effectively, and customers get access to a trusted ecosystem that’s been trained, certified, and supported directly by SAP.

It’s truly a “win-win-win” — for SAP, our partners, and most importantly, our customers.

Behind the Program: Enablement, Execution, and Engagement

At its core, Migration Factory 2.0 is built on three simple but powerful pillars:

Enablement: We equip partners with the latest training, certifications, and migration tooling — including our Integration Suite Black Belt 2.0 program.
Execution: We support them with proven methodologies, automation frameworks, and best practices developed alongside SAP experts.
Engagement: We celebrate their success through co-marketing, events, and storytelling opportunities that amplify their impact across the SAP ecosystem.

Every one of these pillars is about empowering collaboration — because success in integration isn’t achieved in isolation.

Why Partners Are the Game Changers

Working closely with our partners, I’ve seen firsthand the dedication, innovation, and creativity they bring to every customer engagement.
Migration Factory 2.0 gives them more than just visibility — it gives them a platform to shine.

Through the program, partners can:

Earn SAP’s Partner Badge for SAP PO/SAP Integration Suite Modernization
Be featured on our Migration Factory Partner Listing on SAP.com
Participate in co-marketing campaigns, webinars, and video series like Integration Situation
Receive qualified migration assessments from SAP
Connect with other partners and SAP experts through enablement sessions and community collaboration spaces

It’s inspiring to see how quickly our partner community has embraced this journey — not just as a business opportunity, but as a shared mission to help customers move forward.

Helping Customers Choose the Right Partner

For customers, we’ve made it easy to find the right expertise through the Migration Factory Partner Listing on SAP.com.
Each partner listed has been enabled through SAP’s framework and offers migration assessments, readiness checks, or implementation services tailored to customer needs.

Whether you’re in Europe, Asia, or North America — you can now connect directly with a partner who understands your regional and industry-specific challenges.

My Favorite Part: The Collaboration

One of my favorite things about being part of this initiative is watching new partnerships form — partners collaborating with each other, learning from SAP experts, and even co-creating new migration approaches together.
It’s a reminder that technology may power transformation, but people make it happen.

Every week, I see stories from partners who have taken what they learned from Migration Factory enablement sessions and turned it into real customer impact. That’s what keeps me passionate about this program — it’s not theory, it’s transformation in action.

Let’s Move Forward — Together

If you’re a partner, now’s the time to get involved.
Join the Migration Factory 2.0 program, earn your certifications, and showcase your success stories to the global SAP community.

If you’re a customer, explore the Migration Factory Partner Listing on SAP.com to connect with certified experts who can help you plan your move from SAP PI/PO to SAP Integration Suite.

The future of integration is here — and it’s collaborative, connected, and cloud-driven.
Together, we’re accelerating integration modernization — one connection at a time.

High-Volume Data Handling in SAP Integration Suite - Our Journey to 10 Million Records

2025-12-02T15:49:20.601000+01:00

“In the middle of difficulty lies opportunity.” – Albert Einstein

Handling large-volume data integration is something every integration specialist meets sooner or later. Recently, our team faced one of those “opportunities”—a requirement to transfer around 10 million records from a source system to a target application using SAP Integration Suite (IS) formerly called as SAP Cloud Platform Integration (CPI).

At first glance, the mapping requirements were straightforward. But as always, the devil hides in the details: the pagination behavior of the OData V4 adapter, the Integration Suite processing limits, and unforeseen behavioral quirks pushed us through several attempts before landing on a robust solution.

This blog walks through:

What approaches we tried
Why they failed
What finally worked
Key learnings for anyone building high-volume integrations on SAP IS

Context: The Scenario

The source system exposed data through an OData V4 service. A key limitation we discovered early on:

Pagination is fully server-controlled in OData V4 adapter
The page size cannot be customized in SAP Integration Suite (e.g., you cannot set it to 1,000 or 10,000) when using the standard OData V4 adapter, it always respects the server-side limit
Example: If the server page size is 50,000, SAP IS will always retrieve chunks of 50,000 - nothing less

This limitation became the center of the problem.

Approach 1 — Standard OData V4 Adapter + Looping Process Call

(Expected to work… reality had other plans)

How it worked:

Used the OData V4 adapter as-is with server-side pagination
Used Looping Process Call to iterate through pages

What happened:

If the total data was below 50K, everything worked smoothly
Above 50K, the iFlow got stuck in Processing
No errors
No termination
Messages remained frozen for days

Example:

Server page size → 50K
Data set = 40K → Success
Data set = 150K → iFlow stalled indefinitely

Lesson: Looping + uncontrolled server pagination = unpredictable behavior.

Approach 2 — OData V4 Adapter + Custom Pagination Logic

(Better… but still not scalable enough)

This time we added:

Custom counter checks
Pagination logic in iFlow
Looping until full completion

Result:

Worked better than Approach 1
Successfully processed volumes under ~1 million records
Beyond that threshold → iFlow stuck again, still showing Processing but not progressing
No runtime error, no bottleneck in MPL — simply a silent stall

Lesson: The bottleneck was structural, not logical.

Approach 3 — Final Working Solution (and the hero of the story)

“Simplicity is the ultimate sophistication.” — Leonardo da Vinci

Key idea:

Avoid OData V4 adapter entirely.

Use the Classic HTTP Adapter with explicit control over pagination (via top & skip).

This allowed us to fully control the data fetch size and execution flow.

Our Winning Architecture

Flow 1: Master Controller iFlow

Call the source system via HTTP adapter
Retrieve total record count
Calculate the required number of batches

Batch size = server-side max (e.g., 50K)

For each batch, create a message containing only the skip value
Store skip values in Data Store

Example:

Total records = 1,000,000
Batch size = 50,000
Total batches = 20
Stored skip values = 0, 50000, 100000, ...

Flow 2: Worker iFlow

Poll Data Store
Read skip value
Call API using HTTP adapter with parameters:
$top=50000
$skip=<value from datastore>
Process the dataset
Deliver to target system

The Big Win

This mechanism:

Gave us full control over pagination
Completely bypassed OData V4 limitations
Handled 10+ MILLION records without stalls
Achieved stable throughput
No permanent IFlow “Processing” states
No invisible bottlenecks

Lesson: If the adapter limits you, take control with HTTP.

Key Learnings

SAP Integration Suite is powerful and evolving, but very high-volume scenarios still expose adapter-level limitations
OData V4 Adapter may not be suitable for massive pagination-driven extractions in all cases
HTTP adapter with custom pagination is a reliable fallback
Sometimes the “classic” tool is the best tool

And yes—raising an SAP incident might eventually clarify the root cause, but business timelines forced us to engineer a workaround.

Conclusion

High-volume data integration is never trivial. The key is to experiment, observe system behavior, and design around limitations. Our final approach was not just functional—it was scalable, predictable, and production-proof.

If you’re dealing with similar large dataset transfers in SAP IS, this solution pattern might save you hours of troubleshooting.

Feedback Welcome

I’d love to hear your thoughts, improvements, or other patterns you’ve successfully used for large-volume integration scenarios in SAP Integration Suite.

Thank you for reading!

I2Integration Solutions | A Startup

Connect in LinkedIn: I2Integrate

Migrating XSLT mappings from SAP Process Orchestration to SAP Integration Suite

2025-12-05T14:14:56.289000+01:00

While SAP Integration Suite, Cloud Integration supports XSLT mappings, you may encounter subtle yet impactful differences when migrating XSLT-based mappings from SAP Process Orchestration (PO). This post outlines the main variations between both environments, explains typical runtime issues, and provides practical guidance for smooth adaptation.

XSLT Processor Differences

The XSLT processor behind Cloud Integration is Saxon EE 9.9.1.6 (as of November 2025 – see this Blog for details on verifying the processor version) while SAP Process Orchestration next to its default allowed the import and use of other processors.

While these differences should not usually cause major compatibility problems, certain manual adjustments after the tool-assisted migration might be required to deploy or execute mappings successfully. In particular, there are variations in how standard XSLT functions handle data types, how Java classes are used within XSLT code and how other stylesheets are included.

Data Type Handling in XSLT Functions

SAP Process Orchestration tends to be more lenient regarding data type usage in standard XSLT functions. Cloud Integration, on the other hand, applies stricter type validation during compilation and runtime.

Example 1: Using xsl:sort with Data Types

The xsl:sort function sorts data based on specified criteria:

<xsl:sort select="data" data-type="text"/>

The allowed data types for this function are "text" and "number". On SAP Process Orchestration, the following syntax works without error:

<xsl:sort select="DATES" order="ascending" data-type="xsd:Date"/>

However, in Cloud Integration this causes a runtime error:

Adjusting the data-type accordingly to text or number solves this issue. However, one needs to pay attention to the effects this might have on the format and thus the rest of the stylesheet execution.

Example 2: Using format-number() with non-numeric inputs

On SAP Process Orchestration, the following syntax works without error:

<xsl:value-of select="format-number(substring(data, 0, 3), '0.00')"/>

In Cloud Integration, this causes a compilation error during runtime:

The issue arises because format-number() requires a numeric input, while substring() returns a string.
To resolve this, explicitly convert the substring to a number:

<xsl:value-of select="format-number(number(substring(data, 0, 3)), '0.00')"/>

Please note that if a global number format is defined, this conversion might affect the formatting of the substring according to that global setting.

Using Java Classes in XSLT

XSLT mappings sometimes rely on custom Java classes to extend the functionality of native XSLT functions, a common practice in integration projects where XSLT offered fewer built-in capabilities.

During migration, you may encounter Java classes ranging from simple helpers (e.g., string or date transformations, counters) to more complex ones (e.g., document loaders, RFC calls, or value mapping lookups). While some advanced use cases may require redesign or alternative approaches, simpler helper classes can still be used in Cloud Integration.

Step 1: Uploading the Java Classes

Upload the Java classes as a JAR file and add them to the iFlow’s References (using the Archive option).

If the java classes are contained in the same Imported Archive (IA) as the XSLT using them on PO, the migration tool will automatically import them as it imports the entire IA during the migration process. However, if the java classes are in a separate IA, this needs to be done manually post tool migration.

Please note that the JAR file must be added as a local resource into the iFlow. Currently it’s not possible to use as a reusable artifact.

Step 2: Adjusting XSLT Syntax

Namespace Declarations

SAP Process Orchestration allows multiple styles for Java namespace declarations, while Saxon (the processor in Cloud Integration) supports only one format.

a) Inline Declaration

xmlns:java="http://xml.apache.org/xslt/java"

<xsl:variable name="date" select="java:com.edi.xslthelper.DateTransform.GetDate(data)"/>

b) Namespace Declaration with Class Path

xmlns:date="java:com.edi.xslthelper.DateTransform"

<xsl:variable name="date" select="date:GetDate(data)"/>

In Cloud Integration, only the second option (namespace declaration with class path) is supported. Therefore, all Java class calls must be manually adapted accordingly.

Type Handling in Java Class Calls

Just like native XSLT functions, Java class calls in Cloud Integration require explicit type consistency. For example:

<xsl:variable name="__function4" select="variable:setValue($var,'Name',string(number(data)))"/>

If a Java class expects a string, the input must be explicitly converted. On SAP Process Orchestration, the same code might work without this conversion.

In one specific migration case, a Java method required an integer input — here, neither round() nor number() worked, but the XSLT function xs:integer() was necessary.

Please note that compilation errors such as “Errors were reported during stylesheet compilation” are often related to incorrect data types. Explicitly converting inputs usually resolves these issues.

References to other stylesheets within the XSLT

XSLT code from different stylesheets can be used in an XSLT mapping using the include function:

<xsl:include href="Stylesheet2.xsl"/>

The included stylesheet needs to be added manually as a reference to the iflow:

On Cloud Integration, no folder structures are supported so if the IA on PO had a nested folder structure containing the stylesheets, make sure to upload them individually and remove the path in the include function of your original stylesheet like our example above.

Recommendations for Successful Migration

To ensure smooth execution of XSLT mappings in Cloud Integration:

Always verify and explicitly define correct data types.

Adapt namespace declarations for all Java class calls.

Adapt the include of additional stylesheets.

Upload all necessary additional components (jar files, stylesheets).

Test mappings individually after migration to detect type-related issues early.

Simplify or refactor complex Java-dependent logic where possible.

Following these guidelines helps prevent runtime errors and ensures stable, predictable execution after migration.

Conclusion and Next Steps

Migrating XSLT mappings from SAP Process Orchestration to SAP Integration Suite requires close attention to how the underlying XSLT processor interprets data types and Java extensions.
While most mappings migrate seamlessly, subtle differences, particularly in data type handling, namespace declarations, and custom Java integrations, may lead to compilation or runtime issues if not adjusted.

Stay tuned for the next part of this series, where we’ll continue our deep dive into migration patterns and modernization best practices in SAP Integration Suite, including insights on content-based routing, custom code handling, and error management.

FAQ – Migration from SAP Process Orchestration to SAP Integration Suite

2025-12-05T20:26:50.090000+01:00

This blog provides answers to the most frequently asked questions from customers and partners planning their migration from SAP Process Orchestration (PI/PO) to SAP Integration Suite.

This content was prepared by many experts from different areas at SAP and it covers assessment, tooling, technical migration topics, and operational aspects to help you plan and execute a smooth transition to SAP’s cloud-native integration platform.

Last Updated: Nov 2025 – SAP Integration Suite Move Experts.

Assessment and Planning

This section is focused on questions related to the initial planning or assessment of your landscape, normally before the start of the migration project.

Q1: Why should I move from SAP Process Orchestration to SAP Integration Suite?

A: Migrating from SAP Process Orchestration to SAP Integration Suite enables organizations to modernize their integration landscape with a cloud-native, fully managed, and future-proof integration Platform as a Service (iPaaS) that supports both cloud and hybrid scenarios.

It eliminates infrastructure maintenance, reduces total cost of ownership, and accelerates time to value through more than 4000 prebuilt integrations, 4,600+ APIs, and approx. 1400+ business events available on SAP Business Accelerator Hub (as of end of 2025) and keep adding up. See more information in Value Proposition: Why You Should Move to SAP Integration Suite.

Q2: What is the Migration Assessment tool in SAP Integration Suite?

A: The Migration Assessment is a capability within SAP Integration Suite designed to analyze your SAP Process Orchestration interfaces providing many insights about the interfaces’ complexity, dependencies, categories of functionalities and effort estimation for the technical migration. See more information in Migration Assessment.

Q3: Which SAP Process Integration/Orchestration versions are supported by the Migration Assessment?

A: The Migration Assessment supports SAP Process Integration/Orchestration versions:

7.31 SP28 and above
7.40 SP23 and above
7.50 SP06 and above

The Migration Assessment supports interfaces created based on Interface Configuration Object (ICO) and interfaces created based on Receiver Determination (together with Sender Agreement, Receiver Agreement and Interface Determination) in dual stack environments.

Note: For 7.50 (SP06 to SP09), make sure to have implemented the patch as described in the SAP Note 2456339.

Q4: How can I start planning my migration project?

A: Begin by running the Migration Assessment to understand your system landscape and estimate migration efforts. Then define the migration strategy (e.g., phased migration, modernization on focus areas).

Review the Migration Guide, evaluate reusable content, and prepare your SAP Integration Suite tenants (development, test, and production). SAP recommends the Discovery Center mission Get Started with Migration to SAP Integration Suite to get confidence and understanding on the tools.

Q5: I have SAP Process Integration 7.1. Can I use the Migration Assessment and/or Migration Tool?

A: SAP cannot guarantee that the Migration Assessment and Migration Tool can work properly in an SAP Process Integration version different than the ones supported (see question 3), although many of the APIs used might be available on the same. SAP recommends upgrading the SAP Process Integration to a supported release before running the assessment and/or migration to ensure accurate results.

Q6: How can I determine the number of required message blocks while moving from SAP Process Orchestration to SAP Integration Suite?

A: In the Migration Assessment result, you can have the counting of message throughput and some performance indicators per interface such as the average message size, for the previous month that you ran the extraction. You can use both information to calculate the number of required messages blocks in SAP Integration Suite.

Make sure to activate the monthly performance collection on SAP Process Orchestration as per SAP Note 3300008.

For synchronous messages, you might need to check if synchronous messages are logged on the Message Overview Monitor as per the SAP Note 2442373. Make sure to read throughout the note and agree or not with any additional overhead due to the additional message logging in case this is not enabled, and you want to collect also such data.

For more information of what is the definition of a Message on SAP Integration Suite refer to the SAP Note 2942344 and Discovery Center.

Q7: Where can I find more information about how to use the Migration Assessment?

A: You can find more information about the Migration Assessment in the following references:

Q8: I have on-premise to on-premise integration scenarios and I don’t want to exchange my messages over the Internet in SAP Integration Suite. What is the best solution?

A: For on-premise to on-premise integrations where you don’t want messages to enter the public Internet, the best solution is to run your integration flows using the Edge Integration Cell. It lets you design and manage integrations in the cloud while executing all runtime processing inside your own network, fully avoiding external message exchange. You can find more information in the following references:

Q9. What are the typical migration approaches and how do they differ?
A: Typical migration approaches are:

Lift-and-Shift: Move existing SAP Process Orchestration interfaces to SAP Integration Suite with minimal functional changes. This reduces short-term project risk and effort, preserving legacy designs (quick win) and safeguarding existing investments. Use when timelines are tight or when business logic must remain unchanged. The downside is to lose the momentum to promote innovation leveraging other SAP Integration Suite capabilities than Cloud Integration.
Modernization: Re-design interfaces to use API-led or event-driven patterns for instance, remove deprecated technologies, consolidate redundant interfaces, centralize common functionalities and promote a Clean Core mindset. This requires more design work but yields long-term maintainability, scalability and ensures a future-proof landscape.

Q10. How long does a typical migration project take, and what resources are required?
A: Duration depends on landscape size, complexity, and chosen approach:

Small landscapes (up to 100 interfaces, mostly lift-and-shift) commonly take 1–3 months.
Medium landscapes (up to 300 interfaces, mostly lift-and-shift) commonly take 3-6 months.
Large landscapes, depending on the number of the interfaces, can take more than 1 year but also has bigger opportunities of parallelization using the right tools and promoting a learning curve across the members of the project.

Required technical resources normally include:

Integration architect (for medium and large landscapes)
Integration Lead
Cloud Integration developers
Project manager

Depending on how you want to run the validation phase, you might need to consider allocating business users for specific phases and if testing tools will be used, then specific QA/Automation Test engineers.

Q11. Can I run the Migration Assessment without external internet access (e.g., on secure networks)?

A: The Migration Assessment extracts data from your on-premise SAP Process Orchestration system via a secure connection established through SAP Cloud Connector to the SAP Integration Suite tenant. Because it requires a connection between the on-premise system and the SAP Integration Suite service, you cannot run the assessment entirely offline; however, connectivity is secured and routed through Cloud Connector, so your systems do not need to be open to the public internet. Please note that intermediary components such as reverse proxies cannot be used to connect with Migration Assessment.

Q12. Is the Migration Assessment available on all SAP Integration Suite editions (e.g., starter, standard, premium)?
A: The Migration Assessment capability is available in the Free Tier, Trial, Standard and Premium editions of SAP Integration Suite. The Migration Assessment is not available in SAP Cloud Integration (Neo environment).

Q13. Can AI tools assist in modernization (e.g., auto-mapping, code transformation)?
A: Yes. SAP Integration Suite leverages AI-assisted capabilities to support and accelerate modernization. these include:

Generative AI for flow generation: You can bootstrap Integration Flows using AI, helping to create integration flows more quickly.
Integration Advisor enhancements: AI can suggest mapping patterns and recommend semantic mappings based on libraries and historical data.
Anomaly detection: AI helps detect runtime anomalies and integration issues, enabling proactive monitoring and optimization.
AI-powered adapter: There is an AI Adapter for Integration Suite that facilitates generative AI–driven integration scenarios.

These AI features can reduce manual effort, speed up design, and improve the quality of migrated or modernized integrations. See more information in Artificial Intelligence.

Q14. How does modernization differ from migration?
A: Migration is the technical move of integration artifacts from SAP Process Orchestration to SAP Integration Suite with the minimum changes to make the interface runnable again. Modernization is a broader redesign that rethinks integration patterns (e.g., APIs/events, pipelines), removes obsolete constructs, and aligns integrations with cloud-native practices. It often follows or accompanies migration but has a stronger emphasis on long-term architecture, reusability, and business enablement.

Q15: Where can I find more information about modernization?

A: You can find more information about modernization in the following references:

Migration Tools and Capabilities

This section is focused on questions related to the tooling available to automate and accelerate your migration from SAP Process Orchestration to SAP Integration Suite.

Q1: Is there a tool to migrate my interfaces from SAP Process Orchestration?

A: Yes. The Migration Tool in SAP Integration Suite accelerates the conversion of SAP Process Orchestration integration artifacts (e.g., mappings, communication channels, and interface objects) into Cloud Integration artifacts. It significantly reduces manual effort and ensures consistency between the source and target environments. See more information in Migration Tooling.

Q2: What are the benefits of using the Migration Tool in Cloud Integration?

A: The Migration Tool accelerates the migration process, minimizes manual effort, and reduces human errors. The Migration Tool helps to ensure that the developer reuses common artifacts and that the interfaces are migrated in a consistent way.

Q3: Are there any limitations in the Migration Tool?

A: Yes. The Migration Tool currently supports a defined set of adapters, components and integration patterns. Some complex scenarios (e.g., BPM, ccBPM, custom adapter modules, mappings with unsupported functions) may require manual adjustment. See more information in Known Limitations of Migration Tooling. Please note that the Migration Tool is continuously updated to close the gaps and to increase scenario coverage.

Q4: Is there a way to import SAP Process Orchestration artifacts without using the Migration Tool?

A: Yes. The Migration Tool will take care to import the dependent objects from your interface all at once; however, if you prefer, you can import many artifacts in an isolated manner. See more information in the following references:

Q5: Is Cloud Connector setup mandatory to connect the Migration Assessment and Migration Tool to SAP Process Orchestration?

A: Yes. The SAP Cloud Connector is required to establish a secure connection between SAP Integration Suite (cloud) and the on-premise SAP Process Orchestration system. It allows the tools to extract configuration data without exposing the system directly to the internet. See more in Add an SAP Process Orchestration System.

Q6: Does the Migration Tool support other non-SAP integration platforms?

A: No. The Migration Tool is designed specifically for migrating integration scenarios from SAP Process Orchestration to SAP Integration Suite. Migration from non-SAP platforms must be handled manually or with partner tools specialized in cross-platform migrations.

Q7: Where can I find more information about the Migration Tool?

A: You can find more information about the Migration Tool in the following references:

Q8. How are the Message Mappings migrated with the Migration Tool?
A: The Migration Tool analyzes message mappings and imports them into Cloud Integration as the best available equivalent: it will convert native message mapping objects where possible, importing Message Mapping as local or global resources. The migration wizard supports reuse where possible (for example, reusing existing message mapping artifacts as shared resources).

Note: XSLT and Java mappings are only imported as local resources.

Q9. Is the Migration Tool available on all SAP Integration Suite editions (e.g., starter, standard, premium)?
A: The Migration Tool is a feature of the Cloud Integration capability on SAP Integration Suite and is generally available in the Free Tier, Trial, Standard and Premium editions of SAP Integration Suite. The Migration Tool is not available in SAP Cloud Integration (Neo environment).

Q10. How are security credentials handled during migration (e.g., user/passwords, keystores)?
A: Credentials and keystore material are not automatically migrated. The Migration Tool will migrate some connectivity/credential references (i.e., adapter parameters, keystore aliases, user IDs), but you must reconfigure and securely store credentials in the SAP Integration Suite tenant (e.g., Key Store, OAuth credentials). Keystores and certificates can be manually exported/imported and must be validated for post-migration. Treat credentials separately in your runbook and ensure secure handling (do not embed plain passwords in migrated flows). See more information in Managing Security Material in Cloud Integration.

Functional and Technical Migration Topics

This section is focused on questions related to specific use cases while migrating interfaces from SAP Process Orchestration to SAP Integration Suite, its differences and migration strategy.

Q1: Is it possible to reuse Operation Mappings from SAP Process Orchestration in Cloud Integration?

A: Yes, you can import the Operation Mappings from the ES Repository to Cloud Integration. However, since you cannot edit the Operation Mapping after the import, SAP recommends importing the individual steps of your Operation Mapping as flow steps (i.e., Message Mappings, XSLT, Java Mappings). The Migration Tool is able to read the content of the Operation Mapping whereas the Operation Mapping as such won’t be imported, instead all referenced artifacts such as message mappings, XSLTs, and Java mappings will be imported following SAP’s recommendation.

Q2: What happens with my ABAP Proxies in ECC or SAP S/4HANA post-migration?

A: ABAP Proxies can still be generated in design and used in runtime, but instead of connecting to SAP Process Orchestration, they will connect to SAP Integration Suite. For more information how to migrate the ABAP proxy for the design and runtime, see the following references:

For the runtime, to avoid having one SM59 destination per Integration Flow, you can create an Integration Flow with an XI sender adapter acting as a single XI entry point and which then dispatches the XI messages to the actual integration flows. SAP recommends using the Pipeline for Cloud Integration which supports this approach out of the box via a so-called generic XI inbound processing flow. Furthermore, to handle XI messages sent from Cloud Integration to an ECC or SAP S/4HANA system in a common way, the Pipeline for Cloud Integration supports a generic XI outbound processing flow also taking e.g. message packaging into account.

The Pipeline for Cloud Integration actually supports the runtime of any interface in SAP Integration Suite by recreating the SAP Process Integration/Orchestration-style pipeline execution using a set of generic, reusable integration flows that handle receiver determination, interface determination, mapping, routing, and retries, allowing messages to run through a structured, processing sequence. See more information in Pipeline Concept and in particular section Generic Inbound and Outbound.

Q3: What happens with my IDocs in ECC or SAP S/4HANA post-migration?

A: IDoc-based communication can continue through Cloud Integration using the IDoc adapter. The connection between ECC or SAP S/4HANA and the SAP Integration Suite tenant can be established securely via Cloud Connector or Direct Connection depending on your network setup. See more information in IDoc Adapter.

For the runtime, SAP also recommends using the Pipeline for Cloud Integration. Like for XI inbound and XI outbound, the Pipeline for Cloud Integration comes with a generic IDoc inbound processing flow as well as a generic IDoc outbound processing flow to handle the configuration of IDoc scenarios in a common way (see previous question). See more information in Pipeline Concept and in particular section Generic Inbound and Outbound.

Q4: How can I migrate my adapter modules (standard and custom)?

A: Standard and custom adapter modules may already have equivalent functionality in Cloud Integration through pre-built adapter features or out-of-the-box flow steps. In case they are not available, you can check as well the Message Transformation Utilities community package, where you can also find many of these adapter modules converted into Groovy scripts and ready to use. See more information in Adapter Modules in the Migration Guide.

Q5: How can I migrate my Java Mappings?

A: The Migration Tool will import your Java Mapping as a non-editable local resource (.JAR) to your Integration Flow and will wrap the mapping call using a Groovy script as per defined in Migration Java Mappings. Please be aware that your Java Mapping will only work if it’s not using any SAP Process Orchestration specific library. SAP recommends converting the Java Mapping to Groovy if possible, however, adapting the Java code and recompiling it using an external IDE is also an option for small adjustments.

The Migration Tool will not import additional dependencies, so you need to import them manually post-migration.

Q6: How to handle PGP Encryption/Decryption while moving from SAP Process Orchestration to Cloud Integration?

A: The Migration Tool supports the migration of the standard adapter modules for PGP Encryption/Decryption. That means that by post-migration you’ll be able to see the Encryptor or Decryptor flow steps. The PGP keys must be manually imported into Cloud Integration.

Q7: Are RFC/JDBC lookups supported in Cloud Integration?

A: Yes, but with some differences. RFC lookups can be achieved via RFC adapter or OData/API-based service calls. JDBC lookups are supported through the JDBC adapter, provided the database is securely reachable from the cloud via Cloud Connector. See more in RFC Lookup and JDBC Lookup tutorials.
In SAP Process Integration/Orchestration the lookup was often done directly in the mapping using a reference to a Communication Channel. In Cloud Integration, you can decide if you want to implement the lookup directly as a UDF or in a separated step. By doing in a separated step outside the mapping, you also simplify the monitoring.

Q8: Is it possible to reuse Function Libraries in Cloud Integration?

A: Yes. Function Libraries (FL) can be imported into Cloud Integration. You can import them together with your interface using the Migration Tool or import specific Function Libraries directly into a package. This allows you to bring Function Library definitions into Cloud Integration and reuse them across Integration Flows. However, you should review any library references and adjust naming conventions or package structures to ensure they work correctly in your migrated interfaces.

Q9: How to move from SAP Process Orchestration B2B Toolkit to SAP Integration Suite?

A: You can migrate B2B scenarios from SAP Process Orchestration to SAP Integration Suite by following the dedicated B2B migration guidance. The recommended approach is to first assess existing B2B components (agreements, mappings, message types) and then select one of the supported migration paths:

Migrate to Cloud Integration, converting ICOs, mappings, and B2B message flows into Integration Flows using the migration approaches and templates provided.
Adopt Trading Partner Management (TPM), which replaces PO’s B2B Toolkit by managing partners, agreements, and message processing natively in Integration Suite.

During migration, you may need to adjust adapters, communication channels, and partner-specific configurations. For instance, as of today, EDISeparator can’t be migrated and imply into a redesign of your B2B interface.

After migration, re-create or refine partner setups in TPM or Cloud Integration and validate end-to-end B2B processing before go-live. See more information in Migrating B2B Interfaces.

For more questions how to proceed with your B2B migration journey, please contact the b2bintegrationfactory@sap.com, which is a focused team at SAP to support customers on the B2B migration.

Q10: Does SAP Integration Suite support transport mechanisms comparable to those in SAP Process Orchestration?

A: Yes. SAP Integration Suite supports artifact transport using Cloud Transport Management Service (CTMS). See more information in Transport Management Options.

Q11: Is there any testing automation tool to validate my interfaces post-migration?

A: Yes. SAP recommends partner tools like INT4 IFTT or Figaf Testing Suite for automated validation. These tools help compare source and target message payloads, mappings, and end-to-end message flows. See more information in Int4 Shield Lite or Figaf DevOps.

Q12: How can I migrate my ccBPM or BPM from SAP Process Integration/Orchestration to Cloud Integration?

A: Cloud Integration does not support the migration of ccBPM or BPM directly, although you can redesign them into normal Integration Flows using the processes flow steps as they are based on BPMN. For integration-centric processes, see Guidelines to Implement Specific Integration Patterns. For human-centric workflows, use SAP Build Process Automation.

Q13: Are there best practices for structuring and naming artifacts in Cloud Integration?

A: Yes. Use consistent naming conventions that reflect integration purpose, source, and target systems. Group related artifacts within packages. See more information in Naming Conventions.

Q14: How to ensure Quality of Service (Exactly Once and Exactly Once In Order) support in Cloud Integration?

A: Cloud Integration supports Exactly Once (EO) and Exactly Once In Order (EOIO) through JMS queues. Additionally, idempotent handling is required which, unlike in SAP Process Integration/Orchestration, is often not built into the adapter itself but must be modelled directly in the Integration Flow. See more in Quality of Service.
Usage of JMS queues requires a concept for efficient operations to e.g. model restarts in case of errors, error notification and error handling. Also, the number of JMS queues in a tenant is limited and should therefore be used carefully. More information about the JMS queues in Cloud Integration can be found in Cloud Integration - JMS Resource and Size Limits.
Also in this case, the Pipeline for Cloud Integration offers the usage of generic queues and implements generic error handling and restart options.

Q15: Is there a way to prioritize selected integration scenarios in Cloud Integration?

A: Prioritization can be managed by configuring separate JMS queues. This ensures that high-priority scenarios receive processing preference and are not delayed by bulk traffic. You can also apply pipeline designs that route high-priority messages to specific queues. When using the Pipeline for Cloud Integration, you can setup multiple pipelines and configure the JMS sender adapters of each pipeline accordingly to assign more tenant resources for high priority scenarios.

Q16: How can I check which standard content is available in SAP Integration Suite to replace my standard XI content?

A: You can explore the SAP Business Accelerator Hub, which contains over 10,000 prepackaged integrations, APIs, events, etc. Use it to identify equivalent or improved content that can replace standard XI Content from SAP Process Orchestration.

Q17: Can I test my mappings and messages directly in Cloud Integration like in SAP Process Orchestration?

A: Yes. There are two possibilities to test mappings and messages in Cloud Integration. You can either test only your message mapping in the editor page, or you can run your Integration Flow in a simulation where you can validate one or more flow steps, including your message mappings. You can monitor payloads and headers for validation before deployment. See more in Test Message Mapping and Simulation of an Integration Flow.

Q18: Will User-Defined Functions (UDFs) be converted to Groovy scripts after migration using the Migration Tool?

A: No. The Migration Tool does not automatically convert UDFs into Groovy scripts. UDFs can be imported and may continue to work as-is if they do not depend on PI/PO-specific libraries; if they do, you must refactor them manually (convert to Groovy or adapt Java code). Track UDFs during assessment and plan manual conversion as needed.

Q19: Can I migrate interfaces with adapters that are not available in Cloud Integration?

A: The Migration Tool does not automatically migrate such adapters, although you may migrate parts of the interface and apply the necessary adaptations after the migration. These adaptations might include:

Replace the adapters to more generic protocols (e.g., HTTPS) and implement specific requirements using flow steps.
If it’s a partner adapter, check with the same provider if they have a replacement for Cloud Integration.
As a last resource, you can create your custom adapter using ADK. See more information in Developing Custom Adapters.

Q20: Which Java version can I use for dependencies in Groovy Script?

A: Make sure to follow the code guidelines for Java 17. See more information in the SAP Note 3498280 - Script incompatibilities with upcoming software upgrade.

Q21: Can I use my own CI/CD pipeline to manage my Cloud Integration artifacts?

A: Yes. Cloud Integration exposes APIs (Cloud Integration OData/REST) that allow export/import and automation of artifacts; you can integrate these into your CI/CD pipelines (Git + build pipelines + deploy scripts). For more information about the Cloud Integration APIs, access Business Accelerator Hub.

Please find below few additional community and partners references to create or use CI/CD pipelines on Cloud Integration:

Q22. How do I migrate interfaces with “Adapter-Specific Message Attributes” (Dynamic Configuration)?
A: Adapter-specific attributes (dynamic configuration) become message headers or properties in Cloud Integration. Map adapter attributes to message headers/parameters to preserve behavior. Review and test each adapter configuration since attribute names and behaviors may differ between SAP Process Orchestration and Cloud Integration. See more information in Headers and Exchange Properties Provided by the Integration Framework.
If you are using Dynamic configurations in your Mappings you need to adjust them accordingly by also accessing these headers within your Mapping. If you are reading such headers and properties, you can use the in-built node functions, if you need to change such values, please proceed with Groovy script as explained in Access Headers and Properties in Scripts.

Q23. Can I reuse my configuration from Integration Directory (e.g., Receiver Determination, Interface Determination)?

A: Yes, you can reuse the logical design by migrating your configuration to Cloud Integration using the Pipeline for Cloud Integration that emulates Receiver/Interface Determination. The Migration Tool supports the Pipeline Approach which assists you in creating integration artifacts such as integration flows, mappings and Partner Directory entries to run your scenarios in the Pipeline for Cloud Integration. See more information in Pipeline Approach. Optionally, you can manually create the artifacts. In this case, use the so-called Partner Directory Accelerator Tool provided by the community.

Q24. Are synchronous/asynchronous bridges supported (sync-async or async-sync patterns)?
A: Async-sync pattern is supported in a manual migration and using Migration Tool.

The opposite sync-async pattern, where a synchronous request is converted into an asynchronous message and the Integration Flow waits for the asynchronous response from the target API within a single integration flow is not supported as of today.

Q25. How can I migrate Alerts Rules or notification integration scenarios?
A: You cannot migrate Alert Rules from SAP Process Orchestration as-is. However, SAP recommends reconfiguring such alerts using SAP Cloud ALM. See more information in Alerting. Alternatively, you can also use the SAP Alert Notification Service for SAP BTP.

Q26. How can I migrate Message Mapping with Value Mapping-lookups?

A: Value Mappings are supported and can be migrated as Value Mapping objects into Cloud Integration. The Migration Tool imports value mappings references in the message mapping, but it does not migrate the Value Mapping object itself. After migrating the interface, you can import the Value Mapping directly into the package and validate whether the values are correct.

Q27. How can I migrate my ValueMappingReplication and ValueMappingReplicationSynchronous scenarios?

A: These scenarios can’t be directly migrated to Cloud Integration. Value Mappings are separate artifacts in Cloud Integration and they can updated via OData API calls and not via a standard interface. Note that updates via API are only for the design time versions of the Value Mappings, they still need to be deployed to the runtime to reflect the changes. Refer to blog Migrating ValueMappingReplication from SAP PI/PO to CPI on step-by-step instructions.

Q28: Is it possible to use dynamic EOIO queues in Cloud Integration?

A: In dynamic EOIO queues, the queue name is set based on payload information or using custom adapter modules. As of today, dynamic queues are not supported directly on Cloud Integration as the name of a JMS queues must be fixed. A possible option is to use a shared queue but in case of errors messages could block each other. If you require same setup as of today, please look at following roadmap item in the SAP Integration Suite Roadmap.

Q29: Is it possible to archive messages in Cloud Integration

A: If you require message archiving in Cloud Integration, this is possible using an external Content Management System (CMS). For more information check the online help and have a look at SAP Note 3449326

Q30: Is Time Availability Planning supported in Cloud Integration:

A: In SAP Process Orchestration you could use time availability planning to stop a Communication Channel at a specific time. In SAP Cloud Integration you might use a timer event for adapters that support request/reply pattern to achieve similar functionality. Alternatively, you can implement your own mechanism to temporarily stop receiving messages for a defined period, as demonstrated in the blog Add SAP PI/PO Communication Channel Start/Stop Functionality to Your iFlows.

Please note that using a timer event with request/reply pattern might have an impact on the message consumption, considering that each message execution will count as at least one transaction. For more information about the message metric definition, see on SAP Note 2942344.

Security and Connectivity

This section is focused on questions related to security use cases and connectivity differences between SAP Process Orchestration and SAP Integration Suite.

Q1. How is authentication and authorization handled in SAP Integration Suite?
A: SAP Integration Suite uses the identity and access management (IAM) features of SAP BTP / SAP Cloud Identity Services to handle authentication and authorization. Key points:

Identity Authentication (IAS): Users (both developers and business users) are authenticated via SAP Identity Authentication Service or a trusted external identity provider. See more information in Security Administration: Managing Authentication and Authorization.

SAP has its own SAP Cloud Identity Services tenant, SAP ID service. SAP ID service is the default identity provider of SAP BTP and where you register to get initial access to SAP BTP. Trust to SAP ID service is preconfigured by default.

Roles & Role Collections: Authorization is managed through role collections in BTP. Administrators assign predefined role collections (e.g., for Cloud Integration personas) to users or groups to control what they can do. See more information in Personas for Cloud Integration.
Service Authentication (OAuth / Service Keys): For system-to-system communication, Integration Suite supports OAuth 2.0 client credentials flows. You can create a service instance with a service key to obtain OAuth credentials (client ID / secret) for integration scenarios. See more information in Creating Service Instance and Service Key for Inbound Authentication.
Certificate-based Authentication: If you configure client certificate authentication, the load balancer (or relevant component) validates the certificate and maps it to a service key for Integration Suite. See more information in Client Certificate Authentication (Inbound).

This layered IAM model ensures both human user access and secure service-to-service authentication, using OAuth, certificates, and strong role-based control.

Q2. How do I handle certificates and keystores after migration?
A: Certificates, private keys, and keystores from SAP Process Orchestration are not migrated automatically and must be uploaded manually into the Cloud Integration Keystore. During migration, you should export certificates from SAP Process Orchestration, import them into the tenant, and reassign them to the respective adapters or endpoints. Renewal must also be managed manually using the tenant’s keystore tools. See more information in Managing Security Material in Cloud Integration and Managing Keystore Entries.

Q3. Can SAP Integration Suite connect to on-premise systems without VPN?
A: Yes. Integration Suite can connect to on-premise systems without requiring a VPN by using the SAP Cloud Connector, which establishes a secure reverse-proxy tunnel from on-premise to BTP. This avoids opening inbound firewall ports. See more information in Connecting to On-Premise Systems Using Cloud Connector.

Alternatively, SAP Private Link Service can also be used to establish private, non-internet network connectivity between BTP and hyperscaler VPC/VNet environments. However, as of today you cannot connect SAP Integration Suite to the SAP Private Link Service. You would rather need an app router deployed also in BTP to intermediate the message exchanges. Please make sure to check if the required service for your scenario is supported while using SAP Private Link Service and also any potential limitation that might exist. SAP also recommends running a Proof of Concept first while using this approach. See more information in What Is SAP Private Link Service? And SAP Private Link Service Use Cases for SAP Cloud Integration.

Monitoring and Operations

This section is focused on questions related to monitoring, logging, archiving and operation related differences between SAP Process Orchestration and SAP Integration Suite.

Q1: How should error handling and logging be adapted in SAP Integration Suite?

A: SAP Integration Suite provides modern, cloud-based error handling and logging capabilities. Use exception subprocesses, audit logs, and message tracing to design resilient error management. See more information in Guidelines and Best Practices for Message Monitoring.

Q2: Can I reprocess failed messages in SAP Integration Suite like in SAP Process Orchestration?

A: Unlike SAP Process Orchestration, SAP Integration Suite does not have a “restart message” feature built in. However, you can implement the retry mechanism using JMS queues. See more information in Apply the Retry Pattern.
The Pipeline for Cloud Integration supports built-in error handling and restart capabilities, i.e., automatic retries as well as manual retry options including a so-called dead letter queue where messages are stored which have exceeded the maximum number of retries. Furthermore, you have the option to use an extension package which supports sophisticated restart capabilities using data store instead of the standard error handling provided by the pipeline. See Process Integration Pipeline Extension - Restart via Data Store.

Q3: How can we get alerts for failed integrations in SAP Integration Suite?

A: You can configure SAP Cloud ALM to receive alerts based on message status. Cloud ALM provides dashboards, notification rules, and APIs for monitoring Integration Suite message health and exceptions. See more information in SAP Integration Suite (Cloud Integration) and Alerting.

Alternatively, you can also use the SAP Alert Notification Service for SAP BTP.

Q4: How to migrate User-Defined Message Search when moving from SAP Process Orchestration to Cloud Integration?

A: A User-Defined Message Search configuration cannot be directly migrated. However, you can replicate similar functionality by defining custom message attributes in Cloud Integration, which can be used for filtering and searching in Message Monitoring. See: Custom Header Properties to Search for Message Processing Logs.

Q5: Is it possible to monitor channels migrated to Cloud Integration?

A: Cloud Integration does not use “communication channels” as in SAP Process Orchestration. Instead, message flows are monitored via the Message Monitoring view, which provides detailed visibility of message status, runtime logs, and performance. See more information in Monitor Message Processing.

Q6: Can I reuse my SLD settings (business systems, technical systems, SWCV, etc.) in Cloud Integration?

A: No. The concept of System Landscape Directory (SLD) does not exist in SAP Integration Suite. Only sender (SAP_Sender) and receiver (SAP_Receiver) identifiers can be reused, typically through Apache Camel headers directly defined in the Integration Flows. See more information in Headers and Exchange Properties Provided by the Integration Framework. When setting up XI proxy scenarios, your business system needs to be maintained in a table. See Setting Up XI Proxy Runtime.

Q7. How can I set up centralized monitoring across multiple SAP Integration Suite tenants (e.g., landscape with multiple regions)?
A: You can achieve centralized monitoring of multiple SAP Integration Suite tenants using SAP Cloud ALM (CALM) with its Integration & Exception Monitoring and Health Monitoring capabilities. Here’s how it works:

Integration & Exception Monitoring: CALM lets you correlate individual messages across different tenants and systems into end-to-end business scenarios. You can define "integration scenarios" that span several Integration Suite tenants. Alerts trigger on failed messages, grouped failures, or deployment exceptions, and you can filter by iFlow, sender/receiver, package, etc.
Health Monitoring: Collects and displays technical health metrics (e.g., JMS resource usage, certificate validity) across all your Integration Suite tenants in a single pane. https://support.sap.com/en/alm/sap-cloud-alm/operations/expert-portal/health-monitoring/health-monitoring-setup-configuration/health-mon-for-integrationsuite-cloud-intergration.html
Alerts & Automation: You can configure alert rules in CALM (for example, for error messages) and trigger operation flows to remediate or notify responsible teams.
Role-Based Access: Permissions in CALM let you control who sees what (which tenants, which scenarios) by selecting the right scope in the “Select Scope” mode.

This architecture enables a single point of operational visibility across a global, multi-tenant Integration Suite landscape — helping operations teams to monitor, alert, and drill down into issues from one central tool. See more information in SAP Integration Suite (Cloud Integration) and Integration & Exception Monitoring.

As an alternative, you can also connect SAP Integration Suite with SAP Focused Run for such centralized monitoring. See more information in SAP Integration Suite (Cloud Integration) and Health Monitoring for SAP Integration Suite (Edge Integration Cell).

Q8. Can I integrate SAP Integration Suite logs with external monitoring tools (Splunk, Dynatrace, Azure Monitor, etc.)?
A: Yes. Cloud Integration supports external logging, allowing you to forward message processing logs to third-party tools. You can activate external logging in the Cloud Foundry environment and configure an HTTP endpoint (for example, a Splunk HEC) as the target. After creating the destination and service key, external logging is enabled through the Cloud Integration API, and log levels can be controlled globally or per Integration Flow. For long-term retention, message logs can also be archived to an external CMIS repository. While Splunk is the primary documented example, similar setups can be used for other monitoring platforms that accept HTTP-based log ingestion. See more information in External Logging Cloud Foundry Environment and Archiving Data, Cloud Foundry Environment.

Please note that SAP strongly discourages from using Message Processing Log Attachments for general message persistence as well when transitioning from the ArchiverModuleBean adapter module in SAP Process Orchestration to Cloud Integration. Log attachments don’t qualify as a comprehensive archiving solution as the data is only stored in Cloud Integration's internal database for 30 days, after which it's deleted permanently. Incorporating log attachments in this context can also cause a performance issue by burdening the allocated database storage within your Cloud Integration tenant with an excessive influx of MPL entries.

Project Enablement and Support

This section is focused on questions related to customer references, enablement and support.

Q1: I’d like to move to SAP Integration Suite, but I’m new to the solution. Where can I find information to get started?

A: SAP recommends starting with the following references:

Q2. Is there a template project plan or checklist available?
A: Please refer to the discovery center mission Get Started with Migration to SAP Integration Suite to get insights on how to start your transformation journey.

Q3. Where can I find more success stories of customers that concluded a migration project?
A: Customers can find more success stories in Accelerate your move from SAP Process Orchestration to the cloud.

Q4. Who can support me during migration (SAP Services, Partners, Move Experts)?
A: SAP provides dedicated experts to assist customers migrating from SAP Process Orchestration. You can reach out to the SAP Integration Suite Move Experts at: SAPIntegrationSuiteMoveExperts@sap.com

SAP also provides dedicated experts to assist customers on migrating B2B scenarios from SAP Process Orchestration to SAP Integration Suite. You can reach out to the SAP B2B Integration Factory experts at: b2bintegrationfactory@sap.com.

Additional References

Everything you need to move to SAP Integration Suite

Fast-Track Your Integrations To The Cloud Through Our New Expert-Guided Implementation Service

2025-12-17T15:16:01.710000+01:00

Fast-Track Your Integration Transformation To The Cloud Through Our New Expert-Guided Implementation service

Are you ready to migrate your critical integration scenarios to the cloud - in a secure and scalable way?

SAP Enterprise Support Advisory Council is piloting a new expert guided implementation service (EGI) focused on helping customers starting to migrate their interfaces from SAP Process Integration / Process Orchestration to SAP Integration Suite. As a participant, you’ll gain exclusive early access to content, influence the final offering with your feedback, and build hands-on experience before general availability. This isn’t just another webinar - it’s a practical, step-by-step experience where you’ll migrate interfaces in your own environment, with guidance from an expert throughout.

This structured approach ensures you gain both theoretical knowledge and practical experience, helping you build confidence in using SAP solutions effectively. Since SAP Enterprise Support is included with every SAP cloud subscription, you can access this offering at no additional cost.

After the completion of the 3-day remote workshop, you will have the knowledge of how to proceed to migrate their interfaces from SAP Process Integration / Process Orchestration to SAP Integration Suite.

The purpose of this EGI service is to support customers to begin their migration from SAP Process Integration (PI) / Process Orchestration (PO) to SAP Integration Suite.

Firstly, we discuss the value proposition of migrating to SAP Integration Suite, how to estimate the efforts involved in migrating using the Migration Assessment tool before migrating a simple interface to the SAP Integration Suite using the Migration Tool.

Finally, we prepare customers for developing integration scenarios using SAP Integration Suite in line with best practices using SAP Cloud Connector and the SAP Business Accelerator Hub.

Please see this teaser video for further information.

What You’ll Gain
This service will equip you with the skills to leverage:

Migration Assessment tool to estimate the efforts involved in migrating interfaces to the cloud
Migration Tool to migrate a simple interface to the SAP Integration Suite
SAP Business Accelerator Hub to import and use standard integration scenarios

Why It Matters?
Customers should begin their migration from SAP Process Integration (PI) / Process Orchestration (PO) to SAP Integration Suite in advance of end-of-maintenance in 2027.

What You’ll Do?

Perform Migration Assessment to understand the effort involved in migrating to SAP Integration Suite.
Migrate a standard SAP PO Integrated Configuration Object (ICO) to an Integration Flow (Ready to Migrate).
Browse, select, and importing a standard integration package (e.g., Government interaction or Bank integration).
Gain practical experience with SAP expert support

Who Should Join?
The service is tailor-made for:

Integration consultants
Developers

Join the EGI service and gain first-hand experience with SAP’s latest innovation in multi-model programming. Learn more and register for the service by contacting SAP Enterprise Support Advisory Council through esac@sap.com.

---------------------------------------------------------------------------------------------------------------------

About the authors:

Robert Kelly is Architect Lead for BTP for SAP Enterprise Support. Based in Dublin, Ireland, Robert has been with SAP since 2005, holding various roles across the organization. Today, he focuses on helping businesses implement their digital transformation through SAP Enterprise Support offerings.
Antonio Sánchez is the Integration Lead for LAC region at SAP. Based in Mexico City, Mexico, Antonio has over 8 years of experience driving complex integration landscapes (on premise and hybrid). Today, he focuses on helping businesses modernize their landscapes through SAP Integration Suite and Clean Core strategies.

A context change is NOT always caused by addContextChange() alone.

2025-12-29T08:33:34.395000+01:00

A context change is NOT always caused by addContextChange() alone.
CPI also creates context changes automatically when parallel queues advance differently.

What is really happening in your case

You have THREE relevant queues aligned in mapping:

productTaxItem
some other node (likely RECORDTYPE / TaxCode / something parallel)
companyCodeOut (your UDF output)

Your UDF only controls companyCodeOut,
but CPI aligns all queues together.

Notice:

companyCodeOut value is SAME (BB01)
But another queue changes context (B2 → 22)

CPI inserts an implicit context change to stay aligned with the other node.

So:

Context 2 → created by your UDF
Context 3 → created automatically by CPI due to parallel node context shift

That’s why they appear together.

Exploring End-to-End Business Processes in SAP Business Suite

2026-01-05T10:50:19.179000+01:00

Modern business processes such as procurement, production, sales, service, finance, controlling, and human resources are highly interconnected and characterized by numerous interfaces, dependencies, and dynamic integration points. Consistent master data usage and close cross-functional collaboration are essential to meet time, cost, and quality objectives.

SAP provides an integrated solution portfolio that supports these end-to-end business processes based on modern technologies and evolving business requirements. Due to the breadth and continuous evolution of the SAP portfolio, gaining an initial overview can be challenging. The objective is therefore to offer a structured understanding of SAP process terminology, integration concepts, and corresponding solutions.

Mapping SAP Solutions

Finance as a core function of end-to-end business processes

Finance ensures the proper recording, processing and evaluation of all financial transactions of a company. It reflects the financial reality of operations and ensures compliance with legal, regulatory and country-specific accounting standards.

Duties and responsibilities

Its core tasks include the continuous posting of business transactions, the analysis of financial data and its structured reporting. Finance thus provides the basis for transparency, control and external reporting.

Central interfaces

Finance is closely interlinked with other areas of the company:

Customers / Debtors: Receivables management and complaint support
Sales: Early detection of credit risks and clarification of payment or delivery problems
Procurement: Review of incoming invoices and management of accounts payable

These interfaces make finance an integrative cross-sectional function.

Typical results

Periodic financial statements (balance sheet, profit and loss account, cash flow statement)
Maintain and manage accounts receivable, vendor, and asset data
Financial and liquidity reporting for management and controlling

Critical success factors

High data quality and timely availability of financial information
Transparent assessment of creditworthiness and payment behavior
Compliance with compliance and risk management requirements
Consistent master data and end-to-end system integration

Conclusion

Finance is a central integration point of end-to-end business processes. Incorrect or delayed data transfers have a direct impact on transparency, controllability and compliance.

Controlling as a management function of the company

Controlling supports management by planning, calculating, analysing and communicating financial information. It creates transparency about the economic situation of the company and serves as internal control, control and decision-making support.

Duties and responsibilities

The core tasks of controlling include internal planning, budgeting, control and reporting on the financial health of the company. The focus is on the analysis of costs, revenues and profitability as well as on the derivation of key performance indicators relevant to management.

Central interfaces

Controlling works closely with operational and market-related departments:

Production: Cost and revenue control via cost accounting, budgeting of organizational expenses, and planning and estimating production costs
Marketing and Sales: Providing information on sales variances to adjust sales campaigns or correct price ranges

Typical results

Analysis results and management reports to assess financial soundness
Cost, result and variance analyses
Decision-making bases for improving cost accounting and financial planning

Critical success factors

Effective, realistic planning and budgeting
Accurate, consistent, and timely data
Appropriate control and key performance indicator systems

Conclusion

Controlling is the central control body between operational business and management. The quality and timeliness of data as well as clearly defined control systems are crucial for effective corporate management and well-founded decisions.

Human Resources as a Structuring Business Process (R2R-Recruit To Retire)

Human Resources ensures that the company has qualified, efficient and motivated employees. It is responsible for all HR-related business processes along the entire employee lifecycle and thus makes a significant contribution to operational stability and strategic development.

Duties and responsibilities

Core responsibilities include recruiting employees with the right qualifications, onboarding new employees in a structured manner, and managing performance, training, and development opportunities. In addition, HR is responsible for payroll, pension and additional benefits as well as all other cost-relevant personnel topics. Another focus is on improving employee and professional experience.

Central interfaces

Human Resources is a cross-departmental cross-sectional function:

All departments: Implement performance management systems, employee and benefits programs, and secure budgets for personnel and compensation changes
Internal and external accounting: reconciliation of payroll, HR-related costs, accruals and budget planning

Typical results

Employee surveys and evaluations
Leadership, training, and development programs
Proper payroll
Culture, Health, and Employee Retention Programs

Critical success factors

Clear strategic alignment of workforce and capacity planning
Successfully attracting and retaining talent
Effective, transparent performance management
Reliable, integrated workforce data and processes

Conclusion in the context of business process analysis

Human resources is a central end-to-end business process . Media disruptions, a lack of integration with finance or unclear responsibilities have a direct impact on costs, employee satisfaction and performance. An end-to-end HR process is therefore an essential prerequisite for stable and scalable business processes.

See the deep dive for more Informations:

Recruit to Retire – E2E Process Deep Dive

Procurement as an operational and strategic business process (S2P source-to-pay)

Procurement ensures that the company is supplied with goods and services in a timely manner, cost-efficiently and in suitable quality. It supports both operational operations and strategic value creation.

Duties and responsibilities

The core tasks of procurement include overseeing all goods and service requirements, selecting reliable suppliers, and concluding and managing supplier contracts. In addition, procurement procures items to support internal business operations and takes purchasing positions to manufacture products.

Central interfaces

Procurement is closely interlinked with commercial and operational areas:

Controlling: Coordination for the planning and budgeting of order items
Financial accounting: Close collaboration, as accounts payable is part of financial accounting
Departments: Notification of requirements and use of purchasing catalogs

Typical results

Available materials in stock
Valid supplier contracts
Standardized purchasing catalogs for employees

Critical success factors

Strategic Sourcing and Effective Stakeholder Management
Reliable, efficient and sustainable suppliers
Efficient, transparent purchasing processes

Conclusion

Procurement is a central end-to-end business process that directly influences costs, delivery capability and productivity. Close integration with controlling and financial accounting as well as efficient, digitally supported processes are crucial for a stable supply and sustainable value creation.

See the deep dive for more Informations:

DiveSource to Pay E2E Process Deep Dive

Sales as a revenue-driving end-to-end business process (L2C - Lead to Cash)

Sales is responsible for the sale of goods and services and is largely responsible for revenue generation and profitability. It covers the entire process from new customer acquisition to quotation preparation and order fulfillment.

Duties and responsibilities

The core tasks of sales include the acquisition of new customers, the maintenance of existing customer relationships and the implementation of presales activities. Sales creates quotes, takes customer orders, fulfills them in collaboration with the supply chain, and plans future sales.

Central interfaces

Sales is closely involved in cross-departmental processes:

Marketing: Using marketing leads to create targeted offers and contracts
Internal and external accounting: Reporting and reconciliation of revenues from customer orders
Service: Support of service sales, e.g. through consulting or support services

Typical results

Quotes and confirmed customer orders
Long-term and sustainable customer relationships
Revenue and sales plans

Critical success factors

Effective sales estimates and realistic sales planning
Seamless integration into the supply chain
High customer satisfaction
Sustainable revenue generation and increased profitability

Conclusion

Sales is a central end-to-end business process whose performance depends directly on integration with marketing, service, logistics and finance. Media disruptions or a lack of coordination have a direct impact on customer satisfaction, sales and margins.

See the deep dive for more Informations:

Lead to Cash – E2E Process Deep Dive

Production as a value-adding core process (D2O Design To Operate)

Production is responsible for the production of finished products using materials, machines and labour. The aim is on-time and high-quality production at the lowest possible cost – in the example of the Bike Company, the production of bicycles.

Duties and responsibilities

The core tasks of production include the conversion of materials into finished products and compliance with defined manufacturing processes. Standardised processes reduce production costs, ensure quality and meet delivery deadlines.

Central interfaces

Production is closely linked to commercial and upstream functions:

Controlling / internal accounting: Estimation, planning and analysis of production costs
Financial accounting: Reporting of production and cost data as well as optimization of product costs
Procurement: Ensuring material availability through timely purchase of the required components

Typical results

Finished bikes that meet quality standards
Timely delivery of products
Production and cost data for other divisions

Critical success factors

Availability of materials, machines and personnel
Efficient, stable production processes
Minor variances between actual and planned costs

Conclusion

Production is the company's central value-added process. Close integration with procurement, finance and controlling is crucial to controlling costs, ensuring quality and reliably guaranteeing delivery capability.

See the deep dive for more Informations:

Design to Operate E2E Process Deep Dive

Service as a customer-loyal end-to-end business process

The service ensures the maintenance, support and servicing of sold products . It makes a significant contribution to customer satisfaction, customer loyalty and long-term value creation.

Duties and responsibilities

The core tasks of the service include the execution of maintenance and services, the provision of round-the-clock support and the planning and handling of service visits. A central component is ensuring the availability of spare parts and qualified service staff.

Central interfaces

The service is closely interlinked with other company divisions:

Sales: Sharing service histories, handling customer and support requests, and supporting service sales
Procurement: Coordination to ensure that required spare parts are available and delivered within 24 hours

Typical results

Round-the-clock support and service delivery
Service visits carried out with spare parts and qualified service employees
Fully documented service histories

Critical success factors

Short response times and spare parts availability within 24 hours
Effective planning of service costs and deadlines
Use of digital technologies, e.g. Internet of Things (IoT) for premium bicycles

Conclusion

Service is a crucial end-to-end post-sale business process . Close integration with sales and procurement as well as data-based, digitally supported service processes are central to high customer satisfaction and sustainable customer relationships.

Process Integration

The following graphic illustrates process steps within the end-to-end processes Lead to Cash, Source to Pay, Design to Operate, Recruit to Retire and their main integration points.

Process Integration

End-to-End Business Processes and Integration Challenges

SAP end-to-end (E2E) business processes cover the entire flow of a business function across departments, eliminating fragmentation. Sales, supply chain, procurement, finance, and HR are integrated into a single, intelligent workflow.

Key Benefits of SAP

Integration: Unified platform connecting all core business functions
Efficiency: Automation reduces manual effort and errors
Data Consistency: Centralized data as a single source of truth
Compliance: Built-in support for regulatory requirements
Scalability: Flexible solutions that grow with the business
Real-Time Insights: Up-to-date analytics for better decisions
Customer Satisfaction: Faster, more reliable processes improve service quality

SAP BTP - Integration Suite: Clean Architecture vs The Frankenstein Landscape

2026-01-05T16:28:27.950000+01:00

Spoiler

Let me make an honest sentence: I'm not a master in the whole SAP BTP world, however my knowledge is mainly focused on the integration suite.

The goal is simple: to get you thinking about your integration fabric.

Disclaimer: Here, we present architectural lessons learned in the trenches. I am not promoting vendors, but the necessity for architectural practices to follow framework norms, governance and sustainable end-to-end practices is what I have in mind.Let me make an honest sentence: I'm not a master in the whole SAP BTP world, however my knowledge is mainly focused on the integration suite.The goal is simple: to get you thinking about your integration fabric.

Introduction

In this blog, I will dive deeper into the integration layer within the SAP Business Technology Platform (BTP). We are going to focus on service scenarios in BTP Integraton Suite that also reach out to external carbon-based solutions, for example MuleSoft, Bomi, SnapLogic and Solace but also SAP BTP API Management, Advanced Event Mesh and SAP Integration Advisor

This is a sort of "is what I have leaned over the years" type of discussion, as opposed to having been produced just for the purposes of microscope slide making (or framework development).

In this blog series, I want to make some experiences available as developer since SAP XI/PI/PO/CPI longterm. Here are three I need to play with that should do the trick for the community devs to get their heads around:

Also, as an SAP BTP Integration Suite Consultant, I encourage you to dream big and express what you think. Once you have this deep understanding of what is possible with the SAP BTP Integration Suite, not only SAP CPI, you’ll be able to stand as equal with architects in a conversation and shape what that effective environment should look like.

Let have this thrilling journey together.

How I saw some Frankenstein architectures being born: three real cases

In my long career, I have seen plenty of tools that offered to alleviate such complexity only to introduce complexity where none was warranted. One thing to keep in mind is that every tool or company, such as SAP, but also any other vendor has their pros and cons. But the benefits of normalizing these architectures are hard to ignore: less customization, better support, and more cohesive teams.

Case 1: Wasted Potential

When I started performing in this one “As sort of a fresh consultant with SAP BTP Integration Suite” working essentially as SAP PI/PO/CPI Consultant and my role was to glue the pieces i.e. boxes and mappings back again. I did not have the experience or courage to communicate my views back then, I believe that also led to suboptimal results. However, this was also a learning experience for the future.

The project was well-structured with explicit rules, standards, APIs and development models. Yet the external architects at the beginning of a migration to S/4HANA hadn’t considered implementations that already existed. … Even if SAP BTP (SAP Integration Suite – APIM and CPI) was there, they threw away this investment and capability on leveraging more strategic decisions and using the minimum as possible.

Consequently, no usage of the APIM was allowed at all and SAP CPI could only be classified as vanilla-prepackaged with as few adjustements. A second vendor took over the entire APIM infrastructure and bespoke integrations. The result was the undercutting of what had been a winning game plan.

Case 2: Application of External Architecture Patterns

In that case I was similarly unable to remember granular details about APIM and Events Management. The Iflow were my concern and here I spotted a considerable design issue, lets call it flaw: that the payload being kept in datastore is nothing more than an output of a mapping logic making it futile.

This was a “three layer design – Intelligence Layer, Processing/Routing Layer and the Delivery Layer” that was enforced on top of SAP CPI, which came from an entirely different area all together. To preserve this false structure, the solution became rather complex chain of hundreds JMS queues.

Case 3: Scattered teams and technologies

I am not going to discuss in depth about APIM and Events with other vendors. One organization did adopt BTP in piecemeal via Events/API but SAP CPI were the only service that came together and was used appropriately. Duties were separated into teams that didn't talk to each other. In the end, this lack of coordination resulted in higher costs and complexity – which is breaking the very synergy SAP BTP Integration Suite was designed for: SAP Integration Suite.

The Emergence Of “Frankenstein” Architectures And Why Decoupled Integration Does Not Succeed

Organizations have the tendency to spend millions in SAP BTP without fully leveraging its strategic capabilities. But what we end up with is "Frankenstein Architectures" – a collection of parts cut and sewn into a jumble of ill-formed systems. The linked parts may be powerful, but the ecosystem is inherently weak.

These are hardly ever genuine technical constraints. Rather, they emerge from:

Architectural Bigotry: Choices created by management who don’t really understanding the SAP integration terrain.
Lack of Trend Following: Excessive focus on the latest buzzwords, without considering the merits of having a complete ecosystem.
Siloed communication: A gap between high-level architects and the developers working with SAP Integration Suite.

With SAP at the core of your backend, be it ECC or S/4HANA then BTP is something else altogether on a different level, and I mean because that’s where its roots are from. Despite the necessity of third-party integrations, there comes a point when the trade-off between “market-trending” external tools and native connectors actually incurs a technical debt that negates the end customer’s requirement for stability. Different systems can live together side by side, but nothing comes close to the level of integration offered in SAP world with SAP Integration Suite.

Figure 1: Frankenstein Architecture

The Trap of the “Legacy Mindset”: The Real Barrier to True Innovation

Although we can critique tools, vendors and platforms till the cows come home, on some level our constraints are not technological at all. The greatest hindrance to a successful innovation experience is habit, accumulated over years of dependence on legacy systems. Such statements as “we won’t touch it, it’s working,” “the developer already is not with a project” and “there are no any docs” belong to the type that depends on stable but inflexible architecture. This leads to known experiences that do not evolve, led by a strong fear of the new.

There are many that still operate under the paradigm of on-premise integration landscapes from a decade ago. This oldskool attitude results in a frustration tainted with fear of the new, or unfamiliar paradigms and perhaps more often than not, a mis-appreciation of what today's platforms are capable of.

A real innovation requires to think differently. The question should not be “How do I generate this map?” a closer look: “Is this a map? Should it be an event? An API? Or whether it should exist at all in its current version?”

Without such a crucial change, old habits can die hard for companies looking more innocently to roll the past forward without realizing it is in danger of imposing historical limitations on new opportunities and tools. Thus, the result is not genuine modernization.

The Voice of the SAP Integration Suite Consultant: You’re the Strategic Bridge

A highly experience Integration Consultant—either in a senior role or that of an expert one—needs to have full knowledge of the SAP Business Technology Platform (BTP) integration suite Event Mesh (EM), Enterprise Assessment Management (EAM), API Management (APIM), Integration Assessment (IA) and Cloud Integration (CPI). But such technical proficiency is only the beginning. If you want to add value, then we need to do more than just drive “tickets” or be used as a “delivery“ service, not only SAP CPI developer.

What you think about SAP BTP Integration Suite Consultant ?

Apart from SAP PO: Migration to SAP CPI or Migrating the Legacy (Snap Logic, Boomi, MuleSoft, Informatica, Microsoft etc.)

With middleware, many companies find themselves managing a hodgepodge of technologies. The 1,000 interfaces that need to be migrated from the likes of Snap Logic, MuleSoft, Informatica, Dell Boomi or webMethods to SAP BTP – SAP Integration Suite is not simply a question of technical mapping; it’s actually a functional exercise.

Think of migration from SAP PI/PO to CPI. How many of you've seen flows with mapping layers having tons of UDF's, field-field mappings assigning to lots of standard functions (remove context, collapse context & rely on it), Conditional operators and Java mapping (as well) or Adapter module performing entirely different job.

When dealing with such intricate mappings and modules, typically when you run the SAP Migration Assessment your migration status may be "non-migratable." Another point of consideration is that even if a integration consultant has the skills to migrate these interfaces, do you really want them reverse engineering extracting prodcution payloads and manually testing for so long just to validate the results?

Furthermore, where is the documentation? Is the developer of this interface already gone?

Instead of looking at migration exclusively, it perhaps makes more sense to look rebuilding and examining the interfaces using native capabilities within SAP Integration Suite. Some of them could be transformed to events, others may become simple APIs.

If the move from SAP PI/PO to SAP CPI is daunting, it’s even trickier when you have third-party interfaces in the mix. The details of such migrations can certainly complicate matters.

Figure 2: SAP Integration Consultants

Dismantling the Frankenstein Architecture in case of Multiples Platforms

The Int4 Suite (previously known as Int4 IFTT/Shield) is a test automation and service virtualization tool designed specifically for SAP ecosystems. It acts as an “accelerator” to dismantle the Frankenstein architecture and simplify complex migrations.

Image 3 – Dismantling the Frankenstein Architecture

Functional regression is the biggest challenge when changing from SAP PI/PO to BTP. Testing convoluted, undocumented legacy mappings may appear to be testing hell—but it need not be.

Virtualization: Test Without Limits
- Int4 Shield "feels" the behaviour of external systems from within APIM itself. And since this is possible, you guessed it also can we make against SAP BTP E2E full flows, even if the backend does not yet exist.
No More Reverse Engineering
- Quit spending weekends trying to decode obsolescent Java mappings, User Defined Functions (UDFs) with no documentation. Instead of building these factors by hand, Int4 Shield uses the Comparison Approach:
Automated Extraction : Securely captures real production messages to make a "test case repository."
Parallel Execution: The old PI/PO mapping and the new BTP mapping are executed in parallel by this tool.
Automatic comparison: for a penny or to the last character – Int4 shield checks each single difference and shows where logic diverges.
Massive Resource Savings
- The demand of manual testing is also greatly decreased by comparing with the real-world data as ground truth.
- Reduce manual testing efforts up to 80%.
- Test hundreds of scenarios in minutes, not weeks.
- Remove paperwork barriers: If the output matches, the logic works.

Take apart the Frankenstein SAP PI/PO mappings and others

The tool Figaf has these integration challenges in mind. The Figaf DevOps Suite, especially the Migration Edition, is built for the integration layer and has become the favored option when it comes to moving off SAP PI/PO and into the SAP Integration Suite (BTP).

It is not a "generic" migration tool for all non-SAP external systems, like legacy databases and non-SAP ERP systems), but it supp (where integration flows connect those external systems with the SAP world).

Image 4 - Figaf migration SAP PI/PO

Figaf: Focus and Capabilities

Figaf is a key component to DevOps and migration projects beyond the simple movement of code, as legacy logic is transformed into the modern Business Technology Platform (BTP) environment.

Automatic Migration: The system automatically migrates PI/PO ICOs to iFlows, making the migration easy and allowing you to execute the migration flexibly with respect to architecture.
Translation to Predicate Logic: Figaf skillfully converts complex Java and Mapping User-Defined Functions (UDFs) into Groovy scripts that adhere to BTP guidelines, so that legacy system functionalities are maintained in the transition to novel environments.
Lifecycle Management: The set of tools consists of transport management, Git versioning and automatic documentation that covers the missing parts in the standard SAP BTP service.
Focus:: Figaf is designed for SAP PI/PO, the SAP Integration Suite (CPI) and API Management which provides a clear focus on integration problems.

RISE with SAP and Clean Core: Integration Must Not Be Forgotten

RISE with SAP is about more than transitioning to S/4HANA; it’s a fantastic time to eliminate historical sources of waste.

The Classic Clean Core approach as it has been seen until now, for the most part only attacking the backend and identifying archived code that uses older ABAP "Z" code combined with customer modifications. This is necessary, but only a part of the meta-morphosis. Refining the backend result without the integration layer is a partial transformation.

Why "Clean Integration" Matters:

Integration Suite as a Filter: SAP BTP – which includes API Management, Event Mesh, Integration Advisor and Cloud Integration - is designed to keep your core stable. This suite helps put the ugliness in its place - far away from your backend.

Not Embracing the “Frankenstein” Anti-Pattern : Depending on miscellaneous external tools to enrich the inbuilt capability violates the ethos of a Clean Core. These are the sorts of practices that drive "borrowed architectures" which gradually acquire technical debt over time.

How to Future-Proof Your Systems: A standard core demands a standard connection. If you don’t Integrate Clean, you’re likely just putting off big problems for another day.

Bottom Line: A Clean Core and a Messy Integration Layer cannot both exist. That’s crucial no matter how you currently are reevaluating 20 to 30 years of ECC custom code; it is just as necessary for the manner through which your systems will get linked.

Image 5 – Rise and Clean core backend plus Integration refactoring

Conclusion

The intention of this post was to start a conversation between integration developers such as me. Note – this is not a discussion around the various other systems that help you run-the-business. Rather, my interest lies purely with the type of features that SAP BTP Integration Suite has relative to other industry-leading platforms in a similar space.

I wanted to take a deeper look, with closer readers at trade-offs from within the space of API Management (APIM), Event Management (EM), Application Event Management (AEM), SAP Integration Advisor ( IA ) and Cloud Platform Integration (CPI).

This study is conducted to expand our knowledge and understanding of how overlapping functionalities should be addressed in a modern, homogeneous integration architecture.

In the end the decision is from the Integration Architecture responsable, because he must make all the checks between the plataforms and see what can be done with SAP BTP Integration Suite against others plataforms overlapping the services where you can focous in the homogeneos landscape with SAP BTP IS.

Thank you.

Kind regards,

Viana.

IDOCs as Events: How to Simulate and Test Them at Enterprise Scale

2026-01-16T16:20:44.064000+01:00

The integration landscape within the SAP ecosystem has undergone a significant shift in Q4 2025. For years, the industry narrative suggested that IDOCs were relics of the past, destined to be replaced entirely by SOAP Web Services, later one with OData and REST APIs. However, recent updates have changed the table. Not only are IDOCs officially "safe" for the Clean Core era, but they have also evolved into powerful components of modern Event-Driven Architecture (EDA).

In this post, I will explore why IDOCs are making a comeback and, more importantly, how you can simulate and test these scenarios at an enterprise scale.

The 2025 Turning Point: IDOCs are "Clean Core" Safe

The first major update involves the SAP Clean Core guidance (referencing OSS Note 3578329). As of late 2025, IDOCs are now classified as Clean Core Extensibility Level B as per my blog: IDOCs are Still Safe for SAP S/4HANA - SAP Clean Core Extensibility Level B

What does this mean for your S/4HANA journey?

Existing Investments are Valid: If you have stable, working IDOC integrations, you don’t need to scrap them to be "Clean Core" compliant.
Pragmatism over Dogma: While SAP still recommends APIs and Events for greenfield developments, continuing with IDOCs is a pragmatic choice for stable processes, provided the IDOC type isn't deprecated in the S/4HANA Simplification List.

IDOCs Meet the Advanced Event Mesh (AEM)

The second breakthrough is the ability to "event-enable" classic IDOCs using the SAP Event Add-on by ASAPIO as per this blog: IDoc with Integration Suite, Advanced Event Mesh using the Event Add-On

This allows organizations to bridge the gap between legacy reliability and modern real-time agility. By using ASAPIO with SAP Integration Suite, Advanced Event Mesh (AEM), you can:

Go No-Code: Send and receive IDOCs through AEM in a near real-time, code-less manner.
Payload Transformation: Automatically convert classic IDOC formats to JSON on-the-fly for cloud consumption, and convert them back for inbound processing.
Triggering: Link business events in ERP so that a transaction triggers an IDOC extraction and immediate publication to the event mesh.

The Testing Challenge: Scalability and Realism

With IDOCs acting as high-speed events, the question arises: How do we test these scenarios at scale? Standard manual testing isn't enough when you need to validate complex, high-volume event flows.

The Traditional Approach: WE19

The standard tool for simulating IDOCs is transaction WE19 (the IDOC Test Tool). To use it, you find an existing IDOC, use it as a template, modify the data, and trigger it again.

Figure 1 - We19 for outbound processing

The Limitations:

Data Sourcing: Finding the "perfect" IDOC with specific business content is time-consuming (no easy way to search through them)
Lack of Scale: You cannot easily simulate thousands of IDOCs with variable data (different partners, dates, or materials) manually.
Isolation: WE19 tests the IDOC in a vacuum, not the end-to-end event flow.

Enterprise-Scale Simulation with Int4 Suite

To truly simulate IDOCs as events for enterprise testing, you need automation. Int4 Suite provides three sophisticated ways to handle this:

A) Simulating Incoming to Trigger Outgoing

In many business processes, an incoming IDOC triggers an outgoing one (e.g., an incoming Sales Order creates an outgoing Order Confirmation). With Int4 APITester, you can simulate the incoming message and use its variable concept to inject dynamic values (like unique PO numbers or current dates).

Figure 3 - variables so each time the IDOC is triggered the content can change dynamically

This ensures the resulting "Event" (the outgoing IDOC) is generated by the actual business logic of the system.

Figure 2 - IDOCs as outbound from simulating incoming documents

B) Triggering via Message Control (NACE/NAST)

Int4 Suite can trigger output directly via SAP Message Control. This simulates how the system works in production (e.g., printing or sending an EDI upon saving a document).

How it works: By using the Int4 Suite Knowledge Center guidance, you can trigger the output by calling the necessary functional modules or reports (like RSNAST00) to process specific output types for a range of documents, ensuring the "Event" is fired exactly as it would be by a business user.

Figure 4 - How Int4 Suite can trigger IDOCs with Message Control

C) AI-Driven Simulation and WE19

The future of testing involves AI Chatbots. Instead of manually navigating WE19, Int4 Suite allows you to use an AI interface to perform selections and data changes. You can instruct the chatbot to "Generate 50 Sales Order IDOCs with varying quantities or different identifiers" and the suite handles the back-end execution in WE19, bridging the gap between conversational AI and legacy SAP transactions.

Figure 5 - Searching for IDOCs and resending them with Int4 Suite Chatbot

Validating SAP AEM Flows

Once the IDOC is triggered as an event, you must ensure it reaches the SAP Advanced Event Mesh correctly. Int4 Suite allows you to validate these flows by:

Preparation: Configuring the connection between Int4 Suite and SAP AEM to allow the tester to "listen" to specific queues or topics.
Message Selector: Using the Int4 Message Selector, you can pull the actual messages published to AEM and compare them against a "golden" expected payload. This validates that the conversion (e.g., IDOC to JSON) and the routing happened exactly as designed.

Watch it in Action

To see how Int4 Suite handles SAP AEM message selection and validation, check out this technical walkthrough:

Watch: SAP AEM Testing with Int4 Suite

Summary and Next Steps

The combination of Clean Core Level B status and ASAPIO/AEM integration has given IDOCs a second life as modern business events. However, to move these scenarios into production with confidence, your testing strategy must evolve from manual WE19 clicks to automated, variable-driven enterprise simulation.

Want to learn more?

Deep Dive: Explore the SAP Learning Course: Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization to understand how to decouple your testing from external dependencies.
Documentation: Visit the Int4 Suite Knowledge Center for detailed configuration guides on SAP AEM and Message Control.

Using Migration Assessment to Plan Your SAP Process Orchestration to SAP Integration Suite Migration

2026-01-19T11:26:23.748000+01:00

As customers transition from SAP Process Orchestration to SAP Integration Suite, one of the main challenges is gaining early and reliable visibility into the complexity of the existing integration landscape. Without concrete data, migration planning often relies on assumptions, increasing both risk and uncertainty.

The Migration Assessment capability in SAP Integration Suite addresses this challenge by automatically analyzing SAP Process Orchestration integration scenarios and evaluating migration readiness, required adjustments, and technical effort based on a defined rule set. Instead of subjective estimates, it provides fact-based insights that can be directly used for planning, sizing, and architectural decision-making.

This blog post provides a deep technical walkthrough of how the Migration Assessment works and explains how to interpret its results to build a structured and concrete migration plan.

Overview of Migration Assessment

The Migration Assessment in SAP Integration Suite automatically analyzes your on-premise SAP Process Orchestration integration scenarios and evaluating migration readiness, required adjustments, and technical effort based on a defined rule set. It extracts SAP Process Orchestration objects (e.g., Integration Directory, Enterprise Service Repository) and applies a set of predefined rules to gauge technical readiness and technical migration effort.

BTP Solution Architecture

In a typical setup, your on-premise SAP Process Orchestration (with its Integration Directory and ESR) connects via Cloud Connector to the SAP Integration Suite tenant. Within SAP Integration Suite, the Migration Assessment application uses the configured HTTP destination to call the SAP Process Orchestration APIs and extract all integration artifacts. See more information about how to prepare the SAP Cloud Connector in Add an SAP Process Orchestration System.

Prerequisites: To use Migration Assessment, make sure to check the prerequisites in What Is Migration Assessment?

Connecting to the SAP Process Orchestration System and Running the Assessment

Once prerequisites are in place, in summary these are the next steps:

Configure Cloud Connector, exposing the SAP Process Orchestration system.
Add a new system in the Migration Assessment tool.
Create Data Extraction Request.
Create Scenario Evaluation.

It’s not the focus of this blog to go over the process of setup and running the Extraction/Evaluation. You can find a step-by-step details in the Discovery Center mission Get Started with Migration to SAP Integration Suite or the tutorial Use the Migration Assessment Application. With that, you can produce the outputs (PDF/Excel reports) that we will focus on the next sections.

Rules, Assessment Categories and T-Shirt Sizing

A rule consists of multiple parameters and conditions where each interface evaluated will be checked against, each of which has an assessment category, and a weight assigned to it. Based on these weights and categories, the application calculates the estimated effort, which means that some parameters, and therefore rules, have a bigger influence on the final effort estimation than others.

The Migration Assessment categories indicate how a specific functionality in an integration scenario can be implemented in SAP Integration Suite:

Ready to migrate: Scenarios fully match SAP Integration Suite capabilities and can be migrated manually or semi-automatically. Minor adaptations or configuration adjustments may still be required post-migration, but no changes to the end-to-end integration design are needed.
Adjustment required Scenarios partially match SAP Integration Suite capabilities. Migration is possible, but changes to the end-to-end integration design are required, such as protocol conversions or source/target system adjustments.
Evaluation required: Scenarios cannot be directly migrated and require manual analysis. This typically indicates unsupported functionality, custom code and mainly unclear dependencies, requiring manual analysis and possible redesign or re-implementation.

Please note: Each rule has its own assessment category, and a single interface might contain multiple detected rules in it, therefore, the final interface assessment category is based on the “worst” category. In other words, if an interface has at least one rule that is Evaluation Required, the entire interface is classified as such.

The Evaluation Scenarios Dashboard provides an aggregated view of these results, presented as a pie chart along with a summarized list of integration scenarios:

For a more granular view, you can export the Excel report, which provides detailed information for each interface. These details are explained in the following sections.

The T-Shirt size (Small, Medium, Large, Extra Large) reflects the total weighted effort. The Migration Assessment sums the “weight” of all rules triggered by that interface, that will serve to determine the interface size for all that matters (e.g., how many senders, receivers, mappings, attributes in adapter for specific scenarios).

Please Note: SAP provides a rough effort estimation for the technical migration based on the t-shirt and assessment category.

The full list of available rules can be accessed directly in the application under Configure > Rules. All rules in this list are active, and each rule includes a short description explaining exactly what is being evaluated:

The Type column indicates how a rule evaluates a specific value or interval. The following rule types are used:

ValueMatchRule: Evaluates a specific condition or extracted attribute against exact values. This is typically used for true/false checks or validations against a predefined list of static values.
RangeSumRule: Evaluates multiple values of the same attribute that may occur across different objects (for example, mappings or service interfaces) and checks the aggregated result against defined intervals. This rule type is commonly used for counts such as number of parameters, operations, or fields.
RangeRule: Evaluates multiple values of the same attribute against defined intervals without aggregation. This is typically used when assessing thresholds across individual occurrences, such as multiple parameters or operations.

Please note: The Factset attribute is used internally by SAP and is not relevant for the analysis.

By selecting a rule, you can view detailed information about the values or intervals being evaluated:

In this example, the rule is used to determine which message mapping type is used in an interface. If an interface contains multiple mappings, the same rule may appear multiple times in the Excel report, with one line per mapping and its corresponding result.

This rule is of type ValueMatchRule, meaning that Migration Assessment checks for specific values.

Rule Match Value: Contains the value being evaluated by the rule.
Characteristics: Used to further qualify or subgroup the same rule. In this case, it identifies whether the mapping originates from Extended Receiver Determination (EXT_RCV_DET) or from the standard Receiver Interfaces (RECEIVER_IF) structure.
Assessment Category: Determines the assessment category assigned to the interface for this specific rule.
Weight: Represents the effort contribution of this rule. For example, if five Java mappings are used within the same interface (across multiple operations or inbound interfaces), this rule alone would contribute a total weight of 150 (5 × 30)

Results Walkthrough (Excel Report)

In this section, we will provide a walkthrough on the excel report. To generate it, navigate to your evaluated scenario, on the dashboard, and click on Export. You’ll be shortly asked to download the .XLSX file.

Full Evaluation Results

This sheet lists every integration scenario and shows each rule that was triggered. For each rule-hit you see details like the rule name, match value, rule category, and weight.

As described in the previous section in this blog, the column “Sub Characteristic” refers to any relevant sub-grouping used for the same rule and value. The list of possible matches and intervals can be found in the Configure > Rules page.

Interpreting Results (Examples):

If an integration scenario has any rule flagged as “Evaluation Required” (for example, it uses a custom adapter/module), the whole integration scenario will be Evaluation Required. Otherwise it will end up as Ready to Migrate or Adjustment Required depending on other rules.
Sorting this sheet by Weight (descending) quickly highlights the scenarios with the highest effort for a singular functionality/use case. These large-weight cases often involve interfaces with a big number of operations, receivers, etc., as per defined in the range-based rules.
Filtering on Assessment Category = Evaluation required or Adjustment required isolates the critical cases that need manual analysis or post-migration activities for certain. While it’s expected that rules with Ready to Migrate category will have no effort for the migration, there might be cases where a minor-post migration activity within Cloud Integration is necessary.
You can group in the sheet related rules. For example, you might see rules that bring the names of custom adapter and adapter modules, unsupported JDBC drivers, unsupported OS commands, usage of external dependencies, etc. This hints at one-time modernization steps, e.g. “Replace all interfaces using a certain module with the same clean core approach”. That, once done, help multiple interfaces.

To prepare a successful migration strategy, it’s important to take notes of each one of these “findings” and use the SAP best practices to decide which concrete approach will be used afterwards. These notes will also help you, in case a Proof-of-Concept is necessary in order to verify for a certain adaptation use case.

Eval by Integration Scenario

This sheet summarizes results per interface. This view is great for sizing and license planning. For example, you can remove interfaces from the list and still use the “effort” column to manually recalculate the total migration effort. The sheet also shows message throughput per interface.

These Message Throughput are important for estimating the required Integration Suite license (message-based billing).

Additionally you can also have the Message Size and Message Processing Time if you have enabled the performance monthly collection as per the SAP Note 3300008.

For more information of what is the definition of a Message on SAP Integration Suite refer to the SAP Note 2942344 and Discovery Center.

Please Note: The message metrics can also give a hint for inactive interfaces – those with zero messages – which might even be candidates for decommission (though a longer data collection period is recommended before deciding an interface is truly unused).

Type: Qualify if the interface is “Integrated Configuration” (ICO) or “Receiver Determination” (RD) from a Dual-Stack installation.
Integration Scenario: Identification of the interface with the same naming for both Java-Only and Dual-Stack scenarios: SenderParty|SenderComponent|SenderInterface|SenderInterfaceNamespace|ReceiverParty|ReceiverComponent.
Weight: Total weight calculated for the integration scenario based on all applicable rules.
T-Shirt Size: T-Shirt size derived from the total weight according to the defined SAP intervals.
Message Throughput (30 Days): Message volume collected from Message Monitor (Message Status Overview). Please note:
In scenarios with multiple receivers, only outbound messages are counted; inbound entries are excluded.
Only successfully processed messages are considered.
Average Message Size in Bytes (30 Days): Collected from Performance Monitor, using the Last Month time range with a 1-month aggregation interval.
Average Message Processing Time in Milliseconds (30 Days): Collected from Performance Monitor, using the Last Month time range with a 1-month aggregation interval.
Maximum Message Size in Bytes (30 Days): Collected from Performance Monitor, using the Last Month time range with a 1-month aggregation interval.
Assessment Category: Final category assigned to the interface. If at least one rule is classified as Evaluation Required, the interface is categorized accordingly. The same logic applies to Adjustment Required. If no rules fall into these categories, the interface remains Ready to Migrate.
Min Effort Required (Hours): Minimum estimated technical effort for migrating a single interface, based on its Assessment Category and T-Shirt size.
Max Effort Required (Hours): Maximum estimated technical effort for migrating a single interface, based on its Assessment Category and T-Shirt size.
Average Effort Required (Hours): Average estimated technical effort for migrating a single interface, based on its Assessment Category and T-Shirt size.
Extraction Status: Indicates whether the interface was successfully extracted and evaluated:
Extracted with Warnings The evaluation ran, but some interface details could not be fully analyzed. This may occur if sender or receiver agreements could not be retrieved, or if inbound or outbound service interface details were missing. Find below some messages you might find:
- Extraction of Default Service Interface could not identify a SoftwareComponentVersionID for Service Interface: 'x' for integration scenario: 'x' – Indicates that no Software Component Version was selected for the sender interface in the Integrated Configuration or Sender Agreement. As a result, the tool could not retrieve Service Interface details and only partially assessed the interface.
- Some receivers can't be determined because Extended Receiver Determination is used with "Allow Arbitrary Receivers". Therefore, the interface will be partially assessed, excluding all receiver-specific rules. – Occurs when wildcard receivers are combined with extended receiver determination. In this case, the Migration Assessment cannot determine the receiver list at design time, so all receiver-specific rules are skipped.
- Some receivers can't be determined because one or more receiver conditions use XPath expressions. Therefore, the interface will be partially assessed, excluding all receiver-specific rules. – Indicates that receiver determination is based on XPath expressions. Since these are evaluated at runtime, the tool cannot determine the receiver list at design time and excludes receiver-specific rules.
- Message throughput for this interface could not be determined using the Scenario Identifier. Reported values may be inaccurate. – The tool found message throughput data but could not match it uniquely using the Scenario Identifier. Reported values may be inaccurate and should be validated.
- Multiple Scenario Identifiers are identified for the same interface while counting the message throughput. Reported values may be inaccurate – Indicates that a 1:1 relationship between the interface and Message Monitor entries could not be established. This typically occurs when multiple variants of the same sender interface exist (for example, sender wildcard or multiple virtual receivers), which may lead to inaccurate throughput figures.
- Couldn't find sender agreement (inbound processing). – Indicates that the interface does not contain a Sender Agreement.
- Couldn't find receiver agreement (outbound processing). - Indicates that the interface does not contain a Receiver Agreement.
Extracted with Errors The interface could not be extracted and was therefore excluded from the evaluation. This typically results from consistency issues, such as an operation mapping defined in the Integration Directory but not retrievable from the Enterprise Services Repository. In such cases, verify that the relevant software components are correctly assigned to Integration Directory objects (for example, Integration Configuration Objects or Sender/Receiver Agreements). Find below some messages you might find:
- Unable to determine Sender components, Receiver components and Receiver Interfaces. The scenario will not be evaluated. – Indicates that dependent objects could not be identified during receiver determination, pointing to an inconsistency in the configuration.
- No object of type: xxx could be found with the following search criteria - Object: yyy SWCGUID: zzz – Although the tool attempted to retrieve an object (such as a Service Interface or Message Mapping) using its full identifier, the object does not exist in the ESR. This indicates a design-time inconsistency.
- Duplicate key xxx found for integrated configuration and dual-stack configuration. The scenarios linked to this key are excluded from extraction and evaluation. To extract these scenarios, use custom extraction to handle them separately. – Indicates that the same interface exists in both Integration Configuration and Receiver Determination formats. To evaluate such scenarios, create a new extraction Data Extraction and use the custom extraction option instead of a complete extraction to select only one of them.
- Couldn't find service interface details. - The Migration Assessment relies on ESR Service Interface definitions to extract message structure and operation details. If the object exists only in the Integration Directory, the tool cannot access the required ESR metadata.

This is common in “dummy passthrough” or file-to-file scenarios, where no ESR objects are created. While such cases are normally ignored, an error is raised when a Service Interface and Software Component are referenced in the ICO or in Sender/Receiver Agreements but cannot be retrieved from the ESR. This indicates a missing ESR reference or an incorrectly maintained Software Component ID.

Recommendation:
Always review the extraction logs before reading the evaluation results to ensure the assessment data is complete and reliable. You can download it from the Extraction Dashboard page as below:

Scenario Technical Details

The Scenario Technical Details sheet provides a consolidated and detailed view of each integration scenario’s technical metadata. It includes sender and receiver system information, communication channels, mappings, and receiver or interface determination details, making it particularly valuable for migration planning and interface consolidation.

Integration Scenario: Unique interface identification, using the same naming convention for both Java-only and dual-stack scenarios: SenderParty|SenderComponent|SenderInterface|SenderInterfaceNamespace|ReceiverParty|ReceiverComponent.
Interface Type: Indicates whether the interface is Synchronous or Asynchronous.
Sender Communication Party / Sender Communication Component: Identifies the sender party and component. In wildcard sender scenarios, one line is provided per sender.
Interface: Sender (outbound) interface name.
Sender Channel / Sender Adapter: Sender communication channel name and adapter type.
Type of Receiver Determination: Indicates whether Standard or Extended Receiver Determination is used.
Receiver Rule Type / Receiver Rule: Specifies whether a Local Rule or Receiver Rule is used and provides the rule name, if applicable.
Receivers Condition: Full condition string for each receiver. Interfaces with multiple receivers appear as multiple lines.
Operation Mapping / Message Mapping for Extended Receiver Determination: Operation and message mapping names used when Extended Receiver Determination is applied.
Operation-Specific/Not Operation-Specific: Indicates whether the interface configuration is Operation-Specific, Not Operation-Specific, or N/A.
Operation: Interface operation name
Receiver Interface Conditions: Full condition string for inbound interfaces. One line is provided per inbound interface when multiple exist.
Operation Mapping: Operation Mapping name for a single receiver interface.
Message Mapping (Request): Message Mapping name for a single receiver interface. Multiple lines appear if multiple mapping steps exist.
Mapping Type (Request): Mapping implementation type: Graphical Mapping, Java Mapping, XSLT Mapping, or N/A.
Message Mapping (Response): Message Mapping name for a single receiver interface. Multiple lines appear if multiple mapping steps exist.
Mapping Type (Response): Mapping implementation type: Graphical Mapping, Java Mapping, XSLT Mapping, or N/A.
Receiver Communication Party / Receiver: Identifies the receiver party and component. In wildcard sender scenarios, one line is provided per sender.
Receiver Interface: Receiver (inbound) interface name.
Receiver Channel / Receiver Adapter: Receiver communication channel name and adapter type.

Interpreting Results (Examples):

Group interfaces by sender and/or receiver to plan migration waves. A common strategy is to migrate interfaces belonging to the same consumer application together
Identify mappings reused across multiple interfaces. Pivot tables can help detect reusable artifacts and plan their migration as shared integration packages.
Analyze the variety of adapters and communication channels used on both sender and receiver sides to identify standardization or modernization opportunities
Understand how many asynchronous scenarios exist in the landscape. This can support decisions around using the Pipeline concept in Cloud Integration and designing the Partner Directory for specific scenarios such as XI or IDoc. For more information about Pipeline Concept, see Introducing the new pipeline concept in Cloud Integration and Pipeline Concept.

Modernization Recommendations

The assessment also provides Modernization Recommendations based on SAP integration strategy. These suggestions tell you where and how to modernize your interfaces. The recommendations fall into different categories as the below examples:

Integration Style: e.g. adopt event-driven patterns or replace polling with triggers.
Mapping: e.g. use standard, cloud-friendly mapping techniques (graphical mappings) instead of legacy Java or ABAP mappings.
Monitoring & Operation: e.g. enable standardized alerting, use SAP Integration Suite monitoring, or remove hard-coded operations.
Protocol: e.g. switch from JMS or File-based protocols to API-based protocols, or prefer SOAP APIs over IDocs.
Security: e.g. use OAuth2 or certificate-based auth instead of basic authentication.

You can check the help documentation with the complete description of each category and each recommendation in Modernization Recommendations.

Integration Scenario: Unique interface identification, using the same naming convention for both Java-only and dual-stack scenarios: SenderParty|SenderComponent|SenderInterface|SenderInterfaceNamespace|ReceiverParty|ReceiverComponent.
Modernization Category: Recommendation category as defined in the Modernization Recommendations help documentation.
Possible Modernization Item: Indicates the source or aspect of the interface identified as a candidate for modernization.
Recommendation: Target modernization recommendation as defined in the Modernization Recommendations help documentation.

Please note that a single interface may have multiple modernization recommendations.

While some modernization items may represent quick wins, others can require significant changes to the interface design or even to the underlying business process. It is therefore important to carefully assess the impact of each recommendation during the planning phase. If certain improvements cannot be implemented as part of the migration project, the assessment results can still serve as a baseline for defining a long-term modernization roadmap to be executed after the migration.

API and Business Event Recommendations

Beyond the general modernization recommendations, Migration Assessment can go a step further by identifying opportunities to modernize IDoc and BAPI (RFC)-based integrations. Based on the detected usage, it proposes suitable SOAP and OData APIs available in SAP S/4HANA, helping you align your integrations with SAP’s recommended, API-based integration patterns.

These insights are available in the API Recommendations Excel sheet.

Similarly, the Business Event Recommendations Excel sheet provides recommendations for redesigning integrations using an event-driven architecture, based on the business events available in SAP S/4HANA.

Object ID: Name of the IDoc or BAPI identified as a candidate for modernization..
Type (BAPI/IDOC): Indicates whether the object is an IDoc or a BAPI. Currently, only these object types are supported.
API/Business Event: Name of the target API or Business Event proposed for modernization.
Technical Name: Technical name of the API or Business Event. This can be used to search directly in SAP Business Accelerator Hub or to activate the service in SAP S/4HANA.
Protocol: For APIs, indicates whether the service is available as OData V2, OData V4, or SOAP.
Solution: Indicates the SAP solution in which the API or Business Event is available. Currently, Migration Assessment proposes objects available in SAP S/4HANA On-Premise, SAP S/4HANA Cloud, private edition, and SAP S/4HANA Cloud, public edition.

Notes:

If the same API is available in multiple solutions and/or protocols, the values are listed as comma-separated entries in the Technical Name, Protocol, and Solution columns.
A single IDoc or BAPI may be replaced by multiple APIs depending on the business process, resulting in multiple rows for the same object in the Excel report.

You can find a practical example how you can explore, analyze and modernize an interface using such recommendations in Modernizing for a Clean Core: IDoc to Events & APIs in SAP PI/PO to Integration Suite Migration and Modernizing RFC/BAPI-based Integrations for a Clean Core with SAP Integration Suite.

Effort Estimation

The Effort Estimation sheet consolidates the total technical migration effort by aggregating the estimated days associated with each T-shirt size, resulting in an overall execution estimate (for example, “Project Effort = 123 days”).

This estimate covers only the technical re-implementation of interfaces, ideally using the migration tool where applicable. It explicitly excludes activities such as prepare, explore, validation, and cutover.

A learning curve factor is applied to the calculation. When multiple interfaces share the same size and category, they tend to be similar, allowing developers to become more efficient over time. This efficiency gain has been consistently observed across multiple migration projects and is reflected in the final effort calculation.

The intervals used for the learning curve factor are outlined below:

Number of Interfaces x T-shirt size	Learning Curve
10-50	25%
51-100	27%
101-200	30%
201-500	33%
501 or more	35%

Use this estimate as a baseline for building your project schedule, taking into account the effort required for critical phases such as testing, the tools and accelerators available to support the migration, and the external parties that must be aligned to ensure a successful go-live.

Please note that the technical execution effort provided by the Migration Assessment may vary depending on the technical team’s expertise and the scope of modernizations included in the migration journey.

In the Excel file, the calculations are presented in two tables. The first table includes interfaces categorized as Ready to Migrate and Adjustment Required, while the second table contains interfaces categorized as Evaluation Required.

Interfaces under Evaluation Required typically need manual analysis and are therefore subject to higher estimation deviations. You may sum the results of both tables as-is for an initial migration effort estimate, but only after reviewing the Evaluation Required scenarios to ensure the figures are reasonable.

Conclusion

The Migration Assessment reports provide a concrete, data-driven foundation for your SAP Process Orchestration to SAP Integration Suite migration plan. They clearly identify which interfaces are straightforward to migrate (Ready to Migrate and Adjustment Required) and which require deeper analysis (Evaluation Required), while quantifying the expected effort in days.

Use these insights to structure the migration into logical phases. Although it’s normal to have a single structured project to migrate all the interfaces, you can also start, for example, by migrating all Ready to Migrate interfaces within a specific business area (low effort), while in parallel analyzing the Evaluation Required interfaces that may need redesign or even preparing a Proof-of-Concept to validate a particular modernization. The assessment also promotes consistency by identifying shared artifacts, so mappings or channels are reworked only once, and by proposing modernization opportunities such as protocol changes or API adoption to future-proof your integrations.

In short, don’t migrate blindly. Leverage the Migration Assessment to uncover hidden dependencies and effort drivers before implementation begins. This allows you to organize delivery into manageable deployment waves, assign realistic effort estimates to each wave and make informed technical decisions early.

For additional questions related to the SAP Process Orchestration to SAP Integration Suite migration, see FAQ – Migration from SAP Process Orchestration to SAP Integration Suite.

Additional References

SAP Integration Suite - Agentic Testing is available now with Int4 Suite

2026-02-06T10:13:21.141000+01:00

The SAP BTP Integration Suite AI roadmap for 2026 showcases a massive shift toward Agentic AI, focusing on making the platform not just a tool for developers, but an orchestrator of autonomous agents. While SAP is actively building these capabilities, Int4 Suite is already delivering on several of these "future" promises today, particularly in the realm of Test Agents.

The SAP BTP Integration Suite AI Roadmap (2026)

According to the SAP Community update, the roadmap is divided into two major pillars: AI for Integration (productivity) and Integration for AI (orchestration).

MCP (Model Context Protocol) Gateway: SAP is betting heavily on MCP as the standard for connecting and governing AI agents. This will allow the Integration Suite to act as a "control plane" for agents.
Joule-Driven Development : SAP is moving beyond simple prompts to full iFlow generation and design validation using Joule, SAP’s digital assistant.
Specialized AI Agents (Future Roadmap):
- Migration Agent: To convert Java mappings and adapter modules into Groovy scripts.
- Configuration Agent: To suggest iFlow configurations based on historical data.
- Test Agents (Planned): SAP explicitly mentions the plan to develop Test Agents that provide test data and test cases during the development of an iFlow to allow for immediate testing.

Int4 Suite: SAP Integration Suite Test Agents are available today

While SAP’s own Test Agents are currently on the roadmap for future development, Int4 Suite already provides a functional testing engine that automates the most time-consuming parts of SAP integration.

1. Natural Language Test Creation

SAP’s roadmap envisions using Joule for iFlow testing. Int4 Suite already utilizes advanced AI models to allow users to create and manage test cases through natural language.

Figure 1 - Int4 Suite Test Agents can create, change, and run any tests on the SAP Integration Suite.

The Chatbot Experience: Instead of navigating complex technical menus, users interact with an AI "Testing Agent."
Semantic Intelligence: Built on a Business Knowledge Graph, the system understands the relationship between technical messages and business data. You don't need a Message ID; you can simply ask the assistant to find or create test cases based on specific business criteria, like "Sales Orders for US-based customers."
Autonomous Execution: The agent doesn't just suggest a case; it handles the setup, injection, and execution of that test into your landscape (e.g., from Dev to QA) automatically.

2. Automated Test Case Generation from Historical Data

A key goal of SAP's future roadmap is providing "test data and test cases" automatically. Int4 Suite fulfills this today through two innovative modules:

The Robotic Crawler: This tool acts as a "search and capture" engine. It scans historical electronic messages and business documents directly from production environments of SAP Integration Suite or legacy middleware (like SAP PI/PO), extracting the full payload of real transactions.
The Repeater Module: This module "replays" captured production messages through your new integration scenarios. For example, during a migration to SAP BTP Integration Suite, Int4 Suite takes a real Production Sales Order and runs it through your new iFlow to ensure the resulting S/4HANA document matches the original exactly.
Secure Anonymization: To ensure GDPR compliance, Int4 Suite includes a data scrambling engine that anonymizes sensitive information before the test case is created, making real-world data safe for use in non-productive environments.

Bridging the Gap: Why Agentic Testing Matters Now

As SAP moves toward "Agentic IPaaS", where autonomous agents like Quote Creation or Receipt Creation Agents operate within your system—verification becomes the primary challenge. While SAP focuses on the orchestration of these agents, Int4 Suite focuses on the validation.

Because SAP BTP Integration Suite updates are automatic and frequent, Int4 Suite acts as a "continuous insurance policy." It validates the "logic under the hood", confirming that business documents are created correctly in SAP S/4HANA, rather than just checking if a technical message was "sent."

Migrating Content-Based Routing Scenarios Using the Migration Tool in SAP Integration Suite

2026-02-12T23:29:04.379000+01:00

Objective of this Blog

The goal of this blog is to explain how the Migration Tool supports Content-Based Routing (CBR) asynchronous integration scenarios. The blog will cover the following key areas:

What is Content-Based Routing (CBR) in SAP Process Orchestration
Standard Receiver Determinations – Understanding Rules
No Receiver Is Found – options such as Error Message, Ignore, or Select a Default Receiver
How the Migration Tool migrates CBR scenarios from SAP Process Orchestration to SAP Cloud Integration

What is Content-Based Routing (CBR) in SAP Process Orchestration

Content-Based Routing (CBR) in SAP Process Orchestration is a mechanism that routes messages to the correct receiver based on the content of the message. Instead of sending a message to a fixed receiver, CBR uses Receiver Determination with Rules to evaluate message payloads (XML fields, attributes, or headers) at runtime and forward the message to only one receiver whose condition is satisfied. This enables intelligent routing without requiring any changes to the sender system.

At configuration time in SAP PO, you can define conditions that depend on the content of the message. These conditions can be applied both to receiver communication component determination and inbound interface determination. However, in this blog, we will focus specifically on receiver communication component determination, where multiple potential receivers can be configured but only one receiver is selected at runtime based on the defined routing rules.

Standard Receiver Determinations

Here you manually specify the receiver as well as conditions for forwarding the message to the specific receiver.

You can also define rules for forwarding the message to the receivers.

The following options are available:

Specify “Local” Rules: You define the rules specially for a specific receiver determination. This then also applies for messages where the address field in the header matches the key of the receiver determination.

Insert (Reusable) Rules: You use separately defined rules that can be reused in multiple receiver determinations. A rule such as this is defined as a standalone object in the Integration Directory and identified as a receiver rule.

Note: A receiver rule applies to all messages whose address header matches the object keys of the receiver determinations in which the receiver rule is used. SAP recommends using receiver rules if you want to use the same rule in different scenarios.

For more details, see Defining Standard Receiver Determinations

Receiver interfaces and Communication Channels are assigned to specific receivers: In the following example, Receiver interfaces and mappings are bound to their corresponding receivers.

NoReceiverBehavior

Specifies what happens if no receiver can be determined at runtime.

Possible values:

Error Message: Message processing is terminated with an error.
Ignore: Message processing is ended as defined by your configuration settings.
Specified Receiver: The message is sent to a fixed predefined receiver.

How the Migration Tool migrates CBR scenarios from SAP Process Orchestration to SAP Cloud Integration

Migration Wizard:

In the Migration Wizard, after completing Step 1 – Select Process Orchestration System and Step 2 – Select Process Orchestration Artifacts

the next page is Step 3 – Choose Pattern and Approach. In this step, you need to select the appropriate migration pattern and the corresponding approach based on your integration scenario.

Note: Content-based scenarios can be migrated using both the CBR (Content-Based Routing) and RL (Recipient List) patterns. However, it is recommended to choose the CBR pattern when the message is ultimately routed to only a single receiver

Content-Based Routing (CBR) Pattern: Multiple receivers can be configured, but at runtime the system evaluates message content and conditions and forwards the message to only one final receiver.
Recipient List (RL) Pattern: In the Recipient List pattern, the message can be sent to multiple receivers, with or without conditions. It is used for one-to-many routing where several receivers are eligible to receive the same message.

Note: In SAP PO (Process Orchestration), there is no strict technical distinction between CBR and RL. Both are configured through Receiver Determination rules, and the behavior depends on how the conditions and receivers are defined.

Step 4 and Step 5 are used to import the required mapping objects from your SAP Process Orchestration system.

Step 6 is where you provide the name of the Integration Flow, and

Step 7 allows you to review the objects that will be migrated to SAP Cloud Integration.

After a successful migration, a Summary Page is displayed, providing key insights and direct navigation links to the migrated artifacts in Cloud Integration.

Now let us understand how the Migration Tool generates the Content-Based Routing pattern based on the existing integration configuration and its key flow steps.

Note: This blog primarily focuses on understanding and applying the standard approach.

Standard Approach

After a successful migration, the Integration Flow is typically split into two integration processes - the first acting as the Inbound Integration Process and the second as the Outbound Integration Process.

Note: Both processes are internally connected using the ProcessDirect adapter, enabling seamless message transfer between the inbound and outbound integration Processes.

Inbound Integration Process:

This process receives the message from the sender, sets the sender system and message type, and performs receiver determination where the defined receiver rules and routing conditions are evaluated. The content-based routing logic is executed here to identify the appropriate receiver based on the message content.

Content Modifier – Receiver Conditions & Interface Conditions:

The Content Modifier stores the predefined conditions derived from Receiver Determination and Interface Determination. The local rules, receiver rules, and inbound interface conditions configured in SAP PO are migrated and maintained here, where they are listed and used during runtime evaluation for routing decisions

Let us understand the migrated content from SAP PO that appears in above Content Modifier – Exchange Properties section.

SAP-DYNREC-<Receiver Communication Component>:
SAP-DYNREC is a prefix added to each Receiver Communication Component present in the migrated ICO.

The value of this property represents the receiver condition migrated from Configured Receivers - Rules. If a condition is defined in SAP PO, it is carried over here; otherwise, the value is set to true(), indicating unconditional routing eligibility for that receiver.

SAP-IFDET-<Receiver Communication Component>~IFx:
SAP-IFDET is the prefix used for Interface Determination and is also added to the Receiver Communication Component name. The suffix ~IFx acts as an interface index indicator, which increments based on the number of receiver interfaces maintained for that receiver.

For example, if Receiver_1 has three receiver interfaces, the generated properties would be:

SAP-IFDET-Receiver_1~IF1
SAP-IFDET-Receiver_1~IF2
SAP-IFDET-Receiver_1~IF3

The value of each property reflects the interface condition migrated from the on-premises system. If interface-level conditions exist, they are preserved; if not, the value defaults to true().

These exchange properties collectively store the migrated receiver and interface rules, enabling the integration flow to evaluate routing logic dynamically at runtime.

Receiver Determination:

Receiver Determination is implemented as a Process Call that invokes a local integration process. This local process contains a static receiver-determination Groovy script which evaluates the predefined conditions migrated in the previous step (Receiver Conditions and Interface Conditions). Based on these conditions, the script identifies and returns the appropriate receiver for the message.

Router and No-Receiver Behavior:

The Router is used to forward the message to the specific receiver that was determined based on the evaluated conditions.

In addition to routing, it also manages the No-Receiver Behavior. If no receiver is found, the Migration Tool dynamically generates the configured fallback option.

For example, it can automatically route the message to a default receiver (in this example, RL_Receiver_4).

Alternatively, if the configuration is set to Error = an Exception Event is generated, and if set to Ignore = an End Event step is created to terminate the flow without further processing.

Outbound Integration Process:

The Outbound Integration Process contains the mappings, receiver communication channels, and the configured receivers, and is responsible for delivering the processed message to the final target system.

Router:

In the Outbound Integration Process, the Router uses the receiver determined in the Inbound Integration Process to bind the corresponding receiver interface/mappings to the specific receiver via its associated communication channel. The message is then forwarded along the appropriate route based on the evaluated conditions, ensuring it reaches the correct receiver.

Pipeline Approach

In this section, we will migrate the same example using the Pipeline Approach.

Key Highlights in the Migration Wizard:

After selecting the Pipeline Approach for your migration use case, the Migration Tool allows you to modify alternative partner information, as well as review and update the migrated receiver/interface conditions and endpoints, as illustrated in the screenshot below.

After a successful migration, you can view the generated artifacts and navigate to them directly.

In the Pipeline Approach, scenario-specific Inbound and Outbound Integration Flows are created. The Outbound Integration Flow is generated for each receiver configured in the respective ICO, ensuring that messages are routed correctly based on the original configuration.

The Partner Directory tab provides an overview of the created Partner ID along with their associated parameters.

On the Binary Parameters tab of the Partner Directory, you can see that a binary parameter with the ID receiverDetermination has been created. This parameter contains the XSLT used to determine the appropriate receivers during message processing.

For more information, See Using the Partner Directory in the Pipeline Concept

For a deeper understanding of the Pipeline Approach, please refer to the following references:

Migration Tooling now supporting migration via the pipeline approach

Applying the pipeline concept for an integration scenario in general

Learn here the differences and characteristics of each approach to choose the one that aligns best with your migration needs Standard vs Pipeline Approach

Post-Migration Activities – Key Points to Keep in Mind:

After successfully migrating CBR Integration Flow, the following activities should be verified and completed:

Verify Migrated Artifacts: Ensure that mappings (local and global), Function Libraries, imported archives, and Local UDFs are migrated correctly and functioning as expected.
Adapter Configuration: Adapter parameters are externalized. Verify the configurations and update them as needed to match the target environment.
Adapter Conversions: Adapter conversions such as JSON-to-XML or CSV-to-XML are migrated automatically. Check the configuration in the conversion flow steps and adjust if necessary.
Security Artifacts: The Migration Tool does not create or import security artifacts in Cloud Integration. Manual creation of security materials (certificates, keystores, etc.) is a prerequisite before deploying the Integration Flow.
Reusable Mapping Options: If the “Enable Reusable Mapping” option was selected during migration, ensure that the standalone artifacts are deployed first before deploying the main Integration Flow.

For other manual activities for specific senarios, please refer to the section “Manual Activities Depending on Integration Scenario” in the P2P Blog from series

Conclusion:

Content-Based Routing (CBR) scenarios can be successfully migrated to Cloud Integration using the Migration Tool, preserving receiver determination, routing conditions, mappings, and adapter configurations. While most artifacts are migrated automatically, post-migration verification and manual activities - such as security setup and reusable mapping deployment - are essential. Following the recommended steps ensures that your integration flows continue to run reliably and efficiently in the Cloud Integration environment.

What Will Be Covered in the Next Parts of Master Blog Series:

In the next parts of this blog series, we will explore the following topics in depth with a detailed and comprehensive walkthrough:

Extended Receiver Determination using the Pipeline Approach
Operation-Specific Receiver Determination and Multi-Operation Scenarios
Content-Based Routing (CBR) – Synchronous Use Cases