SAP Community - SAP Integration Suite

SAP PO to SAP CI Migration - Simplifying File-Based Scenarios with SMB Adapter in SAP CI

2026-02-09T11:20:57.235000+01:00

Every enterprise today is actively working on SAP PO to SAP Cloud Integration (CI) migration as part of their move towards modern, cloud-based integration platforms. While many interface types can be migrated smoothly, one of the most common challenges during SAP PO to SAP Cloud Integration (CI) migration is handling file-based interfaces that rely on internal on-premise file systems. In many landscapes, business applications exchange data by placing files on shared network folders, and SAP PO integrations are tightly built around these locations.

In SAP PO, this was quite straightforward. The File/NFS Adapter allowed direct access to internal network paths without the need for FTP servers or external exposure. As a result, many legacy integrations continue to depend on this simple and secure approach.

But when moving to SAP Integration Suite, teams quickly realize an uncomfortable truth: SAP CI does not provide a native NFS adapter. Since SAP CI runs in the cloud, it cannot directly access internal file systems, making a direct “like-for-like” migration of such scenarios difficult.

This creates a big question:

How do we migrate scenarios where files are stored inside the customer’s internal network?

Solution :

Option 1 – FTP/SFTP

A common workaround suggested in projects is to introduce an FTP/SFTP server and move files there first.

But highlight why this is not ideal:

FTP is not recommended for security reasons
SFTP might require extra infrastructure and additional costs

So we need something better.

Option 2 – SMB Adapter (Best fit)

SAP has released the SMB Adapter in SAP Integration Suite specifically designed to address this exact problem.

The SMB adapter facilitates file-based operations and accelerates implementation time to connect to a server using SMB (Server Message Block) protocol. The adapter is available only for Standard service plans and above of the SAP Integration Suite.

Feature highlights:

Secure authentication with Server Message Block (SMB) shares.
Offers compatibility with various SMB dialects.
On-Premise Connectivity via Cloud Connector.
Supports connections to SMB using Encryption, DFS, and Signing.
Provides different file handling options such as override, append, fail, and ignore.

High-Level File Based Architecture Explanation:

The above diagram illustrates the architectural shift when migrating file-based integrations from SAP PO to SAP Cloud Integration.

In SAP PO landscapes (Diagram 1), accessing files stored inside the customer’s internal network was relatively simple. The SAP PO File Adapter could directly read and write files from network locations using the NFS protocol.

Application servers typically mounted shared drives, and SAP PO accessed them seamlessly as local folders.

However, in SAP Cloud Integration ((Diagram 2) this approach is no longer possible. Since SAP CI runs in the cloud, it cannot directly mount or access internal network file systems. Moreover, SAP Integration Suite does not provide an NFS adapter like SAP PO.

This creates a major migration challenge for scenarios where:

Business applications drop files on internal network folders
SAP PO polls those folders using the File/NFS adapter
No FTP/SFTP servers are involved

To address this gap, SAP introduced the SMB Adapter in SAP Integration Suite.

The lower part of the diagram shows the modern CI-based approach:

Internal folders are exposed as SMB Shares on the customer network
SAP Cloud Connector establishes a secure tunnel between SAP CI and the on-premise network
The SMB Adapter in SAP CI connects through Cloud Connector
Communication happens over TCP using the SMB protocol
Files can be securely read from or written to internal locations without exposing them to the internet

This architecture provides a clean and secure replacement for NFS-based integrations in SAP PO, enabling a smooth migration path for file-based scenarios without introducing FTP servers or additional middleware.

Additional Scenario – When an SMB Server Already Exists

In many customer landscapes, an SMB file server is already available in the internal network (diagram 1), and applications directly place files on SMB shared folders. In SAP PO setups, even in such cases, the File/NFS adapter cannot consume these files directly. The SMB share first needs to be mounted on the SAP PO server and exposed as a local file path. Only after this mounting, SAP PO can access the location using the NFS/File adapter. This adds additional administrative effort and dependency on server configurations.

With SAP Cloud Integration, this limitation no longer exists. The SMB Adapter in SAP CI can connect directly to an existing SMB server through SAP Cloud Connector without any need for drive mounting. As long as the folder is available as an SMB share and properly exposed via Cloud Connector, SAP CI can immediately read from or write to it. This significantly simplifies the architecture, reduces infrastructure dependencies, and makes the migration of such scenarios from SAP PO to SAP CI much more straightforward.

In the Next Sections, We Will See:

How to : Create or update an SMB Share on the network
Configure: Cloud Connector for SMB access
Build: Configure SMB Adapter in SAP CI
Demo Scenario:

Pick a file from on-prem location
Process it in SAP CI
Delete the file as a part of post processing

Section A – Preparing the SMB Share

In our scenario, the internal file server is Linux-based. The following steps need to be executed by the Infrastructure team to create and expose a folder as an SMB share. These commands can be run on the Ubuntu server via SSH using tools like PuTTY or the command prompt.

# Update packages - before installing new components, ensure that the system packages are up to date
sudo apt update
 
# Install Samba and client tools required for SMB communication
sudo apt install samba smbclient -y
 
# Create the folder that will be exposed as an SMB share
sudo mkdir -p /srv/smb/smb_share
 
# Create SMB user
sudo adduser smbuser
 
# Set directory ownership and permissions
sudo chown -R smbuser:smbuser /srv/smb/smb_share
sudo chmod -R 775 /srv/smb/smb_share
 
# Backup Samba config
sudo cp /etc/samba/smb.conf /etc/samba/smb.conf.bak
 
# Configure the SMB Share - Add the new share definition to the Samba configuration
sudo bash -c 'cat >> /etc/samba/smb.conf <<EOF
 
[smb_share]
   path = /srv/smb/smb_share
   browseable = yes
   read only = no
   valid users = smbuser
   force user = smbuser
   create mask = 0660
   directory mask = 0770
EOF'

This configuration defines:

The physical path of the share
Read/write access
Authorized user
File and folder permission masks

# Create and enable the Samba-specific password for the SMB user:
sudo smbpasswd -a smbuser
sudo smbpasswd -e smbuser
 
# Restart Samba services
sudo systemctl restart smbd nmbd
 
# Allow Samba through firewall (if UFW is enabled)
sudo ufw allow samba
 
# Verify Samba configuration
testparm -s
 
# Verify share listing
smbclient -L localhost -U%
 
# Test share access
smbclient //localhost/smb_share -U smbuser

#Accessing the Share from Windows access: Once the SMB share is created, it can be accessed from any authorized Windows machine using the network path format using the credentials created above:
\\<server-name-or-ip>\smb_share

Deploy the credentials (smbuser) as basic credentials in SAP CI Security Artifact, these credentials will be configured in the SMB Adapter for authentication.

Section B – Cloud Connector Configuration

As we are connecting to On Premise Server, Cloud Connector comes into picture for the connectivity.

Configurations:

Internal Host: The IP address or the host name of the Internal Server on which SMB share is avaiable

Port: 445 (Used for TCP protocol)

Check out this article to setup TCP connection in Cloud Connector: https://help.sap.com/docs/connectivity/sap-btp-connectivity-cf/configure-access-control-tcp

Section C – Setup SMB Adapter in SAP CI Iflow

SAP CI IFlow:

Configuration of SMB Sender Adapter

Field	Description
Address	Specify the hostname or IP address of the SMB Server. Specify Virtual Hostname if Cloud Connector is used
Domain	Specify the domain used for authentication.
Proxy Type	Specify the proxy type: • Internet • On-Premise
Location ID	Location ID of Cloud Connector (proxy type = On-Premise)
SMB Dialect	Select the SMB dialect or version to be used for communication. Recommendation is to use the latest one available in the adapter, 3.1.1 for now An SMB dialect is a specific version of the SMB protocol that defines the supported features, capabilities, and communication formats between a client and a server
Share	Specify the SMB share folder which represents the network resource Example: Assuming the mount path is \\ServerName\ShareName, you must specify Share as ShareName.
Authentication	Select the authentication type for connecting to the SMB server. Currently only Basic Authentication is supported
Credential Name	User Credentials security artifact
Timeout (in secs)	Specify the maximum waiting time (in seconds) for a response message from the SMB Server.
Enable Encryption	Enable to turn on encrypted communication between client & server. Recommendation is to Enable Encryption for better security. This option is applicable only if the server supports it. This adds encryption to the data in transit, supported only for SMB 3.x dialect
Enable DFS	Enable Distributed File System DFS in SMB is a feature that provides a unified virtual file system namespace, allowing multiple SMB file shares across different servers to be accessed through a single logical path.
Enable Signing	Enable SMB Signing. Recommendation is to Enable Signing for better security. This option is applicable only if the server supports it. This adds signing to the data in transit. supported only for SMB 3.x dialect
Maximum Reconnect Attempts	Specify the maximum number of retries permissible for reconnection to the SMB server before message processing starts.

Recommendation : Use the latest 3.1.1 SMB Dialect with Encryption and Signing for better security

The processing tab contains the following fields:

This tab has parameters similar to what we see in SFTP Adapter Processing.

Please check this document for detailed information: https://api.sap.com/odata/1.0/catalog.svc/Files('2ee08d2557d84acfab3331448c2784b1')/$value

Section D - Demo:

In the Demo, the idea is to read a file from the SMB Share using SMB Sender Adapter.

SMB Share:

Content in the File:

The Sender Adapter Configuration is shown as above, Lets deploy the IFlow now.

Message run in TRACE mode:

File is received in SAP CI and deleted from the SMB Share.

In this similar manner, you can also use SMB receiver adapter to write a file on the folder, the connection tab configuration remains same as Sender Adapter, Operation Type in the Processing tab will be changed to “Create File”

Conclusion:

Migrating file-based scenarios from SAP PO to SAP CI no longer needs to be a roadblock.

The SMB Adapter provides a clean, secure, and SAP-recommended approach to connect SAP Integration Suite with internal network file systems making it the closest and most reliable replacement for the NFS adapter of SAP PO.

With minimal changes to existing infrastructure and no need for FTP servers, the SMB adapter truly simplifies one of the trickiest parts of PO to CI migration.

Hope this help,

Cheers!

Punith

Kick Off 2026 With Impact: Collaborate on 56 Fresh SAP Customer Engagement Initiative Projects

2026-02-09T18:32:10.774000+01:00

We’re excited to announce that Cycle 1 of the SAP Customer Engagement Initiative for 2026 is now live!
This cycle features 56 new projects, offering SAP customers and partners the opportunity to gain early insights into upcoming product developments and collaborate directly with SAP teams to shape the next generation of SAP solutions.

🗓Registration is open until March 13, 2026.

In a rapidly evolving business environment, early involvement can make a meaningful difference. Through the SAP Customer Engagement Initiative, you can work directly with SAP product managers and developers, sharing your feedback on concepts, prototypes, and plans while they are still in the early stages.

To help you explore all available opportunities, we’ve prepared a complete overview of the projects.
View the full list here, or browse the links below to discover the topics most relevant to you.

SAP Ariba

Reporting and Analytics in SAP Ariba Invoicing

SAP Business Technology Platform

SAP Concur

Data & Analytics

SAP S/4HANA Cloud

SAP Globalization

Others

Let’s shape the future together!

Innovation happens through collaboration. By participating in the SAP Customer Engagement Initiative projects, you help SAP create better, more relevant solutions for businesses like yours. This is your chance to influence what comes next.

Don’t miss out – sign up today at influence.sap.com and be a part of the SAP Customer Engagement Initiative Cycle 1 in 2026!

Warm regards,
Your SAP Customer Engagement Initiative Team

Follow-up after registration: When you register for a project, you will be invited to an introductory call with the SAP project lead. At this point further participation is optional. Typically, all activities are governed by the Feedback Agreement with SAP.

How to Get Started with Pipeline for Cloud Integration

2026-02-10T16:02:09.566000+01:00

This blog is a beginner’s blog for getting started with Pipeline for Cloud Integration, for integration developers having experience in Cloud Integration in general. The Pipeline was introduced beginning of 2024, when it was a concept (referred to as Pipeline Concept) as part of the migration guide for migrating from SAP Process Orchestration / SAP Process Integration to SAP Integration Suite. In the last months and years, the Pipeline has been evolved from a concept to a solution, being regularly enhanced with new features and customer requirements. That’s why there is a lot of Pipeline-related content available. As a central starting point, this blog aims to shed light on what the Pipeline is about and how to initially set it up in Cloud Integration.

Motivation

The Pipeline is a framework designed to ease setting up integration scenarios. Instead of starting from scratch each time, it uses a standard design provided by SAP. This saves time and reduces complexity because you can reuse the same building blocks for different scenarios. It works by handling tasks asynchronously, which helps keep systems running smoothly. The Pipeline offers strong error-handling and retry options, both automatic and manual, to keep messages flowing. Plus, it allows content-based routing based on the message content during processing. It ensures that messages are processed Exactly Once and supports idempotency, keeping data accurate and consistent.

The Pipeline simplifies complex integration setups, like content-based routing and recipient lists, and helps in cases of receivers and interfaces splits. Generic integration flows can be reused across scenarios, cutting down on effort and complexity. It works well for the migration of SAP PI/PO to Cloud Integration, with support from the migration tool, while keeping necessary processing features intact. You can also use the Pipeline to create new scenarios, whether they are asynchronous or synchronous. It efficiently uses limited resources in Cloud Integration, like JMS queues, by sharing them across several scenarios. By using the standard, this framework is flexible, allowing for customization and extension to fit specific use cases.

Use Cases

The Pipeline for Cloud Integration is suited for but not primarily restricted to companies transitioning from SAP PI/PO to Cloud Integration. It provides a smooth migration process leveraging the migration tool. Beyond migrations, the Pipeline is a solution for designing new integration scenarios in a uniform structure, making it easier for maintenance and monitoring. It can use generic inbound integration flows as single entry points for both XI proxy and IDoc scenarios, streamlining message processing, and has an option for generic XI or IDoc outbound flows. Additionally, the Pipeline supports extended receiver determination, enabling more precise routing than usual XSLT mappings.

For simpler uses, point-to-point scenarios are supported, where you can bypass receiver and interface determination steps for faster runtime and simpler configuration, relying on string parameters from the Partner Directory instead of XSLT mappings. For special situations, the Pipeline supports the use of receiver-specific JMS queues, although the default is a generic outbound queue to keep operations straightforward. It also accommodates combined receiver and interface determinations in a single XSLT, as well as sender wildcard scenarios. Altogether, the Pipeline allows to stay in standard while supporting a variety of use cases.

Architecture

The Pipeline works with multiple Integration Flows using a limited number of JMS queues for asynchronous scenarios. There are generic and scenario-specific Integration Flows: generic Integration Flows are developed and enhanced by SAP, being published in SAP Business Accelerator Hub (see next chapter “Initial Setup of Pipeline”). The scenario-specific Integration Flows do not contain lots of complexity and are either generated by the migration tool, or you can create them manually. For different scenarios, messages share the generic Integration Flows as well as the JMS queues – the latter one is important as it targets the reuse of limited resources in Cloud Integration.

For content-based routing and dynamic message processing behavior, the Pipeline relies on the Partner Directory, from which it reads the required information at runtime. Based on the sender system and the sender interface, the Pipeline looks up the Partner ID (Pid) in the Partner Directory. The Pid is the name of your integration scenario, which holds together the scenario, containing string parameters for dynamic message processing behavior as well as receiver and interface determination, either as binary parameters for content-based routing using XSLT mappings, or as string parameters for point-to-point scenarios (which have exactly one receiver system and one receiver interface).

The architectural diagram almost shows the bare minimum required for Cloud Integration: 4 Integration Flows (2 generic Integration Flows, 2 scenario-specific Integration Flows), 2 JMS queues, and the Partner Directory (with minimum 2 entries per scenario being 1 alternative partner and 1 binary parameter for content-based routing with combined receiver determination). From this architecture, the Pipeline can be highly extended with more Integration Flows, JMS queues, and Partner Directory entries, to implement a variety of different scenarios and use cases by using the standard framework.

Initial Setup of the Pipeline

To set up the Pipeline for the first time, you can follow the steps below to run your first working scenarios. In this blog post, two scenarios are described with a step-by-step guide which you can follow along to set up the Pipeline in your tenant. You can use a development tenant or even setup a trial tenant to follow along.

Point-to-point scenario (sample 5)

From our experience, most of the integration scenarios are point-to-point, meaning that, for a combination of sender system and sender interface, these scenarios have exactly one receiver system with one receiver interface. These scenarios bypass the content-based routing and therefore are easier to setup by using string parameters in the Partner Directory for receiver and interface determination.

The following example is sample scenario 5 (PID: PIP_Samples_Scenario_5) of the sample scenarios by @alex_bundschuh. As explained above, you need 4 Integration Flows for that, as well as 2 (automatically created) JMS queues and some Partner Directory entries. The following table shows how this fits together (in order of occurrence at runtime):

Type	Technical name in standard	Name in picture of architecture	Purpose
Integration Flow scenario-specific	PIPSamplesScenario5_Step01 (custom name)	Inbound (scenario-specific)	This Integration Flow receives the incoming message and puts it to the generic JMS queue for decoupling.
JMS queue	PIPX01	Inbound X queue	The JMS queue holds the message until it is taken by the next Integration Flow and eventually handles retries.
Integration Flow generic	Pipeline v2 Generic Step02 – Integrated Messaging Runtime Async	Integrated Messaging Async (generic)	After looking up the Pid from the Partner Directory, this Integration Flow covers both receiver and interface determination, covering special cases such as point-to-point scenarios.
Partner Directory entry – alternative partner	PIP_Samples_Scenario_5	Partner Directory	By looking up the combination of sender system and sender interface, the PID is determined as name of the scenario.
Partner Directory entry – string parameter	PIP_Samples_Scenario_5	Partner Directory	For the PID, this entry holds the string parameters needed for point-to-point receiver and interface determination.
JMS queue	PIPQ04	Outbound queue	The JMS queue holds the message until it is taken by the next Integration Flow and eventually handles retries.
Integration Flow generic	Pipeline v2 Generic Step06 – Outbound Processing	Outbound (generic)	This Integration Flow prepares the message to be sent out and calls the scenario-specific ProcessDirect address.
Integration Flow scenario-specific	PIPSamplesScenario5_Step07_RCV1_IF1 (custom name)	Outbound (scenario-specific)	This Integration Flow is called via ProcessDirect adapter. If necessary, scenario-specific conversion can be done here for the receiver system, before the message is sent out of Cloud Integration.

You might be wondering why the Integration Flows cover step01, step02, step06, and step07. This is due to historical reasons, steps 02, 04, and 05 are now all covered by Integration Flow “Pipeline v2 Generic Step02 – Integrated Messaging Runtime Async” and step03 is an optional scenario-specific Integration Flow if inbound conversion like JSON to XML or CSV to XML is needed (the latter one is shown in the picture of architecture with the name “Inbound Conversion (scenario-specific)”). With that, let’s start step by step with setting up the Pipeline in your tenant.

Copy standard packages from SAP Business Accelerator Hub

In total, there are four active packages related to the Pipeline. For the initial setup, however, you only need to copy two of these packages to your Cloud Integration tenant:

For that, find the packages in the “Discover > Integrations” area of your tenant and simply copy both packages to the tenant.

Deploy generic Integration Flows

From these packages, only two Integration Flows need to be deployed to get started.

Pipeline v2 Generic Step02 – Integrated Messaging Runtime Async from package “Cloud Integration Pipeline – Generic Pipelines”
Pipeline v2 Generic Step06 – Outbound Processing from package “Cloud Integration Pipeline – Generic Outbound”

This can be done in the “Design > Integrations and APIs” area of the same tenant. The default configuration of the Integration Flows is sufficient; you can just deploy them both without any changes.

Once these Integration Flows are deployed, you can check which JMS queues have been created in the background. For that, go to “Monitor > Integrations and APIs > Message Queues”. The default queues are “PIPX01” and “PIPQ04”, both come with a dead letter queue “PIPX01_DLQ” and “PIPQ04_DLQ” in which the message ends up if the number of retries have been exceeded. (Additionally, you might see “PIPQ01”, which used to be the old default queue. When using Integration Flow “Pipeline v2 Generic Step02 – Integrated Messaging Runtime Async”, the default queue is “PIPX01”.)

Create and deploy scenario-specific Integration Flows

Generally, these scenario-specific Integration Flows would either be generated by the migration tool, or you would copy them from the templates package, or you would create them manually, as they usually don’t contain too much logic.

For this sample, you can import the sample package for scenario 5 to your tenant. In “Design > Integrations and APIs”, import the package from your local device. Without any modification needed, deploy the following artifacts:

PIPSamplesScenario5_Step01
PIPSamplesScenario5_Step07_RCV1_IF1

Additionally, there is a little helpers package which you can import to your tenant to deploy this Integration Flow simulating a receiver system:

PIP_Mocked_Receiver

Setup Partner Directory entries

To setup the Partner Directory entries required for your first scenario, you can use the Partner Directory UI. To access it, select “Monitor > Integrations and APIs > Partner Directory” in your tenant. In addition, there is a Pipeline-specific accelerator tool which helps you to set up your Partner Directory entries. You can learn more about this tool in the upcoming chapter.

You’ll see that all Partner Directory entries (no matter if it’s alternative partners, string parameters, or binary parameters) have the same partner ID, which holds together the scenario. For a point-to-point scenario, we need two string parameters for receiver and interface determination, all others (like MaxJMSRetries in that case) are optional and can be used to influence the message processing behavior at runtime.

Alternative partner:

{
    "Pid": "PIP_Samples_Scenario_5",
    "Agency": "Sender_51",
    "Scheme": "SenderInterface",
    "Id": "SalesOrder.Create"
}

String parameters:

{
    "Pid": "PIP_Samples_Scenario_5",
    "Id": "MaxJMSRetries",
    "Value": "2"
}

{
    "Pid": "PIP_Samples_Scenario_5",
    "Id": "receiverDetermination",
    "Value": "Receiver_51"
}

{
    "Pid": "PIP_Samples_Scenario_5",
    "Id": "interfaceDetermination_Receiver_51",
    "Value": "/PIP/Step07/Samples/Scenario_5/Receiver_51/IfIdx1"
}

Run your first scenario

With this setup, you’re able to run your first scenario through Pipeline for Cloud Integration. For that, prepare an HTTP message in the HTTP client of your choice, e.g. Postman or Bruno.

### trigger sample scenario 5
POST https://{{host}}/http/PIP/Step01/Samples/Scenario_5
Authorization: usual authentication to call an Integration Flow, e.g. basic authentication or OAuth using a service key from SAP BTP
Content-Type: application/xml
SAP_Sender: Sender_51
SAP_SenderInterface: SalesOrder.Create
xPipeline: true

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:pi="http://pi-elevation.bootcamp.com">
    <soapenv:Header/>
    <soapenv:Body>
        <pi:MT_SalesOrder_0001>
            <salesOrder>
                <orderNumber>50001</orderNumber>
                <orderDate>10/01/2023</orderDate>
                <customer>
                    <firstName>Amruta</firstName>
                    <lastName>Kamble</lastName>
                    <street>Hauptstrasse</street>
                    <number>89</number>
                </customer>
                <items>
                    <itemNumber>Test</itemNumber>
                    <material>Test_material</material>
                    <quantity>5</quantity>
                    <price>550</price>
                </items>
            </salesOrder>
        </pi:MT_SalesOrder_0001>
    </soapenv:Body>
</soapenv:Envelope>

Under “Monitor > Integrations and APIs > Monitor Message Processing”, you can check how your message was processed at runtime. There, you should see 5 new messages with status “Completed”. They all have the same correlation ID; you can filter by this correlation ID to only display the messages corresponding to the last run of your scenario. With that, you can see that the steps 01, 02, 06, and 07 of the Pipeline were called. At runtime, your Partner Directory entries have been accessed by step02. For each entry, there are details on the right-hand side such as sender and receiver as well as custom headers set by the Pipeline.

Congratulation, your first scenario is running! This is almost the simplest option of running the Pipeline, yet it is heavily used in practice. To build on that, you can take a look at the next scenario using content-based routing. Since you have now initially set up the pipeline, new scenarios will be set up with even fewer steps.

Scenario with XSLT for content-based routing (sample 1A)

The following example is sample scenario 1A (PID: PIP_Samples_Scenario_1A) of the sample scenarios by @alex_bundschuh. As explained above, you need 4 Integration Flows for that, as well as 2 (automatically created) JMS queues and some Partner Directory entries. The following table shows how this fits together (in order of occurrence at runtime):

Type	Technical name in standard	Name in picture of architecture	Purpose
Integration Flow scenario-specific	PIPSamplesScenario1_Step01 (custom name)	Inbound (scenario-specific)	This Integration Flow receives the incoming message and puts it to the generic JMS queue for decoupling.
JMS queue	PIPX01	Inbound X queue	The JMS queue holds the message until it is taken by the next Integration Flow and eventually handles retries.
Integration Flow generic	Pipeline v2 Generic Step02 – Integrated Messaging Runtime Async	Integrated Messaging Async (generic)	After looking up the Pid from the Partner Directory, this Integration Flow covers both receiver and interface determination, covering special cases such as point-to-point scenarios.
Partner Directory entry – alternative partner	PIP_Samples_Scenario_1A	Partner Directory	By looking up the combination of sender system and sender interface, the PID is determined as name of the scenario.
Partner Directory entry – string parameter	PIP_Samples_Scenario_1A	Partner Directory	Based on the Pid, the Pipeline checks if a strung parameter with Id InboundConversionEndpoint is set in the Partner Directory, which is done for this scenario.
Integration Flow scenario-specific	PIPSamplesScenario1_Step03 (custom name)	Inbound conversion (scenario-specific)	Based on the ProcessDirect address set in the Partner Directory, a custom Integration Flow is called for inbound conversion. In this scenario, this is done by a JSON to XML converter.
Partner Directory entry – binary parameter	PIP_Samples_Scenario_1A	Partner Directory	For the PID, this entry holds the corresponding XSLT mapping for content-based routing.
JMS queue	PIPQ04	Outbound queue	The JMS queue holds the message until it is taken by the next Integration Flow and eventually handles retries.
Integration Flow generic	Pipeline v2 Generic Step06 – Outbound Processing	Outbound (generic)	This Integration Flow prepares the message to be sent out and calls the scenario-specific ProcessDirect address.
Integration Flow scenario-specific	PIPSamplesScenario1_Step07_RCVx_IFx (custom name)	Outbound (scenario-specific)	This Integration Flow is called via ProcessDirect adapter. If necessary, scenario-specific conversion can be done here for the receiver system, before the message is sent out of Cloud Integration.

Copy standard packages from SAP Business Accelerator Hub

As these packages are reused and we have already done this for our first scenario, we don’t need to do anything in this step.

Deploy generic Integration Flows

These are the same Integration Flows which we have deployed earlier for the first scenario, so no action required for now.

Create and deploy scenario-specific Integration Flows

For this sample, you can import the sample package for scenario 1A to your tenant. In “Design > Integrations and APIs”, import the package from your local device. Without any modification needed, deploy the following artifacts (in this scenario, step07 relies on a message mapping, which also needs to be deployed):

PIPSamplesScenario1_Step01
PIPSamplesScenario1_Step03
PIPSamplesScenario1_Step07_RCV2_IF1
mm_item_to_order

Setup Partner Directory entries

This time, for content-based routing, we need an XSLT as binary parameter for receiver and interface determination in addition to alternative partners and string parameters. These entries can again be created in the Partner Directory UI or with the accelerator tool.

Alternative partner:

{
    "Pid": "PIP_Samples_Scenario_1A",
    "Agency": "Sender_1A",
    "Scheme": "SenderInterface",
    "Id": "PurchaseOrderItem.Create"
}

String parameters:

{
    "Pid": "PIP_Samples_Scenario_1A",
    "Id": "MaxJMSRetries",
    "Value": "1"
}

{
    "Pid": "PIP_Samples_Scenario_1A",
    "Id": "InboundConversionEndpoint",
    "Value": "/PIP/Step03/Samples/Scenario_1"
}

Binary parameters:

You can save the following XSLT as .xsl file on your local device and then upload it in the Partner Directory UI. Especially when dealing with Binary parameters, the recommendation is to use the accelerator tool, as this aims to simplify your interaction with the Partner Directory for the Pipeline. Using this tool as described in the chapter below, you don’t have to create the XSLT from scratch on your own, but the tool can generate it for you based on a tabular input – make sure to check the tool out!

{
    "Pid": "PIP_Samples_Scenario_1A",
    "Id": "receiverDetermination"
    "ContentType": "xsl",
    "Value": upload the following XSLT from your local device
}

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="3.0">
<xsl:param name="dc_country" />
<xsl:template match="/">
        <ns0:Receivers xmlns:ns0="http://sap.com/xi/XI/System">
            <ReceiverNotDetermined>
                <Type>Error</Type>
                <DefaultReceiver />
            </ReceiverNotDetermined>
            <xsl:if test="/*:Item/Category = 'Keyboards'">
                <Receiver>
                    <Service>Receiver_11</Service>
                    <Interfaces>
                        <xsl:if test="/*:Item/Quantity = '10'">
                            <Interface>
                                <Index>1</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_11/IfIdx1</Service>
                            </Interface>
                        </xsl:if>
                        <xsl:if test="/*:Item/CurrencyCode = 'EUR'">
                            <Interface>
                                <Index>2</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_11/IfIdx2</Service>
                            </Interface>
                        </xsl:if>
                        <xsl:if test="/*:Item/Quantity != '10'">
                            <Interface>
                                <Index>3</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_11/IfIdx3</Service>
                            </Interface>
                        </xsl:if>
                    </Interfaces>
                </Receiver>
            </xsl:if>
            <xsl:if test="(/*:Item/Category = 'Keyboards') or (/*:Item/Category = 'Software')">
                <Receiver>
                    <Service>Receiver_12</Service>
                    <Interfaces>
                        <xsl:if test="$dc_country = 'DE'">
                            <Interface>
                                <Index>1</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_12/IfIdx1</Service>
                            </Interface>
                        </xsl:if>
                        <xsl:if test="$dc_country != 'DE'">
                            <Interface>
                                <Index>2</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_12/IfIdx2</Service>
                            </Interface>
                        </xsl:if>
                    </Interfaces>
                </Receiver>
            </xsl:if>
            <xsl:if test="(/*:Item/Category = 'Keyboards') and (/*:Item/ProductName != 'XXXX')">
                <Receiver>
                    <Service>Receiver_13</Service>
                    <Interfaces>
                        <xsl:if test="/*:Item/Quantity = '10'">
                            <Interface>
                                <Index>1</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_13/IfIdx1</Service>
                            </Interface>
                        </xsl:if>
                        <xsl:if test="/*:Item/CurrencyCode = 'EUR'">
                            <Interface>
                                <Index>2</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_13/IfIdx2</Service>
                            </Interface>
                        </xsl:if>
                        <xsl:if test="/*:Item/Quantity != '10'">
                            <Interface>
                                <Index>3</Index>
                                <Service>/PIP/Step07/Samples/Scenario_1/Receiver_13/IfIdx3</Service>
                            </Interface>
                        </xsl:if>
                    </Interfaces>
                </Receiver>
            </xsl:if>
        </ns0:Receivers>
    </xsl:template>
</xsl:stylesheet>

Alternatively, in the accelerator tool, your scenario would look like below. Without the need to deal with the syntax of the XSLT, you can focus on entering the XPath conditions and receiver system / receiver interface, to generate the XSLT from your input. For more details on this accelerator tool, please find the next chapter.

Run your second scenario

### trigger sample scenario 1A
POST https://{{host}}/http/PIP/Step01/Samples/Scenario_1?country=DE
Authorization: usual authentication to call an Integration Flow, e.g. basic authentication or OAuth using a service key from SAP BTP
Content-Type: application/json
SAP_Sender: Sender_1A
SAP_SenderInterface: PurchaseOrderItem.Create
xPipeline: true

{
    "ns0:Item":{
        "@PurchaseOrderNumber":"1A9201",
        "@OrderDate":"2019-05-06",
        "@ItemNumber":"10",
        "ProductId":"HT-XXXX",
        "ProductName":"XXXX",
        "Category":"Software",
        "Quantity":"10",
        "CurrencyCode":"EUR",
        "Price":"799.00"
    }
}

Under “Monitor > Integrations and APIs > Monitor Message Processing”, you can again check how your message was processed at runtime, ideally filtered by the correlation ID. This time, step03 has also be called for scenario-specific inbound conversion, as this is set as a string parameter in the Partner Directory.

With that, also your second scenario is running! This is just the beginning – there are lots of more options and sample scenarios available. You can easily set them up with a Postman collection provided – there are different messages you can test for each scenario, e.g., for scenario 1A, there is a message prepared where you can observe receivers and interfaces splits.

When further discovering the Pipeline, our strong recommendation is to not edit the generic Integration Flows but stay in the standard to easily get updates. Most of the use cases can be implemented with the standard, as the Pipeline keeps evolving covering more and more different scenarios.

Accelerator Tool

As you saw during the initial setup, we deal with XSLT mappings for content-based routing. To make maintenance of XSLT, replication of Partner Directory content, and other topics related to Partner Directory easier, there is an accelerator tool specifically developed for Pipeline for Cloud Integration. The idea is to use this SAP open source tool in combination with our standard UI. Feel free to give it a try, there is also a session available from Devtoberfest 2025 which shows the setup step by step.

Link Collection

SAP Help

Standard documentation as part of migration guide from SAP PO: https://help.sap.com/docs/migration-guide-po/migration-guide-for-sap-process-orchestration/pipeline-concept

Partner Directory entries for the Pipeline: https://help.sap.com/docs/migration-guide-po/migration-guide-for-sap-process-orchestration/using-partner-directory-in-pipeline-concept

Partner Directory UI: https://help.sap.com/docs/cloud-integration/sap-cloud-integration/managing-partner-directory-entries

Introduction of the Pipeline at Devtoberfest: https://www.youtube.com/watch?v=LFfW8rnm4fU

SAP Community (recent blogs after package split)

Version 1.0.0: https://community.sap.com/t5/integration-blog-posts/new-integration-packages-for-the-pipeline-for-cloud-integration/ba-p/14175339

Package split
Custom preprocessing exit: https://community.sap.com/t5/integration-blog-posts/new-feature-for-the-pipeline-for-cloud-integration-custom-preprocessing/ba-p/14199571
New templates for enhancing the custom receiver determination: https://community.sap.com/t5/integration-blog-posts/new-templates-for-the-pipeline-for-cloud-integration-enhancing-the-custom/ba-p/14199651

Version 1.0.1: https://community.sap.com/t5/integration-blog-posts/introducing-a-new-version-1-0-1-of-the-pipeline-for-cloud-integration/ba-p/14257263

We now support a generic IDoc outbound flow to standardize and ease the configuration of IDoc outbound scenarios: https://community.sap.com/t5/integration-blog-posts/generic-idoc-outbound-flow-in-cloud-integration-pipeline/ba-p/14269062
We now support a generic XI outbound flow to standardize and ease the configuration of XI outbound scenarios: https://community.sap.com/t5/integration-blog-posts/generic-xi-outbound-flow-in-cloud-integration-pipeline/ba-p/14269061
We have improved the support for sender and receiver parties.
We have improved the support for receiver-specific queues and the definition of the queue for receiver-specific outbound processing.
In a sender wildcard scenario, we now support inbound conversion per sender.
Non-XML payloads are encoded before storing in an exchange property to avoid that the payload gets corrupted when reading from the exchange property again.
For some scenarios, you have the option to run scenarios in the pipeline without the need of the Partner Directory: https://community.sap.com/t5/integration-blog-posts/run-pipeline-for-cloud-integration-without-the-partner-directory/ba-p/14257311

December 2025 shipment: https://community.sap.com/t5/integration-blog-posts/new-fixes-and-features-in-the-pipeline-for-cloud-integration-package-with/ba-p/14294379

We have changed the duplicate handling for the generic XI and IDoc inbound processing flows as follows: In case of duplicates, the message processing logs end with Completed instead of Escalated to avoid that an http error code 500 is returned to the sending system.
For testing purposes, you can now switch off the duplicate check for the generic IDoc inbound processing flow. By default, the duplicate handling is enabled.
The XI inbound processing flow now supports dynamic adapter-specific headers. A feature which has just recently be shipped with an enhancement of the XI adapter. See Dynamic Headers.
An Exactly Once In Order (EOIO) check has been added to the IDoc inbound processing flow. Since we do not support EOIO in the Pipeline yet, the message goes into an error.
The definition of alternative partners has been extended to be able to determine partner ID based on sender component name, sender interface name, and sender interface namespace. This was supported before for XI and IDoc inbound scenarios, now you can do this for any scenario if required. If not, you can stick to the option to determine partner ID based on sender component name and sender interface name only.
We fixed an issue with a wrong reference to a script in the Pipeline v2 Generic Step02 - Integrated Messaging Runtime Sync flow.
The allowed headers list of the template flow Pipeline v2 Template - Custom Exit has been extended to support the header SapQualityOfService. This way, you have the option to use or change the SapQualityOfService header in a custom pre-processing flow. For instance, you do not like to change the EOIO setup of an XI interface in the sender system but still like to process the messages in the Pipeline accepting EO delivery as long as the Pipeline doesn't support EOIO. So you can call the custom exit flow right at the beginning of the generic XI inbound flow and switch from ExactlyOnceInOrder to ExactlyOnce.
A new template Pipeline v2 Template Step07 - Outbound Processing Point-to-Point to Generic XI Outbound has been added that allows you to create a scenario-specific outbound processing flow that calls the generic XI outbound processing flow. The template can be used for both synchronous and asynchronous communication.
A new template Pipeline v2 Template Step07 - Outbound Processing Point-to-Point to Generic IDoc Outbound has been added that allows you to create a scenario-specific outbound processing flow that calls the generic IDoc outbound processing flow.

SAP Business Accelerator Hub

Package “Cloud Integration Pipeline - Generic Pipelines”: https://hub.sap.com/package/CloudIntegrationPipelineGenericPipelines/integrationflow

Package for step02 (including integration messaging runtime async and sync), as well as old step02, step04, and step05
Integration flow “Pipeline v2 Generic Step02 - Integrated Messaging Runtime Async”: https://hub.sap.com/integrationflow/com.sap.integration.cloud.pipeline.v2.generic.step02.integrated.messaging.async

Package “Cloud Integration Pipeline - Generic Outbound”. https://hub.sap.com/package/CloudIntegrationPipelineGenericOutbound/integrationflow

Package for step06 and step08 (latter ones are optional for generic XI or IDoc outbound)
Integration flow “Pipeline v2 Generic Step06 - Outbound Processing”: https://hub.sap.com/integrationflow/com.sap.integration.cloud.pipeline.v2.generic.step06.outbound.processing

Package “Cloud Integration Pipeline - Generic Inbound”: https://hub.sap.com/package/CloudIntegrationPipelineGenericInbound/integrationflow

Package for generic XI or IDoc entry point (optional)

Package “Cloud Integration Pipeline – Templates”: https://hub.sap.com/package/CloudIntegrationPipelineTemplates/integrationflow

Package with different Integration Flows for different steps and scenarios which can be customized based on your needs

Data Store Extension

Version 1.0.0: https://community.sap.com/t5/integration-blog-posts/process-integration-pipeline-extension-restart-via-data-store/ba-p/14153116

Version 1.0.1: https://community.sap.com/t5/integration-blog-posts/new-ci-pipeline-restart-extension-features-supporting-new-pipeline-package/ba-p/14230547

Supports new integration packages for the Pipeline for Cloud Integration and allows flexible linkage of Generic Pipeline copies to the Pipeline Stages.
Enhanced Restart Job Integration Flow:
Generic Job Profile to restart all integration scenarios defined in the Partner Directory through the Pipeline Framework.
New configuration options to persist the Job Log.
New Integration Flow "Pipeline API - Restart Job Log" to retrieve both the Restart Job run list and detailed log data (if log persistence is enabled).
Improved configuration and monitoring: New parameters (such as "NotOlderThanHours" for Restart Job), several bug fixes, enriched monitoring headers, and better exception handling.

Accelerator Tool

GitHub: https://github.com/SAP-samples/integration-suite-partner-directory-accelerator-for-pipeline-concept

Blog: https://community.sap.com/t5/integration-blog-posts/partner-directory-accelerator-tool-for-pipeline-concept/ba-p/14095019

Devtoberfest: https://www.youtube.com/watch?v=m51z53fc1c4

History – older SAP Community blog posts before package split

Version 1.0.0 – initial release in March 2024: https://community.sap.com/t5/technology-blog-posts-by-sap/introducing-the-new-pipeline-concept-in-cloud-integration/ba-p/13639651

Applying the pipeline concept for an integration scenario in general: https://community.sap.com/t5/technology-blog-posts-by-sap/applying-the-pipeline-concept-for-an-integration-scenario-in-general/ba-p/13640018
Applying the pipeline concept for a multicast integration scenario: https://community.sap.com/t5/technology-blog-posts-by-sap/applying-the-pipeline-concept-for-a-multicast-integration-scenario/ba-p/13641417
Applying the pipeline concept for a point-to-point integration scenario: https://community.sap.com/t5/technology-blog-posts-by-sap/applying-the-pipeline-concept-for-a-point-to-point-integration-scenario/ba-p/13641474
Applying the pipeline concept for an interface split scenario with one receiver message type: https://community.sap.com/t5/technology-blog-posts-by-sap/applying-the-pipeline-concept-for-an-interface-split-scenario-with-one/ba-p/13641560
Applying the pipeline concept for an interface split scenario with multiple receiver message types: https://community.sap.com/t5/technology-blog-posts-by-sap/applying-the-pipeline-concept-for-an-interface-split-scenario-with-multiple/ba-p/13641662
Applying the pipeline concept for an interface split scenario with order at runtime flag set: https://community.sap.com/t5/integration-blog-posts/applying-the-pipeline-concept-for-an-interface-split-scenario-with-order-at/ba-p/13641691

Version 1.0.5: https://community.sap.com/t5/integration-blog-posts/latest-pipeline-concept-enhancements-custom-error-handling-and-others/ba-p/13757664

Extension for custom error handling
In generic IDoc inbound processing flow, display list of IDoc numbers in case of IDoc bulk messages
For IDoc inbound, sender interface is calculated as a combination of MESTYP, IDOCTYP and CIMTYP
Supporting test mode via testMode header in the allowed headers configuration
In standard error handling, copied messages from the dead letter queue are switched to DEBUG log level

Version 1.0.6: https://community.sap.com/t5/integration-blog-posts/new-pipeline-concept-features-new-partner-id-definition-alternative-partner/ba-p/13787400

Revised partner id approach due to lengths restrictions of the partner id
Option to use alternative partner in case of sender wildcard scenarios and to overcome partner id restrictions
Changed default max retry to 5 instead of unlimited retry
For messages in test mode, failed messages are not put into retry
For generic integration flows, adapter parameters were externalized
Option to configure message end event type in case of message stored in dead letter queue, default is Escalated
Option to bypass receiver determination and interface determination steps in case of Point-to-Point pattern
Option to configure a pipeline JMS queue prefix which makes configuration of queue names easier if you create another set of generic integration flow

Version 1.0.7: https://community.sap.com/t5/integration-blog-posts/new-pipeline-concept-features-supporting-custom-header-properties-and/ba-p/13894048

Support for custom header properties
Support for dynamic configuration parameters

Version 1.0.8: https://community.sap.com/t5/integration-blog-posts/new-pipeline-concept-features-more-bypass-options-and-custom-extensions/ba-p/13955138

Option to combine receiver and interface determination in one single XSLT mapping for an improved runtime behavior
Option to bypass interface determination pipeline step in case of Recipient List pattern without interface split
Option to bypass receiver determination pipeline step in case of interface split scenarios with one single receiver only
Supporting header-based XSLT routing conditions if message body is non-XML
Extension for custom receiver determination instead of XSLT from Partner Directory
Extension for custom interface determination instead of XSLT from Partner Directory
New pipeline processing log providing more details if message is stored to the dead letter queue
Fixed standard retry handling for generic integration flows with splitter to avoid message duplicates

Version 1.0.9: https://community.sap.com/t5/integration-blog-posts/new-pipeline-concept-features-integrated-runtimes-and-supporting-landscape/ba-p/14000234

Supporting different tenant stages, e.g., DEV, QA, PRD
New integrated messaging runtime "Pipeline Generic Step02 - Integrated Messaging Runtime Async" combining inbound conversion and receiver/interface determination in one pipeline step
New integrated messaging runtime "Pipeline Generic Step02 - Integrated Messaging Runtime Sync" for handling synchronous Content-Based-Routing scenarios
New template "Pipeline Template Step01 - Inbound Processing Synchronous" for scenario-specific synchronous inbound processing
New template "Pipeline Template Step07 - Outbound Processing Synchronous" for scenario-specific synchronous outbound processing
Generic inbound processing for XI supports both asynchronous and synchronous messaging
Failed test messages end with escalation instead of completed
Added custom error handling for generic XI and IDoc inbound flows

Version 1.0.10: https://community.sap.com/t5/integration-blog-posts/new-pipeline-concept-features-supporting-service-interface-operations-and/ba-p/14049909

Supporting service interface operations
Updated the allowed header list
Have done script optimizations
Converted the XI message ID to upper case

Version 1.0.11: https://community.sap.com/t5/integration-blog-posts/new-pipeline-for-cloud-integration-features-with-version-1-0-11/ba-p/14093335

The search based on IDoc number in the message monitor has been improved by removing the leading zeros from IDoc number in ApplicationID and custom header properties.
For the XI inbound flow, the partner ID is determined also based on service interface namespace in addition to system name and service interface name.
We fixed an error with wrong inbound queue in case of custom error handling for the integrated messaging runtime.
We introduced a configuration option to switch off the option to determine the partner ID using the so called "tilde option". The default is that this option is switched off.
We changed the default inbound processing queue of the XI inbound and the IDoc inbound flows from PIPQ01 to PIPX01 so that by default the integrated messaging runtime is used.

Version 1.0.12: https://community.sap.com/t5/integration-blog-posts/new-pipeline-concept-features-with-version-1-0-12-improved-handling-of/ba-p/14112869

Improved handling of custom header properties
New processing option: Using exchange properties
Previous Approach Still Supported: Manually Setting customHeaderProperties

Support by migration tool: https://community.sap.com/t5/integration-blog-posts/migration-tooling-now-supporting-migration-via-the-pipeline-approach/ba-p/14073721

SAP CPI: WSDL Headers Not Visible After Upload? Here’s the Fix

2026-02-12T08:17:18.687000+01:00

Introduction : When working with shared WSDLs in SAP CPI, SOAP headers are sometimes not fetched correctly after the WSDL upload. Even though the same WSDL works for both source and target systems, CPI may fail to display the headers. This blog explain a simple one-line fix to resolve the issue.

Body :

When performing message mapping in SAP CPI, it only considers elements defined inside the <schema> section of the WSDL. Any SOAP headers that exist outside this scope—like custom or extended headers won’t be recognized by CPI. This can be confusing, because the WSDL may work perfectly in both your source and target systems, yet CPI doesn’t display the headers, making them impossible to map.

CPI parses only the schema-defined elements. Headers defined outside the schema or not explicitly referenced are ignored,

We need to add <xs:element ref="emf:EMFHeader" /> element to the source and target schema as shown in the shared screenshot.

Step-by-Step Implementation

Open the source schema in CPI.
Locate the <xs:schema> section.
Add <xs:element ref="emf:EMFHeader" /> at the appropriate position.
Repeat the same process in the target schema.
Save and reopen your mapping

After these steps, all previously hidden headers should be fully visible, ready for mapping.

Summary : In SAP CPI, SOAP headers may not appear in message mapping when using shared WSDLs because CPI only reads the elements defined in the schema. And adding <xs:element ref="emf:EMFHeader" /> to both source and target schemas makes the headers visible for mapping.

Beyond the Workhorse: What I’ve Learned Modernizing U.S. Utilities

2026-02-12T12:08:47.681000+01:00

Introduction

In my decade-plus of architecting for major U.S. utilities—from the high-pressure power corridors of the Northeast to the expanding grids in the South—I’ve seen a shift in what "success" looks like. For a long time, the goal was simple: Keep the lights on. But as we hit 2026, that benchmark is failing. Aggressive decarbonization and the wave of decentralized energy (DERs) like rooftop solar and EV charging are putting a massive strain on our trusted workhorse, SAP IS-U.

1. The Reality Check: When the "Standard" Hits the Ceiling

IS-U is a dependable system for meter-to-cash, but it was designed for a world of predictable, one-way power flow. In my recent field work, I've kept hitting three "Legacy Burdens":

The Batch Job Bottleneck: Waiting for overnight runs to understand grid load is a non-starter in a smart-grid world.
The "Spaghetti" Problem: Years of custom ABAP "Z-code" have made some environments so brittle that a simple integration takes months of testing.
The 2027 Clock: S/4HANA migration isn't just an upgrade; it’s a race to preserve business logic buried in 20 years of customizations.

2. My Architecture Philosophy: The "Clean Core" Mindset

The biggest shift I’ve driven in recent programs is moving away from the instinct to "customize inside the ERP." By adopting a Clean Core strategy, we treat SAP BTP as our innovative layer.

This keeps the S/4HANA core stable. While the core handles the heavy transactions, the "brain" (SAP BTP) manages the fast-changing logic. This gives us speed without risking the stability of the billing engine.

3. Practical Field Notes: Real Impact with BTP

This isn't theoretical. I’ve seen this move the needle in North American programs, including work with one of the largest utility companies in north America:

Integration Suite: This is the "glue" connecting AMI, weather data, and regulatory feeds without brittle, point-to-point interfaces.
Hindsight to Foresight: We are now using SAP Datasphere to identify transformer stress before it leads to failure.
The Human Element: Customer Satisfaction (CSAT) rises when we use BTP to send proactive usage alerts mid-month.

4. A Deep Dive: The Automated Reconnection Case

I’m particularly proud of rebuilding the customer reconnection process. Traditionally, this was a multi-day headache. We turned it into a real-time event.

How we built it:

Payment Trigger: Customer pays via an app (SAP Build).
Instant Clearing: SAP Integration Suite pushes the update to FI-CA.
Decision & Execution: We applied a 3-layered governance protocol to ensure only "Safe-to-Reconnect" signals hit the AMI smart meters.

4. Lessons from the Trenches: What Leaders Need to Know

This isn't just about clicking buttons in the BTP cockpit; it's a cultural shift. If you are leading a team, remember:

Close the Skill Gap: Veteran ABAP teams have the domain knowledge—help them translate that into Node.js and CAP.
Avoid "App Sprawl": Without governance, you’ll end up with a hundred disconnected micro-apps.
Data Residency: For U.S. utilities, compliance for billing data must be built into the architecture from Day 1.

Conclusion: The Future is Composed

Across the programs I’ve led, the winning pattern is clear: S/4HANA is the Heart, BTP is the Brain, and IoT/Integration is the Senses.

SAP IS-U has served us well, but the energy transition demands more agility. The question isn't if we should move to BTP—it's how quickly we can use it to stop being reactive and start being proactive.

I'd love to hear from other architects: What's the messiest "Z-code" logic you're currently trying to move out of your core? Let's discuss in the comments.

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

2026-02-12T23:29:04.379000+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 Content-Based Routing (CBR) Asynchronous pattern

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

Publish events from CAP Node.js applications to Event Mesh of Integration Suite

2026-02-13T05:19:07.232000+01:00

In this blog I’ll show how to publish events from a CAP application to SAP Integration Suite’s Event Mesh. Both the CAP application and Event Mesh are located in the same BTP subaccount. I’ll skip the setup steps for Event Mesh and focus specifically on publishing events from the CAP application.

Step 1: start by creating a new CAP Node.js application in Business Application Studio:

cds init emis-samebtp
touch srv/service.cds
touch srv/service.js

Step 2: in service.cds, define a simple service with a function that triggers an event:

service GreetingService {
  function helloEvent(to: String) returns String;
}

In service.js, implement the function to emit an event to Event Mesh:

const eventTopic = 'cap/demo/v1/sample/hello-event';

module.exports = async (srv) => {
  const messaging = await cds.connect.to('messaging');

  srv.on('helloEvent', async (req) => {
    const target = req.data.to;
    const data = { To: target, Message: 'Hello world events!' };
    
    await messaging.emit(eventTopic, data);
    req.notify(`Event sent > ${eventTopic}`);
    
    return `Hello event: ${target}`;
  });
};

Step 3: add the necessary services for authentication and messaging:

cds add xsuaa --for-production
cds add enterprise-messaging-shared --for-production

Then update your package.json to configure the messaging service:

"cds": {
  "server": { "index": true },
  "requires": {
    "[production]": {
      "auth": "xsuaa",
      "messaging": {
        "kind": "enterprise-messaging-shared",
        "publishPrefix": "stc/emis/",
        "format": "cloudevents",
        "vcap": {
          "label": "event-mesh-message-client",
          "plan": "message-client",
          "name": "emis-samebtp-messaging"
        }
      }
    }
  }
}

Step 4: generate the MTA deployment descriptor:

npm install
cds build --production
cds add mta

Edit the generated mta.yaml to ensure the resource definitions match your package.json configuration.

Step 5: run the build and deploy commands to push your application to BTP.

cds build
cf deploy mta_archives/your-archive.mtar

Step 6: Testing the Integration

Navigate to the Event Mesh section in SAP Integration Suite. Select a queue and subscribe to the topic "stc/emis/cap/demo/v1/sample/hello-event".

Then use the OAuth client credentials from XSUAA to call your CAP service "https://<your-hostname>:443/odata/v4/greeting/helloEvent?to=Mark".

If everything is configured correctly, you’ll receive a response and see the event appear in your Event Mesh queue.

This setup is ideal for scenarios where you need real-time eventing between BTP applications and other SAP or non-SAP systems. Give it a try and let me know how it goes in the comments!

Receive Events from Event Mesh of Integration Suite to CAP Node.js Applications

2026-02-13T13:02:39.358000+01:00

In a previous blog, we covered how to publish events from a CAP application to Event Mesh of Integration Suite. This blog post is the natural counterpart. Here, we'll walk through the steps to configure a CAP Node.js application to consume and process events from the Event Mesh of SAP Integration Suite (often referred to as EMIS). Both the CAP application and Event Mesh are in the same BTP subaccount, but it also works if they are provisioned in different BTP subaccounts.

This guide skips the initial Event Mesh provisioning and focuses on the application development, configuration, and deployment steps for event consumption.

Step 1: start by creating a new CAP Node.js application in Business Application Studio

cds init emis-consume
cd emis-consume
touch srv/consume-event.cds
touch srv/consume-event.js

Step 2: Define the Service Handler in srv/consume-event.cds

service ConsumeEvent @(path: '/consume-event') {
    // Entity definitions are optional for a pure event consumer service
}

Step 3: Define the event handling logic in srv/consume-event.js

const cds = require('@sap/cds');

module.exports = cds.service.impl(async function () {
    const messaging = await cds.connect.to('messaging');

    // Handle events in "$namespace/hello-world" topic
    await messaging.on('hello-world', (msg) => {
        console.log('> hello-world event received: ', msg.data);
    });

    // Handle events in "$namespace/greeting" topic
    await messaging.on('greeting', (msg) => {
        console.log('> greeting event received: ', msg.data);
    });
});

Step 4: add the necessary services for authentication and messaging:

cds add xsuaa --for production
cds add enterprise-messaging-shared --for production

Then update your package.json to configure the messaging service:

"cds": {
  "requires": {
    "production": {
      "auth": "xsuaa",
      "messaging": {
        "kind": "enterprise-messaging-shared",
        "publishPrefix": "$namespace/",
        "subscribePrefix": "$namespace/",
        "format": "cloudevents",
        "vcap": {
          "label": "user-provided",
          "name": "emis-consume-messaging-ups"
        },
        "queue": {
          "name": "$namespace/incoming"
        }
      }
    }
  }
}

Step 5: Prepare the MTA Deployment Descriptor

npm install
cds build --production
cds add mta

You must then edit the generated mta.yaml file to ensure the resource definitions match the configuration in package.json. Specifically, verify that the emis-consume-messaging resource points to the correct user-provided service.

Step 6. Crucial Workaround: Mocking the Management Endpoint

During deployment, cloud foundry runtime attempts to create the queue defined in package.json via a management URI provided by Event Mesh. Currently, this can fail with the error: "Requested route does not match any of the defined routes."

Workaround:

1). create event mesh service instance & key

service name: SAP Integration Suite, Event Mesh
service plan: message-client
name: emis-consume-messaging

With below parameters:

{
    "namespace": "stc/emis/consume",
    "options": {
        "management": false,
        "messaging": false,
        "messagingrest": false
    },
    "resources": {"units": 10},
    "rules": {
        "queueRules": {
            "publishFilter": ["${namespace}/*"],
            "subscribeFilter": ["${namespace}/*"]
        },
        "topicRules": {
            "publishFilter": ["${namespace}/*"],
            "subscribeFilter": ["${namespace}/*"]
        }
    }
}

Then create a service key and copy its value.

2). Modify the service-key by replacing its management uri with a mock endpoint. The mockend endpoint should always return 201 when receiving PUT request, for example,

PUT https://stc-mock.free.beeceptor.com/hub/rest/api/v1/management/messaging/queues/testqueue

3). Create a User-Provided Service in your Cloud Foundry space using this modified service key (emis-consume-messaging-ups). This is the service your CAP application will bind to.

4). Login to Event Mesh of Integration Suite >> Configure, create the queue stc/emis/consume/incoming

5). add below topic subscription to the queue

stc/emis/consume/hello-world
stc/emis/consume/greeting

This configuration ensures any event published to these topics is delivered to your application's queue.

Step 7: Build and Deploy

mbt build
cf deploy mta_archives/emis-consume_1.0.0.mtar

Step 8: Testing

Go to the Test section of your Event Mesh in the Integration Suite. Send test events to the topics hello-world and greeting.

In the BTP cloud foundry cockpit, navigate to your deployed application and check its logs.

You have successfully configured a CAP Node.js application to act as an event consumer from Event Mesh of SAP Integration Suite. Although we had to implement a workaround due to a current compatibility issue between CAP's queue management and Event Mesh's Management API, the overall pattern remains sound and functional. Hopefully, SAP will address this compatibility issue soon, making the developer journey even smoother.

Migrating from ASANWEE to ASAAEMEE: From SAP Event Mesh to SAP Advanced Event Mesh

2026-02-13T13:26:20.613000+01:00

Introduction

Event-driven architectures are increasingly shaping modern SAP landscapes. Many customers started their journey using the NetWeaver add-on for event enablement (component ASANWEE) to publish business events from their SAP systems to SAP Event Mesh.

While this setup works well for basic SAP BTP scenarios, growing enterprise requirements — such as hybrid integration, advanced routing, and high availability — often require a more powerful event broker.

This is where the Event Add-On for ERP (ASAAEMEE) in combination with SAP Advanced Event Mesh becomes highly relevant.

This article applies to:

SAP ERP (ECC 6.0 and higher)
SAP S/4HANA (on-premise, private cloud, all versions)

and explains the technical migration steps from component ASANWEE to ASAAEMEE.

Prerequisits:

NetWeaver Add-On for Event Enablement is installed (component ASANWEE).
Event Add-on for ERP is installed (component ASAAEMEE, installed on top of ASANWEE).
SAP Advanced Event Mesh service instance is provisioned.
Service Key from the BTP is available.
Ensure that the erp_event_add_on entitlement is added to your subaccount in the SAP BTP cockpit.
The SAP Integration Suite, Advanced Event Mesh instance must be of type standard plan, not default plan. For details on migrating to the standard service plan, refer to the SAP Advanced Event Mesh migration guide.

Migration Steps

Step 1: Create RFC-Destinations.

To establish the connection to the SAP Advanced Event Mesh, we will create three RFC-Destinations in transaction SM59.

1. Create RFC-Destination pointing to the REST endpoint of the Advanced Event Mesh (Available inside the AEM broker).

Type: G (HTTP Connection to External Server).
Target Host: AEM REST endpoint host.
Basic Authentication: Add credentials, listed in the AEM broker for the REST endpoint.
SSL: Active.
Connection test should return in a 405 Method Not Allowed.

2. Create RFC-Destination for the Handshake (Available inside the SAP BTP Service Key).

Type: G
Target Host: Handshake URL from the SAP BTP Service Key
Path Prefix: /handshake
SSL: Active.

3. Create RFC-Destination for the Token (Available inside the SAP BTP Service Key).

Type: G
Target Host: Token endpoint from Service Key
Path Prefix: /oauth/token
SSL: Active.

Step 2: Add Certificates to the Trust Store.

To enable secure communication with SAP Advanced Event Mesh, the server certificate must be trusted in your SAP system.

Open transaction STRUST.
Select the SSL Client PSE that is used in the RFC destination created in SM59 (usually SSL Client (Anonymous) unless a specific PSE was assigned).
Click Import Certificate.
Upload the certificate file (.cer / .crt).
Click Add to Certificate List and save.

Step 3: Enable the Event Add-On for ERP.

Inside your SAP Advanced Event Mesh, navigate to Event Add-On for ERP.

After enabling the service, the component can be installed on your SAP system.

Step 4: Activate BC-Set.

Business Configuration Sets contain customizing and configuration-related table entries required for proper communication with SAP Advanced Event Mesh.

Transaction: SCPR20

Enter BC-Set name:/ASADEV/ACI_BCSET_FRAMEWORK_AEM
Choose Activate.

Step 5: Copy Instance for SAP Event Mesh to new Instance for SAP Advanced Event Mesh.

Go to SPRO -> IMG -> Integration with Other SAP Components -> SAP NetWeaver AddOn for Event enablement -> Connection and Replication Object Customizing
Or go directly to transaction /ASADEV/ACI_SETTINGS.
Copy the existing SAP Event Mesh instance to create a new SAP Advanced Event Mesh instance:

Replace RFC destinations with the ones created for AEM
Change Cloud Type from SAP_EM to SAP_AEM.

Hit Enter and copy all.
Skip errors for duplicate Event Linkages

Delete all Default Values (not required for SAP AEM):

Delete Error Type Mapping (not required for SAP AEM):

You can keep the message type in case you delete the old Instance pointing to the SAP Event Mesh.
Update message types if keeping the old SAP_EM instance::
- Create new Message Type in transaction WE81.
- Activate Change Pointer for the new message type in transaction BD50.

Add Event Linkages for the new message type:

Go to Header Attributes.
- Delete all Header Attributes for SAP EM.
- Add new Header Attributes for SAP AEM.

Go to Field Mapping and configure a dynamic topic.
- Each level becomes a segment in the dynamic topic.
- There are static segments (Default Values) and dynamic segments (Source structure and Source field).

Step 6: Add validation Instance for the SAP BTP.

Got to Connections and add New Entry.
A Validation Instance will be necessary for the authentication against the BTP.
Add RFC destination for Handshake (from Step 1).

Go to Default Values and specify:
- ACI_CLIENT_ID: Client ID from the Service Key.
- ACI_TOKEN_DESTINATION: RFC-Destination for the Token (from Step 1).
- AUTH_TYPE: OAUTH (Certificate also possible; refer to official documentation).

Add client secret from the Service Key
- Transaction: SPRO
- Go to: Integration with Other SAP Components -> SAP NetWeaver AddOn for Event enablement -> Set the cloud connection password
- Or go directly to transaction: /ASADEV/SCI_TPW
- Select the Cloud Instance for validation: SAP_VALIDATION
- Enter the client secret in the Cloud Shared Secret field and execute.

Step 7: Test the new connection to SAP Advanced Event Mesh.

After the steps from above we can now test our new connection to the SAP Advanced Event Mesh.

Change something in the Application, where your Event Add-on for ERP does have an Oubtound Object configured and check the monitor transaction /ASADEV/ACI_MONITOR.

Cloud response should be 200 OK.

On the left side of the Trace we can see the JSON and dynamic topic, that was used to send the message to the SAP Advances Event Mesh.

This was configured inside the Field Mapping of the Outbound Object.

Migration Completed

After these steps, your SAP system is successfully switched from SAP Event Mesh to SAP Advanced Event Mesh using ASAAEMEE.

No changes are required in event definitions.
Monitoring and validation ensure messages are delivered correctly.
Find more configuration options for component ASAAEMEE inside the SAP Discovery Center mission "Data Exchange to Connect SAP ERP with SAP Advanced Event Mesh for Event-Driven Integration".

POV 3: Using Integration Suite as Your Governed MCP Server Platform (Part 3/4)

2026-02-14T01:04:11.131000+01:00

This Blog is Part 3 of a Blog series (4 Parts!). Click on the following to navigate back to the main menu of POV on How to Approach Custom Agents in the Enterprise - Blog Series.

POV 3: Using Integration Suite as Your Governed MCP Server Platform *Coming Q2/2026

If you didn't have a chance to tune in to SAP Tech Ed's IN200v | Empower your agents to be responsible (2025) then it is notable that in Q2/2026 SAP Integration Suite's API Management will allow you to apply additional security policies to APIs in your MCP servers and publish your secure APIs with MCP documentation for Agent consumption via the API and MCP Gateway.

Why is this important?

MCP allows agents to access external information for systems, APIs, documents all while reducing agent complexity. In summary, agents with a MCP client will rely on the MCP server to provide structured metadata to the APIs/Protocols. However, these APIs within the MCP server will likely not meet all security requirements and pose some security risk.

With SAP Integration Suite's API and MCP gateway, you will be able to apply additional API Policies around multi-protocol connectivity, routing, transformations (eg. JSON to XML), mapping, traffic management, and security requirements to further secure, monitor and govern your APIs being leveraged as part of your MCP. This will be incredibly powerful for both SAP Agents and non-SAP agents.

Image taken from SAP Tech Ed's IN200v | Empower your agents to be responsible (2025)

How is this relevant to on-premise users?

Users that are on-premise (eg. ECC, S/4HANA on-prem) can leverage Integration Suite to create custom APIs through OData Services or modify prebuilt S/4HANA APIs (see Business Accelerator Hub) and apply additional API policies to reduce security risk. These APIs can then be leveraged in SAP as well as non-SAP agents. However, it is important to consider the rebuild effort of business context and security when accessing SAP data outside of Joule agents (as described in POV 1).

Where else can Integration Suite and SAP help in my Agent Build?

SAP Business Data Graphs! Within Integration Suite you can explore, design, and extend Graph APIs (Odata V4 or GraphQL) for agent consumption.

Think of this as a semantic layer (connecting multiple entities) that sits on top of the API that allows your agent to receive a mix of entities from one central entity - removing the Agent’s effort to combine the entities together.

Graphs are powerful because the projections between data sources (entities) are automatically created between SAP data as SAP leverages the One Domain data model. However, there are also capabilities for developers to extend to non-SAP. Therefore, allowing you to have a simplified semantically rich API ready for Agent consumption with the bonus to apply additional API policies on top of it, resulting in a secure Graph API. For more information on Graph APIs please check out this blog on an Intro to SAP Graphs & Graph in Integration Suite Blog.

An example of this can be seen in the image below that summarizes the demo shown at SAP Tech Ed's IN200v | Empower your agents to be responsible session. You can see that a user prompts an Agent that leverages MCP API tools with additional governance policies applied to the Graph API. This showcases secure and semantically connected data across SAP Risk assessment, Supplier Plant, and Supplier plant materials entities - resulting in higher performing responsible, relevant and reliable AI Agent response.

Source: Graph – SAP Help

Source: Watch Tech Ed sessions on-demand

Next POV?

To check out Part 4 of the Blog Series click: POV 4 - Putting it all Together Across Your Enterprise.

Or click on the following to navigate back to the main menu of POV on How to Approach Custom Agents in the Enterprise - Blog Series.

POV 4: Putting it all Together Across Your Enterprise (Part 4/4)

2026-02-14T01:13:05.033000+01:00

This Blog is Part 4 of a Blog Series (4 Parts!). Click on the following to navigate back to the main menu of POV on How to Approach Custom Agents in the Enterprise - Blog Series.

POV 4: Putting it All Together Across Your Enterprise

Keeping in mind POV 1, 2, and 3 - POV 4 focuses on bringing your enterprise-wide agents together with an additional layer of security and governance.

As discussed, Integration Suite will allow you to create custom APIs - SAP and non-SAP- including Business Data Graph APIs. These can then be further consumed, whether it’s a custom API through SAP or non-SAP or an API that’s part of a MCP server. In other words, both Joule and non-SAP agents will be able to leverage secure governed APIs and MCPs in an interoperable agentic ecosystem.

In simpler words: Integration Suite and Joule Studio will be the key to unlocking secure, governed, and business context rich agent ecosystems.

In Summary

We opened with a critical question: How do you approach your use cases strategically across your diverse AI landscape? The answer lies in three integrated capabilities:

SAP Joule provides the foundation for responsible, reliable and relevant custom agents with Joule through its deep domain knowledge, rich business context, and secure governance capabilities.
Joule can be used for both SAP specific use cases as well as non-SAP Agent collaboration - bringing the best of both worlds together.
Finally, Integration Suite's API management and MCP Gateway capabilities will be key to unlocking an additional powerful security and governance layer for your agents across your enterprise.

This concludes the Blog Series: POV on How to Approach Custom Agents in the Enterprise.

Automated Trace Enabler in SAP CPI

2026-02-15T08:21:15.257000+01:00

Introduction:

While developing integrations in SAP CPI, enabling Trace is one of the most common activities during testing and debugging. It provides detailed visibility into message processing, including payload transformations, headers and properties.

Of course, there are easier ways to enable trace. Browser extensions and supported testing tools make this process very simple and convenient.

However, there are also projects where:

Browser extension are not allowed
External testing tools are restricted
Developers rely only on native CPI capabilities

In such cases, repeatedly navigating through the monitoring UI to enable trace can interrupt the development workflow.

To address this, I built a reusable Trace Enabler Utility iFlow that programmatically enables trace using internal Operations endpoints - keeping the solutions entirely within SAP CPI.

Prerequisites:

Before using the Trace Enabler iFlow, we need to set up proper authentication to invoke the internal Operations API.

In your SAP BTP subaccount:

Navigate to Instance and Subscriptions
Create a new instance for
Service SAP Process Integration Runtime
Plan API
Roles TraceConfigurationEdit, TraceConfigurationRead
Create Service Key and copy Client ID, Client Secret, Token URL
Create OAuth Credentials in SAP CPI Security Material

Integration Flow Overview:

Download Integration flow from the Git : link

This interface consist of two separate Integration Process, both are designed to enable trace for specific iFlows during development.

Each Integration Process serves a different triggering mechanism but follows same core logic:

Accept Interface IDs
Split them (if multiple)
Enable trace individually

1. Timer based Trace Enabler flow

This integration process runs automatically based on a configured scheduler.

The timer can be defined according to development requirements. For example:

Every 9 minutes
During working hours on week days

This makes it useful when trace needs to be enabled periodically during active development hours.

The list of interfaces is maintained as Externalized Parameters.

Example: iflow_1, iflow_2 (separated by comma)

2. HTTPS based Trace Enabler flow

This integration process exposes an HTTPS endpoint for manual triggering.

Developers can use tools like postman to send a request and enable trace on demand.

Note: This interface uses an internal, non-public SAP API that may change or be removed in future releases.

Important Consideration: Activating trace during unwanted runs or unexpected triggers can significantly increases message storage consumption. Always enable trace carefully only when necessary and disable it when no longer required.

Conclusion:

This interface demonstrates how trace activation in SAP CPI can be automated during development using internal API. While useful for streamlining debugging, it should be used with awareness since it relies on a non-public API.

I'd appreciate any insights, improvements or feedback on this approach.

Happy Integrating!

Discover and Publish Events from SAP Advanced Event Mesh in Developer Hub

2026-02-16T10:42:34.494000+01:00

Introduction

Event-driven architecture (EDA) is a cornerstone of modern integration, enabling systems to react in real time to business events with loose coupling and scalability. In this blog, we walk through how to connect SAP Advanced Event Mesh with SAP Developer Hub to discover and publish events, empowering integration teams and developers to explore and reuse event streams within the SAP ecosystem.This setup is especially relevant if you’re looking to build responsive integrations or microservices that react to business events across SAP solutions.

🟢 Delivered Roadmap Item

SAP has delivered manual discovery and publication of events from Advanced Event Mesh to SAP Developer Hub a...

For a complementary scenario focused on discovering events from SAP S/4HANA Cloud using SAP Developer Hub, see the blog “Discover S/4HANA Cloud Events in SAP Developer Hub.” That post walks through registering your S/4HAN...

1️⃣ Overview: Why Discover and Publish Events

Developer Hub acts as a central catalog for APIs and events.
Advanced Event Mesh is the cloud service that enables event distribution across hybrid landscapes.

Discovering events helps teams understand what events are available and reuse them consistently.

2️⃣ Set Up the Destination to Connect Event Mesh to Developer Hub

Go to SAP BTP Cockpit → Subaccount
Navigate to Connectivity → Destinations → Create from Scratch
Fill in details:

Name, Type: HTTP
Base URL of Advanced Event Mesh
Authentication (e.g., BasicAuthentication with API token)
Custom property: sap.isuite.dh.aem.enabled = true

3️⃣ Register and Configure Your Advanced Event Mesh Instance

Describe how to ensure Event Mesh and its event APIs are set up for discovery.

Create event APIs or ensure existing ones are shared
Enable appropriate access permissions

Note: Only shared events will show up in Developer Hub

4️⃣ Discover Events in SAP Developer Hub

Steps to explore events once the destination is set:

Open Developer Hub via Integration Suite
Go to Admin Center → Manage → Content
Select your Advanced Event Mesh business system

Browse events grouped by application domain

5️⃣ Create Products and Publish Events

Explain how to group events into products and publish them:

In Developer Hub, select events you want to publish
Create a Product (logical grouping of events)

Summary

In this blog you learned how to

Connect Advanced Event Mesh with SAP Developer Hub
Discover and publish events for reuse
Enable developers to consume events in integration use cases
Publish the Product to make it discoverable by developers

Decision Logic Modernization in SAP Integrations: Using SAP-RPT-1 for Intelligent Routing Decisions

2026-02-16T19:54:29.244000+01:00

Integration Modernization concept is often discussed in two dimensions:
1) Platform modernization – moving from older stacks like SAP NetWeaver PI/PO, SAP Neo, or legacy 3rd party platforms to SAP Integration Suite.
2) Scenario modernization – shifting from legacy protocols to modern integration patterns such as APIs & event-driven architectures; upgrading ABAP / Java mapping to graphical mapping / groovy script; or moving from basic auth to OAuth 2.0 or client certificate based authentication, and so on.

But there is another Modernization opportunity at the scenario level: decision logic modernization.

In this blog, we explore how routing decision logic, as an orchestration step — can be modernized using SAP-RPT-1, SAP’s latest foundation model hosted on BTP AI Core (Generative AI Hub) — applied to an outbound delivery routing scenario.

The Traditional Approach: Static Rules, Lookups, and Growing Complexity:
In SAP PI/PO and Integration Suite, routing decisions are typically implemented using deterministic, rule-based logic. These decisions often control how a scenario behaves – including which receiver system to call, or which transformation branch to follow. The common approaches include:

Static routing via Routers based on payload elements or fields
Dynamic configurations, such as externalized parameters passed at runtime
Lookups to external systems (e.g., via JDBC, SOAP, RFC lookups) to evaluate conditions at runtime — achieved in Integration Suite via patterns like Request-Reply or Content Enricher

These mechanisms work — but they come with growing challenges:

Rules get combinatorially complex with more conditions and evolving business scenarios
Lookup tables become burdensome to maintain
Decisions become rigid and hard to evolve over time

As a result, rule-based decisioning becomes harder to maintain as business requirements evolve. Agility suffers. Adaptation becomes expensive.

What if, instead of relying on static rule-based logic, iflows could make decisions based on historical business patterns — applying predictive machine learning without the overhead of training and managing custom models? With the in-context learning capabilities of SAP’s latest foundation model, SAP-RPT-1, such predictions can be performed on-the-fly at runtime.

Enter SAP-RPT-1: Foundation Model for Predictive Tasks:
SAP-RPT-1 is a pre-trained foundation model available via BTP AI Core (Generative AI Hub). Unlike traditional ML services that require dedicated data science setup, SAP-RPT-1 offers:

Pre-trained model, ready for “plug and play” in your scenario
No ML infrastructure setup
No data science expertise required
No-code consumption via API
Faster time-to-market
Democratization of AI capabilities across IT functions

SAP-RPT-1 is pre-trained specifically for predictive tasks such as classification and regression over ERP tabular data, unlike many general-purpose GenAI models that are primarily trained on large corpora of natural language text. Instead of building and managing a full ML lifecycle, integration developers can now leverage predictive intelligence directly into iflows — without any data science related heavy-lifting.

If you are new to SAP-RPT-1, I recommend that you read this introductory blog.
Also, explore this SAP-RPT-1 playground.

Business Scenario: Intelligent Outbound Delivery Routing with SAP-RPT-1:
SmartSense Technologies (SST), a global provider of smart security devices, faces challenges in routing outbound deliveries from its manufacturing plants to distribution centers, retail stores, and end customers. Their current routing logic, embedded in integration flows, relies on static rules and lookup tables – employing a combination of Material, Quantity, Delivery priority, Material group, Ship to location, and so on. This leads to frequent shipping delays, cost overruns, and SLA violations whenever logistics conditions change and sub-optimal 3PL partner is chosen.

To overcome these limitations, SST decides to leverage SAP Integration Suite together with SAP-RPT-1 foundation model. By embedding machine learning–driven decision-making into its integration flow, SST aims to dynamically select the optimal logistics partner for each delivery based on historical performance, cost, and delivery times. While SAP-RPT-1 is capable of solving predictive tasks such as classification and regression, we will be using it for classification task — i.e. to classify given delivery (defined by delivery header & item attributes) to most optimal 3PL logistics provider.

The following diagram illustrates the target architecture implemented by SST for intelligent outbound delivery routing using SAP Integration Suite and SAP-RPT-1 model, hosted on BTP’s Generative AI hub:

Step 1: Outbound Delivery Creation
An outbound delivery is created in SAP S/4HANA, which triggers an outbound notification event. The event is consumed by the iflow, which then calls S/4HANA OData API to fetch the following delivery related header and item attributes.

Delivery header fields: DeliveryDate, SalesOrganization, ShipToParty, SoldToParty, DeliveryDocumentType, CreationDate, ShippingPoint, DeliveryPriority, IncotermsClassification, TransactionCurrency

Delivery item fields: Material, DeliveryDocumentItemText, MaterialGroup, ActualDeliveryQuantity, DeliveryQuantityUnit, Plant, StorageLocation, ItemGrossWeight, ItemWeightUnit, ControllingArea, DistributionChannel, GoodsMovementType, ProfitCenter

Step 2: Context Selection – Random Historical Records
We store historic labeled data i.e. delivery headers, items and corresponding optimal 3PL partner data in SAP HANA Cloud. The iflow is configured to fetch a random set of this historic data from HANA Cloud. As recommended in this blog, for most enterprise use-cases, where you have about hundred thousand to million lines of labelled data, depending on how diverse your scenario data is, you may choose the context size, by iterating and finalizing the apt number of historical records to pick. By picking random records, we are able to provide statistically diverse examples, improve prediction quality and avoid bias from sequential records.

The Iflow executes the following query on the HANA Cloud DB:

SELECT TOP ${property.NumberofRecords}
"DeliveryDate",   "DeliveryDocumentNumber",  "CreationDate", "DeliveryPriority",  "IncotermsClassification",  "Material", "DeliveryDocumentItemText", "MaterialGroup",  "ActualDeliveryQuantity", "DeliveryQuantityUnit", "ItemGrossWeight", "ItemWeightUnit", "DistributionChannel", "PartnerNumber"
FROM "RPT1"."historic_3pl_selections"
ORDER BY RAND()

Step 3: Constructing the SAP-RPT-1 Request
We now combine:

Historical random records (known 3PL partner)
The current outbound delivery (3PL partner to be predicted)

The current transaction includes a placeholder: [PREDICT]

The request payload contains:

900 historical labeled rows
1 new outbound delivery row marked for prediction

For detailed info on payload construction, refer to the official documentation page and the GitHub repository (sample Postman/Bruno collections available for experimentation).

Further, while creating the inferencing request to SAP-RPT-1, we trim the columns from original 24 down to only 14 columns of delivery attributes, by removing fields like Sales Org, Controlling Area, Profit centre that do not influence partner selection. This is one of the best practices to achieve best possible predictive outputs. Read more recommended best practices here.

Step 4: Deploying SAP-RPT-1 model in Generative AI Hub

Step 5: SAP-RPT-1 inference response
The response contains Number of predicted records, predicted field (here optimal 3PL partner) along with Confidence score.

Response from our example scenario:

You can also send multiple unknown records in one batch. To read more about the number of max. records and columns supported by SAP-RPT-1, check out this help page.

Step 6: Intelligent Routing in the Iflow
The Iflow now:

Reads the predicted PartnerNumber
Evaluates confidence threshold (optional safeguard)
Routes outbound delivery to the optimal 3PL partner
Optionally, logs decision + confidence for traceability in HANA Cloud.

When AI in Iflows Brings Real Business Value

When routing decisions directly impact business outcomes
If sub-optimal routing can lead to SLA breaches, shipment delays, higher costs, or customer dissatisfaction, intelligent decision logic creates measurable advantage.
When rule-based logic becomes complex and brittle
As business variables multiply (products, regions, priorities, partners), static rules become hard to maintain and scale. ML handles multi-dimensional patterns more effectively.
When historical ERP data contains predictive patterns
If past delivery and fulfillment data reflects consistent business behavior, ML can learn from it and improve future routing decisions beyond deterministic conditions.
When business context evolves over time
With changing product mixes, customer bases, or distribution models, retrainable ML models adapt dynamically — avoiding constant manual rule maintenance.

Not every integration scenario requires ML capabilities. But where routing decisions carry operational or financial impact, replacing rigid rule sets with adaptive decision logic can significantly improve resilience and maintainability. Decision logic modernization is therefore not about adding AI everywhere — it is about applying it where it meaningfully improves orchestration.

Note: This blog revisits our earlier implementation in light of the planned deprecation of SAP BTP Data Attribute Recommendation service, demonstrating an updated approach using SAP-RPT-1 model.

Using Client Certificate Authentication in SAP CPI HTTP Receiver Adapter

2026-02-17T10:17:51.079000+01:00

Introduction

Hi friends, in this blog lets see how to configure the HTTP receiver adapter using client certificate auth type and step by step explain how a PKCS#12 (.p12) certificate is stored in the Keystore, which I have explored in my recent Integration flow development.

What is Client Certificate Authentication?

Client certificate authentication, also known as a mutual authentication method / mutual TLS (mTLS), ensures that:

The client (SAP CPI) authenticates itself to the server
The server also presents its certificate to CPI
Both sides trust each other using certificates issued by trusted CAs

Unlike basic or OAuth authentication, client certificate authentication relies on X.509 certificates and private keys, not usernames or tokens.
For more information about client certificate authentication, refer to the link:

https://help.sap.com/docs/integration-suite/sap-integration-suite/client-certificate-authentication-outbound?locale=en-US&state=PRODUCTION&version=CLOUD

Files Provided by the Partner

Our 3rd party client (receiver system) has provided

certificate.crt — signed client certificate (after providing the signing request)
private_key.key — private key (We need to generate this via OpenSSL if it is a Production tenant)
certificate-chain.pem — intermediate/root CA certificates

To establish the connection, all three must be updated in the tenant keystore, since SAP CPI does not accept .key files directly, these files must be converted directly into a PKCS#12 (.p12) format.

Creating the P12 File

The .p12 file contains:

Client certificate (eg, certificate.crt)
Private key (eg, private_key.key)
CA certificate chain (Intermediate + Root certificates) (eg, certificate-chain.pem)

Using OpenSSL /Command prompt:

Open the command prompt from the same folder in which all these files are stored.

Enter the command below, and it will ask you to set the password. After you enter the password, it generates the p12 file in the same folder.

openssl pkcs12 -export \
-in certificate.crt \
-inkey private_key.key \
-certfile certificate-chain.pem \
-out client.p12 \
-name "client-cert"

Note: An export password is required and will be used later during upload into CPI.

Uploading the Certificate to SAP CPI Keystore

Log in to SAP Cloud Integration
Go to Monitor → Keystore
Choose Add → Key Pair
Upload client.p12
Enter the export password
Save

The certificate is now securely stored and managed by CPI.

Configuring the HTTP Receiver Adapter

In your integration flow:

Add an HTTP Receiver Adapter
Set Authentication to: Client Certificate
In the Credential Name field, select the alias of the uploaded .p12 from the Keystore.

Security Best Practices

Protect the .p12 password
Use separate certificates for PROD and NON-PROD
Monitor certificate expiry dates

Conclusion

Client certificate authentication is a secure and reliable option. Using a P12 certificate from the keystore with the HTTP Receiver Adapter keeps authentication simple and secure.

Thank you for reading this blog. I hope this helps you with your integration. When I started this integration development, I uploaded all the keystore documents separately, but it still ended up failing. Also, I couldn’t find any reference blog on how to handle this. So, I want to share this with others. If you feel this is a long procedure (as I do), please share your ideas and feedback in the comments.

Master Blog: B2B Integration with SAP Integration Suite

2026-02-19T10:22:28.687000+01:00

Introduction

B2B integration plays a critical role in enabling seamless and reliable data exchange between enterprises and their business partners. As integration landscapes grow in scale and complexity, standardized B2B capabilities become essential to ensure secure connectivity, partner onboarding, message validation, monitoring, and operational resilience.

This master blog serves as a technical reference hub for B2B Integration Factory, consolidating all related blog posts in one place to support integration architects and developers in designing, implementing, and operating scalable and governed B2B integration scenarios with SAP Integration Suite.

If you are interested in deepening your knowledge of B2B integration using SAP Integration Suite, we recommend our free learning course. This comprehensive course offers detailed explanations of each B2B capability and includes hands-on exercises with an example end-to-end B2B scenario. You can access it here: SAP Learning: Manage B2B Scenarios Effectively with SAP Integration Suite.

B2B Integration Factory

B2B integration Factory’s services & integration packages

B2B Integration Factory services to unlock the power of SAP Integration Suite's B2B capabilities

B2B Integration Factory – B2B related Integration Packages with your Custom Extensions

B2B Integration Factory: What is Pre-packaged B2B Integration Content, and what is this used for?

B2B Integration Factory's Role and Value Adds in t... - SAP Community

B2B Integration Factory Q4/2024 Release highlights - SAP Community

First release of B2B Integration Factory – Integration Packages and their Extensions

SAP Migration Factory for Integration Suite – FAQ - SAP Community

The importance of B2B Monitoring in customer's day... - SAP Community

VDA Automotive Flat File Processing with B2B Integ... - SAP Community

B2B integration scenarios

Blog posts describing end-to-end B2B integration scenarios using IA, TPM and CPI

B2B data exchange using Trading Partner Management... - SAP Community

B2B Scenario Sender EDI to IDOC - SAP Community

Bridging EDI and SAP S/4HANA Cloud: Seamless EDI-t... - SAP Community

Completing the B2B migration into SAP Integration ... - SAP Community

Creating MIGs and MAGs Using Integration Advisor i... - SAP Community

How to build custom B2B Interface using Integratio... - SAP Community

Inbound Interface: EDI → SAP BTP (Integration Suit... - SAP Community

Real-Time XML to EDI Conversion: A Step-by-Step CP... - SAP Community

SAP BTP - Integration Advisor - (MIG & MAG) from a... - SAP Community

SAP Integration Suite - TPM - B2B PassThrough Scen... - SAP Community

Streamlining B2B Integration with AI-Powered SAP C... - SAP Community

Use TPM, IA, CI to Efficiently Manage and Run Comp... - SAP Community

Integration Advisor

Blog posts focusing only on IA

Beginner's Guide to Integration Advisor - SAP Community

Base-/Overlay Mappings for Integration Advisor - SAP Community

Creating MIGs and MAGs Using Integration Advisor i... - SAP Community

Integration Advisor – Automotive EDIFACT Subsets (... - SAP Community

Integration Advisor – change in namespace handling... - SAP Community

Integration Advisor: complex mapping code for dime... - SAP Community

Integration Advisor – Create 1:1 Mapping Elements ... - SAP Community

Integration Advisor – Download MAG Simulation Resu... - SAP Community

Integration Advisor – GS1 XML Messages and Namespa... - SAP Community

Integration Advisor – GS1 XML Messages of the vers... - SAP Community

Integration Advisor – direct support of EDI payloa... - SAP Community

Integration Advisor: Early UN/EDIFACT Versions wit... - SAP Community

Integration Advisor – extended support for Custom ... - SAP Community

Integration Advisor – Extended semantic validation... - SAP Community

Integration Advisor: Functions at target side - Or... - SAP Community

Integration Advisor - List of supported XSLT eleme... - SAP Community

Integration Advisor – Mapping element functions, t... - SAP Community

Integration Advisor – Mapping element functions fo... - SAP Community

Integration Advisor – MAG: How to create If-Then-E... - SAP Community

Integration Advisor – MIG Qualification based on m... - SAP Community

Integration Advisor – multi-payload support for MI... - SAP Community

Integration Advisor – new B2B Library content for ... - SAP Community

Integration Advisor – Now GS1 EANCOM Library avail... - SAP Community

Integration Advisor – Odette Message Standard - SAP Community

Integration Advisor: Overview of components for bu... - SAP Community

Integration Advisor – payload-based qualification ... - SAP Community

Integration Advisor - Quickly create your individu... - SAP Community

Integration Advisor - support for multi-value Qual... - SAP Community

Integration Advisor – Support of xCBL Messages - SAP Community

Integration Advisor – Tradacoms Message Standard - SAP Community

Integration Advisor – Use Custom XSLT as MAG - SAP Community

Integration Advisor: Using the Pre-Transformation ... - SAP Community

integration content advisor: Create a customized i... - SAP Community

integration content advisor: Create a mapping usin... - SAP Community

integration content advisor: The importance of cus... - SAP Community

How to Provide Read-only Access to Integration Adv... - SAP Community

Restoring the hierarchical order of a flattened so... - SAP Community

SAP BTP - IS - ( IA | CPI ) - The Commander's Blue... - SAP Community

Support for ASC X12 Subsets (VICS etc.) in Integra... - SAP Community

Streamlining B2B Integration with AI-Powered SAP C... - SAP Community

Taming the X12 856 message in SAP Integration Advi... - SAP Community

Using EDI Envelopes in Integration Advisor - SAP Community

Trading Partner Management

Blog posts focusing only on TPM

Archiving B2B Messages from SAP Integration Suite ... - SAP Community

B2B data exchange using Trading Partner Management... - SAP Community

Custom Message Mapping - TPM - B2B - SAP Integrati... - SAP Community

Custom Search Attributes in SAP B2B - SAP Community

Integrating Cloud Application Lifecyle Management ... - SAP Community

Guide for migrating PI/PO B2B mappings to Integrat... - SAP Community

Reusing SAP PI/PO B2B mapping content in Cloud Int... - SAP Community

SAP Cloud Integration : B2B - Restart/Retry Messag... - SAP Community

SAP Trading Partner Management - Part I: TPM overv... - SAP Community

SAP Trading Partner Management - Part II: Data - SAP Community

SAP Trading Partner Management - Part III: Partner... - SAP Community

SAP Trading Partner Management - Part IV: Agreemen... - SAP Community

SAP Cloud Integration - Trading Partner Management... - SAP Community

Troubleshooting SAP BTP TPM: Debugging Step 1b and... - SAP Community

Using Trading Partner Management with AI - SAP Community

Summary

This collection brings together key insights, best practices, and technical deep dives on B2B integration using SAP Integration Factory, helping you design, implement, and optimize your B2B integration landscape. If you feel a relevant topic or blog post is missing, please let us know in the comments—we’re happy to expand the list and keep this collection current and comprehensive.

Best practices and guidelines in SAP Integration Suite

2026-02-19T16:00:00.019000+01:00

Let’s be real. Integration can either feel like elegant orchestration… or controlled chaos.

That’s why we’re hosting “Best practices and guidelines in SAP Integration Suite”. This session goes beyond theory. We’ll explore how SAP Cloud Integration (CPI) fits into modern enterprise architecture and how to apply recommended integration patterns across SAP-to-SAP, SAP-to-non-SAP, and hybrid scenarios.

Plus, we’ll dive into the details that actually matter in projects: secure connectivity, smart scripting, message processing, monitoring, and alerting. The stuff that keeps your integrations stable at 2 a.m. when no one wants surprises.

Think of it like designing highways between systems. Good design means smooth traffic. Poor design? Bottlenecks everywhere.

If you’re building or optimizing integrations for customers, this session will give you clarity and confidence.

Register now and let’s build integrations that scale with purpose. https://partneredge.sap.com/en/library/education/psd/2026/feb/e_oe_te_w_PSD_WEB_00013114.html

#SAP #SAPBTP #SAPIntegrationSuite #SAPCloudIntegration #SAPPartners #DigitalTransformation #HybridIntegration

Where Your Ideas Shape SAP BTP: Become Part of the SAP Customer Engagement Initiative 2026-1

2026-02-19T16:02:40.549000+01:00

SAP Business Technology Platform is reshaping how organizations innovate. By unifying application development, automation, data and analytics, integration, and AI, it empowers businesses to build smarter, more efficient, and more adaptable solutions.

Now, you can help shape what comes next.

Cycle 1 of the SAP Customer Engagement Initiative for 2026 is now open, giving you as SAP customers and partners the opportunity to directly influence the future of SAP BTP. Collaborate with SAP product teams and developers, share feedback early, and help guide upcoming capabilities and improvements.

This isn’t just early insight - it’s your chance to impact the direction of enterprise technology.

Registration is open until March 13, 2026.

Check out the full list here or follow the links below to discover the exciting opportunities:

Let’s shape the future together!

Don’t miss out – sign up today at influence.sap.com and be a part of the SAP Customer Engagement Initiative Cycle 1 in 2026!

Warm regards,
Your SAP Customer Engagement Initiative Team

Integrating Using Google Cloud Storage Adapter (GCP Authentication & adapter config)

2026-02-20T10:23:33.844000+01:00

Google Storage Adapter

Introduction to GCS (Google Cloud Storage) :

GCS is a robust and RESTful service for storing and retrieving the data like documents, videos and photos. It stores as a object and provides high performance designed specifically for enterprises. GCS also provide encryption/ decryption capabilities. Our Integration suites provides a adapter to connect with GCS in accessing the object. In this blog, we are going to see how to create service account in Google cloud platform and use it in SAP integration suite for authentication and basic configuration for uploading and retrieving a file.

Advantages of using GCS Adapter:

Integration suite has built-in for GCS adapter, so no need to manually construct REST endpoints.
Built-in support for Buckets and Object operation.
No manual OAuth token handling and no custom scripts for token generation.
Config driven Object operations like upload (Put Object), Download (Get Object), Delete Object and List Objects.
Few integration steps and faster development.
Built-in Error handling and Validation. The adapter Validates bucket and Object Configuration.
Dynamic File and Path Handling. You can dynamically define Buckets. Object Paths and File names.
Key security benefits includes secure key storage and compliance with SAP security Standards

How to get Create Service Account ?

Step 1: Create Service Account in GCP

Navigate to IAM & Admin -> Service Accounts.
Click service account and give a name and add required roles. (You need ‘Storage Object Admin’ role for uploading and reading the file).

Step 2: Generating Key

Click on the email that’s been created on service accounts.
In the Keys tab, Click ‘Add key’. (Create or upload key).
Generate and download. (You have an option to download JSON or p12 file).

Note: If your organisation does not allow downloading the JSON key or P12 you will have to change the org policies. To override you should use Tag.

Navigate to your Org from ‘Project Picker’.
Move to Tag menu.
Create a Tag key (eg: EnableServiceKeyCreation). Open the Tag Key that you created now.
Create Tag values for the Tag Key. (Eg: true, false).

Attaching the Tag to your Project:

Navigate to Manage resources and select your Project.
Click on the ‘Tag’ and your Org in ‘Select scope for your tags’.
Now in the ‘key 1’ you can see the tag key you created earlier listed. And its corresponding values in the ‘Value1’ drop down.
Select whether you want enable/disable the service account creation.

Select ‘Organisation Policies’ and select ‘iam.managed.disableServiceAccountCreation’.
Click Manage policy.
Change to ‘Override Parent Policy’.
To override you need to configure the policy with Rule. One for ‘Enforcement’ and one for ‘Not enforced’
Any one rule has to be default.

Condition needs to added for any one of the rule. Here in this example, I have added the key and if the tag value true then the policy will be enforced.
Click Save

Click ‘Set Policy’. ( you will need Org Policy admin, Org Admin, Org Viewer, cloud asset, Tag Admin roles). Only after this you can download the JSON or P12.

Step 3: Creating Private key alias

P12 file :

you can just download the file and a password with be given by the GCS.
Upload the file as Key pair in SAP Integration Suite and give a name for the alias and enter the same password that GCS given to you.

JSON File:

Extract the private key from the JSON. (Remove the /n and “).
Save it as <filename>.pem
Create ‘public certificate’
Create p12 file
Now, upload this p12 file as Key pair in SAP Integration Suite and give the name for alias and enter the same password that you set before.

How to Configure the Adapter:

Use the alias we created in the ‘Private Key Alias’ and the service account email that was created in GCS.

How to configure Google Storage Receiver adapter to Upload a file?

Operation : Create to upload a file.
Directory: Folder path to upload file.
Object Name : file name
Content type: file content type
Existing file handling:
- override - Creates a new object or replaces the object with new one.
- Ignore - Skip object creation and no error
- Fail - throws error

How to Configure the Google Storage Sender to read a file?

Directory: Folder to read the file from
Object Name: File name to read
Post processing: after processing you can Archive or delete or keep the object.

After deploying your Iflow you can see the file is created / retrieved to/from your specified location in GCS. Explore more on the object where you can do archive or delete the file once it is fetched by the Iflow.

Useful Links:

SAP Documentation: SAP Google Storage Adapter Guide | SAP Google Storage Adapter Help

Using Adapter HTTP - Response 403 for OData API Post Method- How to solve the big challenge

2026-02-21T11:06:08.764000+01:00

Connecting SAP S/4 HANA or ERP systems with external applications using OData services is becoming the backbone of modern enterprise integrations. Tools such as SAP Cloud Integration (CPI) or Integration Suite’s using HTTP Adapter make it easy to consume or expose APIs—until you hit a frustrating roadblock:

“HTTP 403 – Forbidden” when calling an OData API POST method.

This error is notoriously deceptive. Your GET requests work fine. Your endpoint is correct. Your payload is correct. Yet POST still fails.
Why?

In this blog, we’ll break down why HTTP 403 happens, what makes POST requests special, and—most importantly—how to solve this challenge with proven, real-world fixes.

1. Understanding the 403 Forbidden Error

A 403 Forbidden response means:

The server understood your request but refuses to authorize it.

In the context of OData POST calls via the HTTP adapter, this almost always indicates an authorization, CSRF, or policy-related issue.

2. Why GET Works but POST Fails

Many developers test an OData service with a GET call, find that it works, and assume the setup is correct. But POST behaves differently because it:

Modifies data, triggering stricter authorization checks
Requires CSRF token handling (depending on the endpoint)
May require additional headers

This is why GET succeeding does not prove the integration is fully configured.

3. The Top Causes of HTTP 403 for OData POST (and How to Fix Them)

Cause 1 — Missing or Incorrect CSRF Token

Many SAP OData services require a valid X-CSRF-Token for POST/PUT/PATCH/DELETE.

✔ Solution:
Perform a GET request with header:

X-CSRF-Token: Fetch

and capture:

Returned CSRF token
Returned cookies

Then send them along in your POST call:

X-CSRF-Token: <token>
Cookie: <cookies>

Cause 2 — Incorrect or Missing Headers

Some OData services enforce additional constraints.

Mandatory headers may include:

Content-Type: application/json
Accept: application/json

4. How to Troubleshoot 403 Efficiently

Step 1 — Test POST via Postman

Fetch CSRF token first
Send cookies + token in POST
Add all required headers

Step 2 — Check SAP Gateway Error Logs

Use transaction /IWFND/ERROR_LOG or /IWBEP/ERROR_LOG.

You may see:

"No CREATE authorization"
"CSRF Token validation failed"
"Request method not allowed"

These messages are extremely helpful.

5. Example Adapter HTTP Configuration for POST (CPI)

Headers

Method: POST
Content-Type: application/json
Accept: application/json
X-CSRF-Token: <fetched token>
Cookie: <SAP cookies>

Body (Example)

{
  "Name": "Sample Item",
  "Quantity": 10
}

Set Header for Cookie + CSRF token

Groovy Script 1(Shown from above Iflow image)

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


def Message processData(Message message) {
    def headers = message.getHeaders();
    def cookie = headers.get("Set-Cookie");
    def csrf = headers.get("x-csrf-token");
    StringBuffer bufferedCookie = new StringBuffer();
    for (Object item : cookie)
    {
        bufferedCookie.append(item + "; ");
    }
    message.setHeader("Cookie", bufferedCookie.toString());
    message.setHeader("x-csrf-token", csrf)

    return message
}

POST Method

Session handling

On Exchange: If this configuration option is selected, the session will be re-used for the whole processing of one message, meaning for one message exchange. This makes sense if the integration flow executes several calls to the same backend during one message exchange, for example in case of a loop or multicast scenario. Then the subsequent calls are much faster because no authentication is to be executed. It can also be used if the server keeps a state and you want to connect several times to the stateful service within one exchange

6. Conclusion – Turning a Frustrating 403 into a Successful POST

The HTTP 403 Forbidden error for OData POST calls is one of the most common yet misunderstood issues when integrating SAP systems. But once you understand:

CSRF handling
Role/authorization requirements
Header and policy rules
Gateway restrictions

…the problem becomes easy to solve.

Following the troubleshooting guidelines above will help you quickly identify the root cause and ensure your POST requests work reliably—whether you're integrating via CPI, API Management, BTP, or direct HTTP calls.

Service	SAP Process Integration Runtime
Plan	API
Roles	TraceConfigurationEdit, TraceConfigurationRead