SAP Community - Cloud Integration

Integration Suite in 2025 & 2026

2026-02-03T18:16:06.981000+01:00

Watched this beautiful session by @UdoPaltzer: https://www.youtube.com/watch?v=kFynsigf99o

In case you wanted a quick summary, here you go:

Modernize Integrations:

Use standard content as much as you can
Try to replace your RFCs and IDOCs with OData, Rest, and SOAP.
Leverage Event-driven Integration pattern (for real-time scenarios)
Use Side-by-side extensions to leverage API-centric integrations (with Build)
Leverage monitoring and error resolution capabilities by using SAP AIF (for Business Users), and Cloud ALM (for technical users)

End of maintenance. Time is ticking!

2027 - SAP PO | Standard Maintenance sunset
2030 - SAP PO | Extended maintenance sunset
2028 - Cloud Platform Integration Neo | Services sunset

As far as your migration support is concerned, SAP provides Migration guides, documentation, and community content, which you are already aware of. What is additionally provided is:

SAP Migration Factory | a free 2-3 weeks program to help you assess and plan your migration from PI/PO to Integration Suite
Evolve Neo Program | free access to SAP experts who will help you plan and prepare your migration to Cloud Foundry
SAP Service and Support | quick migration assistance with short duration, low cost engagements

Edge Integration Cell

The latest kid in the block is now flexible to run hybrid integration runtime, which is offered as an optional extension to Integration Suite, which will help customer-managed private landscape to leverage the capabilities of Integration Suite.
The landscapes it supports are: Microsoft AKS, Amazon EKS, Red Hat OpenShift, SUSE Rancher, Google GKE.

Cloud ALM

Your one stop for end-to-end technical health monitoring for: SAP BTP, S/4HANA, S/4HANA Cloud, SuccessFactors, Integration Suite, Customer Experience, Business Network, Concur, Fieldglass.
You can configure the Oubound Channels like: email alerts, on chat-based apps like MS Teams/ Slack, Ticketing System like Service Now, Tasks like JIRA, APIs like SAP Analytics Cloud/ Grafana, and Operation Automations like Build Process Automation, and SAP iRPA, etc.
For us Integration Suite guys, you can use it for Cloud Integratio, API Management and Event Mesh as well.
Specifically for Integration Suite, you can now monitor Tenant Availability, Certificate Validity, Database and Resource consumption, Content, Exhaustion status of JMS queue. So, no more building custom iflows to trigger alerts. Please know that CALM pulls data every 5 mins, and persists data for 30 days. I wonder if they have a feature to display the trace only for failed messages. SAP, are you listening?

Innovations in 2025

Artificial Intelligence
- Joule copilot-based discovery and reuse of artifacts were made available in Business Accelerator Hub
- Generation of Integration flow steps
- Groovy script optimization
- API anomaly detection
- API traffic prediction for usage and trend
- AI adapter
Business Accelerators
- Additional non-SAP adaptors like, AI, Google, BigQuery, IBM MQ (JMS), BigQuery, Microsoft Azure Service Bus, Microsoft OneNote, Mongo DB, Salesforce Pub/ Sub, Shopify, etc
- New design guidelines to ensure upgrade readiness of Groovy Scripts (Camel 3 to Camel 4)
Migration & Modernization
- Generate ABAP proxy in the backend without any dependency on PI
- Edge Integration Cell: Local OData API access, HANA DB, Shared Kubernetes, Basis Authentication during offline mode
- Alerting of failed B2B messages in CALM
- Automatic B2B interface creation based on Payload
API-centric & Event-driven integration
- Lightweight adapter in the context of Advanced Event Mesh for small, light-weight, event-driven integration with non-SAP applications
- Migration support from EM to AEM

Agent-ready Application: IPaaS & AI Market Evolution & Trends

Agent iPaaS
Agent Integrations
Agent Orchestration
AI TRiSm (trusted relationship governance of the AI agents

SAP Integration Suite to become the trusted AI Integration Fabric: IS is evolving to become a trusted AI Integration fabric

Some of the use cases are:

Integration for AI (to make agentic interactions & orchestration to make applications agent-ready)

MCP Gateway
Agent Orchestration
AI Gateway
Agent Identity Verification
LLM connector

AI for Integration (features in IS)

Joule
Anomaly detection
API traffic predictions
Script Optimization
Configuration Agent

2026 SAP Integration Suite Strategic Outlook:

Leveraging Joule for building Integration flows
MCP enablement for APIs
Migration Agents for Java Mappings & adapter modules
AEM events in developer hub
15+ new third-party adapters including Adobe Sign, Google Suite, Oracle, OFTP2, Salesforce Service & Marketing, Cloud, Oracle Eloqua
Joule Skills & AI Agents in SAP Business Accelerator Hub
B2B capabilities in Edge Integration Cell

Roadmap for SAP Integration Suite:

Artificial Intelligence
- Integration flow design validation
- Joule based generation of iflows
- MCP for agentic AI
- Migration agent for adapter modules, Java mapping
- Configuration Agent
- Payload-size anomaly detection
Business Accelerators
- More connectivity options, meaning, more adapters like Google Drive & Sheets Microsoft Excel & Outlook, OFTP2, RosettaNet, Salesforce Service Cloud, etc
- Support for publications of Joule Skills & Agents in Business Accelerator Hub
- Commercial module for Partner Content. Consumers/Customers with a licence to Partner Content can now use it. Currently, customers can copy and use it for free, but from now on, the IP rights are protected, so you can use it only if you have a licence.
Migration & Modernization
- Mass migration from PO to IS
- Edge Integration Cell: customer-managed cloud connectors, offline mode support for 48 hours, B2B capabilities, multiple instances of EIC per Kubernetes Cluster
- SAP IS data centers in Australia, Germany, India, Japan, US.
API-Centric & Event-driven integrations
- AEM health monitoring in SAP Cloud ALM
- Auto discovery and publications of events from AEM to Developer Hub as single catalog for APIs and Events
- Consumption of events through Developer Hub

Integrating IBM MQ On-Premise with SAP Cloud Integration Using the IBM MQ Adapter

2026-02-04T11:07:45.573000+01:00

SAP Cloud Integration offers a wide range of adapters to enable seamless connectivity between business applications. Among these is the IBM MQ Adapter, specifically engineered for messaging scenarios within IBM MQ environments. Notably, this adapter maintains strong feature parity with its predecessor in SAP Process Orchestration (PO), making it an ideal solution for customers planning a migration to the SAP Integration Suite. The IBM MQ adapter is available as part of your Standard license for SAP Integration Suite. For more information, see SAP Note.

Let us first understand how the two variants of IBM MQ adapter interact with SAP Cloud Integration:

JMS (Java Message Service): This adapter uses the native IBM MQ JMS. It is designed for high-performance, stateful connections, supporting features like transacted sessions, message headers (MQMD), and complex correlation IDs.
REST API: This adapter can also interact with IBM MQ using its provided REST APIs.

This blog further discusses the IBM MQ Adapter within the context of the JMS. Furthermore, the adapter supports two connectivity types:

Internet – for connecting to IBM MQ Cloud
On-Premise – for connecting to IBM MQ servers hosted within a customer’s network (via Cloud Connector)

In this blog, we focus exclusively on the On-Premise integration scenario and the available connectivity options to help you integrate your IBM MQ on-premise server with SAP Cloud Integration.

Connectivity Options for IBM MQ On-Premise Integration

You can connect SAP Cloud Integration to an on-premise IBM MQ server using any of the following approaches:

Using EIC (Edge Integration Cell)
Directly from Cloud Integration using One-Way SSL
Directly from Cloud Integration using Two-Way SSL

Below, we discuss each approach in detail.

1. Connectivity Using Edge Integration Cell (EIC)

SAP’s Edge Integration Cell (EIC) allows you to run Cloud Integration capabilities within your own network. When using EIC, you do not need a Cloud Connector because the runtime is already deployed in your on-premise environment.

Prerequisites for Edge Integration Cell Connectivity

The only prerequisite for this setup is that your IBM MQ on-premise server must be reachable from the EIC runtime (via internal network routes).

In this scenario, you configure the IBM MQ adapter using the Internet proxy type, even though you are connecting to an on-premise MQ server. For more details, see SAP Documentation. You can establish No SSL, One-Way SSL, or Two-Way SSL connectivity when using EIC. For One-Way and Two-Way SSL setup details, you can refer to the sections below. The only part that does not apply in the EIC scenario is the Cloud Connector configuration.

2. Connectivity from Cloud Integration Using One-Way SSL

When integrating directly from Cloud Integration (CI) to an on-premise IBM MQ server, the traffic flows via SAP Cloud Connector. To establish a secure connection, you must enable at least One-Way SSL on your MQ channel. Below are the prerequisites and steps for a successful setup.

Prerequisites for One-Way SSL Connectivity

1. Use IBM MQ Adapter Version 1.4.1 or Above

Ensure the IBM MQ adapter version 1.4.1+ is installed in both:

Cloud Integration Design Time, and
Cloud Integration Runtime

Note: This version contains critical SSL enhancements required for secure on-premise connectivity.

2. Create TCP Connectivity in SAP Cloud Connector

Before Cloud Integration can reach your IBM MQ server, you must configure TCP connectivity in the SAP Cloud Connector:

Create a TCP Resource in Cloud Connector for the MQ host and port.
Ensure that the IBM MQ on-premise server is reachable from Cloud Connector (network routing must be open)

This step is mandatory because Cloud Connector acts as the secure tunnel that bridges SAP Cloud Integration with your internal MQ network.

3. Enable One-Way SSL on the IBM MQ Channel

Your IBM MQ server must have SSL CipherSpec enabled for the specific channel used by Cloud Integration.

To configure this:

Open IBM MQ Explorer.
Navigate to your Queue Manager.
Select the Channel used for Cloud Integration.
Open Properties → SSL.
Choose a CipherSpec from the supported list.

IMPORTANT: If other applications are connecting to the same channel, they must also support the newly configured CipherSpec. Otherwise, their connections will fail.

4. Upload the Queue Manager Root Certificate to Cloud Integration

SAP Cloud Integration must trust the IBM MQ server. For this:

Extract the root certificate from the Queue Manager's KDB (Key Database) file
Upload this certificate to the Cloud Integration Keystore

The certificate may be:

Self-signed, or
Signed by a trusted Certificate Authority (CA)

You can select either of the two options as long as Cloud Integration trusts it.

5. Configure Authentication in the IBM MQ Adapter

Depending on the Channel Authentication (CHLAUTH) configuration on the MQ server, you may need to assign:

Authentication Type = None, or
Authentication Type = Basic (username/password)

Because this is a one-way SSL setup, certificate-based client authentication is not required.

When using the Cloud Connector, the connection often appears to MQ as coming from the OS-level user of the SAP environment. If MQ has MQSNOAUT (Security) disabled, the channel might reject the connection if vcap isn't a recognized user on the MQ host. In which case , you might need to enable the vcap user in your IBM MQ Server.

3. Connectivity from Cloud Integration Using Two-Way SSL

Two-Way SSL (also known as Mutual SSL) provides an enhanced level of security where both Cloud Integration and the IBM MQ server authenticate each other using certificates. This setup is recommended for environments with stricter security requirements.

Below are the prerequisites and configuration steps for enabling two-way SSL between Cloud Integration and your IBM MQ on-premise server.

Prerequisites for Two-Way SSL Connectivity

1. Enable SSL CipherSpec and Require Client Authentication on the MQ Channel for Two-Way SSL:

The IBM MQ channel used by Cloud Integration must have an SSL CipherSpec enabled
The channel’s SSL configuration must be set to Require SSL client authentication

This ensures that MQ validates the certificate presented by Cloud Integration.

2. Upload the Queue Manager Root Certificate to Cloud Integration

As with One-Way SSL:

Extract the root certificate from the Queue Manager’s KDB file
Upload it into the Cloud Integration Keystore

This allows Cloud Integration to trust the server certificate presented by IBM MQ.

3. Trust the Cloud Integration Root Certificate in IBM MQ

For mutual SSL to work, IBM MQ must also trust the certificate used by Cloud Integration:

Obtain the root/intermediate certificate of the client certificate used by Cloud Integration
Import this certificate chain into the MQ Queue Manager’s KDB keystore
Restart the channel or refresh SSL configuration (REFRESH SECURITY TYPE(SSL)) if needed

This step ensures that MQ can validate the client certificate sent from Cloud Integration during the SSL handshake.

4. Upload the Client Certificate + Private Key to Cloud Integration

Cloud Integration must present a certificate to authenticate itself:

Create or obtain a client certificate (self-signed or CA-signed).
Combine the certificate and private key into a PKCS#12 (.p12) file.
Upload it to the Cloud Integration Keystore.
Upload the certificate part in IBM MQ.

You will reference this key pair in the IBM MQ adapter.

5. Configure the IBM MQ Adapter for Certificate-Based Authentication

Within the IBM MQ adapter:

Set Authentication Type = Client Certificate
Select the correct Key Pair Alias (the uploaded .p12 file)
Ensure the alias name matches the certificate expected by the MQ server

6. Validate Channel Authentication (CHLAUTH) Rules

IBM MQ channel authentication rules should:

Allow connections from the certificate’s DN (Distinguished Name)
Map the DN to the correct MQ user (if required)

Incorrect CHLAUTH rules are one of the most common causes of Two-Way SSL connection failures.

Common Connection Errors and How to Resolve them

When configuring connectivity between SAP Cloud Integration and an IBM MQ on-premise server, SSL or channel-level issues may cause the connection to fail. One of the most frequently encountered errors is mentioned below:

org.apache.camel.CamelException: Error message: An error occurred while starting or stopping JMS Connection.
Reason: JMSCMQ0001: IBM MQ call failed with compcode '2' ('MQCC_FAILED')
reason '2397' ('MQRC_JSSE_ERROR')

This error typically indicates an issue at the SSL/TLS layer during the MQ connection handshake. Below are the most common root causes and how to troubleshoot them.

1. Possible Reasons for MQRC 2397 – JSSE Error

1. Keystore / Truststore Misconfiguration

This occurs when:

Cloud Integration does not trust the MQ server certificate
MQ server does not trust Cloud Integration’s client certificate (in Two-Way SSL)
Wrong certificate file (or wrong alias) is used
Certificate chain is incomplete

2. CipherSpec Mismatch

The CipherSpec configured in the IBM MQ channel must match exactly with the CipherSpec configured in the IBM MQ adapter in Cloud Integration. A mismatch will cause SSL handshake failure.

2. Validation Checklist

Before attempting connection again, verify the following:

1. IBM MQ Adapter Version

Ensure that the adapter version is 1.4.1 or above in both design and runtime.
This version or later is required for on-prem SSL connectivity.

2. TCP Connectivity in Cloud Connector

A TCP connection must be configured in SAP Cloud Connector, and the MQ server must be reachable from it.
If Cloud Connector cannot reach MQ, SSL negotiation will never start.

3. Correct Certificate Uploads

Verify that the correct certificates are uploaded based on the SSL model:

One-Way SSL

Cloud Integration must trust the MQ Queue Manager certificate

Two-Way SSL

MQ Queue Manager must also trust the Cloud Integration client certificate
Cloud Integration must upload the client certificate + private key (.p12)

Ensure that the certificate aliases are correctly referenced in the MQ adapter.

4. CipherSpec Alignment

Confirm that the same CipherSpec is configured in:

The MQ Channel → SSL properties
The IBM MQ adapter → SSL settings

CipherSpecs must match exactly (e.g., TLS_RSA_WITH_AES_256_CBC_SHA256). It is worth noting that IBM MQ and Java (SAP CI) often use different naming conventions for the same Cipher.

For more information about CipherSpecs, see https://www.ibm.com/docs/en/ibm-mq/9.3.x?topic=java-tls-cipherspecs-ciphersuites-in-mq-classes

TIP: In order to troubleshoot the issue, please check the error logs on the IBM MQ server. The server logs provide much deeper insights and often reveal the exact root cause of the SSL or connection failure.

Checking IBM MQ Error Logs

When diagnosing SSL/TLS or channel-level connection issues, the IBM MQ server logs provide the most reliable insight into what went wrong. These logs often reveal precise errors such as certificate validation failures, CipherSpec mismatches, expired certificates, CHLAUTH rejections, or handshake-level SSL alerts.

Below are the primary MQ logs and how to access them.

1. Queue Manager Error Logs (AMQERR01.LOG)

Every Queue Manager maintains a set of rotating error log files. These are the most important logs for SSL troubleshooting.

Location (Linux/Unix):

/var/mqm/qmgrs//errors/AMQERR01.LOG
/var/mqm/qmgrs//errors/AMQERR02.LOG
/var/mqm/qmgrs//errors/AMQERR03.LOG

Location (Windows):

C:\ProgramData\IBM\MQ\qmgrs\<QMGR_NAME>\errors\AMQERR01.LOG

What you will find there:

SSL handshake failure details
Certificate DN mismatch
Unsupported or mismatched CipherSpec
Channel authentication (CHLAUTH) errors
Missing or untrusted certificates
Key repository (KDB) issues

Look for messages like:

AMQ9637: Channel is lacking a certificate.
AMQ9620: Internal error on SSL handshake.
AMQ9645: SSL connection closed due to a protocol error.

These messages directly point to what needs fixing.

2. MQ System Error Logs

MQ also maintains system-level logs that may show additional information:

Location (Linux/Unix):

/var/mqm/errors/AMQERR01.LOG

These logs can contain:

Global SSL warnings
CHLAUTH or authorization errors
System-level key repository failures

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

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

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

The SAP BTP Integration Suite AI Roadmap (2026)

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

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

Int4 Suite: SAP Integration Suite Test Agents are available today

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

1. Natural Language Test Creation

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

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

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

2. Automated Test Case Generation from Historical Data

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

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

Bridging the Gap: Why Agentic Testing Matters Now

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

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

JMS Mastery Series Part 1 - The Async Awakening

2026-02-06T10:32:09.582000+01:00

The Async Awakening: Why Synchronous Integration is Holding You Back

Or: How I Learned to Stop Worrying and Love Asynchronous Processing (Part 1 of 3)

Introduction

If you asked me a few years ago whether most integrations should be asynchronous, I would have said: "It depends - many scenarios require synchronous processing."

Today, after many production integrations and troubleshooting sessions, my answer is more opinionated: Most point-to-point integrations default to synchronous unnecessarily.

The real operational challenges in SAP Cloud Integration (CPI/CI) don't come from implementation errors like bad mappings or misconfigured adapters - those are straightforward to diagnose and fix. They come from architectural decisions: interfaces that block on every timeout, messages that vanish when processing fails, and systems so tightly coupled that one component's downtime brings down the entire chain.

This three-part series explains:

Part 1 (this article): Why synchronous is overused and async is underutilized
Part 2: Why JMS queues are essential for reliable async processing
Part 3: How to implement this in production with confidence

Important context: This series focuses on point-to-point integrations with transformation and orchestration needs - scenarios where CI provides value beyond simple routing. For S/4HANA business events and pub-sub patterns, Event Brokers (like Event Mesh/AEM) are often the right choice. Both patterns coexist in modern SAP landscapes.

Key Takeaways

SAP CPI / CI behaves synchronously by default for HTTP-based integrations
True decoupling must be designed explicitly.
Asynchronous ≠ Guaranteed Delivery
Non-blocking sender adapters alone do not make an interface reliable.
JMS is the main answer for reliable asynchronous processing in CI
Without persistence, retries, and DLQ, messages can be lost from automated recovery paths.
EO and EOIO are design patterns, not free platform features
They require idempotency, ordering discipline, and end-to-end design.

The Synchronous Trap: When Defensive Design Hurts

Walk into any SAP integration landscape and you'll find the same pattern: most point-to-point integrations are synchronous by default.

Why? Not because business requires it, but because it feels safer:

"Let's wait for confirmation so we know it worked"
"The user should see the result immediately"
"Async is more complex, let's keep it simple"
"That's how we've always done it"

These sound reasonable in isolation. But they create hidden fragility, even when only a single synchronous call is involved:

Availability coupling: The caller is unavailable as long as the receiver is unavailable
Performance coupling: The receiver's latency directly becomes the caller's latency
Blocked capacity: Threads, connections, and work processes are held while waiting
Poor scalability: Traffic spikes amplify blocking and quickly overwhelm synchronous paths

In synchronous chains, these effects compound.

Even with API-first principles - reusable services, proper APIM layers, well-tested microservices - we often build synchronous interactions that trade apparent simplicity for hidden operational risk, without applying resilience patterns to absorb delay, failure, or burst load.

The real question isn't "Should this be async?" but rather: "What specifically requires the caller to wait for completion?"

Answer honestly, and you'll find synchronous requirements are narrower than your default patterns suggest.

Common Async Candidates

These integration patterns rarely need synchronous processing:

Master data synchronization: CRM customer updates don't need to wait for S/4HANA confirmation
Document archival: Invoice posting shouldn't block on DMS storage completion
Notifications and emails: Order creation shouldn't fail if email service is down
Batch processing: High-volume operations benefit from queuing and parallel processing
External system updates: Downstream systems can receive updates asynchronously

Pattern recognition: If the user doesn't need the result to proceed with their next action, it's probably an async candidate.

When Synchronous IS the Right Choice

Not everything should be asynchronous. Synchronous is correct when:

Immediate validation required: Credit limit check before order submission
Transactional integrity: Operations that must succeed or fail together atomically
User expects immediate result: Price calculation, inventory availability check
Fast, stable operations: Reference data lookups from highly available systems

⚠️These scenarios are narrower than our habits suggest. Many integrations default to sync out of caution, not requirement.

The Hidden Costs

Simple to understand ≠ simple to operate reliably at scale.

What works smoothly in development often becomes problematic in production:

Aspect	Synchronous Costs	Asynchronous Costs
User Impact	User-facing failures, slow performance, downtime	Delayed feedback, eventual consistency
Operational	Cascading failures, availability coupling	Queue monitoring, message tracking
Development	Faster initially, harder to scale later	Slower initially, easier to scale later
Debugging	Simpler traces, immediate errors	Distributed traces, correlation needed
Resilience	Manual recovery, lost messages	Automatic retry, guaranteed delivery

For point-to-point integrations where users don't need immediate completion, async costs are typically more manageable than sync costs at scale.

⚠️Async without ops discipline and organisational maturity can be worse than sync (read part 2 & 3 to get more details). This series assumes production-grade operations, not ad-hoc integration development. Async-first is not a technical preference - it's an organizational maturity decision.

A Practical Decision Framework

Instead of defaulting to sync, use this framework:

Question 1: Can the user/system proceed without waiting?

YES → Strong async candidate → Go to Q2
NO → Likely sync → Validate with Q3

Question 2: Is this high-volume OR could backend be slow/unavailable?

YES → Async strongly recommended (resilience + scalability)
NO → Async still beneficial for decoupling, but lower urgency

Question 3: What specific part of the result does the caller actually need?

Just acknowledgment ("we got it") → Async
Business validation only → Consider hybrid (validate sync, process async)
Complete result with details → Likely sync

A Note on Advanced Hybrid Patterns

Modern high-scale platforms (Amazon, Shopify, Uber) use sophisticated hybrid patterns that combine synchronous and asynchronous processing:

Synchronous: Critical validations (inventory, pricing, payment authorization)
Asynchronous: Backend processing (ERP order creation, warehouse notification, analytics)

This gives users instant feedback on what matters (order accepted, payment confirmed) while backend processing happens reliably in background.

However, implementing these patterns requires significant infrastructure:

Local staging/tracking databases
Dual numbering schemes (platform ID vs. SAP document number)
Order lifecycle management
Reconciliation processes
Status synchronization workflows

These patterns are powerful but complex. For this introduction, we focus on clear-cut async scenarios that don't require hybrid complexity.

⚠️Hybrid patterns deserve their own detailed discussion. The key learning here is that "synchronous vs. asynchronous" isn't always binary - you can decompose processes to identify which parts truly need to be synchronous.

Architect's Note: Even Synchronous Can Be Loosely Coupled

An interesting nuance: even synchronous communication can achieve significant decoupling when routed through middleware layers rather than direct point-to-point calls.

When sender systems connect to receivers through CI, API Management, or SAP Open Connectors, these intermediary layers provide important benefits:

Message structure mapping, format conversion: Most visible role of middleware
Protocol translation: Sender doesn't know receiver's protocol
Version management: Changes to receiver API don't break sender
Rate limiting: Protection from burst traffic
Security layers: Authentication/authorization centralized
Routing flexibility: Redirect to different endpoints without sender changes

This provides looser coupling than direct integration, even in synchronous mode.

Synchronous Patterns with some Async Benefits

With some adapters we can achieve higher decoupling:

CI HTTP Adapter with Retry:

✓ Automatic retry on receiver failures (HTTP errors configurable, up to 3 attempts)
⚠ Very limited compared to JMS possibilities (for details check part 2 and 3)

CI SuccessFactors OData V2 adapter with Retry:

✓ Automatic retry on receiver failures (5 retries, 3 min intervals)
⚠ Fixed settings (only HTTP 429, 502, 504 errors)

Bottom line: Middleware-mediated synchronous is better than direct synchronous. Patterns like HTTP adapter retry can achieve some Async decoupling. But for point-to-point integrations where users don't need immediate response, full async with JMS provides the most mature operational model with guaranteed delivery, sophisticated retry, and production-grade monitoring.

Conclusion: Rethinking the Default

The goal of this article isn't to convince you that "everything should be async." That would be as dogmatic as "everything should be sync."

The goal is to challenge the unexamined default toward synchronous patterns.

Key takeaways:

Many integrations are synchronous out of habit, not requirement
Scenarios like master data sync, archival, and notifications should almost never be synchronous
Synchronous is correct when user must wait for specific result to proceed
Ask: "What specifically requires the caller to wait?" - the answer is often "nothing"
Async has costs (monitoring, correlation, complexity) that are often more manageable at scale
Choose based on business requirements and operational model, not convenience

Decoupling isn't just a technical choice; it's a customer experience strategy and a business continuity decision.

But simply switching to async SOAP or other non-blocking adapters isn't enough to guarantee delivery. As we'll discover in Part 2, there's an uncomfortable truth many integration consultants overlook...

Coming up in Part 2: The JMS Revolution

We've identified why synchronous defaults hold us back and which scenarios clearly benefit from async. But here's the critical gap: Asynchronous ≠ Guaranteed Delivery.

In Part 2, we'll discover why non-blocking adapters alone aren't enough. I'll show you why JMS is the game-changer that transforms SAP CI from a web service mediator into a reliable message broker, and how Quality of Service levels (EO, EOIO) actually work in production.

JMS Mastery Series Part 2 - The JMS Revolution

2026-02-06T10:57:33.324000+01:00

The JMS Revolution: Achieving Guaranteed Delivery in SAP Integration Suite

Confessions of a JMS Advocate (Part 2 of 3)

Recap from Part 1: We challenged the synchronous default and discovered that most integration scenarios don't actually require the sender to wait for complete processing. We identified the hidden costs of "simple" synchronous patterns and established that true business requirements for sync communication are narrower than our habits suggest. Now we'll explore the technical solution - but with a critical caveat.

Why Asynchronous Alone is Not Enough

Suppose we convince stakeholders that the sender doesn't need to wait 8 seconds for all operations to complete. A quick technical acknowledgment of receipt is sufficient. The rest happens in the background, with asynchronous feedback on subsequent steps.

We're ready to build our first truly asynchronous iFlow.

Understanding CI's Default Behavior

CI works in synchronous mode by default when using common web service sender adapters - the pattern used in most modern integrations, unless explicitly designed otherwise:

HTTP adapter: Sender waits until all steps complete (End Message, End Error, or End Escalation event)
OData adapter: Synchronous by nature (RESTful protocol)
SOAP adapter: in most situations synchronous

...but we have asynchronous option:

SOAP adapter can be configured also for fully async operation:

SOAP 1.x with Message Exchange Pattern = One-way - WS Standard

We run a proof of concept with async SOAP. Success! The sender receives an immediate HTTP 202 Accepted response. No blocking while our integration logic executes. We can see it in the trace (probably using CPI Helper).

Victory, right?

The Critical Gap: What Happens When Things Go Wrong?

Not so fast. We've achieved non-blocking behavior, but we haven't achieved middleware-managed guaranteed delivery..

Here's what we're still missing:

Scenario: Your async SOAP integration receives a message, sends immediate acknowledgment, then encounters an error during processing:
- validation failure in step 5 of 7,
- runtime error in groovy script,
- network timeout due to receiver system down,
- API response with error,
- tenant restart or worker node crash during message processing

What happens?

✗ Message is NOT persisted in any recoverable queue
✗ No automatic retry mechanism
✗ Message is effectively LOST from automatic processing perspective
✗ Recovery requires manual intervention (if possible, download initial payload from DataStore, MPL attachment or Persist Step, and resubmit)

You've made the sender's life easier (no blocking), but you haven't made the integration reliable.

This is the uncomfortable truth many integration consultants forget: Asynchronous ≠ Guaranteed Delivery

⚠️Actually, there is also one more variant for the SOAP One-Way Message Exchange Pattern, which is the "Robust" processing type. This provides a very interesting kind of behavior which is described in the last section of this blog.

The Holy Grail of Integration: Guaranteed Delivery

What's missing is a persistence layer that saves the message from the sender. If something goes wrong, we don't need to bother the sender - we handle it ourselves. We're mature enough to take responsibility once we accept a message. Fire and forget.

⚠️Guaranteed delivery served by middleware means: once CI accepts responsibility, delivery will be retried automatically until success or explicit DLQ handling - without sender involvement

Unfortunately, SOAP has no built-in message persistence.

Even Idoc (over HTTP with SOAP envelope), which many assume is "reliable," doesn't have built-in persistence in CI (as opposed to PI).

Only two adapters have persistence built into their configuration:

XI - ABAP proxy, used with SAP PI and also available in CI (great for lift-and-shift migrations)
AS2 - Common EDI protocol

If you're not using XI or AS2, you need another way to persist messages.

Enter the star of our show: JMS (Java Message Service) - The Missing Piece

Why JMS Is the Game-Changer

JMS provides what async SOAP or IDOC cannot: a durable queue that guarantees your message will be delivered, even if the receiver is temporarily unavailable, even if your tenant restarts, even if processing fails the first three times.

The game-changer: JMS works with ANY sender adapter (if async behaviour expected).
You are not limited to SOAP or IDOC. You can utilize obviously our favourite HTTP adapter (again - if it is not handled in RESTful way - not expecting synchronous response).

You can also add JMS queue after any polling adapter like SFTP or Mail.

For all polling adapters, message stays at source in case of error and retried in next poll, but still JMS is very useful in specific scenarios like Granular retry after split (e.g File → split → every record send in separate message to receiver via JMS queue).

Bottomline: Sender adapter + JMS receiver adapter = Async with guaranteed delivery

JMS Is CI's Internal Queueing Engine

JMS can persist messages and guarantee delivery with At Least Once (ALO) semantics. This single adapter transforms CI into a message broker-like engine capable of reliable, resilient, scalable message delivery with high data quality.

However:

JMS messages cannot cross tenant boundaries
JMS adapter does not support connectivity to any other, customer-provided message brokers via JMS protocol (name here most popular: IBM MQ, Apache ActiveMQ, RabbitMQ). If you need to connect with external message broker use corresponding available adapters in CI like: IBM MQ (also with JMS Variant). Most will work with AMQP adapter.

JMS Leverages SAP Event Mesh

JMS adapter in CI uses SAP Event Mesh as the underlying messaging infrastructure. While the interfaces are not event-driven, they adopt event-architecture characteristic - Guaranteed message delivery through:

Resilience via retry patterns: If something breaks, it automatically retries and eventually delivers the message to the receiver
Message queueing: Buffer messages during spikes/bursts when sender and receiver operate at different paces

Important Caveat on "Guaranteed Delivery"

Even with guaranteed delivery configured, certain scenarios can prevent message delivery (or result in what could be termed "guaranteed non-delivery"):

Permanent data errors (fail fast, no retry):

Non-existent product in order line item
Completely wrong message format or structure
Schema validation failures

Temporary/connectivity errors (retry appropriate):

After several retries, if the receiver remains unavailable (extended maintenance windows or unexpected downtime), messages (if well designed) end up in the Dead Letter Queue (DLQ).

In this situation messages may not be delivered if:

TTL (Time To Live) expires and the message becomes stale. In such cases, it may be preferable not to deliver the outdated message, or implement logic to refresh the data if reprocessing occurs after an extended period.
DLQ messages are not reprocessed: This occurs due to the absence of an automatic retry mechanism combined with missed manual intervention.

Clarifying Responsibility Layers

An important distinction: JMS doesn't replace sender-side retry logic - it complements it.

Layer 1 - Transmission (Sender → CI):
Senders can implement retry for network failures and CI unavailability. If the sender doesn't receive HTTP 202 acknowledgment, it retries sending. This is the sender's responsibility and works the same whether CI uses JMS or not.

Layer 2 - Processing (CI → Receiver):
After the sender receives HTTP 202, it stops retrying. Now the message is CI's responsibility. Without JMS persistence, if processing fails (mapping error, receiver down, timeout), the message is lost from CI’s perspective. Sender will not retry after receiving HTTP 202 and CI has no persistent copy.

With JMS, the workflow becomes:

Sender sends message
CI persists to JMS queue
CI returns HTTP 202 (sender is done)
CI processes from queue and calls receiver
If processing fails: JMS automatically retries without sender involvement
If retries exhausted: Message moves to DLQ

This creates true fire-and-forget for senders while ensuring guaranteed delivery by middleware. The sender's responsibility ends at getting acknowledgment; CI's responsibility continues until successful receiver delivery.

⚠️Without JMS, there's a dangerous gap where the sender thinks delivery succeeded (got 202) but the message was never delivered (processing failed). This gap is what JMS eliminates.

If you are working with SAP S/4HANA or ECC, SOAP with SAP RM (Reliable Messaging) is a powerful option for reliable asynchronous communication. It provides:

True non-blocking asynchronous processing
Sender-side and receiver-side at-least-once delivery with built-in persistence in ABAP runtime
Protocol-level duplicate detection
Message sequencing (EOIO – Exactly Once In Order within queue sequences)

When combined with JMS for downstream processing, SOAP SAP RM enables a robust end-to-end integration pattern.

The Real Superpower: Quality of Service Levels

Guaranteed delivery is excellent, but we can go further.

Exactly Once (EO) Processing

Sometimes we cannot tolerate duplicate messages at receivers (sending the same order twice is unacceptable). Deduplication can be handled by the sender, middleware, or receiver.

When middleware needs to handle it, use Idempotent Process Call Step with a unique business key.

JMS + Idempotent Process Call Step achieves QoS = Exactly Once (EO) processing *

Your interface is now both resilient with guaranteed delivery and idempotent. *

⚠️*Warning: If guaranteeing zero duplicates is a critical requirement, middleware-based idempotency may not be sufficient in edge cases involving timeouts and acknowledgment failures.

SAP Help states: "There might still be problems if the call runs into a timeout or the target application doesn't acknowledge the call. In this case, it isn't clear if the message is successfully processed by the application and duplicates can't be completely ruled out."
Define Idempotent Process Call

Mitigation strategies:

Receiver-side idempotency: The most reliable approach. The receiver must implement its own duplicate detection using unique business keys.
Extended timeout configuration: Increase timeout values to reduce the likelihood of premature timeout during processing.
Acknowledge before processing: In some patterns, the receiver can acknowledge receipt immediately, then process asynchronously with its own retry logic. However, this shifts the reliability burden to the receiver.
Accept "at least once" semantics: If business logic is naturally idempotent (e.g., "set customer status to Active" vs. "increment counter"), duplicates may be acceptable.

Bottom line: True "exactly once" delivery is impossible in distributed systems without receiver cooperation. Middleware can reduce duplicates significantly, but cannot eliminate them entirely in failure scenarios. Design your receiver systems to handle potential duplicates gracefully.

Exactly Once In Order (EOIO) Processing

Sometimes, additionally message sequence must be preserved (common in financial transactions or warehouse operations) - strict FIFO (First In, First Out) behavior.

This is achievable using the JMS sender adapter's Exclusive access type (introduced in 2025). With this setting, only one tenant node processes messages from the queue sequentially. If any message fails, all subsequent messages wait in the queue for resolution.

⚠️Warning: This requirement is operationally demanding. You need quick, solid resolution of failed messages to prevent blocking the entire queue. If the first message in an EOIO queue fails, the other 999 messages behind it are stuck until the retry does its work or a human intervenes. This is the biggest "hidden cost" of EOIO. My strong advice: Avoid EOIO unless absolutely required
SAP Community: Ensuring Exactly Once In Order Quality of Service

We've now jumped from EO to EOIO (Exactly Once In Order). Your interface is serialized as well.

⚠️Critical consideration: JMS with Exclusive mode alone isn't sufficient for truly ordered delivery. The sender system and receiver system must also ensure order. It requires end-to-end design because failures can occur anywhere. Only when all components preserve order you can claim QoS = EOIO.

⚠️Critical limitation: The standard SAPJMSRetries header - mandatory for retry handling - is unavailable for Exclusive access type. This is a critical limitation requiring workarounds like persisting retry counts in a DataStore per Message ID. SAP dev team: this gap needs to be fixed.

For high-volume scenarios requiring ordered processing, consider Partitioned Queues in SAP Advanced Event Mesh (AEM). Unlike standard Exclusive Queues, which limit processing to a single consumer and create a performance bottleneck, Partitioned Queues allow for parallel processing while still guaranteeing order within each partition. Scalable ordered processing only in AEM !

Note: XI and SOAP (SAP RM) adapters ensure EOIO end-to-end for ECC and S/4HANA.

XI adapter: Watch out for the XI adapter - it cannot use built-in JMS temporary persistence and requires a separate JMS step with Exclusive access type. In XI sender adapter set "Handled by Integration Flow" delivery assurance setting.

For the Pipeline Concept, the generic iFlow for inbound XI processing doesn't support EOIO yet.
SAP Integration Hub: Pipeline XI Processing

Additional JMS Capabilities

JMS offers several very powerful features:

Scalability

By defining multiple Concurrent Processes in the JMS sender adapter, you can significantly increase throughput. The actual parallel processing power is a product of your environment's scale:

Total Parallelism = Number of Worker Nodes × Concurrent Processes.

This allows you to process high-volume backlogs much faster or design specific "priority queues" to ensure business-critical messages aren't stuck behind bulk data loads.

⚠️Watch out for Resource Limits: Each concurrent process consumes a JMS connection (consumer). Increasing this number too aggressively can exhaust your tenant’s available JMS resource quota, potentially preventing other iFlows from connecting to the messaging infrastructure. Always balance your need for speed with the shared limits of your subaccount

Transactional Behavior

All JMS operations can participate in transactions inside Iflow - commit all or none (rollback).

Two common use cases:

Scenario 1: Start with JMS sender adapter and include JMS receiver adapter in the iFlow (fired from SEND steps). With transaction enabled, if an error occurs after a Send step, the entire transaction rolls back (JMS call is rollbacked).

Scenario 2: (without a JMS sender adapter) Delivering messages after Splitting/Multicasting via JMS receiver adapters (multiple JMS calls). Set JMS transaction on the iFlow. If any JMS call fails, all others roll back.

Pro-tip: message is visible in queue only after processing is finished.

For the JMS sender adapter (or XI / AS2 using JMS as temporary storage) - no transaction handler is required.

For the JMS receiver adapter (or XI / AS2 using JMS as temporary storage) - no transaction handler is required if the adapter is not used in a sequential multicast or in a split scenario

General guideline: To minimize resource consumption, configure transactions to be as short as possible. You can enforce it by moving related tasks into a subprocess so that the transaction can be limited to the subprocess and the main process can be kept nontransactional.

Flexibility

Create queue names dynamically, passing them via headers or properties. This applies to JMS receiver adapters (JMS sender adapter queue name must still be provided statically as it is created at Iflow deployment). This enables creation of highly generic JMS consumers driven by the runtime logic.

Operations in queue monitoring

Extensive monitoring UI options: move messages between queues, delete entire queues or specific messages, manually retry queues or individual messages, download messages for analysis.

RECENT UPDATE: Better filtering has arrived! Beyond Standard Message and Correlation IDs, you can now filter by:

Standard Headers: Sender, Receiver, Application Message ID, Application Message Type
JMS Message ID
Status

Why it matters: You no longer need to rely on DataStore just to get flexible "Entry ID" style searching. Finding specific messages is now faster and more intuitive.

The Curious Case of SOAP One-Way Robust

Earlier we mentioned that the SOAP adapter offers an asynchronous option using the "One-Way - WS Standard" Message Exchange Pattern. However, there is a closely related variant that deserves special attention due to the confusion it frequently causes: SOAP 1.x One-Way Robust.

This processing type introduces a subtle but important distinction between guaranteed delivery and decoupling - two concepts that are often (incorrectly) treated as the same thing.

The Paradox: “Asynchronous” That Blocks

When SOAP 1.x is configured with Message Exchange Pattern = One-Way and Processing Type = Robust, the runtime behavior looks like this:

✓ The sender waits until the entire iFlow completes
✓ The HTTP connection remains open until the End Message event
✓ HTTP 202 is returned only after successful processing
✓ Any processing error is returned immediately as a SOAP fault

Wait - isn’t this synchronous behavior?

From a runtime and performance perspective: yes. The sender is blocked exactly as it would be in a synchronous interface.

However, according to SOAP/WSDL semantics, this pattern is still classified as “asynchronous” because:

No business response payload is defined or returned
The interface follows the SOAP In-Only message exchange pattern
The HTTP 202 response is a technical acknowledgment, not a business result

What “Robust” Actually Adds

The key difference between One-Way - WS Standard and One-Way - Robust is error visibility.

Robust processing guarantees that the sender is explicitly informed whether the message was accepted or rejected. This allows the sender to react immediately and - if implemented - retry failed messages.

Characteristic	One-Way - WS Standard	One-Way - Robust
Sender blocking	No – immediate response	Yes – waits for full iFlow
Error visibility	None	Immediate SOAP fault
Retry capability	No	Yes, implemented by sender
Guaranteed delivery	No	Yes, if sender persists and retries messages
Decoupling	Yes	No

Guaranteed Delivery - But Not Decoupled

This is the most important takeaway:

SOAP One-Way Robust can provide guaranteed delivery - but only by shifting responsibility to the sender.

If the sender:

persists outgoing messages
detects SOAP faults or timeouts
retries failed deliveries

then robust one-way processing enables at-least-once delivery semantics.

What it does not provide is decoupling:

The sender remains blocked until CPI finishes processing
Sender throughput is directly tied to CPI performance
Availability of CPI impacts sender availability

⚠️Important distinction: One-Way Robust improves reliability, not scalability or decoupling. It guarantees delivery by protocol semantics and sender retries, not by durable middleware boundaries.

When Is One-Way Robust a Valid Choice?

One-Way Robust is appropriate when:

The sender must immediately know whether processing failed
No business response should ever be returned
The sender is capable of persisting and retrying messages
Runtime coupling is acceptable
Legacy SOAP contracts mandate one-way robust semantics

Why JMS Is Still Essential

If you need both:

Guaranteed delivery and
True asynchronous decoupling

then SOAP One-Way Robust alone is insufficient.

JMS introduces a durable acceptance boundary inside CPI, transferring reliability and retry responsibility from the sender to the integration platform. This enables non-blocking behavior, back-pressure handling, and operational replay - capabilities that robust one-way processing does not provide.

⚠️Best practice: Combine One-Way Robust with an early JMS handoff. Robust handling protects the inbound interface, while JMS provides true asynchronous decoupling and platform-managed reliability.

Coming up in Part 3: JMS in Production

We've covered the "what" and "why" of JMS. Now comes the practical reality. Part 3 delivers battle-tested best practices, real production considerations, and the architectural decision framework you need to choose between JMS and Event Broker patterns.

JMS Mastery Series Part 3 - JMS in Production

2026-02-06T10:57:49.669000+01:00

JMS in Production: Best Practices, Limitations, and When to Use Event Broker

Confessions of a JMS Advocate (Part 3 of 3)

Recap from Part 1 & Part 2: We challenged the synchronous default (Part 1) and discovered that JMS transforms non-blocking behavior into true guaranteed delivery through persistence, retries, and Quality of Service levels (Part 2). Now we address the practical realities: limitations, best practices, and when Event Broker is the better choice.

Considerations and Limitations

Is JMS perfect for all use cases? Of course, not.

Queue Limits

SAP Help: JMS Resource Limits and Optimizing Their Usage

Default tenant limit: 30 JMS queues
Easily increased to 100 (self-service)
Above 100 via SAP ticket (with valid justification)

Is this a serious limitation? If you're enthusiastic about asynchronous interfaces like me, possibly. However:

You can share the same queue across multiple interfaces (group them by Sender, Receiver, business domain etc)
For PI migrations, leverage the Pipeline concept to optimize queue management by reusing a minimal set of queues across all asynchronous integrations. Using Integrated Async Processing results in 2 active queues and 2 corresponding DLQs - keeping the total at a bare minimum of 4 queues.

Other limits are generous and should not require workarounds:

Default 90-day, maximum 180-day retention period. However note that JMS is transient storage, do not treat it like a database!
9.3 GB storage size (in addition to the 32 GB tenant database), expandable to 30 GB

⚠️While the theoretical maximum message size is very high (1280 MB - 256 × 5 MB chunks), pushing large attachments (e.g. 20MB+ PDFs) into JMS is an architectural anti-pattern. If a high-volume interface with large payloads hits a downstream bottleneck over a weekend, it can exhaust the entire storage pool (and memory during serialization). The result is catastrophic: every other JMS-based interface on your tenant will fail.

The Expert's Recipe: Implement the Claim Check pattern (store large files in an Object Store/DMS and pass only the reference via JMS) and/or enforce strict payload size validation at the sender adapter to reject oversized requests. Implement monitoring alerts in CALM to check storage capacity.

Dead Letter Queue Handling

I highly recommend using DataStore for DLQ management - you have complete control over automatic retry frequency via Timer steps (beyond manual retry).

However, for standard retry scenarios, JMS is superior and much more performant than DataStore (which is a database, not designed for high-throughput messaging).

API Operations

No OData APIs for operations on JMS queue / queue messages (unlike for DataStore / DataStore entries). This prevents operating on JMS from external applications (beside access from Iflow)

Best Practices and Recommendations

Common Misconception: Exception Subprocess Pattern

I frequently see developers using JMS receiver adapter in the Exception subprocess to retry failed messages. Is this correct?
For error handling purpose only: Definitely Yes.
For asynchronous processing: No - the sender still waits for complete iFlow execution

Keep Initial iFlow Simple

Keep the "decoupling" sender iFlow (sender adapter + JMS receiver adapter) as simple as possible.

While you can add steps to save headers, properties, or log messages for audit purposes, be cautious: each additional step increases the risk of failure before the message is safely queued - which would then require exception handling or sender retries (if possible). This essentially defeats the purpose of decoupling. Also remember that your sender must wait through every step before receiving acknowledgment.

Queue Architecture for Complex Flows

How many queues for a long, complex flow?

For resource-intensive logic, split your iFlow with multiple JMS queues. Then each iFlow does ONE thing well and:

Reuse is natural
Failures are isolated
Monitoring is crystal clear (which stage failed?)
Reprocessing is surgical (restart from the failed stage)

But balance it: Consider the JMS queue limit constraint.

Retry Strategy

Retry only temporary errors, not permanent ones (requires careful assessment):

Temporary: Connectivity issues, receiver unavailability, timeouts
Permanent: Invalid data, validation failures, business rule violations, authentication/authorization issues

No universal rule exists for categorizing errors - it depends on receiver implementation.

My personal opinion: In most cases better to retry unnecessarily than fail and ask the sender to reprocess. Initially configure data errors you're certain should not retry (e.g. HTTP 400, 403, 405 or internal errors within iFlow coming from mapping, groovy script logic etc). Everything else triggers retry. After gaining operational experience, add other permanent errors to externalized parameters for filtering.

Remark: Not all data errors are permanent. Some can be resolved on the receiver side, such as:

Missing master data that may be created shortly
Configuration issues that can be corrected

Unlike errors caused by invalid sender data, these are suitable for retry. Determine whether your integration scenario includes such recoverable errors and configure your retry strategy accordingly.

Retry configuration best practices

Retry only a few times (never indefinitely)
Use short breaks (few minutes) with exponential backoff

Temporary issues often resolve quickly. If not, move messages to DLQ (designed for longer pauses: hours or days) to handle extended receiver unavailability or data/configuration issues on Receiver side.

Leverage Adapter-Level Retries

Use retry capabilities of adapters (HTTP, SuccessFactors) in addition to JMS, never alone. Adapter features are limited and cannot replace JMS richness.

Think of it this way: When connectivity issues arise, let the adapter try first (HTTP: max 3 retries, no backoff configuration). If insufficient (more retries needed, undefined HTTP status), JMS catches it - messages always end up in queue or DLQ. You don't want to see Failed status too often or too quickly.

Event-Driven Architecture (EDA) vs. JMS

Using JMS, we've built fully decoupled, resilient interfaces with guaranteed delivery. So why would we need Event Broker at all?

Does EDA still provide benefits? Do we still need an Event Bus like Event Mesh or AEM?

Yes, but for different reasons than you might think.

⚠️And let's be clear: "event-driven sounds impressive in architecture reviews" is not one of them. Neither is "it'll look good on my CV". Event Broker earns its place through actual technical advantages.

When JMS Excels: Point-to-Point with CI Orchestration

For point-to-point and async request-reply where a sender communicates with a single receiver, JMS is the ideal choice when CI already provides necessary mediation and orchestration beyond the basic routing and queueing capabilities of an event broker.

When Event Broker Excels: Pub-Sub Patterns

For Pub-Sub broadcasting through topics (Publish-Subscribe pattern: one sender, potentially many receivers), an Event Broker is always the correct choice.

Yes, you can technically replicate pub-sub in CI. You can successfully create a Recipient List pattern using dynamic routing to many receivers based on varied content (payload, headers/properties, HTTP path/query parameters...). For this, use Partner Directory and XSLTs while maintaining decoupled flows with independent queues per every receiver. Advantages: Partner Directory does not require redeployment, directly configurable on target tenant (no transport), therefore very flexible ... and dangerous tool.

Generally the question becomes: Better to force one tool (CI) to handle everything (doing pub-sub gymnastics) or use specialized tools for specific use cases (CI for mediation/orchestration, Event Broker for pub-sub)? If this isn't obvious, check ISA-M.

EDA's decisive advantage: True decoupling through dynamic subscription. Receivers add themselves to topics without touching the middleware. This flexibility - not just guaranteed delivery - is what separates event-driven architectures from traditional message-oriented middleware.

The Gray Zone: Event Broker for Point-to-Point?

Even for point-to-point, Event Broker can be the better choice when:

Enterprise EDA strategy mandates routing all async through Event Broker for consistency
No CI mediation needed (pure routing, minimal transformation)
JMS limitations become constraining

⚠️But stop cargo-culting Event Broker. 'It might become pub-sub!' is not architecture - it's hedging your bets with someone else's budget. Yes, requirements change. Yes, some point-to-point flows become pub-sub. But when only 1 in 10 integrations actually needs that second subscriber, deploying Event Broker for all 10 is waste. Design for today's reality, refactor for tomorrow's actuality. YAGNI applies to infrastructure too.

Cost Considerations

For high-throughput interfaces, Event Brokers are more cost-effective, as they are charged by data volume (GB) rather than by egress like Integration Suite (charged per outbound messages).
Note: Messages sent out through JMS receiver adapter are not considered as outbound messages because JMS adapter is internal adapter (like ProcessDirect) which makes usage of JMS "free of charge"

SAP S/4HANA Integration

For utilizing standard S/4HANA events, Event Mesh with its CI AMQP adapter is the best match.

Advanced EDA Requirements

For sophisticated EDA needs Advanced Event Mesh (AEM) is the answer

Example use cases:

Event streaming with replay capabilities (Kafka-like)
Request-reply with Reply-To destination for long running processes
Non-exclusive access type with partitioned queues for order ensurance and scalability
Direct point to point - direct messaging without persistent endpoint for performance over reliability
Persistent topic endpoint - as an alternative to queue endpoint, example use case: JMS durable subscribers
Very demanding high-volume integrations

JMS: The King of CI Workflow Async Processing

Central thesis: JMS is the king of point-to-point async processing within CI workflows. This single adapter - available freely in all CI editions (except Basic) - converts synchronous flows into fully decoupled, reliable processing when CI provides necessary mediation and/or orchestration.

This single adapter brings CI close to PI/PO in decoupling capabilities. While PI provides these qualities through configuration, CI achieves them through BPMN freestyle design - a respected successor with modern look and feel.

Stop treating SAP CI only as a web service mediator and orchestrator. With its built-in JMS message broker, CI supports high-throughput, reliable, asynchronous messaging

But recognize its domain: JMS excels at async processing within CI's orchestration scope. For pub-sub patterns and enterprise-wide event distribution, Event Broker wears the crown.

Know which kingdom you're in:

Point-to-point with CI mediation/orchestration: JMS is king
Pub-sub and enterprise EDA: Event Broker is king
Both exist in healthy integration landscapes

Final Thoughts

Many colleagues argue that synchronous interfaces are superior because the sender quickly learns operation results - nothing remains on the middleware side, clean hands for us. This is true if our goal is to minimize responsibility and simplify our lives short-term.

When considering what's best for the project and customer overall:

For point-to-point integrations with CI orchestration: Incorporate "ASYNC-first" and "JMS-first" alongside "API-first."

For business events and pub-sub patterns: Embrace "EDA-first" with Event Broker from day one.

These aren't competing philosophies - they're complementary patterns for different integration scenarios. Master both. Use each where it excels.

Share your thoughts

What are your experiences with JMS and asynchronous processing? I'd love to hear your stories and challenges in the comments below.

If I missed something important or you do not agree - feel free to comment as well, happy to discuss 🙂

Setting Up Document Grounding with Cloud Integration Automation service: Making Joule context-aware

2026-02-09T08:07:07.162000+01:00

While Document Grounding has been used to make Joule context-aware with specific business data, the latest development is that integrating Document Grounding with Joule is now fully automated by Cloud Integration Automation service.

In this blog you will find how Cloud Integration Automation service completely automates the integration of Document Grounding with Joule and SharePoint as the data source, hence making Joule context aware.

For more information regarding Document Grounding refer the blogpost : Joule – Getting Started with Document Grounding

Setting up Document Grounding using Cloud Integration Automation service

To set up Document Grounding, you would need to configure many steps as explained in Blog, however, lets now discover how Cloud Integration Automation service can simplify the whole process.

Prerequisites:

Joule instance should be available in one of the SAP BTP subaccounts
You have prepared SharePoint as mentioned in this Blog step “6. Prepare SharePoint Integration “.

Note: You will use SharePoint details later in the Cloud Integration Automation service workflow

Step 1: Subscribe Cloud Integration Automation service via BTP service marketplace. More details can be found : What is Cloud Integration Automation Service? | SAP Help Portal.

Step 2: Once subscribed, launch Cloud Integration Automation service application and click on “Plan for Integration”

Image 1

Step 3: Search for “Document Grounding” scenario

Image 2

You can view scenario related details such as “Description”, “Scenario Entities”, “Scenario Tasks”.

Image 3

Step 4: Click on “Select Systems”.

Image 4

Step 5: Provide system details and “Generate Workflow”

Provide SAP BTP system details

Image 5

2. Click on Generate workflow ->Background Execution

Image 6

Note: In the above step, Cloud Integration Automation service will generate a fully automated workflow, and users just need to provide few information to complete the integration.

Click on Next step

Select SharePoint as the data source as highlighted in the below screen shot.

Image 8

Click on Next Step

Image 9

Note: In this step Cloud Integration Automation service will create Share point destination, hence you will use share point information such as Share Point client ID, Share Point Client Secrete, SharePoint Tenant ID, Site URL from the Share Point application that you are using as the data source. You can fetch SharePoint details by referring to the screen shots.

Client ID:

Image 10

Client Secrete:

Image 11

Tenant ID:

Image 12

SharePoint URL:

Image 13

Once you provide all the task parameters click on Next step

Image 14

Click on Confirm

Image 15

Image 16

Step 7: Navigate to Scenario Monitoring to check the workflow status.

Image 17

Here you can observe that all the tasks that are needed for this integration are listed and implemented sequentially.

Task list:

Task Name	Task Status
Assign Entitlement for Document Grounding Service	Automated
Create Grounding Service Instance with a Service Key	Automated
Create Cloud Identity Service Instance with a Service Key	Automated
Create Destination Service Instance with a Service Key	Automated
Create Destination in BTP for Existing SharePoint	Automated
Create Destination in BTP for Existing SAP Document Management Service	Automated
Create Pipeline for SharePoint	Automated
Create Pipeline for SAP Document Management Service	Automated

Upon implementation of all the tasks, Document Grounding is fully integrated with Joule and is context aware with SharePoint as the data source.

Step 8: Go to BTP subaccount to check the following:

1. Instances (groundigcli, grounding Des, identityService) are created along with their service keys

2. Document Grounding destination (docu-grounding-dest-sh) is created

Image 19

Step 9: Launch Joule and ask Joule questions. You can now get context-aware answers and with links to its document sources.

Image 20

Useful Links

What is Cloud Integration Automation Service? | SAP Help Portal

Joule provisioning with SAP S/4HANA Cloud Private using Cloud Integration Automation service

Announcement: Register to the new CEI project for SAP Integration Suite in 2026

2026-02-09T08:33:34.010000+01:00

Like in the previous years, we will run a Global Customer Engagement Initiative (CEI) for SAP Integration Suite also in 2026.

Last year, we had 180+ registered customers and partners from over 20 countries worldwide. We ran multiple feedback sessions covering various capabilities and strategic investment topics of SAP Integration Suite such as "SAP Process Orchestration move" (ABAP proxy generation, mass migration, migration assessment, migration agent, etc.), AI & gen AI in the context of SAP Integration Suite in general and for B2B in particular, monitoring and operations, new adapters and adapter enhancements, reusable APIs and governance of API key access, event driven architecture, etc.

In 2026, we will continue collaborating with our customers and partners to gather feedback on product improvements, enhancements and new developments to validate the planned enhancements at an early stage, and ensuring that what we build will meet your business needs.

This will include open discussion about our current product backlog from the roadmap explorer as well as addressing pain points and topics that we collected in last year's CEI project such as more on Edge Integration Cell, AI, SAP PI/PO to SAP Integration Suite migration, Event Driven Architecture, ISA-M, best practices and guidelines, developer experience, etc.

If you like to join the upcoming SAP Integration Suite influence project for providing feedback and shaping the SAP Integration Suite product, please register here (link leads to the customer influence page).

Registration is open from 9th of February 2026 until 13th of March 2026.

Once, the registration closes, we will invite you for an initial call where we go through the scope and the prerequisites of the feedback project. This will be around end of March/ begin of April so that we are able to start the project latest in April this year.

We will run monthly feedback sessions through the end of the year and hold a closing call to summarize our learnings, review the feedback collected, and discuss next steps.

Register today to ensure you do not miss this opportunity to influence and contribute to shaping SAP Integration Suite to meet your business needs.

We look forward to your active participation and valuable feedback.

How to Get Started with Pipeline for Cloud Integration

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

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

Motivation

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

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

Use Cases

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

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

Architecture

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

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

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

Initial Setup of the Pipeline

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

Point-to-point scenario (sample 5)

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

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

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

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

Copy standard packages from SAP Business Accelerator Hub

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

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

Deploy generic Integration Flows

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

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

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

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

Create and deploy scenario-specific Integration Flows

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

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

PIPSamplesScenario5_Step01
PIPSamplesScenario5_Step07_RCV1_IF1

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

PIP_Mocked_Receiver

Setup Partner Directory entries

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

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

Alternative partner:

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

String parameters:

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

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

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

Run your first scenario

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

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

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

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

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

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

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

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

Copy standard packages from SAP Business Accelerator Hub

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

Deploy generic Integration Flows

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

Create and deploy scenario-specific Integration Flows

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

PIPSamplesScenario1_Step01
PIPSamplesScenario1_Step03
PIPSamplesScenario1_Step07_RCV2_IF1
mm_item_to_order

Setup Partner Directory entries

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

Alternative partner:

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

String parameters:

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

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

Binary parameters:

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

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

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

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

Run your second scenario

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

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

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

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

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

Accelerator Tool

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

Link Collection

SAP Help

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

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

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

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

SAP Community (recent blogs after package split)

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

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

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

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

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

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

SAP Business Accelerator Hub

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

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

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

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

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

Package for generic XI or IDoc entry point (optional)

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

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

Data Store Extension

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

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

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

Accelerator Tool

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

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

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

History – older SAP Community blog posts before package split

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

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

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

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

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

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

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

Support for custom header properties
Support for dynamic configuration parameters

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

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

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

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

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

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

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

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

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

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

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

Powering Event-Driven Integrations Using Amazon EventBridge Adapter in SAP Cloud Integration

2026-02-11T08:36:48.204000+01:00

INTRODUCTION:

Event-driven architecture is becoming increasingly popular now-a-days due to its efficient real-time data processing, high scalability and better de-coupling of business systems. Hence, it is becoming new favorite for enterprise integration developers.
SAP Integration Suite supports this modern pattern through various adapters, one of which is the Amazon EventBridge receiver adapter.

The Amazon EventBridge receiver adapter allows seamless event publishing from SAP to Amazon EventBridge, enabling SAP applications to interact directly with AWS services such as Lambda, SQS, and SNS without the need for complex custom API developments or integrations.

In this blog, we will explore how to configure and use the Amazon EventBridge receiver adapter to replicate Business Partner data from SAP S/4HANA to Amazon EventBridge in near real time.

What Is Amazon EventBridge?

Amazon EventBridge is a serverless event bus service by AWS that helps connect applications using events.
It allows you to publish events (like new Business Partner creation, Sales Order creation etc) from SAP and trigger AWS services (like Lambda, Step Functions, SNS, or SQS) for further processing.

Using the Amazon EventBridge Adapter in SAP Cloud Integration, you can directly post these events from SAP to an EventBridge event bus without custom coding or API gateway setups.

Business Scenario Overview

In this scenario, an organization maintains Business Partner master data within SAP S/4HANA. Whenever a Business Partner is created or updated, this information needs to be replicated to AWS for further processing such as validation, analytics, or integration with non-SAP applications.

The goal is to enable a real-time, event-driven data flow from SAP to AWS without building or maintaining point-to-point interfaces.

High-level process flow:

A Business Partner is created or updated in SAP S/4HANA.
The change triggers an outbound message, which is sent to SAP Integration Suite.
SAP Cloud Integration processes and transforms the message.
The Amazon EventBridge receiver adapter publishes the event to the configured event bus in Amazon EventBridge.
The event bus routes the event to the respective targets such as AWS Lambda, SQS, or other consumers.

This approach ensures loose coupling, real-time updates, and scalability across systems.

Integration Flow Design in SAP Cloud Integration

Step 1: Sender Configuration

Sender Adapter: Sender Adapter: SOA Manager to SAP Integration Suite

To enable sender connectivity from SAP ERP to SAP Integration Suite, SOA manager is used to configure the outbound web service communication. This involves creating and configuring a logical port for the relevant consumer proxy in the ERP system.

The logical port is assigned with the HTTPS endpoint of the SAP CI iFlow, along with the required authentication mechanism (for example, basic authentication or client certificate-based authentication). SSL settings, certificates, and user credentials should be properly maintained to ensure secure communication.

For more information about SOA Manager configuration please visit this page.

Configuring SOA Manager | SAP Help Portal

You can also use any other type of sender configuration such as IDOC.

Step 2: Message Transformation

Use a message mapping, groovy script or simple XML to JSON converter to transform the SAP XML payload into the JSON structure as expected by Amazon EventBridge.

Step 3: Receiver Adapter Configuration

Receiver Adapter: Use a ‘request reply’ pallet function and connect it to a receiver using Amazon EventBridge receiver adapter. Follow the below steps to configure the adapter.
Adapter Configuration Details:

AWS Region: eu-west-1 (example)
Event Bus Name: Test_CPI_Content
Source: s4hana
Detail Type: BusinessPartnerEvent
Credential Name: Reference to AWS credentials (stored securely in SAP CI)
Event Detail: The JSON body prepared in step 2

For more information about Amazon EventBridge Receiver adapter configurations, please visit this link. Amazon EventBridge Receiver Adapter

Step 4: Testing
Once the iFlow is deployed, create or change a Business Partner in SAP S/4HANA. Once it is done, you will be able to see a message triggered from SAP S/4 HANA and coming into SAP CI iFlow. The iFlow will convert the XML data into JSON and sends it to Amazon EventBridge.
You will be able to see a corresponding message appear in the Amazon EventBridge Event Bus.
You can then route it to:

AWS Lambda to process or enrich data
Amazon SQS/SNS to notify other systems
Amazon Kinesis or Data Lake for analytics

End-to-end Process from SAP ERP to Amazon EventBridge

Below is the process in which a business partner is created in S4 HANA and sent to SAP Integration Suite. SAP Integration Suite transforms the incoming message into JSON and sends it to Amazon SQS(Simple Queue Service) using Amazon Eventbridge receiver adapter.

New Business Partner in SAP S4Hana

Business Partner ‘12345’ gets created in SAP S4 Hana

Received message in SAP CI

SAP Integration Suite received the message from S4Hana. IFlow converts incoming XML payload into JSON and sent to AWS using Amazon Eventbridge receiver adapter.

XML Payload received from Sap S/4 Hana:

<?xml version='1.0' encoding='UTF-8'?><root><type>sap.s4.beb.businesspartner.v1.BusinessPartner_Changed_v1</type>
<datacontenttype>application/json</datacontenttype><specversion>1.0</specversion><source>...</source><id>c051226f-59a8-1edd-bef6-7efcb8aaffc</id><time>2024-01-11T12:56:29Z</time><data><BusinessPartner>12345</BusinessPartner></data></root>

JSON payload sent to Amazon EventBridge after transformation:

{

  "root": {

    "type": "sap.s4.beb.businesspartner.v1.BusinessPartner_Changed_v1",

    "datacontenttype": "application/json",

    "specversion": "1.0",

    "source": "...",

    "id": "c051226f-59a8-1edd-bef6-7efcb8aaffc",

    "time": "2024-01-11T12:56:29Z",

    "data": {

      "BusinessPartner": "12345"

    }

  }

}

Business Partner Details replicated in Amazon EventBridge

Amazon Event Bus details

Put event is recorded in Amazon Eventbridge.

Data sent into Amazon SQS

The above processing took less than 1 second to complete end-to-end. This ensures near real-time processing of data which makes further processing easier and faster.

Benefits of Using the Amazon EventBridge Adapter

Real-Time Integration: From SAP to Amazon EventBridge, the data will be transferred in near real time, which will make integrations much faster.
Event-Driven Architecture: Promotes usage of decoupled system interactions and better scalability.
Simplified Configuration: Eliminates the need for intermediate APIs or custom connectors. This ensures simplification of complex integrations.
Serverless and Cost-Effective: Uses AWS’s serverless infrastructure with pay-per-event pricing.
Time Saving: Takes very less time in configurations and implementation.

Best Practices

Use consistent naming conventions for event types and sources.
In case of failures, retry mechanisms should be implemented to avoid data loss.
Leverage SAP Cloud Integration monitoring to track message processing status.
Use AWS CloudWatch for monitoring and auditing event delivery.
Maintain version control of your integration artifacts to track changes and ensure reliability.
Use batching mechanism in case of large number of messages for smooth working.

Conclusion

The Amazon EventBridge receiver adapter extends the capabilities of SAP Integration Suite to support modern, event-driven integrations between SAP and AWS platforms.
By using this adapter, organizations can replicate business partner data, sales order data, purchase order data and other master or transactional data from SAP S/4HANA to AWS in real time which can be further used for processing or analytics. Also, Amazon EventBridge adapter can be used to send multiple events using advanced mode settings in the adapter. This functionality helps in complex event-driven architectures saving good amount of time.

This approach provides a scalable, secure, time saving and future-ready integration pattern that aligns with cloud-native architectures and digital transformation goals.

Hope you find this blog informative!

Thanks

Rupali

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

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

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

Body :

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

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

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

Step-by-Step Implementation

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

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

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

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

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

This blog post is part of the series Master Blog: SAP Process Orchestration to SAP Integration Suite Migration – Tool and Guidance exploring how to migrate various integration patterns from SAP Process Orchestration to SAP Integration Suite using the Migration Tool. In this blog, we will focus on the Content-Based Routing (CBR) Asynchronous pattern

Objective of this Blog

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

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

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

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

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

Standard Receiver Determinations

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

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

The following options are available:

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

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

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

For more details, see Defining Standard Receiver Determinations

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

NoReceiverBehavior

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

Possible values:

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

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

Migration Wizard:

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

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

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

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

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

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

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

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

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

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

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

Standard Approach

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

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

Inbound Integration Process:

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

Content Modifier – Receiver Conditions & Interface Conditions:

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

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

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

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

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

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

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

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

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

Receiver Determination:

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

Router and No-Receiver Behavior:

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

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

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

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

Outbound Integration Process:

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

Router:

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

Pipeline Approach

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

Key Highlights in the Migration Wizard:

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

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

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

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

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

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

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

Migration Tooling now supporting migration via the pipeline approach

Applying the pipeline concept for an integration scenario in general

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

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

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

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

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

Conclusion:

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

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

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

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

Automated Trace Enabler in SAP CPI

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

Introduction:

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

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

However, there are also projects where:

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

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

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

Prerequisites:

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

In your SAP BTP subaccount:

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

Integration Flow Overview:

Download Integration flow from the Git : link

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

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

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

1. Timer based Trace Enabler flow

This integration process runs automatically based on a configured scheduler.

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

Every 9 minutes
During working hours on week days

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

The list of interfaces is maintained as Externalized Parameters.

Example: iflow_1, iflow_2 (separated by comma)

2. HTTPS based Trace Enabler flow

This integration process exposes an HTTPS endpoint for manual triggering.

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

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

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

Conclusion:

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

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

Happy Integrating!

🤔 Is This the Right Way to Build Talent Intelligent Hub Integration with SAP Gene AI Hub-Extension

2026-02-15T18:36:04.178000+01:00

****Please check design at the bottom of this article (available for download)***

I've been sketching out an architecture for extending SAP SuccessFactors with AI-powered skills matching and requisition management. But before going down this path, I want to challenge my own assumptions. Is this the best approach, or am I overengineering?

THE PROPOSED ARCHITECTURE:

Here's what I'm considering:

🏗️ Multi-Cloud Foundation (SAP BTP)

- Cloud Foundry runtime for microservices

- HANA DB for data persistence

- Integration Suite for SuccessFactors connectivity

- Identity services for authentication

🤖AI & Analytics Layer

- SAP Generative AI Hub (GPT-4, Claude, Llama)

- Document intelligence and entity extraction

- Vector embeddings for semantic search

- Resume parsing and skills extraction

⚙️Microservices Architecture

- Requisition Analysis Service

- Skills Management Service

- Matching Service

- Custom build services for each capability

📊Advanced Data Layer

- Vector engine for embeddings

- Object store for documents

- HANA DB for structured data

- Build Process Automation for workflows

THE CRITICAL QUESTIONS I'M WRESTLING WITH:

1️⃣DO WE REALLY NEED MULTI-CLOUD COMPLEXITY?

The Good:

✅Flexibility to choose best-of-breed services

✅Avoid vendor lock-in

✅Leverage SAP BTP's enterprise capabilities

The Concerns:

⚠️Operational complexity across multiple clouds

⚠️Higher costs for integration and management

⚠️Steeper learning curve for teams

⚠️More points of failure

Alternative: Could we start with pure SuccessFactors extensions and only move to BTP if we hit limitations?

2️⃣IS MICROSERVICES THE RIGHT PATTERN HERE?

The Good:

✅Independent scaling of services

✅Team autonomy and faster deployment

✅Technology flexibility per service

The Concerns:

⚠️Distributed system complexity

⚠️Network latency between services

⚠️Harder to debug and monitor

⚠️Overkill for a small team or MVP?

Alternative: What if we started with a modular monolith and decomposed later based on actual bottlenecks?

3️⃣ARE WE READY FOR GENERATIVE AI IN PRODUCTION HR?

The Good:

✅Intelligent resume parsing and skills extraction

✅Natural language requisition analysis

✅Semantic matching beyond keyword search

✅Document generation and summarization

The Concerns:

⚠️Hallucination risks in HR decisions

⚠️Bias and fairness implications

⚠️Explainability requirements for hiring

⚠️Cost per API call at scale

⚠️Data privacy and compliance (GDPR, EEOC)

Alternative: Should we start with rule-based matching and traditional NLP, then layer in GenAI for non-critical features?

4️⃣DO WE NEED VECTOR EMBEDDINGS AND SEMANTIC SEARCH?

The Good:

✅Find similar skills even with different terminology

✅Semantic matching beyond exact keywords

✅Better candidate-requisition alignment

The Concerns:

⚠️Added infrastructure complexity (vector DB)

⚠️Embedding model maintenance and updates

⚠️Explainability: "Why was this candidate matched?"

⚠️Cost of generating and storing embeddings

Alternative: Could traditional search with synonyms and taxonomies get us 80% of the value with 20% of the complexity?

5️⃣IS THE INTEGRATION LAYER OVER-ARCHITECTED?

The Good:

✅Clean separation of concerns

✅Reusable integration patterns

✅API management and event mesh

The Concerns:

⚠️Do we need event mesh for this use case?

⚠️Is Build Process Automation necessary or could we use simpler workflows?

⚠️Are we adding layers that slow down development?

Alternative: Direct SuccessFactors OData APIs with simple retry logic?

WHAT MIGHT BE A SIMPLER STARTING POINT?

Phase 1: Validate the Value

- Build a SuccessFactors extension app (UI5)

- Use SuccessFactors APIs directly

- Simple keyword-based matching

- Manual review and approval workflows

- Prove the business value first

Phase 2: Add Intelligence Gradually

- Introduce resume parsing (traditional NLP)

- Add skills taxonomy and synonyms

- Basic analytics dashboard

- Measure improvement over baseline

Phase 3: Scale What Works

- Only then consider microservices if we have clear scaling needs

- Add GenAI for specific high-value use cases

- Introduce vector search if keyword matching proves insufficient

- Expand to multi-cloud only if we need capabilities not in SuccessFactors

THE REAL QUESTIONS:

💭Am I solving for scale we don't have yet?

💭Am I choosing technology because it's interesting vs. because it's necessary?

💭What's the simplest thing that could possibly work?

💭How do we balance innovation with pragmatism?

💭What would a true MVP look like?

WHAT I'D LOVE YOUR INPUT ON:

🔹Have you built similar HR/talent extensions? What worked? What didn't?

🔹Where have you seen GenAI add real value in recruiting vs. just hype?

🔹When is microservices worth it vs. premature optimization?

🔹How do you balance "enterprise-grade" with "ship fast and learn"?

🔹What would you do differently?

I'm genuinely torn between building something robust and future-proof vs. starting simple and evolving based on real needs.

What's your take? Is this architecture the right approach, or should we start simpler and earn our way to complexity?

Drop your thoughts below - especially if you think I'm overcomplicating this! 👇

#EnterpriseArchitecture #SAPSuccessFactors #SAPBTP #TalentManagement #AIinHR #Microservices #CloudArchitecture #SoftwareEngineering #TechLeadership #ArchitecturalDecisions #BuildOrBuy #MVPFirst #OverengineeringDebate

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

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

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

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

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

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

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

These mechanisms work — but they come with growing challenges:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

The current transaction includes a placeholder: [PREDICT]

The request payload contains:

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

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

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

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

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

Response from our example scenario:

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

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

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

When AI in Iflows Brings Real Business Value

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

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

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

Integration: SAP SuccessFactors with SAP S/4HANA Public Cloud

2026-02-17T12:31:00.946000+01:00

Integration Architecture

The integration leverages SAP Master Data Integration (MDI) service running on SAP Business Technology Platform as the central hub for data replication between systems .

Key components include:

SAP Master Data Integration Service: Acts as the middleware for data transformation and routing
SAP Integration Suite: Provides cloud integration capabilities and pre-packaged integration content
Communication Scenarios: Enable secure data exchange between systems
Web Services and APIs: Support real-time and batch data synchronization

Integration Methods

SAP Delivered Integrations
- Full end-to-end integration processes for specific hybrid cloud scenarios
- Pre-configured best practices with guided configuration and onboarding
- Scope item JB1 for SuccessFactors Employee Central integration
Template-based Integrations
- Simplified integration templates primarily for standard scenarios
- Leverages SAP Integration Suite with pre-built integration flows
Customer Driven Integrations
- Custom integrations using SAP Integration Suite and APIs
- Supports specific business requirements beyond standard scenarios

Data Flow Scenarios

Scenario Direction Data Objects Frequency

Employee Master Data	SF → S/4HANA	Personnel data, organizational assignments	Real-time/Scheduled
Organizational Structure	SF → S/4HANA	Company codes, departments, positions	Real-time/Scheduled
Cost Center Data	S/4HANA → SF	Cost center master data	Scheduled
Payroll Results	SF → S/4HANA	Payroll posting documents	After payroll run
Availability Data	SF → S/4HANA	Employee availability information	Real-time

Configuration Steps

Pre-requisites
- SAP Business Technology Platform subscription
- Communication user setup in both systems
- Required authorizations and certificates
SuccessFactors Configuration
- Create communication users for MDI integration
- Configure OAuth connections for secure authentication
- Set up business scenarios for data replication
- Enable address mapping and field mappings
S/4HANA Public Cloud Configuration
- Activate communication scenarios (e.g., SAP_COM_0193 for Employee Central integration)
- Create communication systems and arrangements
- Configure destinations for data flow
- Set up Business Integration Builder for infotype mapping

Key Integration Points

Employee Master Data: Replicates personnel information, employment details, and personal data from Employee Central to S/4HANA for finance and reporting purposes
Organizational Structure: Synchronizes company codes, cost centers, departments, and positions to maintain consistent organizational hierarchy
Time Management: Integrates time data and availability information for workforce planning and scheduling
Payroll Data: Transfers payroll results from SuccessFactors Employee Central Payroll to General Ledger Accounting in S/4HANA

Technical Considerations

Authentication: OAuth 2.0 and certificate-based authentication for secure communication
Data Mapping: Field mappings defined in SAP Note 3078790 for New Business Partner Model
Error Handling: Data Replication Monitor in Employee Central provides status tracking and error resolution
Performance: Maximum 2000 line items per payroll posting document

Monitoring & Maintenance

Data Replication Monitor: Available in Employee Central for monitoring replication status and re-running failed jobs
Integration Monitoring: SAP Integration Suite provides comprehensive monitoring capabilities
Query Administration: S/4HANA maintains query administration tables for tracking integration requests
Application Logs: Detailed logging for troubleshooting and audit purposes

Best Practices

Fit-to-Standard Approach: Limit customizations to accelerate implementation and simplify ongoing maintenance
Master Data Governance: Establish clear data ownership with SuccessFactors as the leading system for employees
Security: Implement proper authentication mechanisms and follow SAP security guidelines
Testing: Thoroughly test integration scenarios in development environments before production deployment
Documentation: Maintain comprehensive documentation of field mappings and custom configurations

Unlocking Customer 360: Integrating SAP Sales and Service Cloud 2 with SAP Customer Data Platform

2026-02-17T14:18:51.187000+01:00

In today’s experience‑driven economy, businesses win by deeply understanding their customers, across every channel, touchpoint, and interaction. SAP Customer Data Platform (CDP) plays a central role in this strategy, enabling organizations to unify, enrich, and activate customer data at scale

With the growing adoption of SAP Sales Cloud Version 2 and SAP Service Cloud Version 2, SAP has delivered powerful, bidirectional integration capabilities that allow companies to seamlessly connect operational CRM interactions with real‑time customer profiles in SAP CDP. These integrations create a rich 360‑degree view of customers that fuels personalization, analytics, automation, and more.

This article breaks down what the integration offers, how it works, and why it matters.

🤝 Why Integrate SAP Sales Cloud & SAP Service Cloud V2 with SAP CDP?

The integration provides a unified, real‑time data environment where CRM interactions, activities, and master data feed directly into SAP CDP, enabling:

A consolidated customer profile from both sales and service operations
Enriched segmentation and activation powered by CRM activity data [
Bidirectional data flows to keep systems aligned and up to date
A foundation for personalized engagement across channels and applications

This creates an end‑to‑end data loop that enhances visibility, decision‑making, and automation across the enterprise.

📥 What Data Does SAP CDP Ingest from the Sales & Service Clouds?

SAP CDP collects data from both platforms through predefined event types and mapping schemas.

Inbound Data (Events → CDP)

SAP CDP ingests multiple categories of CRM activities, including:

Customer Profile updates (individual customers)
Organization and Relationship updates for account‑level intelligence
Service interactions:
- Chat
- Email
- Phone
- Cases
- Registered product activities
Sales interactions:
- Leads
- Quotes
- Opportunities
- Appointments

Each event type is mapped to SAP CDP schemas including Profile, Organization, Relationship, and Activities, providing consistent structuring across data sources.

🚀 Outbound Data (Actions ← CDP)

SAP CDP doesn’t only consume CRM data, it can also enrich and push data back.

The integration allows SAP CDP to send profile, organization, case, opportunity, appointment, and lead data back to SAP Sales Cloud or SAP Service Cloud Version 2.

SAP CDP then receives enriched responses, creating a closed feedback loop where both platforms stay synchronized.

⭐ Key Benefits of the Integration

1. A Unified Customer Profile

SAP CDP aggregates customer events and attributes from both Sales and Service Cloud Version 2, creating a complete, real‑time view of customer journeys.

2. Stronger Segmentation & Personalization

Interaction data (including calls, emails, cases, and opportunities) sharpens segmentation models, enabling more targeted and relevant engagement.

3. Improved Sales & Service Collaboration

Shared data across systems helps teams proactively identify meaningful signals such as churn risk or product issues.

4. Bidirectional Data Harmony

Action‑based enrichment ensures data synchronizes across clouds and remains consistent.

5. Strong Foundation for AI & Automation 🤖

Integrated customer intelligence enhances SAP’s CX AI capabilities (including Joule), enabling automation and predictive insights.

How Organizations Can Use This Integration

Customer Service

Identify high‑value or at‑risk customers before SLA breaches
Personalize case handling using unified interaction history
Enrich service tickets with profile‑level intelligence

Sales Enablement

Prioritize leads using CDP‑enhanced scoring
Improve sales plays with real‑time customer context
Track cross‑touchpoint interactions in one consolidated platform

Marketing Activation 📣

Trigger campaigns based on service or sales events
Build micro‑segments using real interaction data
Coordinate lifecycle journeys with behavior‑based triggers

Conclusion: Data‑Driven Experience Management Starts Here

The integration between SAP Sales Cloud & SAP Service Cloud Version 2 and SAP Customer Data Platform is a major accelerator for companies pursuing customer‑centric business models. By connecting real‑time CRM insights with enterprise‑wide profiles, SAP enables organizations to deliver smarter sales engagement, more efficient service operations, and more relevant customer experiences.

More Info

Suggested learning.sap.com resources and what to look for:

Official product documentation

SAP Sales Cloud and SAP Service Cloud Version 2 Integration Guide

SAP BTP XSUAA Security Configuration Comparison: Attribute-Based vs. Authority-Based Approaches

2026-02-18T03:27:30.148000+01:00

In SAP Business Technology Platform (BTP) Cloud Foundry applications, configuring XSUAA (Extended Services for User Account and Authentication) via the xs-security.json file is a critical step for secure authentication and authorization.

Sample Application used for this article - "Message Reprocessing Application". This scenario try to cover 2 roles - "ReprocessViewer" and "ReprocessAdministrator".

Two main approaches exist:

Configuration A: Explicit attribute-based – manual mapping and control
Configuration B: Authority-based – automatic acceptance of IDP attributes (recommended for most cases)

Understanding the differences helps you balance security, compliance, simplicity, and development speed.

Quick Comparison Table

Feature                          | Config A (Explicit Attributes)          | Config B (Authority-Based)
---------------------------------|-----------------------------------------|--------------------------------------------
attributes section               | ✅ Present (defines email, etc.)        | ❌ Not needed
attribute-references in roles    | ✅ Yes (links attributes to roles)      | ❌ Not present
authorities array                | ❌ Not used                              | ✅ "$ACCEPT_GRANTED_AUTHORITIES"
oauth2 grant-types               | ❌ Uses defaults                         | ✅ Explicit list (authorization_code + others)
oauth2 autoapprove               | ❌ Not set (shows consent screen)       | ✅ true (smooth internal login)

Key takeaway from the table

Configuration A: Explicit Attribute-Based Approach

Structure (xs-security.json excerpt):

JSON

{
  "xsappname": "my-app-reprocess-v2",
  "tenant-mode": "dedicated",
  "description": "Message Reprocessing Application - Security Configuration",
  "scopes": [
    {
      "name": "$XSAPPNAME.ReprocessViewer",
      "description": "View messages, content, and statistics (read-only access)"
    },
    {
      "name": "$XSAPPNAME.ReprocessAdministrator",
      "description": "Full administrative access including reprocess operations and CRUD"
    }
  ],
  "attributes": [
    {
      "name": "email",
      "description": "User email address",
      "valueType": "string"
    }
  ],
  "role-templates": [
    {
      "name": "ReprocessViewer",
      "description": "Read-Only Access - View messages and statistics",
      "scope-references": ["$XSAPPNAME.ReprocessViewer"],
      "attribute-references": ["email"]
    },
    {
      "name": "ReprocessAdministrator",
      "description": "Full Administrative Access - CRUD operations and reprocess actions",
      "scope-references": [
        "$XSAPPNAME.ReprocessAdministrator",
        "$XSAPPNAME.ReprocessViewer"
      ],
      "attribute-references": ["email"]
    }
  ],
  "role-collections": [
    {
      "name": "MessageReprocessViewersRC",
      "description": "Message Reprocess Viewers - Read-only access",
      "role-template-references": ["$XSAPPNAME.ReprocessViewer"]
    },
    {
      "name": "MessageReprocessAdministratorsRC",
      "description": "Message Reprocess Administrators - Full access",
      "role-template-references": ["$XSAPPNAME.ReprocessAdministrator"]
    }
  ],
  "oauth2-configuration": {
    "credential-types": ["binding-secret", "x509"],
    "redirect-uris": ["https://*.cfapps.example.com/**", "http://localhost:*/**"],
    "token-validity": 3600,
    "refresh-token-validity": 86400
  }
}

Advantages

Explicit control over exposed attributes
Fine-grained security and compliance
Enables attribute transformation and ABAC

Disadvantages

Higher maintenance
More complex configuration
Less flexible with IDP changes

When to use: Regulated industries (healthcare, finance, government), ABAC needs, multi-tenant SaaS, strict governance.

Configuration B: Authority-Based Approach (Recommended)

Structure (xs-security.json excerpt):

JSON

{
  "xsappname": "my-app-reprocess-v2",
  "tenant-mode": "dedicated",
  "description": "Message Reprocessing Application - Security Configuration",
  "scopes": [ /* same as above */ ],
  "role-templates": [ /* same as above, without attribute-references */ ],
  "role-collections": [ /* same as above */ ],
  "authorities": ["$ACCEPT_GRANTED_AUTHORITIES"],
  "oauth2-configuration": {
    "grant-types": ["authorization_code", "client_credentials", "refresh_token"],
    "credential-types": ["binding-secret", "x509"],
    "redirect-uris": ["https://*.cfapps.example.com/**", "http://localhost:*/**"],
    "token-validity": 3600,
    "refresh-token-validity": 86400,
    "autoapprove": true
  }
}

Advantages

Simplicity and minimal config
Automatic handling of standard IDP attributes
Lower maintenance, faster development
Seamless with SAP IAS, Azure AD, Okta

Disadvantages

Less granular control (all attributes passed)
Potential over-exposure

When to use (most cases): Standard enterprise apps, RBAC, rapid development, microservices, agile environments.

Deep Dive: Key Differences

Attributes & attribute-references — Explicit in A, automatic in B via $ACCEPT_GRANTED_AUTHORITIES
Authorities — Special directive in B accepts all granted attributes/scopes from trusted IDP
OAuth grant-types & autoapprove — Explicit in B for predictability and better UX (no consent screen for internal apps)

JWT Token Examples

Configuration A (Explicit):

JSON

{
  "user_name": "john.doe",
  "email": "john.doe@example.com",
  "scope": ["my-app-reprocess-v2.ReprocessViewer"],
  "xs.user.attributes": { "email": ["john.doe@example.com"] }
}

Configuration B (Automatic):

JSON

{
  "user_name": "john.doe",
  "email": "john.doe@example.com",
  "given_name": "John",
  "family_name": "Doe",
  "scope": ["my-app-reprocess-v2.ReprocessViewer"],
  "xs.user.attributes": { "email": ["john.doe@example.com"], "department": ["Engineering"], "cost_center": ["CC-1234"] }
}

Application Code Impact (Examples)

SAP CAP (Node.js) – Configuration B:

JavaScript

this.before('READ', 'Messages', async (req) => {
  const userEmail = req.user.attr.email;
  const department = req.user.attr.department;  // extra attributes available
  // ...
});

Spring Boot (Java) – Configuration B:

Java

String email = token.getAttributeFromClaimAsString("email");
String department = token.getAttributeFromClaimAsString("department");

Migration Guide & Troubleshooting

(Refer to the detailed steps in original content for From A → B and vice versa, plus common issues like missing attributes, invalid grant types, consent screens, token size.)

Security & Performance Best Practices

Principle of least privilege
Validate JWT properly (@sap/xssec)
Specific redirect URIs (avoid wildcards in prod)
Appropriate token lifetimes
Prefer X.509 in production
Monitor token size (switch to A if >4KB)

Recommendations by Use Case

Use CaseRecommendedRationaleInternal Enterprise AppConfiguration BSimplicity & standard integrationRegulated IndustryConfiguration AExplicit governance & audit trailRapid Prototype/MVPConfiguration BMinimal configAttribute-Based AuthorizationConfiguration ARequired for ABAC

Conclusion For most SAP BTP applications in 2025, go with Configuration B (Authority-Based) — it delivers simplicity, flexibility, and aligns with modern OAuth/OIDC patterns while reducing maintenance.

Only choose Configuration A when you need strict attribute control, custom transformations, or operate in highly regulated environments.

What approach are you using in your SAP BTP projects? Have you migrated between the two? Share your experiences or questions in the comments — happy to discuss architecture or troubleshooting!

#SAPBTP #XSUAA #CloudFoundry #SAPSecurity #Authorization #IdentityManagement #SAPDeveloper

Master Blog: B2B Integration with SAP Integration Suite

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

Introduction

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

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

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

B2B Integration Factory

B2B integration Factory’s services & integration packages

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

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

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

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

B2B Integration Factory Q4/2024 Release highlights - SAP Community

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

SAP Migration Factory for Integration Suite – FAQ - SAP Community

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

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

B2B integration scenarios

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

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

B2B Scenario Sender EDI to IDOC - SAP Community

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

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

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

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

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

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

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

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

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

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

Integration Advisor

Blog posts focusing only on IA

Beginner's Guide to Integration Advisor - SAP Community

Base-/Overlay Mappings for Integration Advisor - SAP Community

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Integration Advisor – Odette Message Standard - SAP Community

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

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

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

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

Integration Advisor – Support of xCBL Messages - SAP Community

Integration Advisor – Tradacoms Message Standard - SAP Community

Integration Advisor – Use Custom XSLT as MAG - SAP Community

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

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

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

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

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

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

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

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

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

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

Using EDI Envelopes in Integration Advisor - SAP Community

Trading Partner Management

Blog posts focusing only on TPM

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

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

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

Custom Search Attributes in SAP B2B - SAP Community

Integrating Cloud Application Lifecyle Management ... - SAP Community

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

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

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

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

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

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

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

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

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

Using Trading Partner Management with AI - SAP Community

Summary

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

SAP PO to SAP Integration Suite Migration without migration tool (Basic Edition)

2026-02-19T10:55:36.395000+01:00

Introduction

Migrating from SAP PO to the SAP Integration Suite — especially when working with the Basic Edition — can be challenging due to the lack of official migration tool. However, with a structured and creative approach, it’s entirely feasible.

Here’s a quick summary of what I will cover in this blog.

Connection between Subaccount and SAP PO system
Objects extraction process
Designing approach of the integration flows
Configuration in SAP system for integrations
Challenges and key points to be consider and prechecks for this migration
Configuration for File based (NFS) scenario.

Even without the full migration toolkit, with the right mindset and methodology, you can still carry out a successful and efficient PO-to-Integration Suite migration.

Project Background

Here I will be share the details from two of the migration projects where the landscape was like

Source System	SAP PO 7.5 Single Stack
Target System	SAP Integration Suite (Basic Edition)
Mapping Types	ABAP Proxy, IDocs
Adapters Used	XI (3.0), HTTP, File (FTP), IDoc, REST, JDBC

System setup - Cloud Connector (Connection between Subaccount and SAP PO system )

Here we need to add SAP PO system as well along with the SAP system under the connected subaccount. This step is require to extract the objects required for the interface.

Steps: Select the correct subaccount in the SAP Cloud Connector and add one new system where the backend type is SAP Process Integration (from the dropdown) and prepare one connection (HTTP as protocol).

Subaccount --> Cloud to On prim connection --> add new system --> SAP Process Integration --> HTTP --> {SAP PO hostname/Ip and Port} --> {Virtual Host name and port} --> uncheck Principle propagation --> Finish --> Connection Check

Under Resources --> add resource --> URL Path (/) --> Access Policy (All Sub paths)

Cloud Connector - System Configuration

In case of connection failure:

This can be happen and in maximum case this occur when your SAP PO system is not on the same network where Cloud Connector in configured. In such cases one SR need to be raise to SAP to whitelist the IP's or the SAP PO system. --> Idle Approach

In some cases during landscape migration customer create tunnels between there on-prim application and the Rise in that case tunnel between SAP PO server and Rise need to be create. --> rare scenario

Objects extraction process

Before extraction process we need to add the SAP PO system in Cloud Integration as well (First step was to add PO system in Subaccount - done in above step).

Navigate to Integration Suite --> Settings (Integrations) --> System --> add System (SAP Process Orchestration Systems)

Provide the details like System name, Version, server address and credentials. Just note here the server address will be the virtual hostname and port defined in the cloud connector.

Once this is complete, inside the iflow objects can be imported from sap po to cloud integration. To do this open the integration flow (fresh interface i.e. with just message start and end) and go to Integration Flow tab (bottom) then References and required objects like message mapping, data/message types. service interface, wsdl etc.

Just by selecting the message mapping all the dependent objects like dt,mt,wsdl will be imported. In case the original interface in SAP PO is synchronous then only Operation mapping can be select and depended objects will be imported automatically, only when interface is Asynchronous then we need to select the message mapping.

Integration Suite - Objects import

After this import maximum work will be completed and only connection part are the one which need to be done.

With this the iflow designing for the migration interface can be completed but there are some additional Iflows need to be created for seamless processing. I will say those as common routing iflow which will be used to received the transaction from SAP to Integration Suite for Proxy & IDoc based scenario.

We required these Iflow because whenever any transaction generate from SAP it will flow from one destination only to the SAP PO to replicate the same we need to change that destination from SAP PO to Integration suite and for that we need the endpoints. To achieve this we create 3 common IFlows. 1 IFlow to receive all the IDocs from SAP, 2nd IFlow to receive all the ASynchronous XI message and 3rd IFlow to receive all the Synchronous XI message.

Key points while importing Messgae Mapping/Operation Mapping in Iflow design.

In case of Async interface only messgae mapping import can be done.
In case of Sync interface Operation mapping can be import and it will automatically import all depended objects (Message Mappings for both request and response) along with the wsdls (messgae structure).

Once everything is imported just placing them in at the right place is the manual thing.

Common routing flow configuration

Create 3 flow with the configuration mentioned below.

Iflow 1/2: Receive Sync/Async interface from SAP

Sync/Async Iflow Configuration

Here for the sender adapter XI exposed the endpoint eg "/proxy/async" and "/proxy/sync" for async and sync interfaces from SAP and to route these call to the correct interface mentioned "/${header.SapInterfaceName}" in the Address in process direct adapter.

When a call is generated from SAP, in the API call some header are created where one of the header is "SapInterfaceName" is the one which we can use as this contain the name of the service interface which is implemented at ABAP side. With the same actual SI name we can expose the actual interface which has all the message mapping transfomation etc.

Iflow 3: Receiver IDoc from SAP

Here based on the messgae type routing those to perticuler interface can be done and can put mulitple conditions based on the payload data.

SAP Configuration for Sync/Async call

There are some configurations in SXMB_ADM which need to do for both Sync and ASync interface.

Step 1 - Create 3 destinations in SM59 with Type G "HTTP Connection to External Server"

1st destination for SAP to Integration suite Async Interface (SAP_TO_IS_PROXY_ASYNC)
2nd destination for SAP to Integration suite Sync Interface (SAP_TO_IS_PROXY_SYNC)
3rd destination for SAP to Integration suite IDoc send (SAP_TO_IS_IDOC)

Step 2 - Decide which type of interface need the defualt configurations. I recommended chosse which has less number of interface. In my case ASync interfaces are less in number so all default configuration will be for Async.

Step 3 - configure Sender/Reciver ID.

SXMB_MONI --> UNDER CONFIGURATION (CONFIGURE SENDER/RECEIVER ID)

Here create a entry with below data. similar way entries we have to create for all the interface which need additional configuration.

Step 4 part 1 - setting up the IDoc destination

go to WE21 - Create XML port (SAP_TO_IS) and maintain the destination created in step 1 "SAP_TO_IS_IDOC" and assign this XML HTTP port to requried partner profile in WE20.

Content type : application/x-sap.idoc

HTTP version: 1.0

SOAP protocol : checked

Step 4 part 2 - setting up the

Under SXMB_ADM --> Integration Engine Configuration

At initial page the destiantion maintained should be the default destination. In my case that destination belongs to the ASync interface.

Role of Business System : LOC Application Ssystem

Associated Integration Server : dest://SAP_TO_IS_PROXY_ASYNC

Then go to configuration and maintain the rules for Sync interfaces (Sender/Receiver ID) which are created under Step 3.

This is all what we need to do to migrate SAP PO running interfaces to SAP CPI without using Migrtion tool in case you have the basic edition.

For information : I did this migration 1 year back so might be there are some steps which i might used in old ways but this is working absoulty fine till now. I appriate the feedback if community has some.

Thanks

Aman Sharma

Service	SAP Process Integration Runtime
Plan	API
Roles	TraceConfigurationEdit, TraceConfigurationRead