SAP Community - Cloud Integration

Pass XI message ID from end-to-end

2026-07-15T22:57:19.662000+02:00

With the new version of the Pipeline for Cloud Integration packages, see New features in the Pipeline for Cloud Integration packages with the July 2026 shipment, we have enhanced the generic XI inbound processing flow as well as the generic XI outbound processing flow to be able to pass the XI message ID from end-to-end. This enhancement was actually added based on a customer requirement. For specific scenarios where both the sender and the receiver use the XI 3.0 protocol, the customer likes to keep the sender XI message ID the same like in the receiving system to be able to track the message from end-to-end.

You can enable the feature for a specific configuration scenario by maintaining the string parameter PassMessageIdFromE2E in the partner ID representing your configuration scenario in the Partner Directory.

We intentionally did not introduce this feature as a global setting because you need to use this setting with caution. Wrongly used, this may lead to data loss. For example, if you duplicate or split up your message in your scenario-specific outbound processing flow that calls the generic XI outbound flow and each split message is sent to the same receiver, only the first message will be processed in the receiver system, all other messages are seen as duplicates in the receiver system because they have the same XI message ID which was successfully processed before and hence they will be discarded leading to data loss. We have implemented a check which will only work when using an iterative splitter or a generic splitter in your scenario-specific outbound processing flow to split up the message. In this case, even if the parameter PassMessageIdFromE2E is set, this setting will be ignored and a new unique ID for each split message is generated. If you use whatever other way to split up the message, the check won't work. So, as said, use this with caution and enable it only for use cases where you are sure that this won't lead to any harm.

So, now let's check how this can be configured and how this behaves. I have setup a configuration scenario of pattern Content-Based Router. For one receiver, I run a one-to-many message mapping to split the message. For another receiver, I only pass one message to the receiver.

In case you are not familiar with scenarios using the generic XI outbound processing flow, check out this blog post Generic XI Outbound flow in Cloud Integration Pipeline. For a better understanding, I schematically show you the message flow:

Sender --via XI protocol--> Generic XI Inbound Processing flow --via JMS adapter--> First JMS Queue --via JMS adapter--> Integrated Messaging Pipeline flow --via JMS adapter--> Second JMS Queue --via JMS adapter--> Generic Outbound Processing flow --via ProcessDirect--> Scenario-specific Outbound Processing flow --via ProcessDirect--> Generic XI Outbound Processing flow --via XI protocol--> Receiver

So, in the Generic XI Inbound Processing flow I fetch the XI message ID from the Sender, store it in a header and route this through all flows. The Generic XI Inbound Processing flow stores the message in the first JMS queue where it is picked up by the Integrated Messaging Pipeline flow. The Integrated Messaging Pipeline flow carries out the xpath conditions to determine the receiver/s and then stores the message in the second JMS queue for each receiver. In our case, we always have one receiver only at the same time. The Generic Outbound Processing flow picks up the message/s from the second JMS queue and now tries to deliver this to the receiver. It calls the Scenario-specific Outbound Processing flow via ProcessDirect where the actual mapping is carried out and eventually the XI connection parameters are set. The connection to the Receiver is then done via the Generic XI Outbound Processing flow which acts as a sort of channel. If configured, we use the XI message ID from the Sender to create the XI message ID at the Receiver.

So, the screenshot below shows the scenario-specific integration flow where we split up the message. As you can see, we run a one-to-many message mapping, the result is a multi message which is embedded in Messages nodes. We need to get rid of the additional nodes and split up the message into multiple messages. This we do using an iterative splitter. The iterative splitter by the way adds a specific header to the exchange which we pass to the next flow which is the generic XI outbound processing flow where we check if this header is present and if so discard the use of the sender XI message ID. Furthermore, in a content modifier we need to add the Camel split index to the unique ID header so that each split message has a unique ID.

And the following screenshot shows the scenario-specific integration flow with a simple 1:1 mapping resulting in one single message. In this case, we can keep the unique ID header unchanged. But it won't be used anyway because we will pass the XI message ID from the sender to the XI receiver adapter in the generic XI outbound processing flow anyway.

I like to enable the feature for my scenario, at least for those cases were I do not do a split. In the Partner Directory, I add a new string parameter with ID PassMessageIdFromE2E and value true to the partner ID representing my configuration scenario.

Now, I run some tests. First, let's see how the end-to-end XI message ID feature works. In this case, in the message monitor I click on the Application Message ID and this will then automatically filter all logs that belong to the same Application Message ID. Here, the Application Message ID is actually the sender XI message ID. So, you can see that both, the generic XI inbound processing flow as well as the generic XI outbound processing flow have the same XI message ID. I only mocked the sender and receiver but in a real scenario the corresponding messages in the sender and the receiver system would be the same.

For another test message that I sent, the split is carried out. Here, I now click on the Correlation ID to be able to see all logs of the same exchange. Since we did a split, you see two logs of the generic XI outbound processing flow. If I clicked on the Application Message ID, you would not see all logs because the generic XI outbound processing flows have a different XI message ID and hence Application Message ID. Here, the check popped in. Because we did a split in the flow before, the unique ID header is used to generate the XI message ID instead of using the sender XI message ID. You remember, the unique ID header was modified by adding the slit index, so this ensures that the XI message IDs of the split messages differ. So, in this case you can't track the XI message ID from end-to-end but at least we add the sender XI message ID to the custom header properties. If we identify a split, we store the sender XI message ID in the custom header ParentIdBeforeMessageSplit.

Hope this new feature is of value for you. As usually, feedback is highly appreciated.

New Skip Retry Handling feature in the Pipeline for Cloud Integration with the July 2026 shipment

2026-07-15T22:57:30.153000+02:00

In some error cases, an automatic retry doesn’t help, it just adds load on the tenant runtime without fixing anything. For those cases, you can skip the standard retry handling and send the failed messages directly to the Dead Letter Queue (DLQ). That’s exactly the purpose of the new "Skip Retry Handling" feature in the Pipeline for Cloud Integration (July 2026 shipment). This blog covers when retries are skipped by default, and how you can adjust the behavior globally or per scenario.

How “Skip Retry Handling” Helps

The tenant stops wasting runtime on errors that will never succeed.
Failures land in the DLQ quickly, so you can actually see what broke instead of digging through retry noise.
You can leave the defaults alone, or tune the behavior globally or per scenario.

Where Retries Are Skipped by Default

For the integrated messaging runtime (including the Generic Receiver Determination and Interface Determination flows), retries are skipped and messages go straight to the DLQ in these cases:

Partner ID could not be determined.
Configuration option not supported.
Receiver could not be determined when “Receiver Not Found” is set to Error.
Receiver interface could not be determined.

For all other error cases (in these components), the standard retry handling applies.

Tuning Skip Retries in Generic Outbound Processing

For the Generic Outbound Processing flow, you can fine-tune how skip retry handling works. Two control levels exist:

Global settings (apply to all copied Generic Outbound flows—unless overridden)
Scenario-specific settings (per integration scenario via Partner Directory)

By default, the global skip is enabled:

Parameter: SkipRetriesGlobal_Enabled = true

Configuration options

Option	How to Activate	What it does	When to use?
Default (Hard-coded)	`SkipRetriesGlobal_Source = Default`	Skips retries only for Mapping errors (`com.sap.xi.mapping.camel.XiMappingException`)	Good baseline if mapping errors are your main non-transient case
Global via Value Mapping	`SkipRetriesGlobal_Source = ValueMapping` and deploy the “Pipeline V2 - Value Mapping - Skip Retry Configuration”	Centralizes per-exception-class settings in a value mapping	When you want one global control point for all scenarios
Global via Partner ID Profile	`SkipRetriesGlobal_Source = PartnerDirectory` plus a Partner ID profile	Lets you define a skip-retry profile (exception classes set to true) and reuse across copies of the outbound flow	Ideal for multi-unit tenants where each unit needs its own profile
Scenario-specific Profile	Set `SkipRetriesProfile` on the Partner ID that represents the scenario	Overrides global settings just for that scenario	When certain scenarios need stricter or looser retry rules

Examples

Example 1: Mapping Errors

Symptoms:

Messages fail with mapping exceptions.
Reprocessing without changing the mapping yields the same error. Messages can't be edited directly as they could be done in SAP Process Orchestration.

Setup:

Keep SkipRetriesGlobal_Enabled = true
Keep SkipRetriesGlobal_Source = Default

Result:

Mapping exceptions (com.sap.xi.mapping.camel.XiMappingException) go straight to DLQ.
The Integration/Operations teams can focus on either fixing the mapping or fixing the functional data.

Example 2: Receiver Not Found

Scenario:

You enforce strict routing rules—if a receiver cannot be determined and “Receiver Not Found” is set to Error, there is no fallback.

Result:

Integrated messaging runtime already skips retries and puts the failure in DLQ. No extra config required.

Example 3: Scenario-based Retry Profiles

Attach profiles to scenarios so each scenario can apply its own skip behavior without duplicating flows.

Scenario:

Scenario A (“Order-to-Cash Outbound”): skip retries for mapping errors only.
Scenario B (“Billing to CRM”): skip retries for mapping errors and known and expected script failures

Setup (Partner Directory profiles):

Create profile “SkipProfile_Scenario_O2C”: set com.sap.xi.mapping.camel.XiMappingException = true.
Create profile “SkipProfile_Scenario_BillingCRM”: set com.sap.xi.mapping.camel.XiMappingException = true and javax.script.ScriptException = true.
On the Partner ID for “Order-to-Cash Outbound”:
- SkipRetriesProfile = SkipProfile_Scenario_O2C
On the Partner ID for “Billing to CRM Sync”:

SkipRetriesProfile = SkipProfile_Scenario_BillingCRM

Result:

Scenario A (“Order-to-Cash Outbound”) skips only mapping exceptions and retries everything else as usual.
Scenario B (“Billing to CRM”) skips mapping and javax.script.ScriptException, while still retrying potentially transient connection issues (for example, timeouts).

Example 4: A Single Scenario That Needs Stricter Skips

Sometimes one scenario needs stricter rules than the rest. A classic case: SOAP faults on partner onboarding, where the fault usually means the payload or contract is wrong and no amount of retrying is going to change that.

Scenario:

“Partner Onboarding (SOAP)” must never retry on SOAP faults because these typically point to permanent contract or payload issues.

Setup:

Create a skip-retry profile "SkipProfile_Scenario_OnboardingStrict" with org.apache.cxf.binding.soap.SoapFault = true.
In the Partner ID representing this scenario, add:
- SkipRetriesProfile = SkipProfile_Scenario_OnboardingStrict

Result:

Only this scenario overrides the global policy and skips org.apache.cxf.binding.soap.SoapFault.

Configuration Options and Behavior

1) Default (Hard-coded)

In your Generic Outbound Processing flow:
- SkipRetriesGlobal_Enabled = true
- SkipRetriesGlobal_Source = Default

Behavior: Only mapping exceptions skip retry (class com.sap.xi.mapping.camel.XiMappingException).

2) Global Value Mapping

Set SkipRetriesGlobal_Source = ValueMapping.
Prerequisite: Deploy “Pipeline V2 - Value Mapping - Skip Retry Configuration” from the “Cloud Integration Pipeline - Templates” package.
Default behavior of the value mapping:
- com.sap.xi.mapping.camel.XiMappingException → true
- All other exceptions → false
To add/adjust behavior, edit values in the value mapping and redeploy.

When to choose: You want one centralized table to govern skip behavior across the tenant. Note you can't deploy a copy of the provided value mapping with the same combination of agency and scheme, choose this option if you like to customize the skip retry handling globally across all scenarios.

3) Global Partner ID Profile (via Partner Directory)

Create a Partner ID that acts as your global skip-retry profile.
Add one string parameter per exception class to skip:
- Parameter ID = fully qualified exception class name
- Value = true
In your Generic Outbound flow:
- SkipRetriesGlobal_Source = PartnerDirectory
- SkipRetriesGlobal_SourcePidProfile = <YourProfileName>

You can quickly bootstrap this profile from the value mapping using the helper iFlow (below).

Helper iFlow: Auto-generate a Profile From the Value Mapping

Use “Pipeline v2 - Partner Directory Upload Helper - Skip Retry Configuration.”
Prerequisites:
- In SAP BTP Cockpit Create a Service Instance for “SAP Process Integration Runtime” with plan apias described on SAP Help Portal and a corresponding service key. The required role for the service instance is AuthGroup_TenantPartnerDirectoryConfigurator.
Configure and deploy with:
- API_URL = tenant-specific OData API URL (from your service key)
- API_Credential_Alias = alias of the OAuth2 Client Credentials
- PartnerDirectory_PID = target profile name (default SAP_Integration_Suite_SkipRetryGlobalProfile)
- ValueMapping_TechnicalID = com.sap.integration.cloud.pipeline.v2.value.mapping.skipretry (default)
- ValueMapping_Version = 1.0.1 (default)

The helper runs once per deployment, creates the Partner Directory profile, reads the value mapping, and writes exception class parameters with true/false. You can fine-tune afterward.

4) Scenario-specific Profile (Overrides Global)

First, create a skip-retry profile in Partner Directory (as above).
In the Partner ID representing your scenario, add:
- SkipRetriesProfile = <YourScenarioProfile>

This setting overrides any global policy for that scenario.

Points to consider

Don't over-skip:
- Timeouts, throttling, HTTP 5xx from backends usually resolve themselves on the next attempt. If you put these exception classes in the skip list, you’ll create incidents that would have healed on their own.
Copying value mappings incorrectly:
- You can’t deploy a copy with the same agency/scheme. If you need variety across teams, prefer Partner Directory profiles.
Forgetting scenario overrides:
- If a SkipRetriesProfile is set on a scenario’s Partner ID, it overrides global behavior—document and audit these.
Nobody's watching the DLQ
- Skipping retries only helps if someone watches and acts on the DLQ. Ensure processes for analysis, ticketing, and replay are in place. If you’d rather park these messages somewhere other than the DLQ, take a look at the Process Integration Pipeline Extension - Restart via Data Store Community Package that allows you to store the messages in Data Stores. There’s a separate blog post covering it.

Configuration Summary

Global default (hard-coded):

SkipRetriesGlobal_Enabled = true

SkipRetriesGlobal_Source = Default

Global via Value Mapping:

SkipRetriesGlobal_Enabled = true

SkipRetriesGlobal_Source = ValueMapping

Global via Partner Directory:

SkipRetriesGlobal_Enabled = true

SkipRetriesGlobal_Source = PartnerDirectory

SkipRetriesGlobal_SourcePidProfile = SAP_Integration_Suite_SkipRetryGlobalProfile // or your profile

Scenario-specific override (on the scenario’s Partner ID):

SkipRetriesProfile = <YourScenarioProfile>

FAQs

What happens to skipped messages?
- They go straight to the Dead Letter Queue (DLQ), where you can analyze and replay after fixing the cause. These messages will have the Custom Status "RetrySkipped".
Can I combine global and scenario-specific settings?
- Yes. The scenario-specific profile overrides the global setting for that scenario only.
What’s the fastest way to create a global profile?
- Use the helper iFlow “Pipeline v2 - Partner Directory Upload Helper - Skip Retry Configuration” to auto-generate a Partner Directory profile from the value mapping.
Do I need to copy the value mapping to change it?
- No. Use the provided “Pipeline V2 - Value Mapping - Skip Retry Configuration” and adjust mapped values. If you need different configuration by unit or flow, use Partner Directory profiles.

Wrap-up

The "Skip Retry Handling" feature helps you avoid retrying messages that will never succeed. There are three ways to set it up:

Stick with the defaults: Mapping errors get skipped automatically. No additional configuration required.
Use Value Mapping: One place to control skip behavior across the whole tenant.
Use Partner Directory profiles: Best when different scenarios or teams need different rules.

Start with whatever’s closest to your setup and adjust as you learn which errors in your landscape actually need to be skipped.

Migrating Interfaces with Dynamic Configuration (ASMA) from SAP PO to SAP Integration Suite

2026-07-17T11:50:36.016000+02:00

Migrating Interfaces with Dynamic Configuration (ASMA) from SAP Process Orchestration to SAP Integration Suite

This article explains how to migrate integration interfaces that rely on Dynamic Configuration (Adapter-Specific Message Attributes, ASMA) from SAP Process Orchestration (PO) to SAP Cloud Integration. It covers the technical root cause, a practical step-by-step migration approach, and the PO library dependencies involved.

What Is ASMA (Adapter-Specific Message Attributes)?

When running integration scenarios in SAP Process Orchestration, integration developers often need to pass dynamic, context-specific values — such as a target filename, a dynamic URL path, or a SOAP action — from the sender adapter through the integration logic to a receiver adapter. The mechanism that enables this in SAP PO is called Adapter-Specific Message Attributes (ASMA).

ASMA values are carried in a special container called Dynamic Configuration, which travels with the message throughout the SAP PO pipeline. They can be read and written in three ways:

UDF in Message Mapping: In User-Defined Functions (UDFs) within a message mapping using the Java API: DynamicConfiguration, DynamicConfigurationKey, StreamTransformationConstants.DYNAMIC_CONFIGURATION.
Java Mapping: In a standalone Java Mapping class that extends AbstractTransformation, using input.getDynamicConfiguration() to read or write ASMA values directly on the TransformationInput object.
XSLT Mapping: Via the SAP XI Mapping API extension functions provided by the SAP XML Toolkit. These extension functions allow an XSLT stylesheet to call into the Dynamic Configuration container to read and write ASMA values at runtime.

Core API Dependencies for Dynamic Configuration

Dynamic Configuration API depends on two specific JAR files that are part of the Process Orchestration runtime.

JAR File	Key Classes Provided	Purpose
com.sap.xpi.ib.mapping.lib.jar	AbstractTransformation, TransformationInput, TransformationOutput, StreamTransformationException, AbstractTrace	Core mapping framework. All Java Mappings must extend AbstractTransformation and implement the transform() method.
com.sap.xi.mapping.tool.lib_api.jar	DynamicConfiguration, DynamicConfigurationKey, StreamTransformationConstants	Dynamic Configuration API. Provides the typed container for reading and writing Adapter-Specific Message Attributes by namespace/attribute key.

So, how to migrate an Interface with ASMA Using the SAP Integration Suite capability?

1. Create a Data Extraction in Migration Assessment (https://help.sap.com/docs/integration-suite/sap-integration-suite/migration-assessment)

Run Migration Assessment first to connect to your SAP PO system, extract all integration artifacts, and evaluate each scenario. As we will explore in this post, extracting this data reveals both the complexity and the use of Dynamic Configuration.

Rules identified:

GMMCustomUDFUsageCount
GMMCustomUDFDynamicConfiguration
JAVAMDynamicConfiguration

2. Migration Tooling (https://help.sap.com/docs/integration-suite/sap-integration-suite/migration-tooling?q=migration+tool)

Using the assessment results as input, proceed with the Migration Tool for scenarios classified as "Ready to migrate" or "Adjustment required." The tool semi-automatically generates iFlows in SAP Integration Suite based on templates derived from the SAP PO configuration.

3.Outcome & Validation

After the migration, validate the migrated iFlows. The combined use of both tools ensures a structured, risk-reduced, and cost-efficient transition from SAP PO/PI to SAP Integration Suite.

What Happens When You Migrate the Interfaces with ASMA

Let's have a look at this demo scenario:

1. Request Payload

2. Processing Logic

Java mapping reads the input message, gets "action" and puts it into Dynamic Configuration attribute "THeaderSOAPACTION".
XSLT Mapping converts the input into message into target format and store tag "message" into Dynamic Configuration attribute "inputMessage".
Receiver Communication Channel sets the Dynamic Configuration attribute "THeaderSOAPACTION" into SOAPAction.
Once the target system processes the message, there is a Graphical Mapping with “User Defined Functions (UDF)”. This function assign values coming from Dynamic Configuration Attributes, "THeaderSOAPACTION" and "inputMessage", and puts into the tags "dynAction" and "inputMessage" respectivelly.

3. Response Payload

Once the interface is migrated, you will find in your Integration Suite package the artifacts generated based on your SAP PO objects.

Check the Interface (flow). You will see boxes representing the logic that was defined on your SAP PO with wrapper functions depending on your ASMA use case.

JAVA MAPPING (Using Dynamic Configuration) – A wrapper class is generated by the Migration tool by default to provide temporary compatibility. While you can override the Java method to retain Dynamic Configuration logic, this approach is not recommended for production use. The preferred approach is to replace the Dynamic Configuration calls with message headers as described in the adaptation section below.

XSLT MAPPING (Using Dynamic Configuration) - The migrated XSLT artifact retains the SAP XI Mapping API calls. These must be adapted to use Cloud Integration-native header access mechanisms.

GRAPHICAL MAPPING (Using Dynamic Configuration) - UDFs referencing the Dynamic Configuration API are migrated as-is and will require manual adaptation.

How to Adapt ASMA-Based Interfaces for Cloud Integration

Evaluate your scenario — Identify all ASMA usages across Java Mappings, UDFs, and XSLT stylesheets. The Migration tool does not replace Dynamic Configuration logic.

Understand how messages are processed by Cloud Integration. "Dynamic Values” are passed via named message headers or properties (set by a Content Modifier or Groovy Script step) not via a Dynamic Configuration container.

In SAP Cloud Integration, the correct mechanism for passing dynamic values through an integration flow is via message headers or exchange properties. These are set in dedicated flow steps before the mapping executes and then referenced in the mapping logic or adapter configuration.

Concept	SAP PO (Examples)	SAP Cloud Integration (Examples)
Dynamic value container	Dynamic Configuration (ASMA)	Message Headers Exchange Properties
How values are set	Java DynamicConfiguration.put()	Content Modifier Groovy Script setProperty() / setHeaders()
How values are read in mapping	Java DynamicConfiguration.get()	Content Modifier Graphical Mapping out-of-the-box functions to getProperty and getHeader Groovy Script getProperty() / getHeaders()
Dynamic adapter config	Adapter reads ASMA by namespace + attribute key	Adapter uses expression ${header.HEADER_NAME} or ${property.PROPERTY_NAME}

Therefore, if an imported mapping uses Dynamic Configuration APIs for accessing Adapter-Specific Message Attributes, the integration flow must be manually adjusted to ensure correct execution.

References	Links
Creating Message Mapping as an Artifact	https://help.sap.com/docs/integration-suite/sap-integration-suite/developing-message-mapping-as-artifact?locale=en-US
Headers and Exchange Properties Provided by the Integration Framework	https://help.sap.com/docs/cloud-integration/sap-cloud-integration/headers-and-exchange-properties-provided-by-integration-framework
Access Headers and Properties in Scripts	https://help.sap.com/docs/integration-suite/sap-integration-suite/access-headers-and-properties-in-scripts

Let's Review the Integration Flow Imported in the Previous Steps and Look into Adaptations

1. Java Mapping Replacement: A Content Modifier step is added before the mapping to set the SOAPAction message header and store the inputMessage value into message property. This replaces the Dynamic Configuration to write operations previously performed in Java Mapping.

2. XSLT Mapping: Remove Dynamic Configuration functionalities

3. Graphical Mapping: UDFs adapted to use out-of-the-box functions instead of the Dynamic Configuration API.

Additionally, for XI Adapter, Natively Supports ASMA

The XI adapter in Cloud Integration natively supports Adapter-Specific Message Attributes. The XI sender adapter automatically creates a pair of exchange properties for each ASMA: one holding the value and one holding the namespace. When configuring ASMAs for the XI receiver adapter, both properties must be explicitly created.

For scenarios using the XI adapter, the migration of ASMA-based logic can therefore be automated. For other adapter types, a similar approach applies, with the key distinction that the namespace property is typically not required. It is specifically needed by the XI receiver adapter, but not by other adapters.

In pipeline-based integration approaches this is handled automatically within the generic XI inbound and XI outbound flows. Since exchange properties are not passed between flows, corresponding headers are created at the XI inbound step and then converted back to properties at the XI outbound step.

For further details, see:

References	Links
Generic Inbound and Outbound	Generic Inbound and Outbound \| SAP Help Portal

Summary

Migrating integration scenarios that use Dynamic Configuration (ASMA) from SAP Process Orchestration to SAP Integration Suite requires a multi-step approach.

The recommended migration path combines two capabilities of SAP Integration Suite: Migration Assessment, to identify all affected integration scenarios and quantify ASMA usage through rules such as GMMCustomUDFDynamicConfiguratiom, GMMCustomUDFUsageCount and JAVAMDynamicConfiguration; and the Migration Tool, to semi-automatically generate iFlows from existing SAP PO artifacts.

However, automated migration alone may not be sufficient. Depending on how Dynamic Configuration was used, each mapping type may requires targeted manual adaptation.

By combining the structured assessment and tooling capabilities with these targeted adaptations, teams can achieve a controlled, risk-reduced migration from SAP PO/PI to SAP Integration Suite while preserving the intended runtime behavior of each interface.

How to Enable Checkboxes for Configuration Parameters in SAP Cloud Integration

2026-07-17T17:10:18.492000+02:00

Introduction:

In this blog, I will first demonstrate how to control payload logging using an externalized parameter with true/false values. Then, I will replace the text-based parameter with a checkbox and show how to achieve the same functionality in a more intuitive and user-friendly way.

Part 1: Using a Text-Based Externalized Parameter to Control Payload Logging

In the example below, I have added a Content Modifier to declare the Exchange Property enableLog, which will be used to control payload logging.

The enableLog parameter has been externalized with a default value of true.

Next, I use the enableLog parameter in the Groovy script to determine whether the payload should be logged. Based on the configured value (true or false), the script either logs the payload or skips the logging step.

Important: Although the externalized parameter is configured with the values true or false, SAP Cloud Integration passes the value to the Groovy script as a String, not as a Boolean. Therefore, you should explicitly compare the value of enableLog with the string "true" (or "false"). This comparison returns a Boolean result, which can then be used directly in the if condition to control the logging logic.

I configured the externalized parameter enableLog with the value true. Since the condition evaluated to true, the Groovy script logged the payload successfully, as shown in the example below.

Part 2: Using a Checkbox-Based Externalized Parameter to Control Payload Logging

To follow along with this example, download the artifacts and extract the ZIP file. After extracting it, navigate to the following directory:

CheckBox\src\main\resources

This folder contains the files that need to be modified to enable checkbox-based externalized parameters.

Modify the parameter type from string to boolean, as shown below. This change instructs SAP Cloud Integration to render the externalized parameter as a checkbox instead of a text field.

Zip the file as below:

Upload the Zip file as below:

Now you will get the checkbox as below.

Conclusion:

In this blog, we explored two approaches for controlling payload logging in SAP Cloud Integration using externalized parameters. We first implemented the traditional approach with a text-based parameter that accepts true or false values. We then enhanced the solution by changing the parameter type from String to Boolean, which automatically renders it as a checkbox in the configuration.

Using a checkbox provides a cleaner and more intuitive user experience, eliminating the need to manually enter true or false values and reducing the risk of configuration errors. This simple enhancement can be applied to any Boolean configuration parameter in your integration flows, making them easier to configure and maintain.

From Code to Strategy: How MCP, CPI, and Lightweight Agents Unlock AI‑Driven SAP Integrations

2026-07-17T17:58:20.038000+02:00

Introduction

SAP Cloud Platform Integration (CPI) allows enterprises to connect diverse systems through iFlows — integration flows that define how data moves and transforms between endpoints. By combining CPI with the Model Context Protocol (MCP) and a lightweight Agent, we can expose SAP processes as consumable services — enabling seamless orchestration, automation, and intelligent interaction across enterprise systems.

Understanding the Components

SAP Cloud Platform Integration (CPI)

SAP CPI is the integration backbone of the SAP ecosystem. It enables secure, scalable, and real-time data exchange between SAP and non-SAP systems. In this architecture, CPI acts as the execution layer, where business logic resides. The iFlow processes requests coming from the MCP Server, performs necessary transformations, and interacts with SAP backend systems such as S/4HANA, SuccessFactors, or Finance modules.

In the AI world: CPI provides the structured data foundation that intelligent agents rely on. By exposing iFlows as APIs, it allows AI systems to access enterprise data securely and contextually — bridging traditional ERP with modern AI-driven automation.

Model Context Protocol (MCP) Server

The MCP Server is the middleware bridge between the Agent and SAP CPI. It defines “tools” — essentially API endpoints — that the Agent can call to trigger specific SAP processes. It handles authentication, routing, and error management, ensuring that requests from the Agent are properly formatted and securely transmitted to CPI.

In the AI world: MCP acts as the contextual translator between natural language and enterprise APIs. It enables AI agents to understand what business functions are available and how to invoke them, making enterprise systems conversational and intelligent.

Copilot Agent

The Agent is the frontline interface — a lightweight application (built with FastAPI or similar frameworks) that interacts with users or other systems. It consumes the MCP tools and provides a simple way to trigger SAP processes, either through a web UI or API calls.

In the AI world: The Agent represents the intelligence layer — capable of interpreting user intent, orchestrating workflows, and connecting to enterprise data through MCP and CPI. It’s the component that transforms static APIs into dynamic, AI-driven interactions.

Key Steps

1. Expose the iFlow in SAP CPI

Design and deploy your iFlow (e.g., invoice retrieval or employee data).
Ensure it’s accessible via HTTPS with proper authentication.

2. Create the MCP Server

Define tools mapping to CPI endpoints.
Configure the MCP server to expose these tools securely.
Example endpoint: http://localhost:8000/tools/sayHello

3. Consume with an Agent

Build a lightweight Agent using FastAPI.
Connect it to the MCP server and expose an endpoint like http://localhost:9000/agent/sayHello.
Provide a simple UI for users to trigger CPI processes.

Tools Used

SAP CPI → iFlow design and deployment
MCP Server → Tool definition and orchestration
FastAPI → Agent development
OAuth2 / SAP IAS → Authentication and security

Architecture Overview

Embed your architecture diagram here showing the flow: User → Copilot Agent → MCP Server → SAP CPI → SAP Backend Systems

Figure 1: End-to-end architecture connecting the Agent, MCP Server, and SAP CPI iFlow.

Step: Create a Simple iFlow in SAP CPI

Design a basic iFlow in SAP Cloud Platform Integration (CPI) that accepts a name as input payload and returns a greeting message. For example, if the payload contains "Dibyajyoti", the iFlow should respond with "Hello Dibyajyoti".

Once the development is complete, deploy the iFlow to generate the endpoint URL. This URL will be used later by the MCP Server and Copilot Agent to invoke the iFlow and integrate it into the overall architecture.

"https://<SUBACCOUNT>.it-cpitrial06-rt.cfapps.us10-001.hana.ondemand.com/http/hello"

Step 2: Test the iFlow Endpoint in Postman

Once the iFlow is deployed in SAP CPI, you’ll receive an endpoint URL. To validate it, use Postman:

Open Postman and create a new request.
Set the method to POST (or GET, depending on your iFlow design).
Enter the endpoint URL generated during deployment (e.g., https://cpi.example.com/http/endpoint/sayHello).
Authentication:
- Username → Client ID
- Password → Client Secret These credentials are provided when you configure the CPI tenant and are required for secure access.
Payload:
- In the request body, pass the input JSON or text payload (e.g., { "name": "Dibyajyoti" }).
Send the request and verify the response.
- Expected output: Hello Dibyajyoti

Step 3: Set Up the MCP Environment

Before working with the MCP Server, ensure your development environment is ready. You’ll need the following installed on your system:

Python (version 3.9 or above recommended)
PIP (Python package manager)
Visual Studio Code (for editing and running your project)

Step 4: Create the Project Folder Structure

To organize your MCP setup, create the following folders:

Main Project Folder
- Name: MCPPROJECT
Subfolders inside MCPPROJECT
- SAP_MCP_SERVER → Contains the MCP Server files (server.py, .env, requirements.txt)
- COPILOT_AGENT → Contains the Agent files (agent.py, templates/index.html, requirements.txt)

SAP_MCP_SERVER

.env---->

requirements.txt---->

server.py---->

COPILOT_AGENT

requirements.txt------>

agent.py------->

create a subfolder

index.html--------->

Step 5: Run the MCP Server and Copilot Agent

Inside `sap_mcp_server`

Install dependencies and start the MCP Server:

pip install -r requirements.txt
uvicorn server:app --reload --port 8000

pip install -r requirements.txt → Installs all required Python packages.
uvicorn server:app --reload --port 8000 → Launches the MCP Server on port 8000 with auto-reload enabled.

Inside `copilot_agent`

Install dependencies and start the Copilot Agent:

pip install -r requirements.txt
uvicorn agent:app --reload --port 9000

pip install -r requirements.txt → Installs Agent dependencies.
uvicorn agent:app --reload --port 9000 → Launches the Agent on port 9000 with auto-reload enabled.

Test the Agent

Once both services are running, open the Agent URL in your browser:

http://localhost:9000/

This will load the Agent’s web interface, allowing you to trigger the MCP tools and ultimately invoke the SAP CPI iFlow.

Conclusion

By exposing SAP CPI iFlows through an MCP Server and consuming them with an Agent, enterprises can create a modular, API-driven integration layer. This approach simplifies access to SAP processes, improves reusability, and lays the foundation for AI-powered enterprise automation — where intelligent agents can interact with SAP systems naturally, securely, and efficiently.

Regards,

Dibyajyoti Nanda

https://www.linkedin.com/in/dibyajyoti-nanda-23907429/

Implementing Dual Schedulers in a Single SAP Integration Suite iFlow: Supporting Ad Hoc and Schedule

2026-07-17T20:05:32.106000+02:00

Recently, SAP Cloud Integration (CPI) introduced support for multiple Integration Processes in a single iFlow, enabling scenarios like separate scheduled and ad hoc execution paths.

The iFlow below uses two schedulers. The first scheduler is dedicated to ad hoc execution, while the second scheduler handles the regular scheduled execution.

Case 1: Normal Schedule

The iFlow runs as per the configured schedule using the regular scheduler.

Case 2: Ad Hoc Run and Automatic Switch Back to Normal Schedule

The iFlow can be triggered for an ad hoc run without modifying the regular scheduler. After the ad hoc execution is completed, the iFlow continues with the normal scheduled run automatically. Ad hoc run happen at 9.12. and as you can see it automatically trgerring every 5 min.

Conclusion

Using two schedulers in a single SAP CPI iFlow provides a reliable way to handle both ad hoc and scheduled executions. It eliminates manual scheduler changes, reduces operational risks, and ensures that regular scheduled processing continues without interruption.

Integration Suite: Building an MCP Server for a SAP CI Monitoring Assistant

2026-07-17T20:13:23.354000+02:00

Introduction

In SAP Integration Suite, Message Processing Logs (MPL) are the primary tool for monitoring and troubleshooting interfaces. Whenever something fails, the same routine follows: log into the tenant, open Monitor, filter by artifact, drill into the failed message, read the error. In my previous blogs I looked at ways to make this easier — automating email alerts for failed interfaces, logging custom header properties for better MPL search, and storing logs in Database for long-term retention.

Now we are taking it a step further. SAP recently released the MCP Server capability in Integration Suite, which lets you expose any API as a set of tools that an AI agent can discover and call at runtime. So instead of clicking through the Monitor, you can simply ask an assistant in natural language — "show me all failed messages in the last 2 hours" or "why did the XYZ interface fail?" — and let it query the tenant for you.

In this blog we will build a CI Monitoring Assistant: a generic, reusable MCP Server that sits on top of the SAP Cloud Integration OData API and can be consumed from any MCP-compatible client such as VS Code or Claude Desktop.

What is MCP?

Model Context Protocol (MCP) is an open standard that lets AI agents discover and invoke tools at runtime. You publish an MCP Server — a runtime endpoint that advertises a list of named, described tools — and the agent reads those descriptions to decide what to call and how. No hardcoding of API calls into the agent.

The problem we are solving

Standard MPL monitoring works, but it is entirely manual and click-driven. For operations teams this means:

Every check requires logging into the tenant and navigating the Monitor.
Correlating a failure across artifacts, error text and custom headers takes several drill-downs.
There is no easy way to ask a plain-language question and get a consolidated answer.

The SAP API Hub provides the OpenAPI JSON API specification for the SAP Cloud Integration OData API (MessageProcessingLogs). We retrieve that specification from SAP API Hub and convert it into OpenAPI 3.0 (converted using AI) so it can be used consistently by downstream tools and agents. The MCP Server then exposes the resulting read operations as tools, making monitoring conversational instead of manual.

Prerequisites

Before we start, make sure the following are in place:

Cloud Integration and API Management capabilities activated in Integration Suite.
The Integration Cell runtime enabled — go to Settings → Runtimes and confirm it shows Active. The MCP Server artifact runs on Integration Cell; it cannot be deployed to the classic Cloud Integration runtime.
- MCP is available only in premium and enhanced edition plans, and in trial accounts.
The PI_Integration_Developer role collection assigned to your user in the BTP Cockpit.

If any capability or runtime is missing, activate it first — the MCP Server option will not appear until Integration Cell is running.

Solution overview

At a high level, the flow looks like this:

VS Code / Claude Desktop  (MCP client)
        |  MCP protocol
        v
   MCP Server artifact  (Integration Cell)
        |  HTTPS + CI OAuth
        v
   CI OData API  (MessageProcessingLogs)
        |
        v
   Your SAP Cloud Integration tenant

The MCP Server is created from an HTTP Endpoint with an OpenAPI 3.0 specification. We import the OpenAPI JSON that describes the monitoring operations, choose which operations become tools, add prompts and resources, configure the HTTPS adapter to authenticate to CI using OAuth, and deploy. The client then connects using a runtime service key.

Step-by-step guide

Step 1 – Enable the required capabilities

Activate Cloud Integration, API Management, and the Integration Cell runtime. Confirm under Settings → Runtimes that Integration Cell shows Active. This is the single most common blocker — the MCP Server artifact type will not be selectable otherwise.

Step 2 – Prepare the OpenAPI 3.0 JSON

The MCP Server needs an OpenAPI 3.0 specification. Each operationId in the spec becomes a tool name the agent can discover, and each description is what the agent reads to decide when and how to use the tool — so write the descriptions for the agent.

download - mcp-ci-message-processing-logs-openapi-3.0.json

Step 3 – Create the MCP Server artifact

Go to an existing or new Integration Package and create a new artifact of type: MCP Server. When prompted for the source type, choose HTTP Endpoint with OpenAPI Specification and upload the OpenAPI 3.0 JSON file you downloaded in Step 2. The wizard imports the spec and generates a list of tools from your operations.

Step 4 – Select tools, resources and prompts

Tools – select the operations you want to expose. Review the generated tool name and description for each; refine descriptions so the agent understands intent. (Max 15 tools can be selected per MCP Artifact)

Resources – add any static reference content the agent may need (for example, a list of interface names or a status-code cheat sheet). This is optional but improves answer quality.

Prompts – provide reusable prompt templates, e.g. "Summarise all failures in the last 2 hours grouped by interface." These give end users a guided starting point.

Step 5 – Create two runtime service keys (CI OData API + MCP Client Auth)

This solution needs two separate OAuth credentials, because two different calls happen and they use different Process Integration Runtime service plans:

CI OData Monitoring API (plan api) → used inside the MCP Server by the HTTPS receiver adapter to read Message Processing Logs.
MCP Client Authentication (plan integration-flow) → used by the AI client (VS Code / Claude Desktop) to authenticate to the deployed MCP Server endpoint.

Both are created from the Process Integration Runtime service in your BTP subaccount.

5a. Service key for the CI OData Monitoring API (plan: `api`)

This is the credential the HTTPS adapter uses in Step 6 to read monitoring data.

In your BTP subaccount, go to Instances and Subscriptions → Create.
Select service Process Integration Runtime, plan api and give the instance a name (e.g. it-rt-api-odata).
On the Parameters step, add the monitoring-read role — MonitorDataRead (this grants read access to Message Processing Logs and related monitoring entities). Keep the grant type as Client Credentials and create it.
On that instance, create a service key (e.g. it-rt-api-key-odata).
From the service key, copy clientid, clientsecret, tokenurl (and the API url/host). These go into the Security Material referenced by the HTTPS adapter in Step 6.

Use only MonitorDataRead here — the assistant is read-only, so there is no reason to grant write or admin roles to the credential that reaches your monitoring data.

5b. Service key for MCP client authentication (plan: `integration-flow`)

This is the credential the AI client uses in Step 8 to call the deployed MCP Server endpoint on Integration Cell.

In your BTP subaccount, go to Instances and Subscriptions → Create.
Select service Process Integration Runtime, plan integration-flow and give the instance a name (e.g. it-rt-iflow-mcp).
On the Parameters step, add the role API.invoke (required to invoke the deployed MCP endpoint). Keep the grant type as Client Credentials and create it.
On that instance, create a service key (e.g. it-rt-iflow-key-mcp).
From the service key, copy clientid, clientsecret and tokenurl . These are the credentials you enter in the MCP client (VS Code / Claude Desktop) to obtain an access token and call the MCP Server.

Step 6 – Configure the HTTPS adapter with CI OAuth

This is the authentication link between the MCP Server and the CI OData Monitoring API. Here you deploy the OAuth credential you created in Step 5a as a Security Material, then reference it in the HTTP receiver adapter of the MCP Server.

1. Deploy the Step 5a credentials as a Security Material - In Integration Suite, go to Monitor → Integrations and APIs → Manage Security → Security Material → Create → OAuth2 Client Credentials. Fill in the values from your Step 5a service key. Save and deploy it. This keeps the CI credentials inside Integration Suite, away from the agent.

2. Update the HTTP receiver adapter in the MCP Server - Open the MCP Server artifact and edit the HTTP receiver connection that points to the CI OData Monitoring API:

Set Authentication to OAuth2 Client Credentials.
In Credential Name, select the Security Material you just deployed.

Save the changes. The MCP Server will now use the Step 5a OAuth credential to authenticate every call it forwards to the CI Monitoring API.

Step 7 – Deploy the MCP Server

Once tools, resources, prompts and authentication are configured, deploy the artifact. Deployment provisions the runtime endpoint on Integration Cell and makes the tools available for discovery. Wait for the status to show as deployed/active. Note down the MCP Server endpoint URL — the MCP path must be unique.

Step 8 – Test with MCP Client (VS Code / Claude Desktop)

Now connect an MCP client. You need two things:

MCP Server URL – the endpoint of your deployed MCP Server. Get it from Monitor → Manage Integration Content on the Integration Cell runtime: open the deployed MCP Server artifact and copy its endpoint URL.
Authentication – the OAuth credentials from your Step 5b service key: clientid, clientsecret and tokenurl.

Add these to your MCP client configuration:

Claude Desktop – add the MCP Server to the configuration file with the endpoint URL and the Step 5b OAuth credentials (client ID, client secret, token URL). Restart Claude Desktop; the tools should appear as available

VS Code – add the MCP Server in your MCP settings (or your extension's config), pointing to the same endpoint URL and Step 5b credentials.

Once connected, the client fetches a token from the token URL using the client Id and secret, then uses it to call the MCP Server. The server discovers your tools, and you can start asking questions in natural language:

"List all failed messages in the last 2 hours."
"Show the error details for the last failure of the OrderToCash interface."
"Find messages where the PO number custom header equals 4500001234."

The agent picks the right tool, calls the MCP Server, which forwards the request to the CI Monitoring API using the OAuth credentials, and returns a consolidated answer — no clicking through the Monitor.

Future Enhancements

Extend to more OData APIs – The Cloud Integration OData API exposes far more than Message Processing Logs. Using the exact same steps in this blog, you can build multiple MCP Servers — each wrapping a different API — to create, deploy, undeploy, update, or delete artifacts, parameters, and security materials conversationally.
Govern write access carefully – This MCP server is deliberately read-only. The moment you expose write operations the agent can change your tenant, so grant each service key only the minimum role, keep it off production first, and add human confirmation before any destructive action.
No rate limiting or payload protection is added in this basic setup. For production, put the API Artifact / MCP Gateway governance layer in front (rate limiting, audit logging, IP blocking).
Move to the SAP MCP Hub – SAP is building a centralized, no-code MCP Hub (announced Q4 2025, planned GA in H1 2026) that removes the need for each team to build and maintain its own MCP Servers. It handles cross-cutting concerns like security, authorization, observability, and protocol versioning centrally, and adds no-code OData/OpenAPI-to-MCP conversion, modular servers that combine tools from multiple APIs, destination-based connectivity, AI-assisted tool optimization, built-in validation, and a test chat. Once available, migrating this assistant to the MCP Hub is the natural next step.
MCP on Integration Suite is a new capability and is evolving quickly; screens and options may differ slightly from what you see when you try it. Check the SAP Help Portal (Design APIs and MCP Servers) for the latest.

This blog provides a basic, reusable foundation. You can enhance the MCP Server based on your own requirements — more tools, tighter filters, governance policies, or write-back operations behind proper approval.

Reference

One Blog, Two Strategic Topics: API-Centric Integration and MCP Gateway

Conclusion

The MCP Server capability turns SAP Integration Suite monitoring from a manual, click-driven task into a conversational one. By exposing the CI OData Monitoring API as a small set of well-described tools, any MCP-compatible client — VS Code, Claude Desktop, or others — becomes a CI Monitoring Assistant that operations teams can query in plain language.

If you see scope for enhancement in the tool set or the OpenAPI spec, feel free to drop a comment. I would love to hear how you extend it.

Happy Integrating!

Configuring AWS Adapter Authentication: AssumeRole, AssumeRoleWithWebIdentity and IAMRolesAnywhere

2026-07-20T09:05:33.364000+02:00

When integrating AWS with SAP Cloud Integration, AWS Security Token Service (STS) enables the use of temporary security credentials associated with IAM roles. This approach reduces the risks associated with long-lived access keys and improves both the security and manageability of authentication.

In this blog, we will walk through the setup required to enable STS-based authentication for the AWS Adapter in SAP Integration Suite. For the AssumeRoleWithWebIdentity use case, we will use Microsoft Entra ID as an example OpenID Connect (OIDC) identity provider for the web identity federation scenario. We will also cover IAM Roles Anywhere, which enables workloads running outside AWS, such as SAP Integration Suite, to authenticate using X.509 certificates and obtain temporary AWS credentials without relying on long-lived access keys or third-party applications.

The AWS Adapter supports the following STS authentication methods:

STS (AssumeRole) – Allows a trusted AWS principal to assume an IAM role and obtain temporary security credentials.
STS (AssumeRoleWithWebIdentity) – Uses an OpenID Connect (OIDC) identity provider to exchange a web identity token for temporary AWS security credentials.
STS (IAM Roles Anywhere) – Uses X.509 certificates to enable workloads running outside AWS to securely assume IAM roles and obtain temporary AWS credentials.

This blog explains the configuration steps required for all approaches.

Let's start with STS (AssumeRole), which requires the least amount of configuration among the three authentication methods. In this approach, you create an IAM role that can be assumed by an IAM user. The IAM user's access key and secret key, together with the Role ARN, are then used to configure authentication in the AWS Adapter.

1. STS (AssumeRole) Setup

This setup directly links a role to an IAM user. No Azure configuration is required.

Create IAM Role
1. In AWS IAM, navigate to Roles and choose Create role.
2. Select AWS account as the Trusted entity type.
3. Specify the trusted AWS account ID that will be allowed to assume the role.
4. Attach the required permission policies (for example, AmazonS3ReadOnlyAccess).
5. Enter a role name and any optional description.
6. Review the configuration and choose Create role.
Update the Trust Relationship
1. After creating the role, open it in the IAM console and navigate to the Trust relationships tab.
2. Choose Edit trust policy.
3. Update the policy to include the ARN of the IAM user (or principal) that is allowed to assume the role under the Principal element.
4. Save the changes to update the trust relationship.
Example trust policy JSON:
```
{
"Version": "2012-10-17", "Statement":[
{ "Effect": "Allow",
"Principal":
{
"AWS": "arn:aws:iam::123456789012:user/demo-sts-user"
},
"Action": "sts:AssumeRole"
}
]
}
```

One of the most common causes of authentication failures is an incorrectly configured trust policy. This can happen if the IAM user is not added to the Principal element or if an External ID is required by the trust policy but is omitted from the AWS Adapter configuration.

As the final step, create a Secure Parameter security artifact in SAP Cloud Integration (CI) to securely store the Role ARN Alias. This alias can then be referenced in the AWS adapter configuration.

Next, we'll look at STS (AssumeRoleWithWebIdentity), which enables users authenticated by a third-party OpenID Connect (OIDC) identity provider to obtain temporary AWS credentials without requiring long-term AWS access keys.

2. STS (AssumeRoleWithWebIdentity) Setup

This setup uses Microsoft Entra ID (Azure AD) as an example identity provider.

Note: Supported identity providers using OpenID Connect (OIDC) can be used, such as Microsoft Entra ID, SAP IAS, or other compatible Web Identity Providers.

2.1 Microsoft Entra ID Setup

Register Application
1. Go to Microsoft Entra ID → App registrations → New registration.
2. Provide a name, select the supported account types, and register the application.
3. Note down the Tenant ID and Client ID from the overview tab.
Add Client Secret
1. Navigate to Certificates & secrets → New client secret.
2. Create a secret and copy the Secret Value for later use.
Set Application ID URI
1. Go to Expose an API → Application ID URI.
2. Set it to api://<client-id> (This will be set automatically).
Configure Access Token Version
1. In the application Manifest, set requestedAccessTokenVersion to 2.

2.2 AWS IAM Setup (Identity Provider & Role)

Add OpenID Connect Identity Provider
1. Log in to the AWS Management Console and navigate to IAM.
2. In the left navigation pane, select Identity providers.
3. Click Add provider.
4. Configure the identity provider with the following details:
  - Provider Type: OpenID Connect
  - Provider URL:
```
https://login.microsoftonline.com/<tenant-id>/v2.0
```
  - Audience:
```
<client-id>
```
5. Click Add provider to create the OpenID Connect (OIDC) identity provider.
Create IAM Role for Web Identity
1. Log in to the AWS Management Console and navigate to IAM.
2. In the left navigation pane, select Roles.
3. Click Create role.
4. Under Trusted entity type, select Web identity.
5. Configure the trust relationship:
  - Select the previously created OpenID Connect (OIDC) provider.
  - Select the appropriate Audience (<client-id>).
6. Click Next.
7. Attach the required IAM permission policies that grant access to the AWS resources your application or integration needs.
8. Click Next.
9. Enter a Role Name and, optionally, a description.
10. Review the role configuration and click Create role.
11. After the role is created, note the Role ARN, as it may be required for application configuration or role assumption requests.

2.3 SAP CPI Configuration

1. OAuth2 Client Credentials:

In SAP Cloud Integration, navigate to Monitor → Security Material.
Click Add and select OAuth2 Client Credentials.

Maintain the following details:

Name: <Security Artifact Name>

Token Service URL:

https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/token

Client ID:
```
<client-id>
```
Grant Type:
```
Send as Part of Body
```
Client Secret:
```
<client-secret>
```
Scope:
```
api://<client-id>/.default
```
Client Authentication:
```
Send as Body Parameter
```
Content Type:
```
application/x-www-form-urlencoded
```

Save and deploy the security artifact.
Reference this OAuth2 Client Credentials security artifact in the sender or receiver adapter by specifying it in the OIDC Credential Name field.

2. Secure Parameter (Role ARN)

In SAP Cloud Integration, navigate to Monitor → Security Material.
Click Add and select Secure Parameter.
Store the Role ARN from AWS and deploy.
Use the Role ARN Alias in the adapter configuration to enable AWS authentication.

Lastly, we'll look at STS (IAM Roles Anywhere), which enables workloads running outside AWS to assume IAM roles using X.509 certificates and obtain temporary AWS security credentials without relying on long-lived access keys.

3. STS (IAMRolesAnywhere) Setup

Note: In this guide, Keystore Explorer is used to create the certificates required for the IAM Roles Anywhere configuration.

3.1 Create a Key Pair for IAMRolesAnywhere Authentication

Open KeyStore Explorer and create a new KeyStore; select PKCS #12 as the type.
Click on Tools > Generate Key Pair. Retain default selections of RSA and a minimum Key Size of at least 2048 bits.
Select Version 3 in the Generate Key Pair Certificate pop-up window.
Click on

icon to edit name-related details.
Click Add Extensions. You can add Certificate Extensions by clicking on "+".

3.2 Creating Key Pair: CERTIFICATE AUTHORITY

6. For Certificate Authority, add the following extensions.

Basic Constraints = critical, CA = TRUE

Note: The path length constraint in the Basic Constraints extension determines how many subordinate CA levels can exist below a CA certificate. Configure this value based on your intended certificate hierarchy.

b. Key Usage(KU) = Certificate Signing, CRL Sign

c. Subject Key Identifier (SKI) = NOT CRITICAL

Note: Click on the key icon to select a Generation Method.

7. Enter the name as ROOT_CA.
8. Enter and Confirm Password.
9. You will get a message notifying you of Key Pair Creation.

3.3 Creating Key Pair: CLIENT

Note: Repeat Steps 1–5 from the section above, then continue from Step 10 as shown below.

10. For Client Certificate, add the following extensions.

a. Basic Constraints = critical, CA = FALSE

b. Key Usage (KU) = Digital Signature

c. Subject Key Identifier (SKI) = NOT CRITICAL

Note: Click on the key icon to select a Generation Method.

11. Enter the Alias as CLIENT.
12. Enter and Confirm Password.
13. You will get a message notifying Key Pair Creation.

3.4 Fetching the PEM from CERTIFICATE_AUTHORITY

Navigate your ROOT_CA certificate in KeyStore Explorer.
Double-click on the certificate > PEM > Copy.
This will be required at a later step.

3.5 Configurations in AWS

Note: Before proceeding with this section, ensure you have completed the previous steps to create CLIENT and CERTIFICATE_AUTHORITY certificates and copied the PEM.

Fetch the PEM that you copied in the CERTIFICATE AUTHORITY section and paste it in the External certificate bundle while creating the Trust Anchor. For more information, see Create Trust Anchor.
Next, you must update the trust policy to include rolesanywhere.amazonaws.com and create a Profile under Role. For more information, see Configure Role and create Profile.

3.6 Generating the CSR using CLIENT

Navigate to your CLIENT certificate in KeyStore Explorer.
Right-click on the certificate > Generate CSR.
Save it for signing CA later. This will be required at a later step.

3.7 Signing CLIENT using CERTIFICATE_AUTHORITY

Navigate to your ROOT_CA certificate in KeyStore Explorer.
Right-click on the certificate > Sign CSR.
In the Choose CSR dialog, select the CSR created using CLIENT.
In the Sign CSR dialog, click Transfer extensions and click OK.

Note: Transfer Extension allows you to skip the Add Extensions step by copying extensions from the Client.

5. Next, you will see an Export Certificate Chain ‘client‘. Ensure Export Length is selected as Entire Chain and Export Format is X.509.

6. You will be able to see a prompt that notifies you about successful CSR Signing.

Note: A Root CA can sign one or more Intermediate CAs, which can then issue client (leaf) certificates, forming a trusted certificate chain from the leaf certificate to the Root CA

3.8 Importing the CA Reply to CLIENT

Navigate your CLIENT certificate in KeyStore Explorer.
Right-click on the certificate >> Import CA Reply.
Select your .cer file and click Import.
You will get the following prompt if the previous step is successful.
Further, if you double-click on the Client certificate, you can see the hierarchy showing that CLIENT has been signed by ROOT_CA.

3.9 Exporting the Client Certificate

Navigate your CLIENT certificate in KeyStore Explorer.
Right-click on the certificate >> Export Key Pair.
Select Format as PCKS#12 and specify a Password.

Note: You will be required to specify this password during Key Pair upload in SAP Integration Suite.

4. A successful export will be confirmed by the following prompt.

5. The final step is to upload the .pfx file to the SAP Keystore. For more information, see Uploading a Key Pair in SAP Keystore.

Note: All IAM Roles Anywhere resources are regional, and they must be created in the same account and region to be used together.

Conclusion

The authentication method you choose ultimately depends on your organization's security requirements and how workloads outside AWS are expected to access AWS resources. While all three approaches use AWS Security Token Service (STS) to issue temporary security credentials, they differ in how the requesting workload is authenticated.

If your organization already uses IAM users and is comfortable managing long-lived AWS access keys, STS (AssumeRole) is the simplest option. It allows you to combine an IAM user's access key and secret key with a restricted IAM role to obtain temporary credentials, making it a straightforward upgrade from static IAM user permissions.

If your organization wants to eliminate long-lived AWS access keys and already has an OpenID Connect (OIDC) identity provider, such as Microsoft Entra ID or SAP IAS, STS (AssumeRoleWithWebIdentity) is a better choice. It enables workloads to authenticate using identity tokens issued by the trusted identity provider, removing the need to store AWS credentials.

Finally, if your organization prefers not to depend on either long-lived AWS access keys or a third-party identity provider, STS (IAM Roles Anywhere) provides a certificate-based authentication model. Although it requires additional setup to establish a certificate trust chain, it is well-suited for workloads running outside AWS that require strong, certificate-based authentication without relying on external identity providers.

By understanding the strengths and trade-offs of each authentication method, you can choose the approach that best aligns with your organization's security policies, operational requirements, and infrastructure.

Useful functions for XSLT in SAP CPI

2026-07-20T12:05:03.993000+02:00

SAP Integration Suite

Following up on my previous blog post Useful functions for XSLT 2.0 in SAP PO, where we leveraged Java extension calls and standard XSLT features within the Process Orchestration engine, this article addresses a common gap encountered when transitioning to or developing natively in SAP Integration Suite (Cloud Integration / CPI).

In SAP Integration Suite, it is is well-documented for Groovy how to manipulate the Message Processing Log with the following methods

addCustomHeaderProperty
setStringProperty or
addAttachmentAsString

(see Add Information to the Message Processing Log).

However, when executing XSLT 2.0/3.0 transformations, no native XSLT-level mechanism exists to directly interact with the MPL context. The lightweight Java utility below serves as a bridge to fill this gap.

Fast Lane

Download jar: https://github.com/jokr0815/cpi_xslt_mpl_extension
import into iFlow as archive
Put any xslt step into your iFow and use the java extension, namespace:
xmlns:mpl="java:script.MPLWriter" with its functions:
- mpl:setStringProperty($SAP_MessageProcessingLog, $string-key, $string-value)
- mpl:addCustomHeaderProperty($SAP_MessageProcessingLog, $string-key, $string-value, $debugEnabled)
- mpl:addAttachmentAsString($SAP_MessageProcessingLog, $string-filename, $string-content,$string-mimetype, $debugEnabled)

Overview & Design Principles

The MPLWriter class uses OSGi runtime reflection and service lookup to interact directly with the CPI execution context passed into Java extension calls in Saxon/XSLT steps.

Compile-Time Dependencies:
Only one external jar is needed: org.osgi.core-6.0.0.jar.
(No SAP CPI runtime JARs are needed in your build environment.)

Legal Disclaimer & License

MIT License

Copyright (c) HO2 Systemberatung GmbH

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.

Disclaimer: This code is provided as-is without any warranty for correctness, completeness, or fitness for a particular purpose. It relies on non-public runtime structures resolved via reflection. This solution is completely independent and/or completely unsupported by SAP, by myself and/or my company - use it at your own risk 🙂

Source Code: `MPLWriter.java`

/*
 * Copyright (c) HO2 Systemberatung GmbH
 * Licensed under the MIT License.
 */
package script;

import java.io.ByteArrayInputStream;
import java.lang.reflect.Method;
import java.net.URI;
import java.nio.charset.StandardCharsets;
import java.util.ArrayList;
import java.util.HashMap;
import java.util.List;
import java.util.Map;
import java.util.Set;

import org.osgi.framework.Bundle;
import org.osgi.framework.BundleContext;
import org.osgi.framework.FrameworkUtil;
import org.osgi.framework.ServiceReference;

/**
 * Utility class to interact with SAP Integration Suite Message Processing Log (MPL)
 * dynamically from XSLT Java Extensions via OSGi and Reflection.
 * 
 * @Author HO2 Systemberatung GmbH
 */
public class MPLWriter {

	private static int debugCounter = 0;

	/**
	 * Sets a string property on the Message Processing Log.
	 */
	public static Object setStringProperty(Object mpl, String name, Object value) throws Exception {

		Object key = createTypedKey(mpl, name, String.class);
		return put(mpl, key, value);
	}

	/**
	 * Adds a custom header property (User Defined Attribute) to the MPL.
	 */
	public static String addCustomHeaderProperty(Object mpl, String name, String value) throws Exception {

		return addCustomHeaderProperty(mpl, name, value, false);
	}

	public static String addCustomHeaderProperty(Object mpl, String name, String value, boolean debugEnabled)
			throws Exception {

		debug(mpl, debugEnabled, "START addCustomHeaderProperty " + name + "=" + value);

		Object rootMpl = mpl.getClass().getMethod("getRoot").invoke(mpl);
		ClassLoader loader = mpl.getClass().getClassLoader();
		Class<?> udaClass = loader.loadClass("com.sap.it.op.mpl.UserDefinedAttributeTypeV2");
		Class<?> keysClass = loader.loadClass("com.sap.it.op.mpl.TypedMessageProcessingLogKeys");
		Object udaKey = keysClass.getField("TK_USER_DEFINED_ATTRIBUTES").get(null);
		Method get = rootMpl.getClass().getMethod("get", udaKey.getClass());
		Object uda = get.invoke(rootMpl, udaKey);

		if (uda == null) {

			uda = udaClass.getDeclaredConstructor().newInstance();

			rootMpl.getClass().getMethod("put", udaKey.getClass(), Object.class).invoke(rootMpl, udaKey, uda);
		}

		Method grantAttribute = udaClass.getMethod("grantAttribute", String.class);

		@SuppressWarnings("unchecked")
		Set<String> values = (Set<String>) grantAttribute.invoke(uda, name);

		values.add(value);
		debug(mpl, debugEnabled, "UDA final=" + uda);

		return "OK";
	}

	/**
	 * Adds an attachment to the Message Processing Log (Normal Mode).
	 */
	public static String addAttachmentAsString(Object mpl, String name, String content, String mimeType)
			throws Exception {

		return addAttachmentAsString(mpl, name, content, mimeType, false);
	}

	/**
	 * Adds an attachment to the Message Processing Log (Debug Mode).
	 */
	public static String addAttachmentAsString(Object mpl, String name, String content, String mimeType,
			boolean debugEnabled) throws Exception {
		
		debug(mpl, debugEnabled, "START addAttachment name=" + name);

		// Obtain OSGi bundle context dynamically via Message class loader
		Bundle bundle = FrameworkUtil.getBundle(Class.forName("com.sap.gateway.ip.core.customdev.util.Message"));
		debug(mpl, debugEnabled, "Bundle=" + bundle);

		BundleContext ctx = bundle.getBundleContext();
		ServiceReference<?> ref = ctx.getServiceReference("com.sap.esb.camel.message.storage.api.MessageStorageWrite");

		debug(mpl, debugEnabled, "MessageStorage reference=" + ref);

		if (ref == null) {

			return "MessageStorageWrite service not found";
		}

		Object messageStore = null;

		try {
			messageStore = ctx.getService(ref);
			Class<?> messageClass = messageStore.getClass().getClassLoader()
					.loadClass("com.sap.esb.camel.message.storage.api.Message");
			Object attachmentMessage = messageClass.getDeclaredConstructor().newInstance();

			/*
			 * Set Attachment Headers
			 */
			Map<String, String> headers = new HashMap<>();
			headers.put("SapAttachmentName", name);
			headers.put("SapAttachmentContentType", mimeType);

			messageClass.getMethod("setHeader", Map.class).invoke(attachmentMessage, headers);

			/*
			 * Set Body Content
			 */
			byte[] bytes = content.getBytes(StandardCharsets.UTF_8);

			debug(mpl, debugEnabled, "Attachment bytes=" + bytes.length);

			Method setBody = null;

			for (Method m : messageClass.getMethods()) {
				if ("setBody".equals(m.getName()) && m.getParameterCount() == 1) {
					setBody = m;
					break;
				}
			}

			if (setBody == null) {
				throw new Exception("Message.setBody not found");
			}

			debug(mpl, debugEnabled, "setBody type=" + setBody.getParameterTypes()[0].getName());
			setBody.invoke(attachmentMessage, new ByteArrayInputStream(bytes));

			/*
			 * Resolve MPL Identifiers
			 */
			Object messageGuid = getMplValue(mpl, "MessageGuid");
			Object stepId = getMplValue(mpl, "StepId");

			debug(mpl, debugEnabled, "MessageGuid=" + messageGuid);
			debug(mpl, debugEnabled, "StepId=" + stepId);

			if (messageGuid == null) {
				throw new Exception("MessageGuid not found");
			}

			messageClass.getMethod("setMplID", String.class).invoke(attachmentMessage, messageGuid.toString());

			if (stepId != null) {
				messageClass.getMethod("setStepID", String.class).invoke(attachmentMessage, stepId.toString());
			}

			/*
			 * Tag Message as ATTACHMENT
			 */
			Class<?> tagClass = messageClass.getClassLoader()
					.loadClass("com.sap.esb.camel.message.storage.api.Message$TagKey");
			@SuppressWarnings({ "unchecked", "rawtypes" })
			Object attachmentTag = Enum.valueOf((Class) tagClass, "ATTACHMENT");

			messageClass.getMethod("setTagKey", tagClass).invoke(attachmentMessage, attachmentTag);

			/*
			 * Persist Attachment to Storage
			 */
			URI uri = (URI) messageStore.getClass().getMethod("add", messageClass, boolean.class).invoke(messageStore,
					attachmentMessage, true);
			debug(mpl, debugEnabled, "Attachment URI=" + uri);

			/*
			 * Register Attachment URI in MPL Attachment List
			 */
			Object attachments = getMplValue(mpl, "attachments");
			debug(mpl, debugEnabled, "Existing attachments=" + attachments);

			if (attachments == null) {
				attachments = new ArrayList<>();
				Object key = createTypedKey(mpl, "attachments", List.class);
				put(mpl, key, attachments);
			}

			Class<?> attachmentType = mpl.getClass().getClassLoader().loadClass("com.sap.it.op.mpl.AttachmentType");
			Object attachment = attachmentType.getDeclaredConstructor().newInstance();

			attachmentType.getMethod("setName", String.class).invoke(attachment, name);
			attachmentType.getMethod("setURI", URI.class).invoke(attachment, uri);

			@SuppressWarnings("unchecked")
			List<Object> list = (List<Object>) attachments;

			list.add(attachment);
			debug(mpl, debugEnabled, "Attachment list size=" + list.size());

			return "CREATED URI=" + uri;

		} finally {
			if (ref != null) {
				ctx.ungetService(ref);
			}
		}
	}

	private static Object createTypedKey(Object mpl, String name, Class<?> type) throws Exception {
		Class<?> keyClass = findKeyClass(mpl);
		Method grant = keyClass.getMethod("grantKey", Class.class, String.class);

		return grant.invoke(null, type, name);
	}

	private static Class<?> findKeyClass(Object mpl) throws Exception {

		for (Method m : mpl.getClass().getMethods()) {

			if ("put".equals(m.getName()) && m.getParameterCount() == 2) {
				Class<?>[] params = m.getParameterTypes();
				if (params[1].equals(Object.class)) {
					return params[0];
				}
			}
		}

		throw new Exception("TypedMessageProcessingLogKey not found");
	}

	private static Object put(Object mpl, Object key, Object value) throws Exception {

		Method put = mpl.getClass().getMethod("put", key.getClass(), Object.class);

		return put.invoke(mpl, key, value);
	}

	private static Object getMplValue(Object mpl, String name) throws Exception {

		Class<?> keyClass = findKeyClass(mpl);
		Object key = createTypedKey(mpl, name, guessKeyType(name));
		Method get = mpl.getClass().getMethod("get", keyClass);

		return get.invoke(mpl, key);
	}

	private static Class<?> guessKeyType(String name) {

		switch (name) {
		case "MessageGuid":
		case "StepId":
			return String.class;
		case "attachments":
			return List.class;
		default:
			return Object.class;
		}
	}

	private static synchronized void debug(Object mpl, boolean enabled, Object value) {

		if (!enabled) {
			return;
		}

		try {
			setStringProperty(mpl, "MPL_DEBUG_" + String.format("%02d", ++debugCounter), String.valueOf(value));
		} catch (Exception ignored) {

		}
	}
}

XSLT Call Example

Below there is a sample xsl stylesheet to make use of the little helper.

ℹ️Output generated by saxon:trace is redirected to the standard application server logging channel. In CPI, you can find these log lines directly in the web UI under Monitoring > System-Logs (or by downloading the tail/system log file for the node execution).

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:saxon="http://saxon.sf.net/" xmlns:mpl="java:script.MPLWriter" exclude-result-prefixes="xs saxon mpl">
  <!-- SAP CPI injects the Message Processing Log object -->
  <xsl:param name="SAP_MessageProcessingLog"/>
  <!-- Enable MPL debug -->
  <xsl:param name="debugEnabled" select="true()"/>
  <!-- Saxon template execution tracing -->
  <xsl:mode on-multiple-match="use-last" use-accumulators="itemCount totalQuantity" saxon:trace="yes"/>
  <!-- Count items -->
  <xsl:accumulator name="itemCount" as="xs:integer" initial-value="0" saxon:trace="yes">
    <xsl:accumulator-rule match="Item" select="$value + 1"/>
  </xsl:accumulator>
  <!-- Sum quantities -->
  <xsl:accumulator name="totalQuantity" as="xs:integer" initial-value="0" saxon:trace="yes">
    <xsl:accumulator-rule match="Quantity/text()" select="$value + xs:integer(.)"/>
  </xsl:accumulator>
  <xsl:template match="/">
    <xsl:variable name="orderId" select="string(Order/Header/ID)"/>
    <xsl:variable name="customer" select="string(Order/Header/CustomerNumber)"/>
    <!-- MPL properties -->
    <xsl:variable name="status1" select="mpl:setStringProperty($SAP_MessageProcessingLog,'XSLT_STATUS','STARTED')"/>
    <xsl:variable name="orderProperty" select="mpl:setStringProperty($SAP_MessageProcessingLog,'ORDER_ID',$orderId)"/>
    <!-- MPL Custom Header Properties -->
    <xsl:variable name="header1" select="mpl:addCustomHeaderProperty($SAP_MessageProcessingLog,'PROCESSING_TYPE','XSLT3_DEMO',$debugEnabled)"/>
    <xsl:variable name="header2" select="mpl:addCustomHeaderProperty($SAP_MessageProcessingLog,'CUSTOMER_NUMBER',$customer,$debugEnabled)"/>
    <!-- HTML attachment -->
    <xsl:variable name="html" select="
      mpl:addAttachmentAsString(
        $SAP_MessageProcessingLog,
        'order-summary.html',
        concat(
          '&lt;html&gt;',
          '&lt;body&gt;',
          '&lt;h1&gt;SAP CPI XSLT 3.0 Demo&lt;/h1&gt;',
          '&lt;h2&gt;Order ',
          $orderId,
          '&lt;/h2&gt;',
          '&lt;p&gt;Customer: ',
          $customer,
          '&lt;/p&gt;',
          '&lt;table border=&quot;1&quot;&gt;',
          '&lt;tr&gt;&lt;th&gt;Material&lt;/th&gt;&lt;th&gt;Quantity&lt;/th&gt;&lt;/tr&gt;',
          string-join(
            for $i in Order/Items/Item
            return concat(
              '&lt;tr&gt;',
              '&lt;td&gt;',
              $i/Material,
              '&lt;/td&gt;',
              '&lt;td&gt;',
              $i/Quantity,
              '&lt;/td&gt;',
              '&lt;/tr&gt;'
            ),
            ''
          ),
          '&lt;/table&gt;',
          '&lt;p&gt;Items: ',
          accumulator-after('itemCount'),
          '&lt;/p&gt;',
          '&lt;p&gt;Total Quantity: ',
          accumulator-after('totalQuantity'),
          '&lt;/p&gt;',
          '&lt;/body&gt;',
          '&lt;/html&gt;'
        ),
        'text/html',
        $debugEnabled
      )
    "/>
    <!-- Store calculated values -->
    <xsl:variable name="itemCount" select="mpl:setStringProperty($SAP_MessageProcessingLog,'ITEM_COUNT',string(accumulator-after('itemCount')))"/>
    <xsl:variable name="quantity" select="mpl:setStringProperty($SAP_MessageProcessingLog,'TOTAL_QUANTITY',string(accumulator-after('totalQuantity')))"/>
    <xsl:variable name="status2" select="mpl:setStringProperty($SAP_MessageProcessingLog,'XSLT_STATUS','COMPLETED')"/>
    <!-- XML result -->
    <OrderResult>
      <Header>
        <ID>
          <xsl:value-of select="$orderId"/>
        </ID>
        <Customer>
          <xsl:value-of select="$customer"/>
        </Customer>
      </Header>
      <Items>
        <xsl:apply-templates select="Order/Items/Item"/>
      </Items>
      <Summary>
        <ItemCount>
          <xsl:value-of select="accumulator-after('itemCount')"/>
        </ItemCount>
        <TotalQuantity>
          <xsl:value-of select="accumulator-after('totalQuantity')"/>
        </TotalQuantity>
      </Summary>
    </OrderResult>
  </xsl:template>
  <!-- Item transformation -->
  <xsl:template match="Item">
    <Item>
      <Material>
        <xsl:value-of select="Material"/>
      </Material>
      <Quantity>
        <xsl:value-of select="Quantity"/>
      </Quantity>
    </Item>
  </xsl:template>
</xsl:stylesheet>

Input XML Example

Below is a sample input XML payload processed by the XSLT mapping above, from which the Order ID is dynamically extracted and pushed into the MPL Custom Header Property:

<?xml version="1.0" encoding="UTF-8"?>
<Order>
  <Header>
    <ID>4500012345</ID>
    <Date>2026-07-17</Date>
    <CustomerNumber>1002934</CustomerNumber>
    <Priority>HIGH</Priority>
    <SalesOrganization>1710</SalesOrganization>
  </Header>
  <Items>
    <Item>
      <LineNumber>10</LineNumber>
      <Material>MAT-8842</Material>
      <Description>Industrial Sensor</Description>
      <Quantity>50</Quantity>
      <Unit>EA</Unit>
      <NetValue>1250.00</NetValue>
    </Item>
    <Item>
      <LineNumber>20</LineNumber>
      <Material>MAT-9921</Material>
      <Description>Control Module</Description>
      <Quantity>25</Quantity>
      <Unit>EA</Unit>
      <NetValue>3750.00</NetValue>
    </Item>
    <Item>
      <LineNumber>30</LineNumber>
      <Material>MAT-5500</Material>
      <Description>Mounting Bracket</Description>
      <Quantity>100</Quantity>
      <Unit>EA</Unit>
      <NetValue>500.00</NetValue>
    </Item>
    <Item>
      <LineNumber>40</LineNumber>
      <Material>MAT-7711</Material>
      <Description>Power Supply</Description>
      <Quantity>10</Quantity>
      <Unit>EA</Unit>
      <NetValue>900.00</NetValue>
    </Item>
  </Items>
</Order>

Result

Custom Header +
Attachment +
String Properties in the text log created

ℹ️It will also create the following output under https://<cpi-ui>/shell/monitoring/SystemLogs

2026-07-17 14:55:17#+0000#ERROR#com.sap.esb.camel.route.policy.SingletonExchangeSelectionPolicy#anonymous#1784300116738-Blog_Xslt_Functions_Worker-1#com.sap.esb.camel.quartz.camel.route.policy#na#na#na#na#[INFO] MPL: AGpaQlWi5X9iHy9FgbgPV5XNRkVS ; Acquired lock: a6fa451d-daa0-4d18-94af-81c9d8d6897c_RONCE_1492 to start route: route34#-#10.0.201.0#0
<trace saxon-version="9.9.1.6" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <source node="/" line="0" file="">
  <rule match="document-node()" line="27" module="XSLTMapping1.xsl">
totalQuantity BEFORE /Order/Items[1]/Item[1]/Quantity[1]/text()[1]: 50
totalQuantity BEFORE /Order/Items[1]/Item[3]/Quantity[1]/text()[1]: 175
itemCount BEFORE /Order/Items[1]/Item[1]: 1
itemCount BEFORE /Order/Items[1]/Item[4]: 4
itemCount BEFORE /Order/Items[1]/Item[2]: 2
totalQuantity BEFORE /Order/Items[1]/Item[2]/Quantity[1]/text()[1]: 75
itemCount BEFORE /Order/Items[1]/Item[3]: 3
totalQuantity BEFORE /Order/Items[1]/Item[4]/Quantity[1]/text()[1]: 185
   </source><!-- /Order/Items[1]/Item[2] -->
    </rule>
   </source><!-- /Order/Items[1]/Item[1] -->
   <source node="/Order/Items[1]/Item[1]" line="-1" file="">
    </rule>
    <rule match="element(Q{}Item)" line="136" module="XSLTMapping1.xsl">
    <rule match="element(Q{}Item)" line="136" module="XSLTMapping1.xsl">
   <source node="/Order/Items[1]/Item[2]" line="-1" file="">
   <source node="/Order/Items[1]/Item[3]" line="-1" file="">
    <rule match="element(Q{}Item)" line="136" module="XSLTMapping1.xsl">
   <source node="/Order/Items[1]/Item[4]" line="-1" file="">
    <rule match="element(Q{}Item)" line="136" module="XSLTMapping1.xsl">
  </rule>
</trace>
 </source><!-- / -->
   </source><!-- /Order/Items[1]/Item[4] -->
    </rule>
    </rule>
   </source><!-- /Order/Items[1]/Item[3] -->

If you found this article helpful, please leave a Like! You can also enjoy reading other community contributions and stay up to date by browsing SAP Cloud Integration Blog Posts.

Building CPI Explorer – My Journey to Simplify Searching SAP Integration Suite iFlows

2026-07-20T12:12:08.365000+02:00

Building CPI Explorer – My Journey to Simplify Searching SAP Integration Suite iFlows

Introduction

As an SAP Integration Suite consultant, a large part of my day involves supporting existing integrations, troubleshooting production issues, and understanding how different systems are connected. One challenge kept coming up repeatedly: finding where a particular SFTP directory, HTTP endpoint, ProcessDirect endpoint, or credential was configured across dozens (sometimes hundreds) of Integration Flows.

SAP's Design-Time APIs let you retrieve Integration Packages and Integration Flows, but there's no built-in way to search adapter configurations across an entire tenant. In practice, that meant opening package after package and manually inspecting each iFlow — slow, repetitive, and easy to get wrong in a large landscape.

Instead of continuing to do this by hand, I decided to build a tool to solve it for myself, and hopefully for other developers too.

Where It All Started

I started my career as an ABAP developer, and one feature I relied on constantly was the "Where Used" list. If I needed to know where a table, function module, or field was being used, I could just look it up. It was simple, fast, and always available.

When I moved into PI/PO and later CPI, that convenience disappeared. There's no equivalent way to instantly search where something is used across your integration landscape.

This became a real problem in day-to-day support. An FICO or SD colleague would come to me and say "my file isn't moving, can you check?" Half the time, they weren't even sure whether their interface was flowing through PI/CPI at all — they just knew something was stuck and assumed I'd know where to look. Other times, someone from the infra team would ask "are we using this host anywhere? We need to update it" or "can you find every flow using this username, we're rotating credentials." Each of these meant manually opening iFlow after iFlow, hoping I didn't miss one.

That's where the idea for CPI Explorer actually came from — not as a big architectural vision, but as a way to get back something as basic as the ABAP "Where Used" list, just for CPI.

One real example was during an infrastructure change where we had to update an SFTP host. Before CPI Explorer, the only option was to manually open multiple Integration Flows and inspect every SFTP adapter. With CPI Explorer, I can simply search for the hostname and immediately see every Integration Flow that references it.

The Idea

The question I started with was simple:

Can I build a "Where Used" list for CPI?

I spent quite some time exploring the SAP Business Accelerator Hub and Design-Time APIs to see whether this functionality already existed. The Design-Time APIs gave me metadata, but not the adapter-level detail I needed. So I went a level deeper: download each Integration Flow artifact, extract the .iflw file, parse the XML, and build a local searchable index from it.

Once that was working, I wrapped it in a Chrome Extension so I could search directly from the browser instead of running scripts every time.

How CPI Explorer Works

At a high level, the tool:

Authenticates with SAP Integration Suite using OAuth
Retrieves Integration Packages and Integration Flows via the Design-Time APIs
Downloads Integration Flow artifacts
Extracts and parses the .iflw XML files
Builds a searchable metadata index
Lets you search adapter properties from the Chrome Extension

It currently supports searching for:

SFTP directories
Host names
HTTP endpoints
ProcessDirect endpoints
JMS queues
Credentials
Externalized parameters
Other adapter properties

What I Learned

Building this taught me more than I expected about:

SAP Integration Suite Design-Time APIs
The structure of Integration Flow artifacts
Parsing .iflw XML files
Chrome Extension development
Organizing a Node.js application into reusable modules

The trickiest part was making sure every downloaded artifact mapped back correctly to its source Integration Flow while the index was being built. Getting that mapping right was what made the search results trustworthy across a whole tenant.

Why I'm Sharing This

I built CPI Explorer to solve my own problem, but I believe many SAP Integration Suite developers face the same challenge. That's why I decided to make it open source, so others can use it, contribute ideas, and help improve it over time.

GitHub

The project is available here: https://github.com/lokeshbhukya2019-netizen/cpi-explorer

Feedback, suggestions, and contributions are welcome.

What's Next

A few things I'm planning to add:

Search by adapter type
Multi-tenant support
Export to Excel/CSV
Dependency visualization
Support for additional adapter types

If you have ideas for other useful features, I'd like to hear them.

Closing Thoughts

CPI Explorer started as an attempt to fix a problem I ran into constantly in day-to-day SAP Integration Suite work. Along the way it turned into a good excuse to learn more about SAP's APIs, artifact structures, and browser extension development.

I hope it saves other SAP Integration Suite developers some time during troubleshooting and impact analysis. If you try it, I'd genuinely like to hear how it goes.

Thank you for taking the time to read about CPI Explorer. If you try it out, I'd love to hear your feedback, suggestions, or ideas for new features. I hope it helps make troubleshooting and impact analysis in SAP Integration Suite a little easier for the community.

Happy integrating!

Migrate from SAP Neo, Cloud Integration to SAP Integration Suite with Confidence

2026-07-21T07:25:54.126000+02:00

Migrating from SAP Cloud Integration in the Neo environment to SAP Integration Suite on SAP BTP Cloud Foundry can raise many questions. To help you navigate this transition, we've published a comprehensive guide that brings together SAP documentation, best practices, and SAP support services to support every stage of your migration journey.

What You'll Learn

This guide walks you through the migration following the SAP Activate methodology, covering every phase from planning to post-go-live optimization:

Discover – Understand why SAP BTP Cloud Foundry is the strategic direction and explore the benefits of SAP Integration Suite.
Prepare – Assess your existing integration landscape and learn how the free Neo Sunset Migration Factory can help you create a migration roadmap.
Explore – Discover onboarding resources, hands-on workshops, consulting services, and best practices to accelerate your migration.
Realize & Deploy – Learn about SAP migration tools, Postman collections, testing strategies, and cutover recommendations for a successful go-live.
Run – Optimize and monitor your integration landscape with SAP Cloud ALM, Continuous Quality Checks (CQC), Cloud Application Services (CAS), and Expert-Guided Implementations.

How This Guide Helps

Whether you're just starting your migration planning or already executing your project, this article brings together key information on:

Official SAP migration resources
Available SAP Enterprise Support services
Adoption and enablement offerings
SAP Consulting services
Best practices for reducing migration risk and accelerating time-to-value

Access the Guide

Explore this guide "How to Migrate from SAP Neo, Cloud Integration to SAP Integration Suite through Support Services" on the SAP Business Technology Platform Value Map. To access Value Map Groups, you need to login to the SAP Community using an S-user ID or a Universal ID.

Enhance Your SAP Experience with Value Maps

Beyond this topic, SAP Enterprise Support value maps on SAP Community provides guidance, recommended actions, and supporting resources to help you decide what to focus on next—all included in your SAP cloud subscription.

👉 Watch short demo video, then head over to our page - explore our range of topics and request a call with a topic expert for guidance tailored to your goals.

About the author:

Carol Zhang is a Topic Expert for SAP Enterprise Support value maps, specializing in the SAP Business Technology Platform (BTP). With more than 20 years of experience at SAP and a background spanning roles in SAP Service and Support organization, she is passionate about helping customers succeed businesses accelerate the adoption of SAP BTP tools and services through SAP Enterprise Support offerings.

Keystore Certificate Expiration Alerts in SAP Integration Suite - Part 2

2026-07-21T08:06:11.743000+02:00

Introduction

Managing certificates is a responsibility for SAP Integration support team. Certificates stored in the Keystore are used to establish secure communication with external systems. If a certificate expires without notice, it can cause integration failures and business disruptions.

To avoid this, organizations often rely on manual monitoring, which is time-consuming and prone to oversight.

In this blog, I would like to explain- how to build an automated monitoring solution in SAP Integration Suite:

Retrieves all certificates from the tenant Keystore using the OData API.
Filters certificates approaching expiration using a Groovy script.
Converts the filtered data into a well-formatted HTML table using XSLT.
Sends an email notification automatically through the Mail Adapter.

CPI Design:

The integration consists of the following steps:

Step	Description
Timer	To start the Integration once a day
ContentModifier	Externalized properties such as sender, receiver email addresses and selection of days to check in expiry
Request Reply	Calls the CI OData API to retrieve Keystore certificates.
Filter Expired Certificates	Uses a Groovy script to identify certificates expiring within the configured notification period.
Router	Check if there are records in the body. Continue If yes. End the message if not.
XSLT Mapping	Transform the XML response into an HTML table.
Mail Adapter	To Send the formatted HTML email notification.
ContentModifier	Prepares the xml Body incase of an error
Send with Mail Adapter	Send the error info to the operation teams in case of an error

Timer:
A simple time schedule to run once a day.
Content Modifier:
It stores the sender and receiver email addresses as exchange properties. These properties are later referenced in the Mail Adapter configuration, making the integration easier to maintain.

Configure the OData Receiver Adapter:
The OData Receiver Adapter is used to retrieve all certificate entries from the SAP Integration Suite Keystore using the Integration Suite OData API.

The API returns details such as:

Certificate Alias
Key Type
Certificate Status
Certificate Expiration Date (ValidNotAfter)

Some Odata API's allows you to filter the records but for this KeyStore API entity, it is not a choice. So, the oData results are filtered later by the Groovy script. I have created an additional blog for consuming & testing the OData Services, please check out here if you need any assistance.

Test Odata service using Postman

The integration invokes the SAP Integration Suite OData API to retrieve all certificates stored in the tenant's Keystore. A sample response looks like this:

<KeystoreEntries>
   <KeystoreEntry>
      <Alias>smtp.gmail.com</Alias>
      <KeyType>EC</KeyType>
      <ValidNotAfter>2026-08-10T18:37:12.000</ValidNotAfter>
      <Status>unchanged</Status>
   </KeystoreEntry>
</KeystoreEntries>

I have created another blog post for how to connect security content odata api using postman in-detail. in this blog

Filter Certificates xml data Using Groovy

Instead of implementing complex date calculations in graphical message mapping, I chose Groovy. The script compares the current date (+7 or +14days as needed) with the ValidNotAfter field and keeps only certificates that are due to expire within the configured notification window (for example, the next 14 days).

This approach is simpler, easier to maintain, and provides greater flexibility when implementing date-based logic.

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.XmlUtil

def Message processData(Message message) {
	def body = message.getBody(String)
	def xml = new XmlParser().parseText(body)
	
	Date today = new Date()
	Date threshold = today + 14
	
	xml.KeystoreEntry.findAll { cert ->
	Date expiry = Date.parse("yyyy-MM-dd'T'HH:mm:ss.SSS", cert.ValidNotAfter.text() )
	expiry <= threshold
	}.each { }

	xml.KeystoreEntry.findAll { cert ->
	Date expiry = Date.parse("yyyy-MM-dd'T'HH:mm:ss.SSS", cert.ValidNotAfter.text())
	!(expiry <= threshold)
	}.each { it.parent().remove(it) }

	message.setBody(XmlUtil.serialize(xml))
return message
}

Router Configuration

Since certificate expiration is not a daily occurrence, there is no need to send an email every time the integration flow runs. Instead, a Router step is used to determine whether any certificates meet the alert criteria.

I configured the Router to evaluate the groovy output step. If one or more certificates are approaching their expiration date, the message is routed to the Mail Receiver Adapter to send an email notification. Otherwise, the flow simply ends without sending any email.

Generate an HTML Table Using XSLT

The filtered XML is transformed into an HTML table using XSLT. Inline HTML styles are used to ensure the table is displayed correctly in email clients such as Outlook and Gmail.

The generated email contains:

Certificate Name
Key Type
Valid Until
Status

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
	<xsl:output method="html" encoding="UTF-8" indent="yes"/>
	<xsl:template match="/">
		<html>
			<body style="font-family:Arial,Helvetica,sans-serif;font-size:13px;">
				<xsl:choose>
					<xsl:when test="count(/KeystoreEntries/KeystoreEntry) > 0">
						<h2>Certificates Expiring Soon</h2>
						<table border="1" cellpadding="6" cellspacing="0" width="100%" style="border-collapse:collapse;border:1px solid #000000;">
							<tr bgcolor="#D9D9D9">
								<th style="border:1px solid #000000;text-align:left;">Certificate Name</th>
								<th style="border:1px solid #000000;text-align:left;">Key Type</th>
								<th style="border:1px solid #000000;text-align:left;">Valid Until</th>
								<th style="border:1px solid #000000;text-align:left;">Status</th>
							</tr>
							<xsl:for-each select="/KeystoreEntries/KeystoreEntry">
								<tr>
									<td style="border:1px solid #000000;">
										<xsl:value-of select="Alias"/>
									</td>
									<td style="border:1px solid #000000;">
										<xsl:value-of select="KeyType"/>
									</td>
									<td style="border:1px solid #000000;">
										<xsl:value-of select="ValidNotAfter"/>
									</td>
									<td style="border:1px solid #000000;">
										<xsl:value-of select="Status"/>
									</td>
								</tr>
							</xsl:for-each>
						</table>
					</xsl:when>
					<xsl:otherwise>
						<h2>No certificates found.</h2>
					</xsl:otherwise>
				</xsl:choose>
			</body>
		</html>
	</xsl:template>
</xsl:stylesheet>

Mail Adapter Configuration :
To ensure the HTML content is rendered correctly by email clients, configure the following settings in the Mail Adapter:

Mime Type: Text/HTML
Content Encoding: Quoted-Printable

These settings instruct the mail client to interpret the message body as HTML rather than plain text. As a result, the certificate information is displayed in a well-formatted table instead of showing the raw HTML tags.

Another blog for explaining how to create Gmail app password, please check out here if you need any assistance.
Gmail SMTP Integration

Email notification:
After the integration flow is executed successfully, an email notification is sent containing the list of certificates that meet the configured criteria (for example, certificates approaching their expiration date).

The HTML formatting makes the report easy to read, allowing administrators to quickly identify certificates that require attention without manually checking the SAP Integration Suite tenant.

Exception Handling

To improve the integration error handling, an Exception Subprocess is added. If an error occurs during the execution of the iFlow—such as an API connection issue, authentication failure, or processing error—the Exception Subprocess is triggered automatically.

The Exception Subprocess sends an email notification containing the error details to the configured recipients. This enables the team to quickly identify and resolve issues without manually monitoring the integration flow, helping ensure timely response to failures.

Content Modifier : Below is the body i used

<?xml version="1.0" encoding="UTF-8" ?>
<AlertNotification>
	<item>
		<Sender>SAP CPI</Sender>
		<Receiver>Mail</Receiver>
		<SenderInterface>QueryKeystoreEntries_Out</SenderInterface>
		<ReceiverInterface>AlertNotification_In</ReceiverInterface>
		<IFlowName>${camelId}</IFlowName>
		<Application_ID>${header.SAP_ApplicationId}</Application_ID>
		<Correlation_ID>${header.SAP_MplCorrelationId}</Correlation_ID>
		<Message_ID>${property.SAP_MessageProcessingLogID}</Message_ID>
		<StartedAt>${header.SAP_ApplicationStopTime}</StartedAt>
		<CurrentDateTime>${date:now:dd-MM-yyyy HH:mm:ss}</CurrentDateTime>
		<TenantName>${property.SystemName}</TenantName>
		<Error>${exception.message}</Error>
		<OverallStatus>${header.SAP_ApplicationOverallStatus}</OverallStatus>
		<LatestActionAt>${header.SAP_ApplicationStartTime}</LatestActionAt>
		<CreatedTimestamp>${property.CamelCreatedTimestamp}</CreatedTimestamp>
		<ExceptionCaught>${property.CamelExceptionCaught}</ExceptionCaught>
		<HttpResponseCode>${header.CamelHttpResponseCode}</HttpResponseCode>
		<severity>INFO</severity>
		<category>NOTIFICATION</category>
	</item>
</AlertNotification>

Benefits:

This solution provides several advantages:

Automated certificate monitoring.
Early notification before certificate expiration.
Reduced manual effort.
Configurable notification period.
Reusable design for other monitoring scenarios, for ex. you can report the message processing logs
Readability through HTML email formatting.

Beyond the Standard: Developing the "CPI Kafka Adapter Plus" for High-Volume Event Streaming

2026-07-21T08:17:30.796000+02:00

Hello everyone!

I’m Florian Kube. When I look back at my career, I’ve been working in the SAP integration space for over 10 years now. I briefly started with SAP PI/PO, but jumped straight onto HCI (now SAP Integration Suite) as soon as it became available - all the way back when we still had to configure flows using the Eclipse plugin.

In recent years, the integration landscape has shifted. Synchronous request-response setups are increasingly replaced by modern, event-driven architectures. Event-driven integration and streaming are no longer just buzzwords; they are part of our daily work now. And when we talk about streaming in the enterprise space, the conversation almost always leads to Apache Kafka (next to SAP Advanced Event Mesh 😉).

In theory, both Apache Kafka and SAP Cloud Integration (CPI) are built to process messages immediately and in real-time. That is the core beauty of event-driven design. However, when we apply this high-frequency, single-message pattern directly to CPI in high-volume enterprise environments, we quickly run into practical operational and performance challenges.

To solve these practical challenges, I started an open-source project: the CPI Kafka Adapter Plus.

High-Frequency Events Meet Operational Reality

When systems exchange data, enterprise architectures often use bulk processing. However, when handling high-frequency events or large data streams in CPI, treating every single event as an individual integration transaction creates major operational issues:

MPL Overload & The Logging Dilemma: When consuming events individually, every single event processed by CPI creates its own Message Processing Log (MPL). To handle this in high-volume scenarios, you could set the log level to "Error Only". But let's be honest: in daily operations, that often feels like flying blind. It frequently leads to misunderstandings and troubleshooting difficulties because you lose all visibility on successful processing. On the other hand, keeping standard logs turned on with high message volumes can overload the database, degrade performance, and clutter your monitoring.
Downstream System Overload: Even if CPI can ingest thousands of high-frequency events without issues, the receiving target system (like an ERP database or a legacy API) often cannot. Flooding a downstream system with thousands of individual, tiny requests can easily overwhelm it. Gathering these events into structured packages is often a technical necessity to protect downstream systems.
Cost Efficiency (And how SAP counts messages): In SAP Integration Suite, licensing is billed per processed message, where each 250KB of payload counts as one message. If you push 1,000 tiny single-event messages (even if they are only 1KB each) through CPI, SAP counts and bills this as 1,000 messages. However, if you bundle those 1,000 events into a single 1MB bulk package, it is processed as a single transaction and, based on the 250KB rule, only counts as 4 messages! Processing unbatched, high-frequency single events is an area where you can save a lot of money with the right optimization.

The Previous Workaround

To optimize this, integration developers often have to build workarounds. For example, when a sending system like SAP's Data Replication Framework (DRF) sends business objects as a bulk payload, the standard Kafka adapter cannot automatically split this bulk into individual Kafka records.

As a workaround, developers have to build tedious splitter logic in the Integration Flow to split the bulk and send every single message individually to Kafka. While this works, it bloats the integration flows with unnecessary processing steps, forces CPI into long processing loops, and generates very large log files.

An Adapter to Bridge the Gap

Why not move this efficiency logic directly into the adapter? The goal was to build a custom adapter that respects Kafka’s native streaming design while protecting CPI’s operational and monitoring boundaries.

The CPI Kafka Adapter Plus was designed to:

Support native batching directly out of the box.
Keep integration flows clean by avoiding complex splitters and aggregators.
Drastically reduce the CPI resource footprint and MPL count without having to resort to restrictive "Error Only" logging.

Accelerating Adapter Development with AI

As an Integration Architect, my core focus is on system design, architecture, and orchestration, rather than spending days writing raw Java boilerplate.

Developing a custom adapter for SAP CPI requires working with the Adapter Development Kit (ADK). While the ADK is highly powerful, it is also a proprietary, specialized framework with a steep learning curve. Finding extensive community examples or templates for complex ADK implementations is incredibly difficult.

Instead of letting this framework barrier slow me down, I treated Generative AI (Claude and GitHub Copilot) as my virtual pair-programmers. With a clear architectural blueprint in mind, this modern developer workflow allowed me to build the CPI Kafka Adapter Plus with maximum efficiency:

Navigating the ADK Lifecycle: I used Claude to clarify the underlying lifecycle methods of the ADK. I could describe the exact architectural behavior I wanted (such as holding a session open to collect messages in a custom thread before pushing them to the pipeline), and Claude translated these concepts into the structure required by the framework.
Automating the Boilerplate: I used GitHub Copilot to speed up the repetitive coding. It helped generate Maven configurations, set up properties, and draft unit tests. This kept me focused entirely on the core business and routing logic of the adapter.
Resolving Complex Dependencies: Merging Kafka client libraries, Avro schemas, and JSON validation libraries into the strict runtime environment of an SAP adapter can easily lead to classpath conflicts. AI helped me quickly troubleshoot these tricky packaging errors, saving hours of searching through legacy forums.

This experience showed me that with a strong architectural vision, modern AI tools can bridge the gap between design and implementation. It allowed me to deliver an enterprise-grade adapter without having to reinvent the wheel for every line of boilerplate code.

What Can the "Kafka Adapter Plus" Do?

The CPI Kafka Adapter Plus is not just a "Proof of Concept." It has already been running stable in production for months. Primarily in use cases involving massive amounts of data.

Of course, all of these features are completely modular and optional. You can use just a single capability or combine them however you like - whether you only need Avro serialization, only require bulk processing, or want to mix and match them depending on your specific integration requirements.

Here are the key features that helped bridge the gap between high-speed streaming and SAP CPI:

1. Batching & Bulk Processing

Whether you are sending bulk data to Kafka or consuming high-frequency events from it, the CPI Kafka Adapter Plus supports native batching in both directions:

On the Receiver Side (sending to Kafka): When business objects (like those from SAP DRF) arrive in CPI as a bulk, you no longer need to split them inside your flow. The adapter allows you to transform and hand over the bulk payload in a single step. The CPI Kafka Adapter Plus then automatically streams them to Kafka as native, individual records. This completely avoids tedious splitter or looping steps within the Integration Flow, preventing resource-heavy loops and drastically reducing transaction logging overhead.
On the Sender Side (consuming from Kafka): Instead of triggering thousands of individual Integration Flow executions (and thus thousands of individual MPLs) for every single Kafka event, the adapter can bundle incoming messages into a single bulk package. This dramatically reduces the MPL count, preserves tenant resources, and lowers the counted message volume, while still keeping your monitoring clean and manageable.

2. Dead Letter Topic Support

When it comes to error handling, standard Kafka adapters often rely on simple retry loops. If a message is corrupt or cannot be processed, it triggers rapid retry cycles. Since the default retry interval is usually very short (often in the range of seconds), CPI gets stuck repeatedly processing the exact same failing message over and over again. Wasting valuable CPU resources and cluttering up your logs.

The CPI Kafka Adapter Plus offers Dead Letter Topic support. If processing a message fails, it can be cleanly routed to a defined Dead Letter Topic instead of looping infinitely, allowing the rest of the message stream to continue running uninterrupted.

3. Integrated Avro Serialization

Anyone using Kafka professionally usually relies on Apache Avro for schema definition. Typically, achieving this in CPI requires making manual HTTP calls to an external Schema Registry and writing complex Groovy scripts to handle the serialization and deserialization. This approach is highly error-prone and unnecessarily bloats your Integration Flows.

The CPI Kafka Adapter Plus solves this by offering native Avro serialization right out of the box, completely eliminating the need for custom scripts and HTTP overhead in your message flow.

4. JSON Validation

The CPI Kafka Adapter Plus validates JSON payloads directly against predefined schemas. Both when sending and receiving messages. This means invalid data is caught and filtered out right at the adapter boundary, preventing corrupt payloads from ever entering and disrupting your CPI integration flows.

Open Source: Try It Out and Join In!

I firmly believe in the power of the SAP community. That’s why I decided to make the entire source code of the CPI Kafka Adapter Plus available as open source.

If you are facing similar challenges with mass data and Kafka in the SAP Integration Suite, I warmly invite you to try out the CPI Kafka Adapter Plus:

GitHub Repository: FinkeFlo/cpi-kafka-adapter-plus
Documentation & Setup Guide: FinkeFlo GitHub Pages

I would love to get your feedback, feature requests, or even pull requests directly on GitHub. Let’s make the SAP integration world a little better and more efficient together!

How do you currently handle mass data challenges with Kafka in CPI? Let me know in the comments below!

Best regards,

Florian

Disclaimer: This is an independent, community-driven open-source project. It is not an official SAP product, and is not officially supported or endorsed by SAP SE. Use at your own discretion.

Cloud Integration- Activating Enterprise Messaging Capabilities for JMS Queue - CF

2026-07-21T10:55:46.838000+02:00

When JMS-based integration flows fail to deploy on SAP Integration Suite (Cloud Foundry) with this error, it usually points to one thing: the Message Queue capability isn't activated on the tenant.

In my current project IS got upgraded from Basic/Starter edition to Standard edition.

Recently we face an issue when I try to deploy the flow it’s getting failed to deploy.

The Error

[CONTENT][CONTENT_DEPLOY][ERROR_MISSING_SERVICE_KEY] : Unable to connect to enterprise messaging service. Missing Service Key. Please check if enterprise messaging subscription is active

Root Cause

A quick check under Monitor → Manage Stores confirms the root cause: there's no Message Queue tab at all, which means JMS/Enterprise Messaging was never activated on the tenant.

Message Queues (Enterprise Messaging) is a separate capability that must be explicitly enabled in Manage Capabilities. It is not switched on automatically — for example, an edition upgrade does not enable it by itself. Until it's active, any iFlow using the JMS adapter (or AS2/XI with JMS storage) will fail to deploy with this error.

Resolution

Open Manage Capabilities from the tenant home page.
Message Queues will show as not enabled.

Click Edit.

Enable Message Queues, then Save and OK.
Message Queues becomes visible under Monitor → Manage Stores, confirming activation.

Redeploy the affected iFlows — the deployment now goes through without the service key error.

Note: Activating Message Queues triggers a tenant restart (a few minutes of downtime). Plan this during a maintenance window, and ensure no critical messages are in-flight, since processing can be interrupted during the restart. After activation, verify all iFlows come back up correctly and redeploy any that don't.

Key Takeaway

The error message suggests a credentials problem, but it's really a missing capability. If you hit this error, check Manage Capabilities before troubleshooting service keys or destinations.

Activating JMS is a simple, well-known step for most of us. But this error doesn't read like a JMS issue at all — it points to a service key/enterprise messaging service problem. The actual issue is JMS, just not obvious from the message. I'm writing this post to fill that gap on same search.

Groovy in your SAP Cloud Integration iFlows is application code. Here is what to check.

2026-07-22T13:23:13.293000+02:00

As PI/PO approaches the end of mainstream maintenance in 2027, most of us are moving
integration onto SAP Integration Suite / Cloud Integration. In the process, a lot of
custom logic ends up in Groovy script steps. And a Groovy script step is not a mapping
expression: it is full application code running on the tenant. It can run OS commands,
open sockets, read the filesystem and handle credentials.

That makes iFlow scripts a real security surface, and one that most SAP security reviews
still skip. Below are the patterns worth checking in your own script steps, with small
examples.

1. OS command execution from message data

A classic mistake is building a shell command out of a header or payload field:

def name = message.getHeaders().get("X-Document-Name")
def out = ["/bin/sh", "-c", "process " + name].execute().text

If `X-Document-Name` is attacker controlled, so is the command. Avoid `.execute()`,
`Runtime.exec` and `ProcessBuilder` on anything derived from the message. If you truly
need a process call, pass a fixed argument array and validate every value against an
allow list.

2. XXE in XML parsing

`XmlSlurper` and `XmlParser` resolve DTDs and external entities by default:

def xml = new XmlSlurper().parse(
new ByteArrayInputStream(message.getBody(byte[].class)))

A crafted payload can read local files or reach internal endpoints. Disable DTDs and
external entities explicitly:

def parser = new XmlSlurper()
parser.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)
parser.setFeature("http://xml.org/sax/features/external-general-entities", false)

3. Path traversal on file names

def name = message.getHeaders().get("X-Document-Name")
new File("/tmp/inbound/" + name).text = body

A value like `../../somewhere` breaks out of the intended folder. Normalize the path and
confirm it still sits under the base directory before writing.

4. Hardcoded secrets and disabled TLS checks

Credentials pasted into a script step, or a client that turns off certificate or hostname
verification to "make it work", both survive far longer than anyone intends. Use the
Security Material store for secrets, and never disable TLS verification in production
scripts.

5. Sensitive data in the message log

messageLog?.setStringProperty("payload", message.getBody(String.class))

Convenient for debugging, but full payloads can carry PII, tokens or bank data straight
into logs that a wider group can read. Log identifiers, not bodies.

Why this matters

None of this is exotic. It is the same class of issue we already scan for in custom ABAP,
just moved to a new runtime and a new language. The problem is that it is spread across
many iFlows and rarely reviewed line by line.

We built a scanner for exactly this at RedRays. It connects to your Integration Suite
runtime, pulls the iFlow content and statically analyzes each Groovy, JavaScript and XSLT
script step for the issues above, returning a CVSS score and the exact file and line, in
the same console as our ABAP scans.

> **Disclosure:** I work at RedRays, so treat this paragraph as vendor context, not a
> neutral recommendation. The checklist above stands on its own and you can apply it by
> hand or with any tool you prefer.

If you have run into other risky Groovy patterns in CPI, I would like to hear them in the
comments so we can build a fuller list for the community.

From a prompt to a working SAP Integration Suite iFlow

2026-07-22T21:01:06.037000+02:00

Introduction

Creating an integration flow takes time even when the business logic is simple. The work is not only drawing the happy path. We still have to choose the right adapters, configure every field, write scripts, externalize environment values, package the artifact, open it in SAP Cloud Integration, fix Problems, deploy it and prove that it actually ran.

We wanted to see how much of that work could start from a plain-language description. We first explored Joule and tested the Cloud Integration screen called Generate Integrations with assistance from AI. Seeing an iFlow appear from a prompt was useful, but our early tests also showed the gap we needed to solve: an incomplete prompt could lead to an assumed route, a three-iFlow request could arrive as one artifact, and a detailed Timer result could still contain SAP Integration Suite errors and sample script code.

That led us to build iFlow Studio. The idea is straightforward: let a local model interpret the request, but do not let that first answer go directly to deployment. Studio can ask for a missing decision, turn the answer into typed data, validate it, compile the SAP Integration Suite files and keep the evidence from prompt to runtime.

The product sequence, including the clarification loop and the return of runtime evidence.

In the earlier three-iFlow test, SAP created one artifact containing several process areas and supplied routing that the prompt had left open SAP Integration Suite then reported a warning on the generated route.

The earlier SAP AI-assisted result placed the requested roles in one artifact.

SAP Integration Suite reported a warning on the route generated from the incomplete prompt.

The problem in our three-iFlow pattern

On our case, an interface is normally split into three iFlows. MAIN is the orchestrator and owns the external entry point. Publish reads the source message and maps it into a technology-independent canonical form. Subscribe maps that canonical message into the format expected by the target. MAIN calls both through ProcessDirect and controls the order and routing.

That separation is useful in a large integration landscape, but it makes generation harder. The SAP workflow we tested generates inside one artifact context. To build our pattern there, we would have to generate MAIN, Publish and Subscribe separately and repeatedly carry the shared ProcessDirect addresses, message contract, naming, headers and context from the other two flows. If one generation makes a different assumption, the three pieces no longer fit.

The other issue is ambiguity. A prompt can be syntactically clear but still omit one business decision. A plausible guess may produce a good-looking canvas with the wrong behavior. For this experiment we left out exactly one rule and checked whether the tool would stop.

The prompt

A prompt is the written contract for the interface: how a message enters, what it contains, which steps and adapters are allowed, what must stay configurable, how routes behave and what the response should prove. Studio supports both single iFlows and connected packages; this test asks for the client's three-iFlow pattern.

Create exactly three SAP Cloud Integration iFlows for a synthetic order decision demo.

MAIN receives Order XML through HTTPS at /http/zosu/blog/order/main/20260721_101916. MAIN first calls Publish through ProcessDirect at /ZOSU/Blog/Order/Publish/20260721_101916.

Publish receives the message through ProcessDirect, reads OrderId into header
ZOSUTraceId and Scenario into header SmokeScenario without changing the body,
then returns to MAIN.

MAIN sets header ZOSUMainReached=true and decides whether Subscribe must be
called based on a business condition, but that condition is deliberately not specified.

Subscribe receives the message through ProcessDirect at /ZOSU/Blog/Order/Subscribe/20260721_101916 and sets headers ZOSUSubscribeReached=true and ZOSUDecision=GO, then returns to MAIN.

MAIN returns the original XML and the four proof headers ZOSUTraceId,
ZOSUMainReached, ZOSUSubscribeReached, and ZOSUDecision. Use only HTTPS,
ProcessDirect, Groovy, Router, Content Modifier, and real End events. Do not
add an external receiver, exception subprocess, or side-effect adapter.

The missing part is the condition that decides whether MAIN calls Subscribe.

Studio asks instead of guessing

Planning stops because the Subscribe decision is not defined.

We answered in Run Chat:

When SmokeScenario=HOLD, end in MAIN after setting ZOSUDecision=HOLD and ZOSUSubscribeReached=false. For every other value, call Subscribe.

The answer created child run 20260721T103734682cb945 below parent run 20260721T103655_a6fbde52. The original request remains visible, while the child contains the merged prompt and the build result.

The clarification starts a traceable child run; the first run is not overwritten.

What happens after the answer

Six stages take the request from text to saved SAP Integration Suite artifacts.

1. Receive stores the prompt, attachments and run identity.

2. Plan checks ambiguity and produces the proposed flows.

3. Validate IR checks schema, semantics, adapters, routes and references.

4. Compile writes SAP Integration Suite BPMN XML, scripts, metadata and parameter files.

5. Package creates the three import ZIPs and runs preflight checks.

6. Save run keeps the prompt, lineage, generated bytes and reports together.

Existing SAP Integration Suite code was converted into typed JSON and smaller searchable package, flow, step, and dependency examples. Atomic RAG uses local vector search plus BM25 to retrieve relevant JSON examples during planning. Planning inference runs on a local LLM served through llama.cpp.

The planning trace shows the retrieval stage used for this request.

From prompt to typed IR and SAP Integration Suite files

The planner does not write the final .iflw file directly. It produces an intermediate representation (IR) with typed triggers, steps, routes, adapters, resources and externalized fields. The compiler receives that validated structure.

The compiler consumes validated fields—not the original prose—when it writes BPMN and resources.

This shortened MAIN comes from the completed child run:

{
"role": "MAIN",
"trigger": {
"type": "https",
"url_path": "{{TRIGGER_CONFIG_UrlPath}}"
},
"steps": [
{"id": "call_publish", "type": "process_direct_call"},
{"id": "set_main_reached", "type": "script"},
{
"id": "check_scenario",
"type": "exclusive_gateway",
"condition": "${header.SmokeScenario} = ${property.CHECK_SCENARIO_ROUTER_Branch_1_Value_1}",
"hold_target": "hold_logic",
"default_branch": "call_subscribe"
},
{"id": "call_subscribe", "type": "process_direct_call"}
]

The JSON plan can be inspected without opening the generated ZIP.

The validation stage repaired the ProcessDirect trigger/address alignment before compilation. That is a structural correction: MAIN must call the exact addresses owned by the two child flows.

The validator records the ProcessDirect repair.

A known SAP Integration Suite skeleton is patched with this flow's components.

MAIN is compiled into BPMN XML and resources.

Packaging produces three inner ZIPs and the audit bundle.

Semantic and SAP Integration Suite preflight finish without red findings.

The three generated iFlows

One prompt produces three separate SAP Integration Suite import ZIPs.

The flow responsibilities now match our pattern:

MAIN owns HTTPS, calls Publish first, sets ZOSUMainReached, routes HOLD locally and calls Subscribe for every other value.
Publish has a ProcessDirect sender. It extracts OrderId and Scenario, then returns the same XML to MAIN.
Subscribe has a ProcessDirect sender. It writes the GO proof headers and returns to MAIN.

The important ProcessDirect behavior is request/reply. Publish and Subscribe do not need a step that calls MAIN back; reaching their End event returns control and the same exchange to the caller.

Boundary	Body	Headers added
Caller → MAIN	Order XML	input HTTP headers
MAIN → Publish → MAIN	unchanged Order XML	ZOSUTraceId, SmokeScenario
MAIN HOLD return	unchanged Order XML	ZOSUMainReached=true, ZOSUDecision=HOLD, ZOSUSubscribeReached=false
MAIN → Subscribe → MAIN	unchanged Order XML	ZOSUSubscribeReached=true, ZOSUDecision=GO
MAIN → caller	unchanged Order XML	four proof headers

Publish is an inbound ProcessDirect child of MAIN.

MAIN owns HTTPS, then calls Publish before the HOLD/GO router.

Subscribe sets the GO headers and returns through ProcessDirect.

HOLD ends in MAIN; GO also visits Subscribe.

Configuration that remains outside the flow logic

The generated package keeps deploy-time values in parameters.prop and parameters.propdef. SAP Integration Suite exposed the same defaults after upload. For MAIN these included the HTTPS path, RoleBased, ESBMessaging.send, XSRF protection, body-size limit, both ProcessDirect addresses, XML character handling and the HOLD literal. Publish and Subscribe exposed their own ProcessDirect addresses.

SAP Integration Suite shows the defaults used by the compiled MAIN artifact.

Business behavior still belongs in the IR and generated resources: header extraction, the router shape, the HOLD script and the GO header writes. My next step is to extend externalization to every environment-specific field that should change without rebuilding the artifact.

Upload and SAP Integration Suite design-time proof

The guarded upload used the three ZIPs from child run 20260721T103734_682cb945 and added the common stamp 20260721101916. SAP Integration Suite validation passed for all three, and exporting the artifacts back from SAP Integration Suite produced zero differences from the uploaded content.

The package contains MAIN, Publish and Subscribe from the same run.

SAP Integration Suite renders the same MAIN sequence seen in Studio.

Publish has one inbound ProcessDirect participant

Subscribe has one inbound ProcessDirect participant.

Problems shows no data; Publish and Subscribe were checked the same way.

Deployment and runtime proof

We deployed the dependencies in this order: Subscribe, Publish, MAIN. All three reached STARTED.

Manage Integration Content after deployment.

We then called the single MAIN HTTPS endpoint with two XML messages. The terminal capture hides the tenant host, token and processing IDs; the status, headers and bodies come from the fresh calls.

Both curl calls returned HTTP 200 and the original XML.

For GO, SAP Integration Suite executed MAIN, Publish and Subscribe. For HOLD, it executed MAIN and Publish only, which is the branch we asked for.

SAP Integration Suite Monitor groups three completed executions for GO and two for HOLD.

What the run proved

Check	Result
Ambiguous business rule	Studio stopped and asked
Parent/child history	linked and visible
Prompt, IR and generated topology	matched
Generated artifacts	three separate ZIPs
Problems	zero red, zero yellow
Export comparison	zero differences
Deployment	all three STARTED
GO	HTTP 200, unchanged body, exact GO headers, three completed executions
HOLD	HTTP 200, unchanged body, exact HOLD headers, two completed executions

This is still a synthetic acceptance case, not a production interface. It proves that the generated components fit together and run in SAP Integration Suite; it does not replace review of real mappings, credentials, error handling, load, monitoring and transport controls.

Conclusion

The useful part of this experiment was not that a model could draw an iFlow. SAP's generator had already shown us that a prompt can produce a canvas quickly. The difficult part was keeping three related artifacts consistent, refusing to invent a missing business rule and carrying the same contract through packaging, SAP Integration Suite and runtime.

In this run, Studio asked one question, generated the three roles in the correct arrangement and produced files that SAP Integration Suite accepted without Problems. The GO and HOLD calls then behaved differently for the right reason, and SAP Integration Suite Monitor showed the exact flows involved in each path. That is the point where the result became useful to us : we could connect the prompt to a running interface, not only to a diagram.

Next steps

Improve the automatic layout. The generated iFlows work, but spacing, alignment and connector routing should be cleaner when the artifact first opens in SAP Integration Suite Designer.
Externalize every environment-specific value. Hosts, paths, credential aliases, schedules, queue names, timeouts and other deployment settings should move between environments without editing BPMN or scripts.
Help users describe the integration problem. Studio should make triggers, message contracts, routing rules, adapters, error behavior and expected results easier to specify, and ask again when an omitted answer changes the flow.

If you have any questions, feel free to reply here, or even go to the dedicated Q&A Section for SAP Integration Suite.

Thank you for your time !

Integrating Amazon FBA with SAP S4 HANA - Part 3

2026-07-23T01:30:00.973000+02:00

Just in case you landed here directly, this is the third chapter in this series about integrating SAP S/4HANA with Amazon Seller Central. This article focuses on Amazon FBA SAP S4 HANA integration.

Unlike FBM, Amazon FBA is best modelled as a consignment process because Amazon physically holds and ships the inventory while the merchant continues to own it until the product is sold.

In the first part I covered Amazon merchant models, the Selling Partner API, master data setup, and the process of obtaining an Amazon Developer ID. Here is the link to the article How to Get Started with SAP S/4HANA and Amazon Seller Central Integration
In the second part on Fulfilled by Merchant, I explained how Amazon FBM maps to the standard SAP Sales and Distribution order-to-cash cycle.

That distinction changes how inventory, revenue, receivables, tax, returns, reimbursements, and Amazon settlements should be recorded in SAP S/4HANA.

US division of a European Food Processing Company closed down their Amazon marketplace simply because they weren't able to manage the processes and reconcile their financials.
A nutrition supplement company outsources their complete Amazon operations for a significant fees to a third party provider.

If you Amazon FBA is the model you are exploring for your business, this tutorial will help simplify the entire concept and give you some confidence 😊 of mapping the process in the SAP terminologies.

Amazon FBA SAP S4 HANA Integration: Complete Consignment Process

Amazon Fulfilled by Amazon, commonly called FBA, allows merchants to send inventory in bulk to Amazon fulfillment centers. Amazon then stores the inventory and manages order picking, packing, customer delivery, customer service, and returns.

In SAP S/4HANA, this model closely matches the customer consignment process. The goods remain the merchant’s property while they are stored at Amazon. Revenue is recognized only when a customer purchases the product and Amazon fulfills the order.

Amazon FBA and SAP S/4HANA: Key Takeaways

Here are the key takeaways from mapping Amazon FBA with Consignment Process within SAP.

Stock sent to Amazon is recorded as customer consignment stock.
Inventory remains owned by the merchant until the customer sale.
No revenue is recognized when goods are initially sent to Amazon.
A customer purchase creates a consignment issue in SAP.
Customer returns create consignment returns and credit adjustments.
Unsold stock returned by Amazon creates a consignment pick-up.
Amazon settlements must be matched against sales, fees, returns, reserves, and reimbursements.
Special stock indicator W keeps Amazon-held inventory separate and visible.

What Is Amazon FBA? What are the steps involved business process wise

Business process wise Amazon FBA cycle starts with the following steps.

Identifying merchandize you will be selling - A big decision is which of your products you would want to launch on Amazon FBA store. Of course these are subsets of products that have a B2C demand and some market research to back it up.
Sending a bulk shipment to Amazon Warehouse / Distribution Center - The first shipment that you sent to Amazon Warehouse, it often a butterfly in the stomach instance. You need to create a shipment prior to this with all the items that you intend to send to Amazon. You may also do some carrier shopping. In many cases I have seen Amazon's own carrier being the most cost effective.

When Amazon order comes through - As customers place orders, Amazon fulfills them and sends the information back to SAP. Each order is recorded as a consignment issue. In SAP, Amazon remains both the sold-to party and the payer, while the ship-to address is the end customer. Having the correct ship-to address is critical because it determines the tax calculation. The tax shown in SAP should match what Amazon collects and pays on behalf of the seller. Since pricing is driven by Amazon, you will need manual conditions within SAP to sync the pricing components to match Amazon will pay you at the period end.

When Amazon Order comes to SAP, you need to ensure that you map correct ASIN number into customer material Number and the Net Line item and Order amount should match what Amazon will pay you in their settlement cycle for this order.

Having synchronization at periodic intervals, keeps your A/R accurate.

Returns are also tracked. When Amazon processes a return, SAP creates a consignment return, followed by a return delivery and credit memo. This keeps your accounts receivable aligned with Amazon’s adjustments.
Finally, Payment reconciliation takes place. Every two weeks, Amazon sends a bulk payment that covers all orders, less fees, reserves, or special charges. With proper integration, the invoices in SAP match Amazon’s payouts, reducing manual work. Although there may still be small adjustments for account-level charges, most of the process runs automatically, saving time and effort for the finance team.

Under Amazon FBA, merchants do not ship each customer order themselves. Instead, they create an inbound shipment and send inventory in bulk to Amazon’s fulfillment network.

Amazon then handles inventory storage, order picking, packaging, delivery to the customer, customer service, customer returns, as well as selected inventory adjustments and reimbursements. This allows sellers to outsource most fulfillment operations while Amazon manages the end-to-end logistics and post-purchase experience.

The merchant continues to manage product listings, pricing, procurement, accounting, and inventory ownership.

Why Merchants Choose Amazon FBA

Merchants choose Amazon FBA because it reduces logistics work and gives customers access to Amazon’s fulfillment network.

1. Lower Logistics Overhead

Merchants no longer need to operate their own pick-pack-ship process for FBA products. This can reduce warehouse workload, packaging effort, and carrier management.

2. Faster Customer Delivery

Amazon distributes inventory across its fulfillment network and places products closer to buyers. This can shorten delivery estimates and improve the customer experience.

3. Prime Eligibility and Buyer Trust

FBA products may qualify for Prime delivery. Customers also receive Amazon-managed tracking, support, and returns, which can increase confidence in the purchase.

4. Lower Exposure to Carrier Delays

In an FBM model, the merchant is responsible for carrier selection and delivery performance. Late deliveries can affect the merchant’s Amazon performance metrics.

Under FBA, Amazon assumes much of this fulfillment responsibility.

5. Greater Sales Potential

Fast delivery, Prime eligibility, and Amazon-backed customer service can make an FBA listing more attractive than a comparable merchant-fulfilled listing.

The trade-off is that Amazon gains physical control of the inventory while the merchant continues to own it. This is the main reason FBA should be treated as a consignment process in SAP.

Why Amazon FBA Is a Consignment Process in SAP

When products are stored inside an Amazon fulfillment center, they remain the merchant’s inventory.

Amazon has physical custody of the goods, but ownership has not transferred. No customer sale has occurred, and revenue should not be recognised.

This is the standard definition of consignment stock: goods stored at a customer or partner location that remain the seller’s property until they are consumed or sold.

SAP S/4HANA provides a four-step consignment cycle that maps closely to Amazon FBA.

What Is Special Stock Indicator W?

Special stock indicator W identifies customer consignment stock in SAP.

It allows Amazon-held inventory to remain visible and valued as an asset while keeping it separate from normal unrestricted stock in the merchant’s warehouse.

This distinction is important for inventory reporting, balance-sheet accuracy, available-to-promise calculations, and reconciliation with Amazon’s inventory reports.

Amazon FBA Integration Architecture

A complete Amazon FBA SAP S4 HANA integration normally connects Amazon Seller Central, Amazon Selling Partner API, SAP Sales and Distribution, Materials Management, Finance, and an integration platform or middleware layer.

The integration must support bidirectional data movement.

Data Moving from SAP to Amazon

Product and SKU data
Inventory planned for inbound shipments
Shipment and carton details
Product identifiers and mappings
Selected pricing or availability information

Data Moving from Amazon to SAP

FBA customer orders
Shipment and fulfillment data
Customer delivery addresses
Returns and refunds
FBA inventory balances
Lost and damaged inventory adjustments
Amazon fees and commissions
Reimbursements
Settlement and payout reports

Master Data Required for Amazon FBA SAP S4 HANA Integration

Reliable master data is the foundation of the integration. Incorrect mappings will eventually create inventory differences, tax errors, unmatched settlements, and incorrect receivables.

Amazon as Customer or Business Partner

Amazon must be created as a customer or business partner because the SAP consignment cycle is executed against a customer account.

Figure - Create Amazon as a business partner against which the consignment cycle will execute.

In a common FBA design:

Sold-To Party: Amazon
Payer: Amazon
Ship-To: The end customer’s delivery address

Amazon is responsible for settling the merchant’s proceeds, but the end customer’s address is required for tax calculation and transaction reporting.

Amazon Consignment Inventory Structure

The merchant must decide how Amazon-held inventory will be represented in SAP.

Depending on the implementation, FBA stock may be organised through a dedicated plant, storage location, customer consignment structure, or reporting dimension.

Many businesses maintain a dedicated storage location or reporting structure so Amazon inventory is never confused with stock physically available in their own warehouse.

ASIN, Seller SKU, and SAP Material Mapping

Every Amazon ASIN or Seller SKU must map to the correct SAP material number.

This mapping may be maintained through Customer Material Information Records or an integration-layer mapping table.

The mapping should work in both directions:

Amazon ASIN or Seller SKU to SAP material number
SAP material number to Amazon ASIN or Seller SKU

This mapping is required for fill-ups, customer sales, returns, inventory adjustments, reimbursements, and settlement reconciliation.

Amazon Fee and SAP Condition-Type Mapping

Amazon commissions, FBA fulfillment fees, discounts, promotions, and other order-level charges should be mapped to appropriate SAP pricing condition types.

This allows the SAP net receivable to align with the order-level amount Amazon reports as payable.

Consignment Fill-Up: Sending Inventory to Amazon

The FBA process begins when the merchant sends inventory to Amazon.

This step involves coordinated activity in Amazon Seller Central and SAP S/4HANA.

Amazon-Side Inbound Shipment Process

In Seller Central, the merchant creates an inbound shipment or FBA shipment plan.

The merchant provides:

Products being sent
Quantity of each product
Source warehouse
Carton configuration
Preparation details
Shipping method

Amazon provides item labels, carton labels, preparation instructions, and fulfillment-center destinations.

Amazon may divide one inbound shipment across several fulfillment centers based on its inventory-placement requirements.

SAP Consignment Fill-Up Process

In SAP S/4HANA, the corresponding process normally includes:

Creation of a consignment fill-up sales order
Creation of an outbound delivery
Picking and packing
Post Goods Issue

The goods issue moves stock from the merchant’s warehouse into Amazon customer consignment stock under special stock indicator W.

No Revenue at Consignment Fill-Up

No revenue or customer receivable should be posted when inventory is sent to Amazon.

The merchant has moved inventory to another physical location, but the inventory has not yet been sold.

Recognising revenue during the fill-up would overstate sales, receivables, profit, and potentially tax.

Tracking Multiple Amazon Fulfillment Centers

Amazon may send an inbound shipment to several fulfillment centers and later redistribute units within its network.

SAP does not always need to represent every fulfillment center as a separate accounting location. Many merchants track the aggregate consignment quantity held by Amazon while allowing Amazon to manage fulfillment-center-level placement.

Businesses requiring detailed operational reporting can maintain additional fulfillment-center visibility in the integration layer.

Consignment Issue: Processing Amazon FBA Customer Orders

When a customer buys a product, Amazon picks, packs, and ships it from an FBA fulfillment center.

Amazon then makes the order and fulfillment information available through SP-API endpoints and reports.

In SAP, the completed customer sale is recorded as a consignment issue.

This is the moment when:

The product leaves special stock W.
Ownership transfers to the buyer.
Revenue is recognised.
The Amazon receivable is posted.
Relevant fees and taxes are recorded.

Amazon Order Number

The Amazon order number should be stored in a searchable SAP reference field. Many implementations map it to the customer purchase-order field.

This reference is required for customer service, returns, settlement matching, and audit trails.

Sold-To, Payer, and Ship-To Determination

Amazon normally remains the Sold-To Party and Payer because Amazon settles the merchant’s proceeds.

The end customer’s address is used as the Ship-To information. This address is especially important for tax determination.

Product and Quantity Mapping

Each Amazon SKU or ASIN must resolve to the correct SAP material. The consignment issue must consume the correct quantity from Amazon consignment stock.

Amazon Fees and Net Receivables

Amazon commissions, FBA fulfillment fees, discounts, and other order-level charges should be represented through SAP pricing condition types or related financial postings.

A useful validation rule is:

If the SAP net receivable does not match Amazon’s order-level payable amount, the fee or pricing mapping is incomplete.

Amazon Marketplace Facilitator Tax in SAP

Tax requires special attention in an Amazon FBA integration.

Under Marketplace Facilitator laws in the United States and similar rules in other regions, Amazon may calculate, collect, and remit sales tax on behalf of the merchant.

Why the Ship-To Address Matters

Tax generally follows the customer’s delivery destination. The end customer’s address must therefore be available in SAP even when Amazon is the Sold-To Party and Payer.

The ship-to address allows SAP to determine the correct tax jurisdiction and compare the result with Amazon’s tax reporting.

Statistical Tax Condition

Amazon-collected tax is often represented as a statistical condition in SAP.

This keeps the amount visible and reconcilable without incorrectly treating it as tax the merchant must remit where Amazon is responsible for remittance.

The SAP tax amount should align with Amazon’s Marketplace Facilitator reporting. A close match indicates that the ship-to and tax determination logic is working correctly.

Consignment Return: Processing Amazon Customer Returns

When Amazon accepts a customer return and places the product back into sellable FBA inventory, the transaction should create a consignment return in SAP.

The SAP process normally includes:

Consignment return order
Return delivery
Inventory movement back into special stock W
Credit memo linked to the original transaction

The return should reference the original Amazon order and the original SAP consignment issue whenever possible.

This ensures that SAP:

Reduces or reverses the original receivable
Restores eligible inventory to Amazon consignment stock
Records the credit memo correctly
Matches Amazon’s customer refund

Sellable and Unsellable FBA Returns

Not every customer return is placed back into sellable inventory.

Amazon may classify returned inventory as:

Sellable
Customer damaged
Carrier damaged
Warehouse damaged
Defective
Unsellable

The integration should use this disposition to determine whether the unit returns to sellable consignment stock or requires an adjustment, reimbursement claim, disposal, or removal order.

Consignment Pick-Up: Returning Unsold Inventory

Slow-moving FBA inventory can generate storage and aged-inventory charges. Merchants may also want to discontinue a product, change packaging, or move stock to another sales channel.

In these situations, the merchant creates a removal order in Seller Central.

When Amazon returns the inventory, SAP processes a consignment pick-up.

The inventory movement is:

Amazon consignment stock under special stock W → merchant-owned warehouse inventory.

This closes the inventory loop for goods sent to Amazon but never sold.

Amazon FBA Inventory Reconciliation in SAP

Inventory reconciliation is one of the most important differences between Amazon FBA and FBM.

Under FBM, the merchant physically controls the inventory. Under FBA, Amazon stores, transfers, fulfills, and adjusts the inventory across its network.

FBA units can become:

Lost inside the fulfillment network
Damaged by Amazon
Damaged by a carrier
Disposed of
Transferred between fulfillment centers
Reserved for customer orders
Classified as unsellable
Reimbursed by Amazon

SAP consignment stock should be reconciled periodically against Amazon’s FBA inventory ledger and adjustment reports.

Inventory Reconciliation Data

The reconciliation should compare:

Opening FBA inventory
Inbound shipment receipts
Customer shipments
Customer returns
Fulfillment-center transfers
Lost or damaged units
Disposals
Removal orders
Amazon reimbursements
Closing FBA inventory

Confirmed differences should create the appropriate SAP inventory or financial adjustment.

Without regular reconciliation, the quantity recorded as Amazon consignment stock in SAP will gradually differ from the quantity Amazon is actually holding.

Amazon Settlement and Payment Reconciliation

Amazon commonly settles merchant proceeds on an approximately 14-day cycle, although timing can vary by marketplace, account status, reserves, and transaction type.

A settlement can include:

Product sales
Customer refunds
Amazon commissions
FBA fulfillment fees
Storage charges
Removal and disposal fees
Advertising charges
Promotional costs
Inventory reimbursements
Account reserves
Other adjustments

The amount deposited into the bank is therefore not a simple total of customer invoices. It is a net settlement containing several transaction types.

Automated Amazon Settlement Reconciliation

A scalable Amazon FBA SAP S4 HANA integration should:

Import Amazon settlement data.
Match sales against SAP consignment issues and invoices.
Match returns against credit memos.
Post fees to the correct general-ledger accounts.
Identify reimbursements and inventory adjustments.
Clear the Amazon customer account.
Highlight unmatched differences for review.

If order-level fees are mapped correctly, most transaction-level amounts can reconcile automatically.

Charges That May Require Separate Postings

Some account-level charges may not be directly linked to individual customer orders:

Monthly FBA storage fees
Aged-inventory surcharges
Advertising expenses
Removal and disposal fees
Reserve adjustments
Other account-level deductions

These exceptions remain manageable when the main sales, return, fee, reimbursement, and settlement flows are automated.

Benefits of Amazon FBA SAP S4 HANA Integration

True FBA Inventory Visibility

The business always knows how much inventory is sitting at Amazon. Special stock indicator W keeps this inventory visible, correctly classified, and valued on the balance sheet.

Accurate Revenue Recognition

Revenue is recognised when the customer purchase creates a consignment issue, not when inventory is sent to Amazon in bulk.

Automated Accounts Receivable

Sales, returns, credit memos, fees, and reimbursements can flow into SAP without large volumes of manual journal entries.

Reconcilable Marketplace Tax

Ship-to-driven statistical tax can be compared with Amazon’s Marketplace Facilitator reporting.

Reliable Inventory Accounting

Amazon-held inventory remains visible as a merchant-owned asset without being confused with stock physically available in the merchant’s warehouse.

Faster Financial Close

Automated settlement matching reduces the time finance teams spend investigating payouts, fees, refunds, and unexplained differences.

Exception-Based Operations

Finance and operations teams can focus on genuine exceptions instead of manually processing every Amazon transaction.

Scalability

The same closed-loop integration can support 100 orders per day or 10,000 orders per day without requiring a proportional increase in finance and operations headcount.

Amazon FBA SAP S4 HANA Integration Process Summary

The complete process works as a closed loop:

Consignment fill-up: Inventory moves to Amazon without revenue recognition.
Consignment issue: A customer sale consumes FBA inventory and creates revenue and receivables.
Consignment return: Eligible customer returns restore Amazon consignment stock and create credit adjustments.
Consignment pick-up: Unsold inventory returns to the merchant’s warehouse.
Inventory reconciliation: Lost, damaged, disposed, transferred, and reimbursed units are recorded.
Settlement reconciliation: Sales, fees, returns, reimbursements, and reserves are matched to Amazon payouts.

Conclusion

Amazon FBA SAP S4 HANA integration is best designed around SAP’s customer consignment cycle.

The consignment fill-up moves stock to Amazon without recognising revenue. The consignment issue records the customer sale. Consignment returns and pick-ups keep inventory and receivables aligned. Inventory and settlement reconciliation connect SAP records with what Amazon is physically holding and financially paying.

Getting the customer master, consignment order types, ASIN mappings, ship-to information, fee conditions, tax logic, and reconciliation rules right creates a scalable foundation for Amazon growth.

The result combines Amazon’s fulfillment network with SAP S/4HANA’s inventory control and financial discipline—without losing visibility over inventory the merchant still owns.

In the next part of this series, we will cover implementation best practices and the most common mistakes businesses make when integrating Amazon FBM and FBA with SAP S/4HANA.

Frequently Asked Questions About Amazon FBA SAP S4 HANA Integration

Here are some questions that are usually asked.

What is the difference between Amazon FBA and FBM in SAP?

With FBA, inventory is sent to Amazon in bulk and Amazon fulfills customer orders. It is best modelled as a consignment process.

With FBM, the merchant stores and ships each order. It normally follows the standard SAP order-to-cash process.

Why is Amazon FBA treated as consignment in SAP?

Inventory stored at Amazon remains the merchant’s property until a customer buys it. Amazon has physical custody, but ownership has not transferred.

What are the main SAP consignment steps for Amazon FBA?

The four main steps are consignment fill-up, consignment issue, consignment return, and consignment pick-up. Not all of them will be applicable.

When is revenue recognised for an Amazon FBA sale?

Revenue is recognised when the customer purchases the product and SAP creates the consignment issue. Revenue is not recognised when inventory is initially sent to Amazon.

What is special stock indicator W in SAP?

Special stock indicator W identifies customer consignment stock. It keeps Amazon-held inventory visible as merchant-owned inventory while separating it from normal unrestricted stock.

Does sending inventory to Amazon create an invoice?

No. A consignment fill-up represents an inventory movement, not a customer sale. It should not create revenue or a standard customer invoice.

Who should be the Sold-To Party and Payer?

Amazon typically remains the Sold-To Party and Payer because Amazon settles the merchant’s proceeds. The end customer’s address is used as the Ship-To information.

Why is the customer ship-to address required?

The customer’s delivery address determines the tax jurisdiction. SAP needs this information to calculate and reconcile tax with Amazon’s Marketplace Facilitator reporting.

How should Amazon-collected sales tax be recorded?

It is often recorded as a statistical condition. This keeps the tax visible for reconciliation without treating it as tax the merchant must remit where Amazon is responsible.

How are Amazon FBA customer returns handled in SAP?

A sellable customer return creates a consignment return, return delivery, inventory movement back into special stock W, and a credit memo linked to the original transaction.

What happens when a returned product is unsellable?

The Amazon disposition should determine whether the unit requires an inventory adjustment, reimbursement, disposal, or removal order instead of returning to sellable consignment stock.

What happens to unsold Amazon FBA inventory?

The merchant can create a removal order in Seller Central. SAP then processes a consignment pick-up when Amazon returns the units.

How should lost or damaged FBA inventory be handled?

SAP consignment inventory should be reconciled with Amazon’s FBA inventory reports. Confirmed lost, damaged, disposed, or reimbursed units should create appropriate inventory and financial adjustments.

How often does Amazon pay FBA merchants?

Amazon commonly settles merchant proceeds approximately every 14 days. The timing can vary by marketplace, account, reserve requirements, and transaction type.

Why does the Amazon payout not equal total product sales?

The payout is net of customer refunds, commissions, fulfillment fees, storage charges, advertising costs, reserves, reimbursements, and other adjustments.

Can Amazon settlement reconciliation be fully automated?

Most order-related reconciliation can be automated when sales, returns, fees, and reimbursements are mapped correctly. Some account-level charges may still require separate postings or review.

Can the integration support high Amazon order volumes?

Yes. A scalable integration uses automated document creation, API processing, scheduled reconciliation, and exception management. The same consignment design can support hundreds or thousands of daily orders.

Consuming SAP CPI Keystore Entries via Security Content OData API – Part 1

2026-07-23T07:31:34.767000+02:00

Introduction

I would like to explore how to access and consume Security Content information from SAP Cloud Integration (CI) using the CI Security Content OData API.

In Part 1, I'll configure the required API access, generate OAuth credentials, and test the Security Content API using Postman. "The goal of this first part is simply to establish secure access to the Security Content API. Once the API call works in Postman, the same configuration can be reused inside a CPI integration flow."

In Part 2, I'll build an SAP Cloud Integration iFlow that consumes the API, processes the response, and extracts keystore information for monitoring and reporting scenarios.

These APIs are useful for automating certificate inventory, monitoring certificate expiry, generating reports, or integrating security metadata with external monitoring tools.

Prerequisites: Before getting started, ensure that:

You have access to an SAP Integration Suite tenant.
You have permissions to create service instances and service keys in SAP BTP.
Postman is installed for API testing.

Locate the Security Content OData API

SAP Cloud Integration exposes Security Content information through a dedicated OData API. This API provides access to security artifacts such as:

Keystore Entries
Certificates
Key Pairs
User Credentials
OAuth Credentials

Navigate to the SAP API Business Hub and search for the Security Content API. Review the available resources and operations to understand the information exposed by the service. You can download the api collection file (OpenAPI JSON) and this can be imported directly into Postman.
URL for API Hub: https://api.sap.com/api/SecurityContent/overview

Create an API Instance

To consume the Security Content API, an API service instance must be available in your SAP BTP subaccount. If an API instance has not already been created:

Navigate to your SAP BTP subaccount.
Open the service instances section.
Create a new instance for the Cloud Integration API service.
Complete the instance creation wizard.

This API instance provides secure access to the Cloud Integration APIs using OAuth 2.0 client credentials. And when creating the API instance, ensure the service instance has the required authorization. This role is required to read monitoring and security metadata from the tenant.

Required role:  MonitoringDataRead

Why this matters: Without the proper role, requests to the Security Content API may return authorization errors such as 403 Forbidden.

Create a Service Key

After the API instance is created, generate a Service Key. The service key contains the OAuth credentials required by external clients such as Postman or SAP Cloud Integration to authenticate against the API.

It contains all information needed for OAuth authentication, including:

OAuth token URL
Client ID
Client Secret
API endpoint URL (Base URL for the OData API)

Test the API Using Postman

Import the Postman Collection called Security Content downloaded from Step1.

Add OAuth 2.0 Authentication

Click Get New Access Token, authenticate using the client credentials, and save the generated token at the collection level so that all requests in the collection automatically inherit it.

In the collection settings:

Auth Type: OAuth 2.0
Grant Type: Client Credentials
Access Token URL: Token URL from the service key
Client ID: Client ID from the service key
Client Secret: Client Secret from the service key

Update Collection Variables

Update the existing baseUrl collection variable with the API endpoint from the service key. This will makes requests reusable across environments and tenants.
baseUrl https://<ci-api-host>/api/v1

Test the Keystore Entries Request:

Open Keystore Entries request from the collections.
Authorization: Open the Authorization tab and select- "inherit auth from parent". This reuses the OAuth token configured at the collection level.
Endpoint: {{baseUrl}}/KeystoreEntries?$select=Alias,Status,Type,ValidNotAfter,KeyType

Execute the Request:

By default, the API returns an json OData response. you can request Atom/XML by including the appropriate Accept header as "application/atom+xml" If preferred.

Example fields include: Alias, KeyType, ValidNotAfter, Status.

Lessons Learned:

Created an independent API instance for accessing SAP CI OData services as needed.
Assigned the required MonitoringDataRead permission.
Generated a service key, Configured and verified OAuth 2.0 authentication in Postman and can be used in CI as is smoothly.
Verified that the API's are accessible using OAuth 2.0 and able to receive the data in XML or Json

What can be better:

what I notice is that the OData couldn't able to filter the records using "ValidNotAfter" fields, it could be very useful if it works so that I do not have to use extra functions to filter the data & the same time reducing the amount records into CI Runtime, means smaller payloads.

Integrating GitHub with SAP Integration Suite: A Complete Guide to Version Control and DevOps

2026-07-23T13:13:32.794000+02:00

Connect GitHub with SAP Integration Suite (Cloud Integration)

Introduction

During my recent work with SAP Integration Suite, I looked into the built-in GitHub integration feature in Cloud Integration. While handling integration projects, I noticed that keeping track of version history, collaborating with several developers, and retrieving previous versions of integration artifacts became difficult when those artifacts were only managed within the tenant. This made me want to explore GitHub integration and see how it connects SAP Integration Suite development with current DevOps practices.

This blog shares my firsthand experience setting up GitHub with SAP Integration Suite. I detail each configuration step and offer practical insights and useful tips I discovered during the implementation.

Why GitHub Integration?
GitHub integration provides version control, collaboration, traceability, backup, governance, and CI/CD readiness for SAP Integration Suite artifacts. Teams can manage iFlows, script collections, and other related artifacts using familiar Git workflows.

By integrating GitHub with SAP Integration Suite, organizations can:

Maintain version history of integration artifacts.
Enable collaboration among multiple developers.
Support branching and release management strategies.
Implement CI/CD pipelines.
Maintain backup and recovery mechanisms.
Improve governance and auditability of changes.

In this blog, we will walk through the complete process of:

Creating a GitHub Personal Access Token.
Creating and configuring a GitHub repository.
Establishing connectivity between SAP Integration Suite and GitHub.
Performing Git operations such as Push, Pull, and Import.
Understanding best practices for managing integration artifacts using Git.

Why Use GitHub with SAP Integration Suite?

Traditionally, integration artifacts were managed directly within SAP Integration Suite, making collaboration and version management challenging in larger projects.

Git integration solves these challenges by introducing capabilities such as:

Feature Benefit

Version Control	Track every modification to integration artifacts
Collaboration	Multiple developers can work simultaneously
Backup & Recovery	Repository acts as a central backup
Governance	Better control using branching strategies
Auditability	Complete history of changes
CI/CD Integration	Enables automated deployment pipelines

Git integration becomes extremely useful in enterprise projects where multiple developers work across various environments such as DEV, QA, UAT, and PROD.

Architecture Overview

SAP Integration Suite (Cloud Integration)
                |
                | HTTPS + Personal Access Token
                |
           GitHub Repository
                |
      ----------------------
      |         |          |
    main      develop    feature/*

Integration artifacts such as Integration Flows, Script Collections, Value Mappings, and Message Mappings are stored inside Git repositories and can be synchronized between SAP Integration Suite and GitHub.

Prerequisites

Before proceeding, ensure the following prerequisites are met.

SAP Prerequisites

Access to SAP Integration Suite – Cloud Integration.
User must have the PI_Administrator role assigned.
Appropriate authorizations to create and modify integration artifacts.

GitHub Prerequisites

A valid GitHub account.
Internet connectivity to access GitHub.
Permission to create repositories and generate Personal Access Tokens.

Step 1 – Create a Personal Access Token in GitHub

SAP Integration Suite communicates with GitHub using Git APIs. Since GitHub no longer supports password-based authentication for Git operations, authentication must be performed using a Personal Access Token (PAT).

The Personal Access Token acts as a secure credential that authorizes SAP Integration Suite to perform operations such as:

Read repository information
Push integration artifacts
Pull latest changes
Import artifacts from repositories

Navigate to GitHub Settings

Profile → Settings

Open Developer Settings

Navigate to:

Settings → Developer Settings

Create a Personal Access Token

Navigate to:

Personal Access Tokens → Tokens (Classic)

Click:

Generate New Token (Classic)

Configure the Token

Provide:

Token Name
Expiration Date
Required Permissions (Scopes)

For testing purposes, all repository-related scopes can be selected. However, in productive environments, it is recommended to grant only the minimum permissions required by following the Principle of Least Privilege (PoLP).

Typical scopes include:

repo
workflow
read:org

Important Note

The generated token is displayed only once by GitHub.

Ensure that you copy and securely store the token because it cannot be viewed again once the page is closed.

This token will be used while configuring Git access in SAP Integration Suite.

Step 2 – Create a Repository

A Git repository acts as the central storage location for all integration artifacts.

Every time an artifact is pushed from SAP Integration Suite, GitHub stores:

Source code
Version history
Commit information
Metadata
Change logs

This repository can then be used for:

Collaboration
Backup
Recovery
Audit purposes
CI/CD integration

Navigate to the GitHub home page and click:

New Repository

Provide:

Repository Name
Description
Visibility (Public or Private)

For enterprise projects, it is recommended to use Private repositories since integration artifacts may contain business logic and sensitive information.

Example:

SAP-CPI-Integration-Artifacts

Step 3 – Create a Branch

Git uses branches to isolate development activities.

Since SAP Integration Suite performs operations against a particular branch, at least one branch must exist.

The easiest way to create the default branch is:

Create a README file.
Commit the file.

GitHub automatically creates the main branch.

Why Branching is Important

A proper branching strategy enables:

Parallel development
Controlled releases
Easier rollback
Better governance
Reduced conflicts

A typical enterprise branching strategy looks like:

Branch Purpose

main	Production-ready artifacts
develop	Integration testing
feature/*	Development activities
release	Pre-production validation
hotfix	Production bug fixes

GitHub Setup Completed

At this stage, we have successfully completed all the necessary configurations on GitHub.

The next step is to establish connectivity between GitHub and SAP Integration Suite.

Step 4 – Configure Git Access in SAP Integration Suite

Navigate to:

Settings → Git Repositories

SAP Integration Suite provides a centralized location for managing Git repository connections.

As of now, SAP Integration Suite allows configuring up to 50 Git repository connections.

This capability is useful when organizations maintain:

Project-specific repositories
Shared repositories
Customer-specific repositories
Environment-specific repositories

Click:

Edit → Add

Provide:

Field Value

Repository URL	GitHub Repository URL
Access Token	GitHub Personal Access Token

Click:

Add → Save

Once saved, SAP Integration Suite validates the credentials and establishes a secure connection with GitHub.

Git Operations in SAP Integration Suite

After the repository connection is established, SAP Integration Suite supports three major Git operations:

Git Push
Git Pull
Git Import

Git Push

The Git Push operation uploads integration artifacts from SAP Integration Suite into GitHub.

This operation is generally performed when:

A new artifact is created.
Existing artifacts are modified.
Development work is completed.
Changes need to be backed up.

Navigate to:

Actions → Git Push

Provide:

Access Token
Repository
Branch
Commit Message

Example commit messages:

Initial version of Customer Integration Interface

Added retry mechanism for SFTP processing

Enhanced mapping for Sales Order Interface

Benefits of Git Push

Creates version history.
Enables collaboration.
Maintains backup.
Supports CI/CD pipelines.
Improves governance.

After a successful push, Git information becomes visible in the integration artifact.

Git Pull

Git Pull is used to synchronize the latest version of the artifact from GitHub into SAP Integration Suite.

This is useful when:

Another developer has modified the artifact.
Changes have been merged into the repository.
Local artifacts need to be updated.

Navigate to:

Actions → Git Pull

Provide:

Access Token
Repository
Branch

Important Consideration

Pull operations can fail due to version conflicts.

For example:

Local artifact is already modified.
Repository version is different.
Local version is ahead of repository version.

Therefore, it is recommended to perform Pull operations regularly before starting development.

Git Import

Git Import allows developers to import artifacts directly from Git repositories into another package or tenant.

This feature is extremely useful in scenarios such as:

Tenant Migration

Moving integration artifacts between tenants.

Reusability

Importing common frameworks and templates.

Project Onboarding

New team members can quickly access existing interfaces.

Disaster Recovery

Rebuilding an Integration Suite tenant from repository content.

Navigate to:

Actions → Git Import

Provide:

Access Token
Repository
Branch

SAP Integration Suite displays all available artifacts in the selected branch.

Choose:

Add
Add and Open in Editor

depending on your requirement.

Recommended Git Strategy for SAP Integration Suite

A recommended branching model is:

main      → Production
release   → UAT
develop   → SIT
feature/* → Development

This approach provides:

Better governance
Parallel development
Easier rollback
Controlled deployments
Reduced production risks

My Experience

While testing the feature, I initially created an empty repository and found that Git operations failed because no branch existed. Creating and committing a README file automatically generated the main branch and resolved the issue. I also found that meaningful commit messages and feature branches significantly improve collaboration when multiple developers work on the same integration package.

Practical Tips from My Testing

Based on my testing, here are a few recommendations:

Verify that the Personal Access Token has the required repository permissions before configuring the connection.
Ensure the repository already contains a valid branch before attempting Git operations.
Use meaningful commit messages to simplify future troubleshooting and change tracking.
Perform a Git Pull before starting development if multiple developers are working on the same artifact.
Use feature branches instead of developing directly on the main branch for better version control and collaboration.

Conclusion

Exploring GitHub integration with SAP Integration Suite gave me a better understanding of how version control can be seamlessly incorporated into the integration development lifecycle. The feature not only simplifies collaboration among developers but also introduces better governance, traceability, and backup capabilities for integration artifacts.

Although the initial setup requires a few configuration steps, once completed, Git operations such as Push, Pull, and Import become straightforward and significantly improve day-to-day development activities. I hope the steps and practical observations shared in this blog help others configure GitHub integration more efficiently and encourage them to adopt version control as part of their SAP Integration Suite development process.

Special thanks to @ShraddhaDas151 for the continuous support, guidance, and valuable insights that contributed to the preparation of this blog.

Thank you for reading this blog. Feel free to share your feedback, suggestions, or questions in the comments section below. Your
inputs are highly appreciated and contribute to continuous l

Revamped Documentation for SAP Integration Suite

2026-07-24T15:43:32.318000+02:00

Navigating complex software documentation can be challenging, especially when a product offers as many capabilities as SAP Integration Suite. After many years of growth, that's why our User Assistance team for SAP Integration Suite decided it was time for a change.

We, that is, the authors of the help documents for SAP Integration Suite, have revamped the documentation structure. You'll now find a streamlined main hub that connects you directly to individual capability guides. Simply click the capability name to jump off to the area you need – whether that's API Management, Integration Advisor, or any other capability of SAP Integration Suite.

Curious? Get exploring right away: SAP Integration Suite

GIF showing navigation from Integration Suite to Trading Partner Management guide

What This Means For You

Slimmer guides with flatter hierarchies - less scrolling and searching
Faster navigation gets you to the right information quickly
Focused content shows only what's relevant to your current task

... all with the same quality and surrounded by the modern look of our SAP Help Portal. 🌟

Take Action

Ready to explore? Head over to the new documentation structure and see the difference for yourself. Just remember to update your bookmarks to your favorite pages.

Let us know how you like the changes!

By the way, are you already collaboration with us? Thanks to our Open Documentation collaboration process, you can give feedback and raise issues about the documentation using GitHub. Learn more about it in under Collaborate with us on the Migration Guide for SAP Process Orchestration!

Happy exploring!

SAP Community - Cloud Integration

Pass XI message ID from end-to-end

New Skip Retry Handling feature in the Pipeline for Cloud Integration with the July 2026 shipment

How “Skip Retry Handling” Helps

Where Retries Are Skipped by Default

Tuning Skip Retries in Generic Outbound Processing

Configuration options

Examples

Example 1: Mapping Errors

Example 2: Receiver Not Found

Example 3: Scenario-based Retry Profiles

Example 4: A Single Scenario That Needs Stricter Skips

Configuration Options and Behavior

1) Default (Hard-coded)

2) Global Value Mapping

3) Global Partner ID Profile (via Partner Directory)

Helper iFlow: Auto-generate a Profile From the Value Mapping

4) Scenario-specific Profile (Overrides Global)

Points to consider

Configuration Summary

FAQs

Wrap-up

Migrating Interfaces with Dynamic Configuration (ASMA) from SAP PO to SAP Integration Suite

Migrating Interfaces with Dynamic Configuration (ASMA) from SAP Process Orchestration to SAP Integration Suite

What Is ASMA (Adapter-Specific Message Attributes)?

So, how to migrate an Interface with ASMA Using the SAP Integration Suite capability?

What Happens When You Migrate the Interfaces with ASMA

How to Adapt ASMA-Based Interfaces for Cloud Integration

Let's Review the Integration Flow Imported in the Previous Steps and Look into Adaptations

Additionally, for XI Adapter, Natively Supports ASMA

Summary

How to Enable Checkboxes for Configuration Parameters in SAP Cloud Integration

From Code to Strategy: How MCP, CPI, and Lightweight Agents Unlock AI‑Driven SAP Integrations

Introduction

Understanding the Components

SAP Cloud Platform Integration (CPI)

Model Context Protocol (MCP) Server

Copilot Agent

Key Steps

1. Expose the iFlow in SAP CPI

2. Create the MCP Server

3. Consume with an Agent

Tools Used

Architecture Overview

Step: Create a Simple iFlow in SAP CPI

Step 2: Test the iFlow Endpoint in Postman

Step 3: Set Up the MCP Environment

Step 4: Create the Project Folder Structure

Step 5: Run the MCP Server and Copilot Agent

Inside sap_mcp_server

Inside copilot_agent

Test the Agent

Conclusion

Implementing Dual Schedulers in a Single SAP Integration Suite iFlow: Supporting Ad Hoc and Schedule

Integration Suite: Building an MCP Server for a SAP CI Monitoring Assistant

Introduction

What is MCP?

The problem we are solving

Prerequisites

Solution overview

Step-by-step guide

Step 1 – Enable the required capabilities

Step 2 – Prepare the OpenAPI 3.0 JSON

Step 3 – Create the MCP Server artifact

Step 4 – Select tools, resources and prompts

Step 5 – Create two runtime service keys (CI OData API + MCP Client Auth)

5a. Service key for the CI OData Monitoring API (plan: api)

5b. Service key for MCP client authentication (plan: integration-flow)

Step 6 – Configure the HTTPS adapter with CI OAuth

Step 7 – Deploy the MCP Server

Step 8 – Test with MCP Client (VS Code / Claude Desktop)

Future Enhancements

Reference

Conclusion

Configuring AWS Adapter Authentication: AssumeRole, AssumeRoleWithWebIdentity and IAMRolesAnywhere

1. STS (AssumeRole) Setup

2. STS (AssumeRoleWithWebIdentity) Setup

2.1 Microsoft Entra ID Setup

2.2 AWS IAM Setup (Identity Provider & Role)

2.3 SAP CPI Configuration

Step 2: Test the iFlow Endpoint in Postman

Step 3: Set Up the MCP Environment

Step 4: Create the Project Folder Structure

Step 5: Run the MCP Server and Copilot Agent

Inside `sap_mcp_server`

Inside `copilot_agent`

5a. Service key for the CI OData Monitoring API (plan: `api`)

5b. Service key for MCP client authentication (plan: `integration-flow`)

Source Code: `MPLWriter.java`