SAP Community - SAP Integration Strategy

IDOCs are Still Safe for SAP S/4HANA - SAP Clean Core Extensibility Level B

2025-09-23T11:35:28.820000+02:00

Intro

IDOCs are safe to use in SAP S/4HANA programs—and if anyone tells you otherwise, point them to this blog to learn more. IDOCs are now officially part of SAP Clean Core Extensibility! That’s the big news from updated SAP Guidelines (OSS Note 3578329 – Frameworks, Technologies and Development Patterns in Context of Clean Core Extensibility).

This ends the myth that IDOCs are “dead.” They are not. They’re preserved as SAP Clean Core Level B Extensibility, which means your existing IDOC investments are safe. Let’s explore four perspectives—integration, monitoring and error handling, performance, and testing—to see where APIs are recommended first, and where IDOCs still bring value.

1. Integration Perspective

SAP’s recommendation for new development in S/4HANA is clear: use modern integration technologies such as APIs, events, or OData services. They are the strategic direction and best fit for greenfield or transformation projects. That said, not all projects require reinvention. If your business processes remain largely the same as in ECC, and the goal is to reduce cost and risk, IDOCs can still be used. They are not prohibited, and as long as an IDOC type is not listed as deprecated in the SAP Simplification List, it is safe:
https://help.sap.com/docs/btc/lean-sdt-best-practices/sap-s-4hana-simplification-analysis?locale=en-US Because IDOCs are now Clean Core Level B Extensibility, continuing with them is fully supported in SAP S/4HANA on-premise and SAP S/4HANA Private Cloud. They offer a pragmatic path to de-risk projects and leverage existing know-how.

2. Monitoring and Error Handling Perspective

For new interfaces, SAP recommends using AIF (Application Interface Framework) to handle monitoring, error management, and business validations. AIF provides a powerful, unified monitoring layer, and in many cases it comes license-free (for standard SAP interfaces delivered in namespaces like /SDSLS or /LEEDI, or in CFIN, Document Compliance, or S/4HANA Public Cloud). Where APIs are deployed, AIF bridges the gap between technical payloads and business-friendly monitoring.

IDOCs still have a strong card here: their monitoring capabilities are mature, well-known, and integrated into standard SAP transactions. Functional users know how to work with WE02, BD87, and standard reprocessing flows. This means less training, less overhead, and faster resolution in day-to-day operations.

In other words: AIF is recommended, but IDOCs deliver proven stability in monitoring and error handling.

3. Performance Perspective

APIs are the recommended way forward, but they come with a structural tradeoff: their payloads are larger and typically handle transactions individually. This makes them more verbose and sometimes less efficient for high-volume use cases. IDOCs, in contrast, have long supported bundling, batching, and parallel processing at scale. They’ve been the backbone of high-volume EDI and SAP-to-SAP integrations for decades, and their ability to handle millions of documents daily is field-proven. So while APIs are the strategic choice for new designs, IDOCs remain a safe performance option for scenarios with heavy data throughput.

4. Testing Perspective

Testing support for APIs exists (for example, with SXI_MONITOR), but it is more technical and often requires additional training for functional teams. For IDOCs, simulation and reprocessing are familiar to almost every SAP functional consultant. Tools like WE19 and BD87 make IDOC testing and troubleshooting accessible, reducing dependency on specialist skills.

For projects that need to standardize and automate testing across both APIs and IDOCs, solutions like Int4 Suite provide simulation and test automation capabilities that unify all SAP integration scenarios. You can learn more on how to test and simulate SAP integrations in this SAP learning Course: Avoid SAP S/4HANA Project Delays with Third-Party Systems Service Virtualization So while APIs are recommended for new developments, IDOCs still offer ease of testing and proven tooling, especially in brownfield projects.

Conclusion

The strategic path forward in SAP S/4HANA is built on APIs, events, and frameworks like AIF. That’s the official recommendation, and it should guide greenfield and transformation projects. But IDOCs are far from obsolete. They are officially part of Clean Core extensibility, safe to use in both on-premise and private cloud, and carry unique advantages in performance, monitoring, and ease of testing. That makes them not only supported, but still a pragmatic and safe choice when the situation calls for stability, cost reduction, and risk mitigation.

Int4 Suite Agents Empowers Functional Consultants To Test Integrated SAP S/4HANA Business Processes

2025-10-03T11:41:59.491000+02:00

Introduction

Integrated business processes are the bloodstream of SAP systems. Every Sales Order, Purchase Order, Delivery, and Invoice has to flow smoothly, not just within SAP, but across EDI partners (customer, vendors, 3PL partners) banks, warehouses, tax portals.

Here’s the paradox: SAP S/4HANA projects have plenty of sophisticated automation tools, but they rarely help functional consultants in their manual tests. Instead, those tools get pushed into the narrow niche of automation testers. Functional consultants treat them like mythical dragons, complicated, dangerous, and likely to drag them away from their real work into procedural swamps.

The result? Slow testing cycles, dependency on integration specialists, and endless waiting for external partners to provide messages or confirmations.

Changing the story with simulation agents

The better path is not to force functional consultants into scripting or automation frameworks, but to give them simulation agents that mimic the system environment.

Instead of saying: “learn a test framework and run automated scripts,” we can say: “here are agents that simulate your missing EDI partner, your unavailable 3rd party/legacy system and you can test with them right now.”

This changes the game:

No competition with automation teams.
No learning curve with complex frameworks and procedural delays.
Consultants get something they instantly understand: realistic test conditions on demand, using actual historical production data.

How Int4 Suite Agents Work

With Int4 Suite, simulation agents provide a simple interface: the consultant performs the transaction in SAP, the agent feeds in authentic historical test data, and then automatically checks whether the newly generated EDI or non-EDI message matches what was sent in production.

Below are examples of key agents and how they fit into typical integrated OTC and P2P processes

Figure - meet the Int4 Suite Agents

EDI Partner Agent (based on historical data)

Role: Replays authentic production EDI messages from trading partners (ORDERS, DESADV, INVOIC).

How it works:

Consultant performs the transaction in SAP (e.g., creates delivery, sends invoice).
Agent provides historical test data from previously exchanged documents.
Agent automatically compares the newly generated EDI message with the production one for a similar case.

OTC examples:

Consultant in the OTC team replays historical ORDERS from the largest customer and verifies whether, after pricing condition changes, the system still calculates correctly.
Consultant tests goods receipt with historical DESADV data; agent compares the new EDI message against the production one.
Consultant issues a sales invoice (INVOIC) and agent validates it against the original production invoice, checking VAT rules.

Figure - Select Historical EDI messages from Production system which need to be rerun on Test System

P2P examples:

Consultant creates a purchase order; agent provides a historical ORDRSP where the supplier delivered partially, then compares the new outbound message.
Agent simulates a supplier INVOIC and verifies whether workflows behave the same after configuration changes.

Figure - manipulate the historical/production landscape EDI message data before sending that to the test environment

Unavailable System Agent (Non-SAP)

Role: Simulates external systems (banks, customs, WMS/TMS, tax portals) with historical production communications.

How it works:

Consultant runs the business process in SAP.
Agent injects historical test data from the external system.
Agent compares the new outbound message with the original production one.

OTC examples:

Consultant tests e-invoicing using a historically rejected invoice; agent checks whether the new output matches the original and if the new rules handle it.
Consultant tests shipment confirmations with historical WMS responses.

P2P examples:

Consultant tests bank payments; agent supplies historical payment files and checks the new output structure.
Consultant tests tax submissions; agent provides historical records and compares new vs. old messages.

Figure - Display the historical EDI data used on production landscape before rerunning that on the test environment

Historical Data Agent

Role: The production message librarian, replays large volumes or special cases directly from production.

How it works:

Consultant triggers transactions in SAP (bulk orders, invoices, returns).
Agent provides the historical payloads.
Agent verifies test messages against the production equivalents.

OTC examples:

Consultant replays a “Black Friday” scenario with 10,000 ORDERS; agent validates each new EDI message against its production twin.
Consultant tests credit memo flows from historical complaint cases.

Figure – run many historical messages on the test environment for bulk testing purposes

P2P examples:

Consultant tests bulk supplier invoices; agent validates the outputs against production.
Consultant tests blocked spare-parts orders with historical references.

Integration Consultant Agent

Role: A technical assistant that retrieves and compares messages from middleware layers (PI/PO, CPI).

How it works:

Consultant executes the business process in SAP.
Agent fetches the historical integration payload.
Agent highlights differences between new and historical messages.

OTC examples:

Consultant creates a sales order; agent compares the IDoc/XML message with the historical SAP Integration Suite payload.
Agent highlights mapping differences at field level after configuration changes.

Figure – fetch an EDI payload produced by the integration platform (SAP Integration Suite, etc.) from a newly created business document and compare with the historical one from the production landscape without asking SAP Integration Consultant for help

P2P examples:

Consultant enters a supplier invoice; agent pulls historical Ariba-CPI payload and checks consistency.
Agent validates purchase order messages across production and test runs.

Why it matters for SAP S/4HANA projects

In S/4HANA transformations, the external world doesn’t care about your internal redesigns. Customers, suppliers, and banks still expect exactly the same messages they used to get. Outbound and inbound interfaces are fragile bridges that must remain stable.

By equipping functional consultants with Int4 Suite agents:

Test cycles shorten dramatically.
Reliance on external partners and scarce integration resources drops.
Confidence in end-to-end quality rises.

This isn’t about replacing automation experts or integration teams. It’s about enabling functional consultants to independently confirm that what leaves SAP (or comes into it) is still what the outside world expects.

It’s the missing puzzle piece for smooth, low-friction testing of integrated business processes in SAP transformations.

More information:

Agentic AI Testing for Greenfield S/4HANA Outbound Interfaces - Part 1

Int4 Suite — your SAP Joule testbed and skills builder

Process-Aware Agentic Testing of SAP with Int4 Suite

Agentic Testing and Simulation with Int4 Suite's SAP Business Knowledge Graph

Integration Between SAP CPI and SAP DataSphere (JDBC Connection)

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

Integration Between SAP CPI and SAP DataSphere (JDBC Connection)

JDBC – JAVA DATABASE CONNECTIVITY

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

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

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

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

Prerequisites:

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

SAP DataSphere Step by Step Guide :

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

SAP Integration Suite Step by Step Guide :

Create a Package & Artifact

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

Go to Monitoring → JDBC Material

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

Apply JDBC Material in iFlow

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

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

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

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

Sample data Response from JDBC Connection:

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

Accelerating SAP BTP Integrations with GPT-5: Introducing the SAP Integration AI Assistant

2025-11-01T05:32:22.246000+01:00

Introduction

AI is transforming how we work. Over the last few years, tools like ChatGPT have evolved from simple chat interfaces to intelligent partners that can understand complex technical problems.

As an SAP Integration professional, I started thinking — what if we could bring that same level of intelligence into the world of SAP BTP Integration Suite?

Having worked with SAP CPI, API Management, and Event Mesh, I’ve often seen teams spending countless hours writing Groovy scripts, debugging mappings, and testing iFlows. These tasks are essential but repetitive — and that’s exactly where AI can help.

This thought led me to create something new: the SAP Integration AI Assistant — an intelligent support tool built using GPT-5, designed specifically for SAP Integration developers and consultants.

Challenges in SAP Integrations

Working with SAP Cloud Integration (CPI) can be both rewarding and demanding. Integration developers often face common challenges such as:

Debugging and formatting Groovy scripts
Managing complex mappings and error handling
Designing reusable iFlows that align with SAP standards
Searching through documentation for the right solution

While SAP provides excellent documentation, finding exactly what you need under project pressure can take time. AI can make this process faster and smarter — assisting developers with real-time insights.

Meet the SAP Integration AI Assistant

The SAP Integration AI Assistant is built on GPT-5 and trained with integration-specific knowledge. It helps developers solve real project problems efficiently.

Here’s what it can do:

Code Support: Generate, clean, and format Groovy/XSLT/JavaScript scripts with consistent structure.
Design Guidance: Suggest iFlow layouts, adapter configurations, and error-handling approaches aligned with best practices.
Troubleshooting: Analyze error messages or mapping issues and suggest probable fixes.
Learning Tool: Act as a companion for those new to SAP Integration Suite, explaining concepts and configurations clearly.

It’s like having a virtual SAP Integration mentor — available anytime you need it.

Built from Real Project Experience

This idea came from years of working on integration projects across global landscapes — building, optimizing, and reviewing iFlows in SAP BTP.

The assistant is designed to share this accumulated experience. It transforms real-world learnings into actionable insights that any developer can use directly in their daily work.

Getting Started

You can begin experimenting with the SAP Integration AI Assistant right away.

Use it to:

Generate or optimize Groovy/XSLT code
Validate iFlow designs and configurations
Troubleshoot mapping or adapter errors
Explore integration scenarios with API Management and Event Mesh

Try it here: SAP Integration AI Assistant

Sample Examples

Conclusion

AI is no longer a future trend — it’s an everyday tool for developers.
By combining SAP Integration expertise with AI capabilities, we can build integrations faster, reduce manual effort, and improve quality.

#SAPBTP,#IntegrationSuite,#CPI,#SAPIntegration,#AI,#Automation,#GPT5,#CloudIntegration,#Groovy,#XSLT,#SAPDevelopers, @RameshK_Varanganti

Integrations as part of the SAP LeanIX (Enterprise) Architecture?

2025-11-16T17:39:36.351000+01:00

We may have our state-of-the-art Applications. But how do we make them work together? We may have all our Date Objects properly designed and governed. But how do we unlock it for the Users and Agents?

Integration – key is in the Integration Services!

We have to integrate Applications, Users and Agents – in order to unlock our Data and make our Business Processes run seamlessly and efficiently, cross whole Enterprise.

I’ve talked about importance of recognizing the work on integrations in the Enterprise Architecture domain (my article in SAP EA Community: Enterprise Architecture for integration?), but now let’s go with few practical examples…

Integrations @ EAM

If we use SAP LeanIX solutions[1] as EAM (Enterprise Architecture Management) tool, and we want to model our Enterprise Architecture – how do we manage it, if we do not “connect” the dots

Well, we cannot!

Figure 1. Integration Services

Of course, integrations are far more complex than just “connecting” dots. In this example, I’ve used an example where we replicate Business Partner Customers to two order taking channels – fairly common scenario in Omnichannel Sales.

Source is Master Data System (i.e. SAP MDG) – this is clearly marked as an Application in SAP LeanIX.(of course, we may have multiple Applications within one “box”, but overall object modeling is a different story, not covered by this article…).
Target Systems are B2B Channel and Field Sales – again I am color-coding those as Applications.
From Source to Target Systems, we are replicating Customer – this is Data Object.
Finally, we have an Interface (if we use SAP LeanIX notation), or Integration Service (in a broader sense). We may be “happy” in seeing “only” one line, representing BP Customer Replication. connecting Source and Target Systems… This is probably sufficient for high-level C4[2] diagramming and modeling.
However, if we want more details on Interfaces (or dots “connecting” Applications) – i.e. how it actually works, what are the underlying technology and capabilities, which patters were used etc. – then we must go few levels “below” in the integration hierarchy. Each “parent” Interface (or Integration Service). has one or more “child” Interface Components (or Integration Service Components) – i.e. APIs, IFlows, Queues etc.; and those “child” Interface Components “uses” some IT Components – i.e. SAP CPI, API-M, Azure Service Bus etc.

Figure 2. SAP LeanIX Interface Fact Sheet

In SAP LeanIX each object is modeled with its own Fact Sheet, thus each Interface, whether “parent” or “child”, has its Fact Sheet. There are some powerful features when defining Fact Sheets:

We are defining descriptions, attributes, and we also have a possibility to add links to external resources – i.e. we may have external repositories with functional and technical details in Azure DevOps Wikis or GitHub..
We can link Interface with its “parent” or “child:
We can link Interfaces among themselves into “left/right” flow.
We can link with appropriate Application(s), Data Object(s) and IT Component(s)

Interesting though is to note, general recommendation in SAP LeanIX is to use Applications for Business Applications, while Technical Applications (like SAP Integration Suite etc.), enabling specific Interfaces, we should model as IT Components. Although there is no strict limitation preventing us to set i.e. SAP Integration Suite as an Application (this will of course create different pictures in C4 diagrams), the important thing is to choose the approach “once” and stay consistent.

Figure 3. Integration model

Object models with connected Interfaces can very easily become very complex. But do we really have a choice – not to model full integrations? Is it sufficient to have only high-level Enterprise Architecture in EAM tool?

I guess it all depends on the preferences, but I would say – no, it is not sufficient.

And it’s not about – “hey SAP LeanIX give us possibility to model Interfaces in more granularity” – this is about overall management of the Enterprise Architecture. How can we manage something we do not see? And yes, integration is really a key, or a backbone, of daily operations of any Enterprise:

The Architect View(point) must include sufficient level of details on all Architectural components – otherwise we are “blind” in seeing AS-IS state.
Building new or reusing existing integrations cannot be made without appropriate visibility on the underlaying layers of the Interface(s) or Integration Service(s) – otherwise we cannot make educated decision for TO-BE state
If we do not have adequate view on AS-IS and TO-BE, we cannot properly understand the Gap and build roadmap, planning and strategy.

Integrations @ EA Frameworks

Ups looks like no Integration Architecture domain in TOGAF©[2]?

Figure 4. Where is Integration Architecture

Where is Integration Architecture domain?

Is it part of B. Business Architecture? Probably not, but aren’t we saying that integrations are enabling Integrated Business Processes…
Maybe it’s part of C. Information System Architecture, also (usually) split into Application Architecture and Data Architecture? Looks reasonable to be “somewhere” here, but still, it’s not “formally” listed here…
Or is it D. Technology Architecture? Integrations are often observed as “technology” domain, but this is not entirely correct perception…

Hold on, nothing is “carved in stone”…

Figure 5. LeanIX Application and Data Architecture

Interfaces (or Integration Services) should be observed on the same level as Applications and Data Objects – and in SAP LeanIX metamodel[3], indeed we do see that Interface(s) are part of Application and Data Architecture.

Application “provides” and/or “consumes” Interface.
Interface “transfers” Data Object.

Integrations are not just dots or lines – it’s much more, no matter if we observe some underlaying IPaaS or Event Broker as an IT Component or an Application. And if we accept these guidelines, then we have to “pay” attention to model integrations correctly and fully.

Simple and clear…

Integrations @ AI use-cases?

First “reply” would be – yes of course. But let’s think where we are heading with AI…

MCP Serves can be built on tables – accessing Data Objects directly. It can be done, yes, but do we want this or would we prefer some sort of governance by exposing Data Objects via OData and API Management in between? That is the question yet to be answered… But I know my answer. Of course, in the "world" of Microsoft Dynamic365, MCP Servers are actually based on Dataverse object or tables (not APIs) but this is different, I guess…

Now, what about A2A (Agent-to-Agent)? This is also some sort of integration… Well, if it is integration, it is an integration – “things” are not being integrated on its own...

Why am I bringing AI? AI is now “mixing and matching” with everything. While AI Agents and Agentic AI will most certainly impact integration technology, the need to precisely “craft” Integration Services will not disappear. It may change, but it will not disappear!

Putting this in the EAM perspective – yes of course we do want to manage all out AI investments, ideally in one EAM tool, and SAP LeanIX now comes with AI agent hub[4] – equipped to discover, manage and govern all AI agents. Of course, A2A and MCP are somehow inevitable part of it. Another reason to model integrations correctly and fully...

Integration is the key!

Integration, whether it is fully Decoupled Integration based on Event-Driven Architecture principles supporting Compostable Business (Architecture)[5], or it is some more legacy SOA[6] – in all cases, it is Integration Services which are making things “happen”.

So, it’s a glue connecting Application Blocks, right?

No, no – it’s not “just” a glue! It used to be a “real” glue – well at least in legacy solutions, connecting monolithic “boxes”. But now we are Agile, we are building Systems to be “Compossible”. If Applications are Blocks (one can imagine its LEGO©[7] or equivalent), we don’t want to glue Blocks, because we cannot “recompose” our System of Blocks into something different, we cannot change Blocks, and or try new Blocks..

This “glue” we use is invisible it is by design – its Blocks itself – the way how we build them to “fit” – no matter of their particular shape, or size or color, they can always fit. They can fit “tight” but can be “disassembled” at any time we need to “recompose” the System of Blocks.

Sounds simple, but it’s not.

If we want that flexibility, if we want to avoid “fixing” with glue – we need to design and build with precision. And this is more than just technology stack – this is also about overall strategy – what kind of Blocks we need to connect now, or in future. How do we “craft” integrations so everything can fit – not only now. but in foreseeable future as well.

Who are we?

We are Developers – yes (this is our usual background)! We are Engineers – yes (most certainly)! But we are seasoned Architects – yes as well, very seasoned (if I may add)!

We are versatile Architects who need to know, or at least understand, so many different “things” – not only integration technologies, but Data Models, Applications, even Business Processes. After all, we are not integrating Applications and Systems, we are integrating Business (Processes).

Figure 6. Work of EA for Integration

We can be Solution Architects or Enterprise Architect, just as in any domain – but we must be able to understand much more than “just” integration technology.

Is our work perceived that way? Well, this is a different story…

And again – Integration Services…

I am being subjective – yes. But haven’t I proved how important integration is?

Is the integration work seen and valued as any other Enterprise Architecture work? Very rarely, as integration is usually seen as very technical discipline, part of solutioning, not strategy… There are exceptions (obviously)…

Maybe we need to raise the awareness and change the mindset – proper integration modeling and design is the key for the success in many initiatives – and proper modeling has to come as a result of the Integration Strategy, not just "technical" solutioning on case-to-case basis.

Am I giving too much “credit” to integrations? Yes, but with a reason… Just think, how many projects failed or were delayed because integrations were not properly designed or implemented? And this (usually) has nothing to do with “bad” integration developers and integration engineers…

Does this resonate?

Acknowledgment

*) Into image generated by AI.

References

[1] SAP LeanIX: https://www.leanix.net/en/

[2] C4 model: https://c4model.com/

[3] SAP LeanIX Interface Modeling Guidelines: https://help.sap.com/docs/leanix/ea/interface-modeling-guidelines

[4] SAP LeanIX AI agent hub: https://www.leanix.net/en/ai-agent-hub-in-sap-leanix

[5] Composable Architecture: https://community.sap.com/t5/technology-blog-posts-by-members/what-is-composable-architecture/ba-p/13889670

[6] SOA: https://community.sap.com/t5/enterprise-architecture-blog-posts/agile-ea-from-soa-to-interoperability/ba-p/225234

[7] LEGO©: https://www.lego.com/

Partnering for Progress: Accelerate Your Move to SAP Integration Suite

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

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

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

That’s where Migration Factory 2.0 comes in.

Building a Stronger Ecosystem — Together

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

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

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

Behind the Program: Enablement, Execution, and Engagement

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

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

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

Why Partners Are the Game Changers

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

Through the program, partners can:

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

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

Helping Customers Choose the Right Partner

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

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

My Favorite Part: The Collaboration

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

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

Let’s Move Forward — Together

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

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

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

Maximising AI Potential: A Blueprint for Business Success

2025-12-01T13:11:19.101000+01:00

Introduction

In an era defined by rapid technological advancement, businesses face both significant challenges and valuable opportunities as they pursue digital transformation and integrate AI-driven solutions. As organisations work to maintain a competitive edge, AI’s impact on business strategy, customer experience, and operational efficiency has become increasingly pivotal.

As part of my recent doctoral studies in Digitalisation, specialising in Technology Adoption and AI Integration at IAE Nice, Graduate School of Management, Université Côte d’Azur, I explored this evolving landscape in depth through research focused on SAP customers. I am Happy to share the key findings through a series of insightful and practical articles, each offering guidance for both SAP customer leadership and SAP executives navigating the complexities of AI adoption and technology transformation.

Maximising AI Potential: A Blueprint for Business Success (THIS ARTICLE)
Roadblocks to AI Adoption
Is SAP Business Data Cloud the Answer to Your AI Ambitions?

In an era marked by rapid technological advancements, businesses face the dual challenge and opportunity of integrating AI-driven solutions. As organisations strive for competitive advantage, the role of AI in transforming business strategies, enhancing customer experiences, and driving operational efficiency cannot be overstated. This blog explores effective strategies for helping customers navigate the fast-changing AI world, drawing insights from my doctorate reproach aiming to develop a robust theoretical model and managerial blueprint for executive technology transformation and change management.

The Role of AI in Business

Over recent decades, AI has revolutionised how businesses operate, driving personalised marketing, strategic planning, and data-driven insights. Companies now rely on AI-driven chatbots for customer interaction, automated processes for operational efficiency, and data analytics for strategic decisions. The increasing digitization leads to the generation of vast amounts of data, making advanced digital technology indispensable for extracting value from this data. However, this shift also presents challenges, as many businesses struggle to adopt new technologies swiftly enough to remain competitive. Furthermore, technology vendors face the challenge of marketing their innovative solutions effectively and bridging the gap between innovation and adoption.

Key Factors for Successful AI Adoption

Key findings highlight the importance of strategic alignment, collaborative change management, cost considerations, customer experience, and vendor support in the successful adoption of AI technologies. Businesses must ensure AI solutions are in line with their strategic goals to add value and sustainability. Handling change effectively is crucial, involving stakeholders early and prioritising leadership support to cultivate an innovative culture. Financial implications are essential in decision-making, making it vital for organisations to perform detailed cost-benefit analyses to assure profitable returns on AI investments. Enhancing customer experience through AI-driven solutions with user-friendly and personalised interfaces can significantly boost business success. Finally, robust vendor support and training are necessary to facilitate a smooth transition and maximise the advantages of AI technologies, aligning with organisational needs and challenges.

Bridging the Gap: The Fast-Track Model

The Robust Technology Adoption and Contract Retention Model (Fast-Track) is a theoretical framework developed as part of my doctoral studies to provide insights into the multifaceted aspects of technology adoption and retention from both technology vendors' and users' perspectives. The model emphasises understanding and addressing barriers and enablers in three key categories: organisational, personal, and external.

Drawing on established theories like the Technology Acceptance Model (TAM), Diffusion of Innovations Theory, Task-Technology Fit, and the Unified Theory of Acceptance and Use of Technology (UTAUT), the model examines how organisational vision, planning, and stakeholder management influence successful technology adoption. Additionally, it considers strategic management theories such as Kaplan & Norton's Balanced Scorecard framework, which aligns technology strategies with business objectives. The Fast-Track model comprises two primary lifecycle outlines: the Technology Utilisation Lifecycle (for customers) and the Technology Deployment Lifecycle (for SAP/vendors). The former progresses through strategic vision setting, planning, implementation, continuous improvement, and renewal, ensuring technology aligns with evolving business needs. The latter involves market research, sales, implementation, and continuous support, highlighting the importance of understanding customer needs and maintaining engagement.

Furthermore, the model highlights the significance of external factors like industry standards, adoption costs, and vendor support in shaping technology deployment strategies. By addressing these factors, both vendors and users can enhance satisfaction, competitive advantage, and the lifecycle value of technology. Personal attitudes, user training, and change management are additional aspects considered vital in mitigating resistance and enhancing technology adoption. Integrating concepts from technology acceptance models, the framework details how perceived usefulness, ease of use, and associated personal and organisational barriers impact technology uptake and retention. In essence, the Fast-Track model provides a comprehensive strategic pathway for navigating technology adoption and contract retention complexities. It encourages continuous engagement, adaptation, and alignment of technology with organisational goals, thus facilitating successful integration and sustained competitive advantage.

Key Findings and Analyses:

My doctorate research delves into the multifaceted dynamics of technology adoption and contract retention among SAP and various user industries by studying 29 SAP Customers and their Partners across diverse sectors. Utilizing Lexical analysis with NVivo software, the research categorizes and quantifies essential terms, phrases, and themes from interview transcripts, providing a structured and numerical understanding of the content with an emphasis on explicit aspects such as words and visual elements. Key findings include the pivotal role of technology perception in adoption, where strategic alignment with company goals and operational enhancement is crucial, influenced by both internal and external factors like market competition and regulatory requirements. Effective technology adoption requires strategic planning, cost management, and user acceptance, while organizational and personal barriers such as resistance to change and fear of job loss need addressing through robust change management and leadership support. Externally, factors like industry norms and regulatory compliance shape adoption strategies. The cost of technology emerges as a critical determinant, with companies needing to consider both direct and ancillary expenses versus strategic benefits. Positive end-user experiences significantly influence IT contract renewals, with organizations valuing user satisfaction highly. Evaluating alternative vendors involves a detailed analysis of various metrics including solution capability and cost-effectiveness. The study proposes a Fast-TRACK model emphasizing strategic vision, comprehensive planning, and continuous improvement to navigate technology adoption and retention challenges effectively. Practical implications suggest that companies should adopt a holistic approach centered on strategic alignment and robust change management, with SAP urged to demonstrate the strategic value of their solutions and engage customer stakeholders early in the adoption phase to ensure technology implementations meet long-term goals and achieve higher satisfaction and retention rates.

Conclusion

This study explores technology adoption and contract retention using semi-structured interviews and NVivo's Lexical analysis, highlighting the importance of aligning technology with business needs, effective change management, cost considerations, and strategic implementation. Key themes include the influence of perception, organizational alignment, cost, complexity, ease of use, effective change management, and vendor support on technology adoption and retention. The research, set within a leading software corporation, provides valuable insights and validates findings with additional data. It introduces the Fast-Track model, emphasizing strategic considerations and practical implementations for leveraging technology for competitive advantage. The study also underscores the importance of understanding external barriers and enablers, such as cost, industrial norms, competition, and vendor support. The contributions of the research include extending the Balanced Scorecard approach to incorporate digital transformation, offering managerial recommendations, and providing a comprehensive framework (Fast-Track model) for navigating technology adoption and retention. Managerial recommendations include adopting a structured approach to technology integration, fostering a culture of continuous learning, and investing in robust knowledge management systems. Future research topics suggested include the impact of customer confusion on technology adoption, testing the FUTARE model across different regions and company sizes, and its effectiveness on upselling or expanding service contracts. The study provides valuable insights and practical recommendations for organizations aiming to enhance their technology adoption strategies and retain contracts effectively.

The Robust Technology Adoption and Contract Retention Model (Fast-Track) highlights the need for strategic alignment between technology vendors and users within organizational, personal, and external domains for successful technology adoption and retention. Vendors should deeply understand client structures to tailor technologies that integrate seamlessly into client workflows, enhancing operational effectiveness while maintaining compliance with industry regulations. Prospective clients must ensure these technologies align with strategic goals and existing systems. Proper training for users and insightful adjustment to external factors such as competitive trends are paramount. Broadly, managing the dynamics at the vision to planning phase involving pre-sales to sales within both organizational users and technology vendors is critical. This structured approach will help navigate through barriers and enablers, setting a solid base for adopting new technologies and retaining contracts effectively.

If you'd like to explore further, my full research article with reproach is available here. Please don't hesitate to contact me if you wish to discuss the research findings.

Find my Linked Profile: https://www.linkedin.com/in/mi4po/

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

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

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

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

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

This blog walks through:

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

Context: The Scenario

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

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

This limitation became the center of the problem.

Approach 1 — Standard OData V4 Adapter + Looping Process Call

(Expected to work… reality had other plans)

How it worked:

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

What happened:

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

Example:

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

Lesson: Looping + uncontrolled server pagination = unpredictable behavior.

Approach 2 — OData V4 Adapter + Custom Pagination Logic

(Better… but still not scalable enough)

This time we added:

Custom counter checks
Pagination logic in iFlow
Looping until full completion

Result:

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

Lesson: The bottleneck was structural, not logical.

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

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

Key idea:

Avoid OData V4 adapter entirely.

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

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

Our Winning Architecture

Flow 1: Master Controller iFlow

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

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

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

Example:

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

Flow 2: Worker iFlow

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

The Big Win

This mechanism:

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

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

Key Learnings

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

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

Conclusion

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

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

Feedback Welcome

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

Thank you for reading!

I2Integration Solutions | A Startup

Connect in LinkedIn: I2Integrate

SAP Neo Retires – Integration Developers Must Know Before Migrating from Neo to CF

2025-12-03T12:17:49.941000+01:00

SAP has announced the end of maintenance for the SAP Cloud Integration Neo environment by December 31, 2028. This impacts customers running Cloud Integration on Neo and planning to move to the Cloud Foundry–based SAP Integration Suite.

Migrating integration flows from Neo to Cloud Foundry is not a simple export/import of iflows.
Both environments differ significantly in:

Infrastructure
Adapter deployment
Logging & monitoring
Environment variables
APIs
Security materials
Transport & lifecycle management

This blog summarizes the key Neo vs. Cloud Foundry differences you must consider before starting your CPI migration.

1. Cloud Integration Availability: Neo vs. Cloud Foundry

Neo

CPI is available as a standalone product
Runs in SAP-managed data centers
Uses Neo cockpit & proprietary deployment mechanisms

Cloud Foundry

CPI is part of the SAP Integration Suite capability
Runs on hyperscalers (AWS, Azure, GCP)
Uses standard CF principles for scaling, service bindings, logging

📌Important: Some Neo features may not be available or behave differently in CF (refer to Note 2903776).

2. Adapter Deployment Differences

Neo

Custom adapters deployed using Eclipse plugin
Adapter artifacts managed in Neo cockpit

Cloud Foundry

Custom adapters are deployed as Integration Adapter artifacts
Managed via Cloud Integration Design & Monitor applications
Deployment uses CF-based lifecycle mechanisms

Impact:
If you have custom adapters built for Neo, they must be rebuilt or repackaged for Cloud Foundry. Here is the help document to create custom adapters Developing Customer Adapters

3. Logging Differences - Audit Logs & Access Logs

Neo

Audit logs retrieved via Neo Audit Log API
Access logs available under “Access Logs” section

Cloud Foundry

Audit logs available through SAP Audit Log Service
Access logs integrated with Application Logs
Monitoring done via Cloud Integration Monitor

Impact:
Integrations relying on Neo-specific APIs must be redesigned for CF logging services. Here is the help document related to Audit logging in CF environment Audit Logging in CF

4. Environment Variables - Critical Migration Topic

We can use environment variables in integration flows to address technical details like the region,port..etc where Cloud Integration is deployed.

The following table provides the mapping of environment variables in Neo and Cloud Foundry.

Variable Name - Neo	Variable Name -CF	Description
HC_APPLICATION Example value: abcd01iflmap	TENANT_NAME Example value: xyz001	Sub domain of worker application (associated with application identifier for worker node)
HC_APPLICATION_URL Example value: abcd01iflmap.uvwxy.eu1.hana.ondemand.com	TENANT_NAME + IT_SYSTEM_ID + IT_TENANT_UX_DOMAIN Example value: xyz001.it-cpi001.cfapps.eu10.hana.ondemand.com	URL of the worker application sub domain
HC_HOST Example value: hana.ondemand.com	IT_TENANT_UX_DOMAIN Example value: cfapps.eu10.hana.ondemand.com	Base URL of the SAP BTP region host where the application is deployed
HC_LOCAL_HTTP_PORT Example value: 9001	PORT Example value: 8080	HTTP port of the application bound to localhost
HC_OP_HTTP_PROXY_HOST	VCAP_SERVICES	Host of the HTTP Proxy for on-premise connectivity
HC_OP_HTTP_PROXY_PORT Example value: 20003	VCAP_SERVICES Example value: 20003	Port of the HTTP Proxy for on-premise connectivity
HC_REGION Example value: EU_1	IT_TENANT_UX_DOMAIN Example value: cfapps.eu10.hana.ondemand.com	Region where the application is deployed

Here is the nice blog on how to call/get environment variable in CF Integration flows - identify-sap-cloud-integration-tenant-stage-at-runtime

5. OData API Access Considerations

Neo

Uses Neo-based OAuth clients
API base URLs differ
Some OAuth grant types are Neo-specific

Cloud Foundry

Requires enabling API clients via XSUAA
Uses Integration Suite base URLs
Authentication flows must be updated

For example:
If you use CPI OData APIs for CI/CD, monitoring, or automation, the endpoints and tokens must be regenerated. Here is the help document gives more details on inbound communication setup - connection setup for inbound communication for api clients

6. Transport Management & Lifecycle Changes

For the transport of integration content across different tenants, different options are available:

Manual export and import
Usage of CTS+
Usage of the cloud-based Transport Management

These options are identical independent of the environment (Cloud Foundry or Neo). However, setting up transport management using the cloud-based Transport Management service is different in both environments

7. Security Materials (Certificates, Keys, OAuth)

Neo

Keystore stored and managed directly inside Neo cockpit
OAuth clients created using Neo administration tools

Cloud Foundry

Uses Service Instances for trust stores
Certificates and keys must be re-imported
OAuth clients created via Integration Suite

Impact:
Rebuild all security configurations - especially if you use SFTP, AS2, OData, or SOAP with certificates.

8. Custom Scripting Adjustments (Groovy/JavaScript)

Some scripts refer to Neo-specific:

Endpoints
Log files
Environment variables
Adapter classes
Tenant metadata

These must be refactored to support CF equivalents.

9. Monitoring Experience Differences

Neo

Heavy reliance on Neo cockpit
Simplified logging UI
Access logs separate from application logs

CF

CPI Monitor in Integration Suite
Centralized message processing logs
Audit logging via SAP Audit Log Service
Better integrations with external monitoring tools

Impact:
Monitoring dashboards and alerting need reconfiguration.

Conclusion

Migrating SAP Cloud Integration from Neo to Cloud Foundry is a strategic, time-sensitive initiative as Neo retires in 2028. However, the migration is not a technical copy-paste.
Neo and Cloud Foundry differ significantly in:

Adapter deployment
Logging & audit mechanisms
Environment variables
OAuth & API access
Transport landscape
Runtime services
Security configuration

By understanding these environment-specific differences early - and adjusting integration flows, scripts, endpoints, and credentials accordingly - you can avoid migration failures, reduce manual fixes, and ensure a smooth transition to the SAP Integration Suite on Cloud Foundry.

If planned well, the Cloud Foundry environment offers:

Better scalability
CI/CD readiness
Modern logging and monitoring
Hyperscaler flexibility
Improved integration lifecycle governance

The best time to start preparing is now.

Espresso bites – Clean core Integration based on an OData example for SAP AIF monitoring

2025-12-10T08:21:30.976000+01:00

By Robert Schilling & Bertrand Henkel.

As an Enterprise Architect for SAP RISE customers, we guide organizations through business transformation and cloud adoption. The core integration principle enables hybrid architecture scenarios developed by SAP for customers with large and complex SAP landscapes integrating essential elements and enabling a phased transition to the cloud.

For an initial introduction to clean core principles, we recommend the following learning resource: Managing Clean Core for SAP S/4HANA Cloud. Here, we demonstrate how to evaluate and apply clean core principles to ERP systems to maximize business process agility, reduce adaptation efforts, and accelerate innovation. The course is designed for beginners, takes two hours, and is free of charge.

In general clean core integration focusses on four pillars – please follow up with the official documentation or other blog entries like Future-Proofing Enterprise Agility with SAP Integration Suite and Clean Core Principles

Technically speaking the clean core integration principle focusses on these main components:

Establishing an API-led strategy and event driven architecture
SAP Integration Suite on SAP BTP,
Enabling operational excellence for end-to-end monitoring using

the Integration & Exception Monitoring capability of SAP Cloud Application Lifecycle Management (SAP Cloud ALM).
The monitoring capability of SAP Application Interface Framework (SAP AIF) on SAP S/4HANA,
The monitoring capabilities of SAP Integration Suite on SAP BTP

Based on SAP progress, many integration scenarios are already available within this solution architecture: In our daily business as Enterprise Architects we are often asked: “How do I activate these SAP standard scenarios?” and “What should I consider for my custom-built interfaces?”

Therefore, this blog focuses on the reference architecture for the monitoring capabilities for OData Services of SAP Application Interface Framework following the clean core integration principle.

How do I activate SAP AIF Monitoring & Error Handling for SAP standard interfaces for SAP CALM integration?

To do this, the corresponding SAP AIF scenario must be activated. In the SAP documentation (see example: Purchase Requisition – OData V2) for each interface, the available AIF scenario is listed, which can then be activated using the transaction "AIF Content Transport – Deploy /AIF/CONTENT_EXTRACT".

If SAP standard interfaces are not listed as a scenario, SAP asks you to submit a corresponding SAP Customer Influence Request for the relevant interface, like other clean core topics. In general, you can also check the table /AIF/ICD_DATA, which underlies the transaction /AIF/CONTENT_EXTRACT.

In the meantime - How to handle SAP Standard Interfaces, where no SAP AIF Scenario is available?

At present, not all SAP Standard OData Interfaces—such as those from the Maintenance Management area—come with available SAP AIF Scenarios. So, what’s the approach for enabling SAP Cloud ALM Integration and Exception Monitoring in these cases?

These specific SAP Standard Interfaces are handled through SAP Gateway functionalities. You can monitor them directly in SAP S/4HANA using the SAP Gateway Performance Monitor (/IWFND/MONITOR) and review issues in the SAP Gateway Error Logs (/IWFND/ERROR_LOG). Currently, with SAP Cloud ALM, only data from the Error Log can be transferred to SAP Cloud ALM Integration & Exception Monitoring. For more details, please refer to the following section: Enable SAP ABAP Gateway Errors for SAP Cloud ALM.

License requirement for using SAP AIF with custom-developed interfaces:

As described in SAP Note 2293938 – License Check for SAP Application Interface Framework and in the SAP blog "SAP Application Interface Framework – Licensing", a separate SAP AIF license is required to manage custom-developed interfaces via SAP AIF. After purchasing the SAP AIF license, the AIF component AIF_GEN can be installed in the system and used for developing custom interfaces under SAP AIF. The necessary configuration steps for custom interfaces can be found in the relevant SAP help for SAP AIF interface development.

Further information:

IDoc with Integration Suite, Advanced Event Mesh – Process Integration meets Eventing

2025-12-15T04:43:00.463000+01:00

Introduction: Why IDoc-based Eventing matters

Event-driven architectures have become a cornerstone for building responsive, loosely coupled SAP landscapes. With SAP Event Mesh and SAP Advanced Event Mesh (AEM), organizations can now distribute business events in near real time across SAP and non-SAP systems.

However, despite the growing availability of native business events in SAP S/4HANA, IDocs remain one of the most widely used integration mechanisms in productive SAP landscapes today. Especially in hybrid and transition scenarios — such as ECC to S/4HANA conversions, RISE with SAP journeys, or coexistence setups.

This leads to a pragmatic but important question for many architects and integration teams: How can we enable event-driven integration when IDocs are the primary source of truth?

Motivation: Bridging Legacy Integration with Modern Eventing

Many customers want to adopt event-driven integration patterns without breaking existing interfaces or redesigning core business processes. Replacing IDocs with native domain events is often not feasible in the short term due to:

Large numbers of productive IDoc interfaces
Business-critical dependencies on established ALE/EDI processes
Limited capacity to redesign integration contracts during S/4HANA or RISE projects

At the same time, downstream consumers increasingly expect event-based communication, lightweight payloads, and scalable publish/subscribe models instead of point-to-point messaging.

What This Blog Covers

In this blog, we will compare four technical approaches for enabling SAP Eventing with IDocs as a source:

SAP RAP – modeling domain-oriented events in the backend
SAP Application Interface Framework (AIF) – governed IDoc processing and transformation
ASAPIO Event Add-on – purpose-built IDoc-to-event enablement
SAP Integration Suite (PI-style Cloud Integration) to SAP AEM – middleware-driven event publication

The comparison focuses on technical, operational, and commercial KPIs, helping architects and integration leads decide which approach best fits their current landscape — and their long-term eventing strategy.

Furthermore we are planning to release a setup blog for every approach in 2026.

KPI Area	Sub-KPI	SAP RAP	SAP AIF	ASAPIO Event Add-on	IDoc with Integration Suite, Process Integration → SAP AEM
Technical	Architecture fit for eventing	RAP is a development model for OData/REST apps; events must be explicitly modeled and outbound connectors added.	AIF is built to process, validate and route message-based interfaces, including IDocs, before forwarding.	Purpose-built for IDoc capture → event broker integration; minimal coding needed.	Uses IDoc adapters in Integration Suite (Cloud Integration) to pick up IDocs → transform → push to AEM; classic PI-style patterns. Good for hub-and-spoke landscapes.
	Payload granularity & semantic model	High flexibility; you design domain events — can be fine-grained but requires modeling effort.	Strong transformation/mapping capabilities; suitable for shaping IDoc content into event payloads.	Prebuilt mapping designer enables consistent, semantically enriched payloads quickly.	Very flexible message mapping in Cloud Integration; can output structured JSON events or IDoc-like structures.
	Payload type (Original IDoc vs. IDoc-like)	IDoc-like payload — RAP does not emit IDocs; outputs structured domain events that can mimic IDoc segments if designed so.	Original IDoc or IDoc-like — AIF can pass through raw IDocs or transform into custom IDoc-like payload structures.	IDoc-derived payload — captures the IDoc, then emits a normalized JSON event retaining IDoc semantics (not the raw IDoc).	Setup would use standard distribution model (BD64) based in Original IDoc
	Latency & throughput	Not optimized for high-volume IDoc capture; requires event plumbing; suitable for domain events rather than mass IDoc streaming.	Strong runtime for IDoc processing; can scale with tuning.	Optimized for real-time, high-volume IDoc eventing with direct connectors.	Medium–High depending on Cloud Integration worker capacity; good for steady volumes, less ideal for IDoc bursts.
	Development effort & maintainability	Medium–High: event modeling + outbound logic need to be built.	Medium: mostly configuration-driven, reduced custom coding.	Low–Medium: mostly no-code/low-code; install, configure, map, emit.	Low–Medium: requires integration flow development, mapping, testing, monitoring artifacts.
Operations	Monitoring & observability	Standard Event Monitor as part of Event Enablement Framework	Very strong: built-in interface monitoring, message lists, business error handling.	Built-in IDoc/event diagnostics + integration with event broker telemetry.	Cloud Integration monitoring via Message Monitor + separated backend IDoc monitoring → two monitoring planes. Could add it to AIF or CALM
	Error handling & reprocessing	Requires custom retry logic; no native interface reprocessing workflow.	Excellent: assisted corrections, reprocessing, business-user-friendly UI.	Strong support for IDoc re-send, retries, scheduling, and alerting.	Reprocessing via Cloud Integration retry or resending IDoc from backend; not as business-friendly as AIF.
Commercial	Licensing / procurement	No new licenses; uses ABAP/RAP; development cost is the main factor.	Included/licensed with SAP backend; configuration effort applies.	Partner product with subscription/maintenance; reduces dev time.	Requires Integration Suite licenses (message-based or connection-based) + AEM consumption.
	TCO & time-to-value	Longer ramp-up due to event modeling and development effort.	Medium TTV; faster than custom coding thanks to AIF tooling.	Fast TTV; immediate eventing from IDocs with minimal dev.	Fast TTV: Integration flows must be developed, deployed, and maintained; good reuse for multi-system connectivity.
Setup Guide	How to implement it?	Blog will follow	Setup Blog	Setup blog	Setup Blog

There is no one-size-fits-all approach to IDoc-based eventing in SAP landscapes — each option comes with distinct trade-offs across architecture, operations, and cost. While purpose-built add-ons and middleware enable fast time-to-value, backend-driven approaches provide stronger long-term alignment with domain-driven and native event models. Ultimately, the right choice depends on whether your priority is speed, governance, or future-proof event semantics on your journey toward an event-driven SAP architecture.

Stay tuned and Happy Eventing

From PI/PO to SAP Edge Integration Cell: Initial Sizing Approach and Planning for HA/Non-HA Setup

2025-12-16T13:34:19.679000+01:00

SAP Edge Integration Cell- Sizing Approach

Planning the migration from SAP PI/PO to the SAP Integration Suite requires accurate infrastructure sizing for the Edge Integration Cell.

In this post, I demonstrate a practical sizing approach by applying the official Sizing Guide and SAP Note 3247839 (Prerequisites) to a real-world scenario.

By analyzing PI/PO Message Performance, this blog post helps you determine the necessary hardware resources to ensure a stable foundation for your migration to SAP Edge Integration Cell. Furthermore, I will outline the key differences between High Availability (HA) and Non-HA setups, highlighting the critical factors you need to consider when selecting this two setups.

1. Input for Sizing – Business Throughput

Business Throughput is the number of business transactions or messages an SAP system processes within a given time, usually specified as messages or transactions per hour or second. It is a key metric in sizing because it determines the necessary CPU, memory, and other resources to handle the expected workload effectively.

Sizing with Business Throughput involves converting hourly throughput to messages per second to account for load distribution and peak times. SAP uses benchmarks like SAPS (SAP Application Performance Standard) to translate business throughput into hardware requirements.

In summary: Business Throughput quantifies the expected transactional load and is the foundation for planning the infrastructure capacity to ensure optimal SAP system performance and stability.

In our case, we calculate the SAP PI/PO Business Throughput, which measures the volume of messages or transactions processed by the Process Integration and Process Orchestration system within a defined timeframe. This calculation is essential for sizing the infrastructure to support the expected load and ensure optimal system performance.

1.1. Scope

The following components of the EIC will be considered for sizing:

Worker: Executes integration flows within the Integration Suite runtime, built on Apache Camel. Responsible for both synchronous and asynchronous message processing.
Policy Engine: Envoy-based runtime with SAP-specific extensions, enforces policies such as traffic management and security for API proxies.
PostgreSQL Database: Relational database system for storing structured metadata and logging data generated during integration scenarios.
Redis: In-memory data store used primarily for caching and storing operational data, including support for API traffic management policies.
Message Service: Implements asynchronous integration patterns using the JMS protocol and manages local event processing.

2. Required input factors

The following factor will be required:

Number of messages per second
Size of average payload
Complexity of Integration flow

Number of messages per second

When determining the number of messages per second for sizing purposes, it is important to clarify and standardize the assumptions:

The “number of messages per second” should refer to the maximum throughput during peak periods, not an average across the year.
Identify the peak time range (for example, analyze which month has the highest message volume). Subsequently, break down the peak month to the number of messages per second and consider the average payload size for that period.
When calculating, consider the following questions:

Should weekends be included in the calculation, or is message traffic significantly lower?
Should sizing be based on 24-hour operation, or does your existing PI/PO system operate during defined business hours only (e.g., 8 hours per day)?

This approach ensures that capacity is planned according to realistic worst-case load, which is recommended to guarantee stable system performance even during short-lasting throughput peaks

3. Delivered Messages statistics- Performance Monitoring

Crucial Assumption- Peak Period:

For the analysis and sizing calculation, message statistics tables were directly extracted from SAP PI/PO Performance Monitoring. The available week of message data was chosen as the reference peak period. Because only one week of message statistics was available at the time of analysis, all sizing calculations are based on this week—used here as the reference "peak period."

Going this approach because possible higher peaks is not yet accessible.

By using this, the system is planned to handle at least the highest observed workload, safeguarding against typical peak scenarios.

To make the evaluation as clear and practical as possible, the message data was systematically split into three tables:

An All Messages Statistics Table capturing all messages from the week, combining both synchronous (real-time) and asynchronous (delayed/queued) communications.
A Synchronous Messages Statistics Table including only real-time message exchanges, where instant system-to-system response is required.
An Asynchronous Message Statistics Table gathering messages processed without immediate answers, reflecting queued or scheduled processes.

For each of these datasets and every reviewed time interval, two main metrics are calculated:

Average payload size: Indicates the typical data volume per message, usually in kilobytes or megabytes.

Average number of messages per second: Shows the sustained rate at which the system processes messages.

By distinguishing between message types and quantifying peak load figures, the resource requirements for both synchronous and asynchronous scenarios can be more accurately determined.The ultimate goal is to ensure that system capacity meets actual business needs even during the busiest periods.

3.1. All Messages Statistics Table including Sync and Async-Complex

a.All Messages Statistics Table -Average payload size

b. All Messages Statistics Table - Message per second

3.2 Synchronous Statistics Messages Table

a. Synchronous Statistics Message Table - Average payload size

b. Synchronous Statistics Message Table - Message per second

3.3 Asynchronous Statistics Messages Table

a. Asynchronous Message Table - Average payload size

b. Asynchronous Message Table - Message per second

4. Sizing Approach for Worker (Complex Integration Flow)

For sizing the Worker component, all calculations are carried out using complex integration flows. Separating simple from complex flows in real-world systems is often very time-consuming and difficult because this distinction is usually not visible in the message logs.

Furthermore, experience and SAP guidelines show that the actual difference in sizing results between simple and complex flows is not significant. For simplicity and to avoid unnecessary complexity, we base all calculations on complex flows. This guarantees that the system is sufficiently dimensioned for any type of integration workload.

SAP Application Performance Standard (SAPS)

The actual sizing is performed using the SAP Application Performance Standard (SAPS).

For all worker-related calculations in this guide, the rule is applied that 1 CPU core equals roughly 1400 SAPS.

4.1. Synchronous - Complex Integration Flows

Input

Average Payload size for Synchronous -Complex Integration Flow: 12,50KB
Throughput = 0,0077 messages per seconds

Applying linear ratio for payload size

If your actual average payload size or message throughput differs from the values in the predefined table below—which lists CPU and memory requirements for specific throughput and payload sizes—you should use linear scaling to estimate the required resources.

Steps to apply linear scaling:

Identify the closest payload size in the reference table that is nearest to your actual average payload size.

This closest size is called the reference payload size.

Calculate the scaled message throughput using:
Round the scaled message throughput number to the nearest whole number.
Use the CPU, memory, and instance recommendations from the table for the reference payload size and this scaled message rate to size your system.

Determined results

12,5KB/100 * 0,0077= 0,00096 scaled messages per second

Correspond to the table below

CPU

2800 SAPS = 2CPU

// (reminder:1400 SAPS = 1CPU)

Memory

8GB

Number of instances

4.2. Asynchronous- Complex Integration Flows( Variant 2)

Input

Average Payload size for Asynchronous -Complex Integration Flow(Variant 2): 668,67KB
Throughput = 0,56 messages per seconds

Determined results

668,67KB/1024 * 0,56= 0,36 scaled messages per second for 1MB payload size

Correspond to the table above

CPU	2800 SAPS = 2CPU
Memory	8GB
Number of instances	1

5. Message Service Tier for Asynchronous Messages

For Message Service Tier selection, message throughput usually isn't the deciding factor—the number of required JMS queues and general storage are far more critical. You should carefully review your scenarios to determine how many queues you need, consider the asynchronous interface communications and pipeline concepts for Integration Suite.

Once you've selected a tier, you should test and validate if your throughput matches your selected message service tier.

Input

Average Payload size for asynchronous -Complex Integration Flow: 668,67KB
Throughput = 0,56 messages per seconds

668,67KB/1024 * 0,56= 0,36 scaled messages per second for 1MB payload size

For production setups, it is recommended to consider Message Service Tier 250 or higher.

Determined results

Correspond to the table above

CPU	2800 SAPS = 2CPU
Memory	6.5GiB
Persistent Volume	100 GiB

6. Policy Engine

Input

0,56 messages per seconds for asynchronous messages

Determined results

Correspond to the table above

CPU	1400SAPS = 1CPU
Persistent Volume	6.5GB
Number of instances	1

7. Database Sizing (PostgreSQL)

7.1. Storage

Input

Total messages for 1 week: 345,295 messages
Retention period: 30 days. Therefore, the number of messages per month is calculated as 345,295 * 4 = 1,381,180 messages.

Approximate disk space: 13.81 GB, rounded up to 15 GB.

Determined results

This calculation assumes message logging at the INFO level. TRACE-level logging or additional datastore usage could increase storage needs by ~50%.

Additional factors like MPL attachments, trace data, general overhead, datastore entries, and message store entries also consume storage.

For reliability, size for at least 32 GB -->>ideally 64 GB—a low-cost safeguard.

Disk Space (Volume)

64 GB

7.2. Compute Unit

Input

0,57 messages per seconds for all messages

Determined results

Correspond to the table above

CPU	1400 SAPS = 1CPU
Memory	2GB

8. Sizing for Redis

Input

Number of API Artifacts
Hence minimum setup will be chosen

Determined results

Minimum CPU / Memory requirements: 1 CPU / 1 GiB

CPU	350SAPS = round up =1CPU
Memory	0,75GB= round up = 1GiB

9. Sizing Output for EIC

Why do we start with the Non-HA Baseline? We start our calculation with the smallest standard configuration: the Non-High Availability (Non-HA) setup.

In our specific example, the existing PI/PO system has very low message traffic. Due to this low workload, we anticipate that the SAP Edge Integration Cell will not require extensive hardware resources.

At this step, we have not yet decided if the final SAP EIC will be an HA or Non-HA setup. Therefore, we use this minimum baseline as a starting point. Then, we add our specific calculated workload (the "Delta") to it.

Finally, after seeing the total requirements, we compare the results against the HA and Non-HA setups to make a final conclusion

9.1 Minimum Sizing Requirements for non-HA Setup

CPU/Memory- Total 10 CPU/32GIB
Persistent Volumes 101GiB

9.2 Intermediate Calculation of Sizing Requirements from PI/PO System

Component	CPU	Memory	Persist Volume	Instance
Worker	1.Synchron: 2 CPU 2. Asynchron:2CPU Total:4 CPU	1.Synchron: 8 GiB 2. Asynchron: 8 GiB Total= 16 GiB		2-> Worker Instance/pods
Message Service	2 CPU	6.5 GB	100 GB
Image Replication Service			1GB
Policy Engine	1 CPU	1GB		1
Monitoring (Optional)			20GB
Shared Storage: Java Heap Dumps + SNC library (SAPCRYPTOLIB) for RFC Adapter: (Optional)			50GB + 1GB = 51 GB
External Database/-store
PostgreSQL	1CPU	2 GB	64 GB
Redis	1 CPU	1 GB

9.3 Calculate the Delta and the Final Sizing Requirement

Component	CPU	Memory	Persist Volume	Instance
Rest of EIC Components	6CPU	27 GiB
Worker	1.Synchron: 2 CPU 2. Asynchron:2CPU Total:4 CPU	1.Synchron: 8 GiB 2. Asynchron: 8 GiB Total= 16 GiB		2
Message Service	2 CPU	6.5 GiB	100 GB
Image Replication Service			1GB
Policy Engine	1 CPU	1GiB		1
Monitoring (Optional)			20GB
Shared Storage: Java Heap Dumps + SNC library (SAPCRYPTOLIB) for RFC Adapter: (Optional)			50GB + 1GB = 51 GB
Total Cluster Sizing for EIC Components	13 CPU	50,5 GiB	Mandatory = 101 GB Optional= 71 GB	See Instance setting for each component

*External Database/-store Requirement*
PostgreSQL	1CPU	2 GB	64 GB
Redis	1 CPU	1 GB

9.4. Summary and Conclusion

The summary of the sizing results for SAP Edge Integration Cell is based on the final table of the document. The recommended sizing for the non-HA setup amounts to 13 CPU and 50.5 GiB of memory for all EIC components, with a mandatory storage requirement of at least 101 GB and optionally up to 71 GB more. For the external database/store components, PostgreSQL is specified with 1 CPU, 2 GB RAM, and 64 GB storage, and Redis with 1 CPU and 1 GB RAM. These total values are derived from summing the individual components and form the basis for technical infrastructure planning.

The calculation approach was based on real peak load data from one observed week, separating synchronous and asynchronous message types to assess their maximum resource requirements independently. By using these peak values, the sizing ensures the system capacity is designed to handle actual business throughput during the busiest periods, following SAP’s best-practice. The result shows that the calculated values are clearly above the minimum requirement for a non-HA system but do not reach the requirements for an HA setup (which would require at least 20 CPU, 64 GiB RAM, and 204 GiB storage)

Difference between HA and non-HA Setup

The non-HA sizing results for SAP Edge Integration Cell show that with 13 CPUs, 50.5 GiB RAM, and at least 101 GB of storage, the setup exceeds the minimum required for non-HA, but it is still below the requirements for a high-availability (HA) setup, which needs 20 CPUs, 64 GiB RAM, and 204 GB of storage. External datastores and optional components are not included in these figures.

A non-HA setup typically operates around 40 pods on one or two worker nodes. An HA setup runs approximately 80 to 90 pods and is designed to provide higher availability and failover capabilities, especially for the Message Service, which is primarily used for asynchronous scenarios and JMS queues. In non-HA, the Message Service runs as a single instance; in HA, it operates with two replicas and an additional monitoring pod so that if one instance fails, the other can take over, significantly reducing interruptions in JMS-based processing.

The Message Service is a critical component, as it manages asynchronous messages and internal system events. In a non-HA environment, this service exists as a single instance; if it fails, all integration flows using JMS queues fail during the downtime, while other integration flows without JMS are not affected. During this period, deployments and undeployments of artifacts on the EIC also fail, and new Message Processing Logs (MPLs) are no longer written to the database.

Once the Message Service in a non-HA environment is available again, all previously persisted messages remain and will be reprocessed, as long as the underlying persistence volume has not been deleted or replaced. However, if the EIC – including the Message Service – is uninstalled and reinstalled, all queues and messages within them will be lost, since the components are rebuilt from scratch.

An HA deployment runs at least two replicas of the Message Service along with a monitoring pod. This setup enables immediate failover: if one replica fails, the second takes over with minimal interruption, allowing JMS-based integration flows to continue with little or no downtime. Upscale activities on the Message Service will always result in a brief downtime, but in an HA setup this disruption is much shorter than when operating with a single instance in non-HA mode.

Key Aspect for Message Service :

What happens to messages if the Message Service fails in a non-HA setup?

For the duration of the downtime the following things will happen: All Integration Flows that use JMS Queues will fail, other IFlows are not affected. All (un-)deployments of artefacts onto EIC fail. No MPLs will be written to the DB anymore.

Are messages in the queue lost, and can they be processed again when the Message Service is restarted?

Once the Message Service is up again/has restarted all previously stored messages are retained and will get processed again as long as the underlying Persistent Volume has not been wiped out. If EIC has been uninstalled and re-installed again, the Message Service also gets deleted completely --> all queues and messages are lost.

How much downtime do we risk if we need to scale up the Message Service with only one instance in non-HA?

The upscale activity always causes a downtime (usually very short - less than a minute or a few minutes) - also in HA mode.

Additional Consideration:
- The Storage Class must be configured as Block Storage or iSCSI to ensure stable processing of the critical Message Service

HA setup for production

Based on the sizing analysis conducted, I recommend deploying a High Availability (HA) setup with 3 worker nodes for both DEV/TEST and PROD.

Although the HA setup requires higher resources (20 CPUs and 64 GiB RAM) compared to the calculated non-HA requirements (13 CPUs and 50.5 GiB RAM), the delta of 7 CPUs is negligible compared to the outage risks of a non-redundant infrastructure. Crucially, it is not possible to switch from Non-HA to HA without completely redeploying the Edge Integration Cell.

Furthermore, a consistent HA setup across DEV/TEST and PROD eliminates transport errors and guarantees system consistency across all landscapes.

Recommended HA Configuration:

3 Worker Nodes with a total of 20 CPUs and 64 GiB RAM
Message Service with 2 Replicas + Monitoring Pod for JMS High Availability
Block Storage or iSCSI for Persistent Volumes (204 GB)
PostgreSQL or HANA as an external database with HA replication
Starting directly with HA prevents future migrations and data loss

Master Blog: SAP Edge Integration Cell – The Hybrid Integration Journey

2025-12-16T14:09:27.490000+01:00

Overview of SAP Edge Integration Cell Master Blog – The Hybrid Integration Journey

Migrating to the SAP Integration Suite doesn't mean moving all your data to the public cloud. For sensitive "Ground-to-Ground" scenarios, you need a solution that keeps traffic strictly within your private landscape. This is where the SAP Edge Integration Cell (EIC) comes into play.

This Master Blog serves as your central guide for the SAP Edge Integration Cell journey—covering everything from initial planning and architecture to ongoing operations. Whether you are transitioning from SAP PI/PO or starting fresh, this series will guide you through every step.

Below you will find the collection of deep-dive articles, which will be constantly updated as we progress through the journey.

Series	Topic	Description	Link
01	Initial Sizing & HA/non-HA Planning	We start by laying the foundation. This post uses real-world PI/PO performance data to calculate the necessary infrastructure for the EIC. It also clarifies the critical differences and requirements between High Availability (HA) and Non-HA setups.	SAP Edge Integration Cell- Initial Sizing Approach and Planning for HA/Non-HA Setup
02	Coming soon...

Stay Tuned

This series is designed to be a "living document." Make sure to bookmark this page or subscribe to the blog to get notified when the next parts of the series are published.

Do you have specific questions about the Edge Integration Cell that you would like to see covered in upcoming posts? Let me know in the comments!

The Curious Case of SAP Community Moderation: A Study in Arbitrary Excellence

2026-01-08T14:39:45.568000+01:00

The Curious Case of SAP Community Moderation: A Study in Arbitrary Excellence

There's something almost admirable about a system so perfectly calibrated to frustrate its most dedicated contributors. SAP Community's moderation team has achieved what few organisations dare to attempt: the complete democratisation of confusion.

The Algorithm Knows Best

Picture this: you've spent hours crafting a technical blog post. You hit publish. Within moments, the machine learning system — trained, presumably, by a committee of caffeinated squirrels — determines your carefully researched content is indistinguishable from Nigerian prince correspondence. Welcome to spam jail.

But fear not! The moderators check the filter "regularly." Your content will resurface within 24 business hours. Or minutes. Or perhaps never. The timeline, much like the moderation logic itself, remains charmingly mysterious.

A Tale of Two Blogs

Here's where it gets genuinely fascinating.

A blog post about shell command execution in SAP CPI —

https://community.sap.com/t5/integration-blog-posts/getting-unconventional-with-groovy-part-1-executing-shell-commands-reading/ba-p/14294407#M2049

one that, by the author's own assessment, "doesn't reveal 10% of what already existing articles reveal" — gets nuked from orbit.

Meanwhile, this gem about terminal access to CPI runtime

https://community.sap.com/t5/technology-blog-posts-by-members/terminal-access-to-cpi-runtime-execution-of-shell-commands-on-cpi-runtime/ba-p/13460198

has been sunbathing peacefully on the platform for five years. Five. Years.

And what about this post detailing PGP secret keyring handling

https://community.sap.com/t5/technology-blog-posts-by-members/pgp-secret-keyring-in-cpi-the-lost-passphrase-recovery/ba-p/13491284

? If we're genuinely concerned about security implications, one might think exposing cryptographic key management deserves more scrutiny than reading a file via shell script. But no. That one's fine. Perfectly fine.

The logic? There isn't any. Or if there is, it's locked in a vault somewhere, guarded by the same people who decided "Moderator 972001" was an appropriately human identifier.

The Silence Says Everything

When these inconsistencies are raised — politely at first, then with understandable frustration — the response is instructive in its absence.

No explanation. No acknowledgment. No "we'll look into it."

Just the digital equivalent of being shown the door while someone pretends to be very busy with paperwork.

As one contributor put it: "Is there no accountability left?"

The answer, delivered through elegant silence, appears to be: correct.

Transparency? Never Heard of Her

The moderation team operates with the transparency of a brick wall painted black and placed in a basement with no stairs. Decisions materialise from the void. Appeals dissolve into it.

"Moderator 972001" — a designation that radiates all the warmth and humanity of a tax audit — can apparently remove two blogs in three days from the same contributor without so much as a form letter explaining why.

One might ask: is this moderator a real person? A bot? A random number generator with delete privileges?

The community may never know. And that, apparently, is by design.

The God Complex, Quantified

There's a specific institutional pathology at play here. It's the quiet arrogance of systems that punish engagement, reward silence, and treat questions about their own behaviour as an inconvenience.

When contributors ask "Are the moderators operating in good faith?" — a reasonable question given the evidence — the absence of any response tells you everything.

In Conclusion

The SAP Community moderation team has built something remarkable: a platform where the most knowledgeable contributors are rewarded with suspicion, inconsistency, and bureaucratic indifference.

One needn't resort to profanity to describe them. Their work speaks eloquently enough.

A-Z Performance Testing for integrations... And why?

2026-01-09T22:39:41.453000+01:00

A system is as strong as its weakest link – this is a well-known fact.

In the integration domain we connect applications and data, in an integrated system capable to seamlessly perform business processes within different connected applications without interruption and human in the loop (popular wording in the age of AI) action. Of course, this is not an official definition – and there could be many of those (definitions), more-or-less formal.

The important thing is to understand that integrated system of applications will connect many applications and various data flows, usually using various middleware IT components.

Why Performance Testing for integrations?

We do run Unit Testing, Functional Testing or System Integration Testing on our applications or our connected applications – but is this enough?

For the new application, it is just not enough to test only if it fulfils functional requirements – the same way, for an integrated system, with several applications and one or more middleware IT component, it is not enough to test only if the integration works. We need to understand if our application or integrated system can meet specific non-functional requirements. Can it perform? And what are the limits it can sustain?

Yes, I am talking about Performance Testing, Load Testing, Stress Testing and more…

We do those things with applications, but are we following the same route with integrations and integrated systems?

We should…

But let me go first through some general intro – what are the different types of Performance Testing and what are the appropriate Testing Methodology to apply – disregarding if we talk about testing of individual applications, or integrated systems with middleware flows.

Types of Performance Testing

I am not going to go with definitions what is Unit Testing, Functional Testing or System Integration Testing, let me focus only on the family of Performance Testing.

While there are many definitions how to split Performance Testing to several distinct types[1][2][3[4], I will stick to my usual habits and stay with the traditional one from IBM[5].

Load Testing indicates how the system performs when operating with normal and expected loads. We are taking into consideration average numbers of concurrent users, with average system load (operations performed) – i.e. average number of concurrent users placing an order of the average size (number of items).
Scalability Testing is more than Load Testing and less than Stress Testing, as we want to test how the system performs when scaling to the boundary conditions, either current or expected – i.e. peek number of concurrent users (in the peek season, peek hours) placing large orders (number of items).
Spike Testing is creating very sudden increase of users traffic creating shape spikes in system actions – i.e. there is a sudden burst of orders coming by synchronizing offline devices; or more commonly could be caused by sudden restoration of the stopped service now sending huge number or orders at once.
Volume Testing differed from Spike Testing as its focus is on increase of data volumes primarily, and how the system will manage the increased incoming data volumes – i.e. load of large payloads (like orders with extensive number of items) into database tables of queues etc.
Endurance (or Soak) Testing differs from both Spike Testing and Volume Testing as we are not only testing the increase of traffic or data volumes, but rather how the system will manage load throughout longer period, and will there be any degradations in service – i.e. continues load of incoming payloads within several hours or more.
Stress Testing is pushing the system beyond its operational limits, finding its breaking point, understanding the weakest link (where it will break first) – i.e. for order taking incrementally increase the load in number of concurrent users and order size, until system “breaks”.

On top of these testing types, worth mentioning, as part of Stress Testing, we also perform Reliability Testing as well, verifying how the system will recover from the “break” situation – i.e. if the specific service goes down, we do not want to lose any messages in between.

Methodology

Testing methodology depends on the overall development approach, but the most common approaches are:

Waterfall follows sequential testing which occurs after full development.
Agile practice Iterative testing of small parts within sprints.
V-Model stands for Verification & Validation, where testing is linked to development phases.
Spiral combines best-of-both; Waterfall and Agile, making it ideal for large and complex projects; testing is risk-driven and it is integrated into each iterative cycle (spiral)[6].

However, no matter with development approach we practice, key testing goals always stay the same:

Ensure solution meets functional requirements.
Make sure solution also meets non-functional requirements like, overall quality, performance, and security.

Now, I have deliberately avoided saying –only functional requirements are business requirements. In fact, non-functional requirements for performance can very often be very much business relevant, as business can set same clear business driven SLAs.

SLA (Service Level Agreement) is a formal, often contractual promise of service quality, defining what is guaranteed level of service.
KPI (Key Performance Indicator) is an internal measurement of how well SLA goals are met. These measurements are usually very operational.

SLA examples	KPI examples
4s average response time	Last month we achieved 4.87s average response time
99% of orders must be received and processes within 8s	Last quarter we had 97.4% orders processes within 8s
1 000 000 orders per day without degradation of service	Yesterday we have processed 1 002 158 orders, where all SLAs are kept
…	…

What does this tell us?

By clearly understanding SLAs, we can define appropriate Performance Testing measurements (and scripts), something we want to test and what is the level of service we need to achieve with our new application or integrated system.

Please note, focus here is on Performance Testing, so I am not addressing other non-functional requirements, although we may apply similar approach for them as well (bur the actual testing or verification may be significantly different).

Doing it right…

Requirements Gathering & Planning:

For the Performance Testing in integration (or in general), the first step is, of course, gathering all non-functional requirements like SLAs indicating i.e. response time, error rate etc. This is the moment to collect all

defined SLAs
Volumes (i.e. hourly, daily etc.) including expected growth
Business patterns (i.e. patterns or spikes during business hours, or during season)
Systems under test (i.e. what are the systems, or integration flows or IT components which are under test?)
Users or user groups (i.e. integrations are usually built using technical users, but let this be re-confirmed)

Test Design

What do we test?

Let’s have one thing clear – when testing integration, we are testing inbound and outbound, complex multi system flows and respective endpoints of the Provider and Consumer(s). But we are not testing the actual business process within Provider and Consumer(s)– this should be covered by relevant application testing.

What types of testing?

Let us plan what types of Performance Testing we need to execute (Load Testing, Scalability Testing, Spike Testing, Volume Testing, Endurance (or Soak) Testing and/or Stress Testing) and create realistic workload models.

In realistic terms, for integrations, we may stick with only few types of testing, combining necessary testing requirements:

Load Testing based on specific SLAs.
Scalability Testing but combined with Spike Testing, Volume Testing and Endurance (or Soak) Testing (with increased user loads and data volumes, running for a reasonably longer period – i.e. 50% load more than maximum expected.
Stress Testing but also covering Reliability Testing (to understand the limits and recovery process)

What kind of integration are we testing?

There is a difference if we are testing Sync API or flow or Async API or flow[7][8].

Figure 1. Sync vs. Async

All clear, but how does this impact on our Test Design for the Performance Testing? Let's dig deeper...

Figure 2. Example of Sync flow with SAP Integration Suite (CPI and API-M)

Sync Integration Execution is a single thread – only one operation will run at a time.

Sync means Sync Request-Reply pattern. As long as Sender is waiting for a response from the Receiver (either directly or indirectly) to finalize specific operations, this is considered as Sync processing. We may even have in between some queueing with retry logic (i.e. within SAP Integration Suite CPI flow), but if Sender is waiting for the final response, this is still Sync processing.

When testing Sync API or flow i.e. RESTful API or OData API, no matter if we have some CPI flow or API-M in between – testing tool (i.e. JMeter) can immediately get appropriate response, either success (i.e. http200) or some error (i.e. http4xx. htt5xx).

While we may collect additional logging from the Receiver and the middleware IT component(s), this would be more relevant from the perspective of monitory and observability, not Performance Testing itself.

Figure 3. Example of Async flow with SAP Advanced Event Mesh

Async Integration Execution is multi-thread – multiple operation can run in parallel.

Async means decouples, and it may be PubSub pattern, or Async Request-Reply pattern. Here situation is a bit more complex, as we need to collect and compare relevant logs.

In PubSub pattern, individual IT components may or may not be set to send appropriate responses or acknowledgements (http, ACK/NACK, QoS) but those responses or acknowledgements are not (by default) propagated from the Receiver(s) back to the Sender – if set, response and acknowledgement is only an information if the next component in the flow have received the messages.

With Async Request-Reply pattern, Receiver will send backward a separate response message, for the received messages. However, this message is also sent as Async API, usually after some processing is being done in the Receiver system. Implementation of the Async Request-Reply pattern is a separate topic not covered in this article – but in general it can be completely separate Async flow, or it could be build using correlation IDs (i.e. using SAP Advanced Event Mesh and CPI[9], or Solace PubSub+ SolClient Asynchronous Callbacks[10]).

In both Async patterns:

When testing Async API or flow i.e. Event API – the actual success or error can be seen only in the Receiver system log, on which testing tool (i.e. JMeter) may not have direct access.
If we have also Async return flow, depending on the SLA set, we may have to measure success rate and response time etc. for the full round cycle.
Async response messages will carry either confirmation or error message back to the Sender. While error message is not an integration performance issue, the SLA may still require we measure those errors as well.

Again, we may collect additional logging from the middleware IT component(s), but this would be more relevant from the perspective of monitory and observability, not Performance Testing itself.

What is the scope?

Do we test only inbound flow and Receiver endpoint, or do we need to emulate specific processes and actions in the Sender application as well?

Figure 4. What is the scope of testing, what do we script?

Ordinarily we measure performance for inbound flow and endpoint or the Receiver. If the Receiver application is also a Provider, this gives us also the Baseline Performance of the specific Integration Service.

Our primary concern is to understand how the Receiver (no matter if it is Provider or Consumer) can perform – i.e. how many new/modified order requests SAP S/4HANA can handle; or how many new/modified customers being replicated SAP Commerce Cloud can handle.
Secondary goal is to understand how the middleware IT components in front of the Receiver are performing – i.e. API-M including all policies, or CPI flow including value mappings, or Advanced Event Mesh including microservices etc.

However, if we are introducing new Sender application, SLAs may request we perform Performance Testing on the full process starting from the Sender application.

We need to script within the Sender application, appropriate actions invoking APIs, and measure full response from the moment action is invoked, until specific results of the operations are recorded – i.e. order has be placed in SAP Commerce Cloud , API invoked toward SAP S/4HANA, response received, status saved and/or visualized (where in this example, SAP Commerce Cloud would not normally save order, but only visualize the status). .

Do we test all Consumers at once, or we break the flows?

Let’s also understand, depending on the specific integration flow:

Provider can be either Receiver (inbound endpoint receiving message) or Sender (outbound endpoint sending message).
The same way, Consumer can be either Receiver (inbound endpoint receiving message) or Sender (outbound endpoint sending message)
Finally, in each integration flow there is only one Provider, and there can be one or more Consumer(s).

The question is, in case of multiple Consumers as Receivers, do we test them all at once?

Figure 5. Test each Receiver separately

The recommended approach is to test separately for each Receiver. This would give us clear picture of the boundaries for each individual Receiver system.

But can we still have multiple Providers?

Yes and no… In fact, it is possible to have different technical backend systems providing specific Integration Service – i.e. for order taking, we can have two or more SAP S/4HANA backed systems, each servicing different countries or regions, where routing is done in CPI or API-M; but if this is the same Integration Services provided by the same application (even though there are two or more technical systems behind) – in this case, we will consider SAP S/4HANA as one Provider for the order taking Integration Service.

Payloads

We need sample payloads, but we also need to ensure all necessary Master Data and Organizational Data exists and is appropriately configured – i.e. if we are creating orders we need to have existing SoldToParty, Product, OrdeType, SalesOrganization, PricingCondition (or Promo) etc.

But it’s not only payload itself, we also need to understand if we need to set specific attributes with API call (i.e. within http header). This also needs to be defined upfront.

In some cases, some attributes (i.e. in the http body) are triggered specific processing in the Receiver application – for order taking OrderType can invoke different standard/custom functional modules/processing in SAP S/4HANA. All these needs to be defined upfront.

Environment Setup

Most of the test environments are not sized as productive environments and for i.e. Functional Testing this is perfectly fine, but for Performance Testing this may give considerably wrong picture. General recommendation is to run Performance Testing in the test environment (or QA environment) that closely mirrors production, including all IT components and software versions.

How do we do this?

This all depends on the applications and IT components we need to configure. In some cases, it might be rather easy, while in some cases, it might be more challenging. For SAP Integration Suite (CPI or API-M), very common scenario is to have separate tenants but with the same/comparable configuration. For Azure Integration Services (i.e. Service Bus, Functions), it is fairly easy to temporarily change the licensing model of the test environment/subscription and assign it the same power as the productive environment/subscription. Similar is for most SaaS applications is general – it’s all about temporarily configuring the subscription, and if we keep the time window for Performance Testing rather narrow, this will not significantly increase the subscription costs.

But in some cases, this may not be so simple. In case of SAP Advanced Event Mesh, it all depends on the deployment strategy of the broker:

If we use the same tenant for both non-productive (test) and productive environments (separated by i.e. Application Domains hosting productive and non-productive Applications, retrospectively), then no action is needed for conducting Performance Testing, since test and productive environment are the same.
If we use separate tenants for test and productive environment with the same T-shirt size (ideal, but more expensive deployment approach), then again, no issue to proceed with Performance Testing,
If we use separate tenants for test and productive environment but with different T-shirt sizes (more common scenario) we can temporarily deploy non-productive Event flow in the productive environment but connect it temporarily to the test Applications (Publisher/Subscriber) endpoints. Word of caution here thought – if we use SAP Event Add-on (i.e. on our SAP S/4HANA test and production environment) please make sure you follow specific licensing guidelines to understand in which scenarios it may impact the licensing costs (pls check this article from @KStrothmann[11]).
Finally, if we do use separate tenants for test and productive environment, but with different T-shirt sizes, and we do not want to do any temporary deployments in the production environment – it is always possible to temporarily change T-shirt size of our test environment to match the productive environment. Here we should be very careful if it impacts some micro integrations we have, especially during downgrading back after test is done.

While for most of IPaaS or SaaS applications and IT components there is a way to (at last) temporarily configure test environment to match the productive one, in some cases it might simply not be feasible – especially for on-prem system deployments.

What do we do?

There is no golden rule – but there are some workarounds steps we could do.

#	Step	Example
1.	Measure system performance	Let’s measure performance of similar services in the test and productive environments – i.e. for SAP environment use Workload Monitor ST03/ST03N for measuring the response time distribution for various task types (like dialog, background).
2.	Measure program runtime performance (optional)	Optionally, run detailed analysis of specific programs – i.e. for SAP environment use Runtime Analysis (SE30/SAT) for ABAP programs to measure execution time of individual statements, function modules, and database calls.
3.	Measure database performance (optional)	Optionally, run trace on specific performance-related SQL activities – i.e. in SAP environment use Performance Analysis (ST05) to measure where is what time spent on which activities.
4.	Calculate productive vs test environment processing power	Use all measurements to calculate realistic processing power of your test and production environment – i.e. Workload Monitor, Runtime Analysis and Performance Analysis will give some different values showing that productive system is faster. Example: Workload Monitor response time in productive environment is 1.4 faster than in test; Runtime Analysis program executes in productive environment 1.6 faster than in test; Performance Analysis database operation performs in productive environment 1.1 faster than in test; Extrapolate using weight factors (this is just an example): 0.61.4+0.21.6+0.2*1.1=1.38; Final calculation says productive environment is 1.38 times more performant than test environment.
5.	Extrapolate and adjust test results on the test environment	Extrapolate all Performance Testing results obtained on the test environment with calculated factors. Example: If an average response time on the specific S/4HANA hosted Integration Service is 4s in the test environment, we expect it will be more 1.38 times more performant in the productive environment, or expected average response time in the productive environment is 2.9s

Script Development

Now we need to start using specific testing tools like JMeter, Azure Load Testing (also using JMeter scripts) or LoadRunner. Goal is to create scripts to simulate specific actions and interactions which we want to test.

Let’s go through inputs we have collected:

#	Input	Example
1.	SLAs	For the order taking API: Average order response time is up to 4s; 99% of orders are created up to 8s; This is valid for any Customer, any SalesOrganization, default OrderType, standard on-invoice PricingCondition;
2.	Volumes	Annual average 160 000 orders per working day; Maximum (peek) season 270 000 orders per working day; Expected annual growth 10%; Average order has 10 items, where orders normally do not contain more than 50 items;
3.	Business patterns	80% or orders are created doing extended working hours from 10:00-22:00, out of which half is created in the evening 19:00-21:00
4.	Systems under test	S/4HANA API_SALES_ORDER_SRV Sales Order (A2X), single cluster, no policy routing; API-M SalesOrder with policies, excluding CSRF token;
5.	Users	No business user. testing integration only,

Based on inputs we will build appropriate Load Testing script:

#	Script	Example
1.	Target Test Results	Response time percentile 50 should be below 4s; Response time percentile 99 should be below 8s;
2.	Capturing Test Results	Catch the information about sent messages from the Sender side (i.e. testing tool): number of messages sent, start time (sending) and stop time (sending); In case of Async API, catch the overall status on the Receiver system logs on successfully received/processed: number of messages received, overall timing from start to end, and catch response status as well if response/acknowledgement is enabled;
3.	Number of Threads	We count for maximum daily volume + 5 years growth + 50% margin: 270 0001.11.11.11.11.11.5 = 652 257 orders per peek day; But this volume is not evenly distributed through 24h, 40% is in 2h only: 652 257*0.4 / 2 = 130 451 orders in peek hour; Or this is 130 451 / 3600 = 36 orders per second; As we have already included safety margin, we are okay to set: Number of Threads = 36;
4.	Rump-up period	We can use 4s as this is desired average response time, but we will use default 1s for all tests;
5.	Loop Count	For Load Testing there is no need to loop payloads more than 20-50 times;
6.	Payloads	Create payloads: ideally using different Customer(s), ideally covering all (or majority) of SalesOrganization(s), where each will use default OrderType, where each will use only standard PricingCondition(s); Distribute number of items in payloads: 80% average or around average number i.e. 10 items, 5% lower boundaries i.e. between 1-5 items, 10% upper boundaries i.e. between 15-35 items, 5% upper extreme i.e. between 40-50 items; In total we may have 20-50 payloads or more;
7.	Endpoint	API-M SalesOrder endpoint
7.	Users	No business user; JMeter will authenticate and obtain key as a client application, through VPN tunnel;

How does this look like in practice, and what does this mean?

Figure 6. JMeter configuration example

In this example, I use JMeter[12] as a testing tool of choice:

Number of Threads simulates number of concurrent users or concurrent requests at the same time. Obviously, the higher the number, the bigger the load/spike is.
Rump-up period simulates how often we send next batch of requests. Default value of 1s is already very high.
Loop Count will randomly take payloads we have prepared and loop them indicated number of times. Obviously, the higher the number, the longer the soak is.
Payloads are sample messages, and generally they will never be the same. Depending on the specific API and business process, but in most of the cases, the bigger is the payloads (more items, or more segments), the higher the data volume is.

So, for combined Scalability Testing, we may adjust the script and just increase Number of Threads (to simulate spikes), increase percentage of payloads with extreme number of items (to simulate data volumes), and increase Loop Count (to simulate soak).

However, for combined Stress Testing we should gradually increase Number of Threads, while keeping all parameters steady (as in Load Testing) – to see when it breaks (errors, what kind of errors). The second test would be to gradually increase number of items in the payload, while keeping all other parameters steady (as in Load Testing) – to see when it breaks (errors, what kind of errors). Further investigation on errors and system behavior is needed to verify integration reliability, but this will depend very much on the specific integration flow – i.e. Async flows should normally be decoupled with queues and built-in retry resilience, while Sync flow normally receive error response and application/user decide next action

Test Execution

We have designed and created scripts for Load Testing, combined Scalability Testing and combined Stress Testing.

As we are simulating real time scenarios, tests should be performed following realistic conditions:

#	Condition	Example
1.	Applications	No other users should execute the same integration flow which is under test; All other (background) jobs and operations should stay as-is (keep it normal as-is);
2.	IT components	No other users should execute the same integration flow which is under test; All other (background) jobs and operations should stay as-is (keep it normal as-is)
3.	Execution timetable	Tests should respect the business pattern of operations. Why? Because during different days or different hours within the day there might be other (background) jobs or operations impacting overall system performance, and we want to simulate all operations as realistic as possible. We have three distinct business patterns, and we should run all tests during each business pattern: Business day, non-working hours 22:00 -10:00 next morning, Business day, normal working hours 10:00-19:00 or 21:00-22:00, Business day, peek working hours 19:00-21:00;

Test Results

After execution of all tests, we have to conduct appropriate evaluation of results:

#	Evaluation	Example
1.	Load Testing	As per SLAs evaluate actual percentile 50 and 99 for all Test Executions we did (and we have at least 3 runs, one for each business pattern);
2.	Scalability Testing	Analyze percentile 50 and 99 for all Test Executions we did (and there could be many runs); The observations will be used to define the behavior pattern of the overall integration flow i.e.: if we increase Number of Threads 100%, response time will increase 40%, if we orders size for 50%, response time will increase 30%, if we soak for 2h, aggregated response time will increase 10%
3.	Stress Testing	Monitor Test Executions we did (and there could be many runs); This will help us define the behavior pattern of the overall integration flow; The observations will be used to define the boundaries of the integration flow i.e.: system cannot sustain more than 1000 concurrent requests of average size, or system cannot sustain more than 150 items in the order;

For percentiles, we can use aggregated Test Results report.

Figure 7. Percentiles example

This example graph shows that average response time, or percentile 50, is around 3s, while percentile 99 is around 4.7s.

JMeter may provide number of possibilities to calculate percentiles form the aggregate reports, or we may simply go for some of the add-on graph reports and include it in the Test Plan[13].

Next steps…

Remediations?

Of course, most likely your first round of Performance Testing will not provide fully satisfactory results. The next steps are mostly in identifying what optimization potentials there are, work on it, and then re-run the tests. The good this is – all the scripts are already there, so there is no need to re-do all from scratch.

However, if (due to whatever reason) SLAs are re-negotiated and changed – in that case, scripts will also have to be adjusted.

Conclusions

Why am I writing this article?

While most of the Project Management and Test Management routines are very much highly regulated, project teams might be (often?) facing lack of some specific guidelines how to test integrations, especially its performance – as integrations are, lets be honest, rather specific area…

Well, this is at least my view…

In this article, I have used examples with SAP S/4HANA, SAP Integration Suite (CPI and API-M), SAP Advanced Event Mesh and JMeter – but principles are basically the same, no matter if we use SAP or non-SAP applications and IT component.

Anyway, as already indicated – there is no golden rule – this is just one possible approach to organize our Performance Testing for integration. Of course, this is not a rule book, and things should be adjusted to the specific needs. As always, this is just a potential guideline – nothing is carved in stone…

Acknowledgment

*) Intro photo by Adi Goldstein on Unsplash

**) This article uses SAP Business Technology Platform Solution Diagrams & Icons as per SAP Terms of Use governing the use of these SAP Materials (please note, newer version of the Solution Diagrams & Icons, as well as Terms of Use, might be in place after the publication of this article).

More guidelines on Solution Diagrams & Icons can be found in this article by Bertram Ganz.

References

[1] Queue IT: https://queue-it.com/blog/types-of-performance-testing/

[2] Microsoft Learn: https://microsoft.github.io/code-with-engineering-playbook/automated-testing/performance-testing/

[3 Microsoft Learn: https://learn.microsoft.com/en-us/azure/well-architected/performance-efficiency/performance-test

[4] JMeter: https://www.f22labs.com/blogs/mastering-performance-testing-with-jmeter-a-comprehensive-guide/

[5] IBM: https://www.ibm.com/think/topics/performance-testing

[6] Spiral model: https://en.wikipedia.org/wiki/Spiral_model

[7] How to build an Integration Architecture for the Intelligent Enterprise: Part 1

[8] How to build an Integration Architecture for the Intelligent Enterprise: Part 2

[9] SAP AEM Async Request-Reply: https://community.sap.com/t5/technology-blog-posts-by-members/implement-request-reply-integration-pattern-with-sap-advanced-event-mesh-in/ba-p/14074836

[10] Solace PubSub+ Async Request-Reply: https://tutorials.solace.dev/c/request-reply/

[11] SAP Event Add-on: https://community.sap.com/t5/technology-blog-posts-by-sap/cheaper-than-you-think-the-commercial-model-of-the-event-add-on-for-erp/ba-p/14265748

[12] Apache JMeter: https://jmeter.apache.org/

[13] Apache JMeter Test Plan: https://jmeter.apache.org/usermanual/build-test-plan.html

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

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

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

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

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

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

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

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

IDOCs Meet the Advanced Event Mesh (AEM)

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

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

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

The Testing Challenge: Scalability and Realism

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

The Traditional Approach: WE19

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

Figure 1 - We19 for outbound processing

The Limitations:

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

Enterprise-Scale Simulation with Int4 Suite

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

A) Simulating Incoming to Trigger Outgoing

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

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

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

Figure 2 - IDOCs as outbound from simulating incoming documents

B) Triggering via Message Control (NACE/NAST)

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

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

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

C) AI-Driven Simulation and WE19

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

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

Validating SAP AEM Flows

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

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

Watch it in Action

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

Watch: SAP AEM Testing with Int4 Suite

Summary and Next Steps

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

Want to learn more?

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

How SAP S/4HANA Migration Is Shifting from IT Projects to Business Transformation

2026-01-19T23:08:44.562000+01:00

Introduction

SAP S/4HANA migration is no longer just about moving from ECC to a new system. Organizations that treat it as an IT-only initiative often face cost overruns, data issues, and poor user adoption. Successful programs recognize S/4HANA as a foundation for long-term business agility.

Why S/4HANA Migration Is More Than a Technical Upgrade

Modern enterprises operate in complex ecosystems where SAP is deeply integrated with finance, procurement, logistics, analytics, and external applications. Any change to SAP impacts:

End-to-end business processes
Reporting and compliance
Data governance and master data quality
User experience and productivity

Ignoring these factors increases risk and delays value realization.

Key Business Areas Impacted

Finance & Controlling
Universal Journal (ACDOCA) simplifies reporting but requires process redesign and data cleanup.
Data Quality & Governance
Poor master data (vendors, customers, materials) creates migration issues and post-go-live disruptions.
Process Standardization
S/4HANA encourages clean core and best practices, pushing organizations to reduce custom code and manual workarounds.
Change Management & Adoption
Fiori UX changes how users interact with SAP, making training and communication critical.

Choosing the Right Migration Approach

There is no one-size-fits-all strategy. Organizations must evaluate:

Greenfield vs Brownfield vs Selective Data Transition
Business readiness and technical debt
Timeline, budget, and risk appetite

Early assessment and stakeholder alignment are key to making the right choice.

Conclusion

A successful SAP S/4HANA migration is a business-led transformation supported by technology—not the other way around. Companies that invest in data quality, process clarity, and change management unlock faster ROI and long-term resilience.

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

Part 2: Lean (approach) for the integration flow(s) Performance Testing

2026-02-08T14:00:46.912000+01:00

In my previous article (A-Z Performance Testing for integrations... And why?)[1] I’ve tried to provide a comprehensive guardrail for the Performance Testing of the integration flows we are designing, and building…

But no matter what my wish is – the project teams will be often pushed to simplify things a bit, to make it faster, even if there are some trade-offs in quality (although nobody will admit this).

In this article, let’s see an approach with only two test-runs per integration flow.

Lean approach – pragmatic approach?

I won’t go through all the definitions of the various types of Performance Testing, or Testing Methodology etc. All is already covered in my previous article.

Requirements Gathering & Planning

Yes, we still have to undergo the collection of requirements and inputs:

SLAs
Volumes (i.e. hourly, daily etc.) including expected growth
Business patterns (i.e. patterns or spikes during business hours, or during season)
Systems under test (i.e. what are the systems, or integration flows or IT components which are under test?)
Users or user groups (i.e. integrations are usually built using technical users, but let this be re-confirmed)

Test Design

Again, next step is actual design, not too many shortcuts here either, as we still need to understand, but we may simplify it a bit:

What do we test – we are testing integration flows now application functionalities;
What types of Performance Testing – let’s focus on Load Testing and simplified Scalability Testing only;
What kind of integrations are we testing – Sync or Async make difference, so this information is needed in all cases;
What is the scope – ideally, let’s focus first on Receiver endpoint and common (reusable part) of the middleware IT components; if needed, testing any Sender functions will come at the next iteration;
Do we test all Consumers at once – no, as already recommended, we do one Consumer at the time;
Payloads – we definitely need them in all cases.

Environment Setup

Try to have test environment (or QA environment) that closely mirrors production, including all IT components and software versions. If not possible – okay, just make assumptions “how much faster/slower” test environment vs. productive environment is. This may be educated guess based on some other relevant markers, if existing.

Script Development

Here we can make some real simplifications.

We will use same inputs as in previous article:

#	Input	Example
1.	SLAs	For the order taking API: Average order response time is up to 4s; 99% of orders are created up to 8s; This is valid for any Customer, any SalesOrganization, default OrderType, standard on-invoice PricingCondition;
2.	Volumes	Annual average 160 000 orders per working day; Maximum (peek) season 270 000 orders per working day; Expected annual growth 10%; Average order has 10 items, where orders normally do not contain more than 50 items;
3.	Business patterns	80% or orders are created doing extended working hours from 10:00-22:00, out of which half is created in the evening 19:00-21:00
4.	Systems under test	S/4HANA API_SALES_ORDER_SRV Sales Order (A2X), single cluster, no policy routing; API-M SalesOrder with policies, excluding CSRF token;
5.	Users	No business user. testing integration only,

Based on these inputs we will build appropriate Load Testing script, no major changes compared to previous article (except in payloads):

#	Script	Example
1.	Target Test Results	Response time percentile 50 should be below 4s; Response time percentile 99 should be below 8s;
2.	Capturing Test Results	Catch the information about sent messages from the Sender side (i.e. testing tool): number of messages sent, start time (sending) and stop time (sending); In case of Async API, catch the overall status on the Receiver system logs on successfully received/processed: number of messages received, overall timing from start to end, and catch response status as well if response/acknowledgement is enabled;
3.	Number of Threads	We count for maximum daily volume + 5 years growth + 50% margin: 270 0001.11.11.11.11.11.5 = 652 257 orders per peek day; But this volume is not evenly distributed through 24k, 40% is in 2h only: 652 257*0.4 / 2 = 130 451 orders in peek hour; Or this is 130 451 / 3600 = 36 orders per second; As we have already included safety margin, we are okay to set: Number of Threads = 36;
4.	Rump-up period	Always use default 1s for all tests;
5.	Loop Count	For Load Testing there is no need to loop payloads more than 20-50 times;
6.	Payloads	Create payloads: (simplification) using one representative Customer(s), (simplification) using one or max few representative SalesOrganization(s), where each will use default OrderType, where each will use only standard PricingCondition(s); (simplification) make only up to 10 payloads: 8 payloads with average number i.e. 10 items, 1 payload with lower boundaries i.e. 3 items, 1 payload with upper boundaries i.e. 30 items,
7.	Endpoint	API-M SalesOrder endpoint
7.	Users	No business user; JMeter will authenticate and obtain key as a client application, through VPN tunnel;

We will not conduct real Scalability Testing or Stress Testing – but we can conduct something in-between, but let’s still call it Scalability Testing. Script would be based on the previously developed for the Load Testing, with only two minor modifications:

Increase Number of Threads two or three times i.e. 72;
Increase payloads to the extreme limit i.e. all 10 payloads will have 50 items.

Test Execution

We are simulating real time scenarios, but we are also trying to simplify overall execution as well. We will have only two tests each will run only once:

#	Condition	Example
1.	Applications	No other users should execute the same integration flow which is under test; All other (background) jobs and operations should stay as-is (keep it normal as-is);
2.	IT components	No other users should execute the same integration flow which is under test; All other (background) jobs and operations should stay as-is (keep it normal as-is)
3.	Execution timetable	Conduct both simplified Load Testing and Stress Testing only on the peak hours period, as for SLA this one only really matters… Why? Explanations is the same as before – because during different days or different hours within the day there might be other (background) jobs or operations impacting overall system performance, and we want to simulate all operations as realistic as possible. We have only one test-run: Business day, peek working hours 19:00-21:00;

Test Results

Now there are only two test-runs we did:

#	Evaluation	Example
1.	Load Testing	As per SLAs evaluate actual percentile 50 and 99 for the Test Execution we did
2.	Scalability Testing	Observe percentile 50 and 99 for the Test Execution we did. If we pass without errors, but response time comparable with SLA, we can conclude – test has passed.

Conclusions

Why simplified Performance Testing? If we need to do it right, why should we compromise?

It’s about being pragmatic. Whether we like it or not, delivery teams are under pressure, and full-blown testing should be still conducted for the business-critical Integration Services. But in same cases, making things a bit faster without sacrificing too much – might be a proper choice (when pressed with time).

Does this resonate?

Again, this is only a proposal. Architect, experts and project teams may decide differently of course…

Acknowledgment

*) Intro photo by Christopher Burns on Unsplash

References

[1] A-Z Performance Testing for integrations: https://community.sap.com/t5/technology-blog-posts-by-members/a-z-performance-testing-for-integrations-and-why/bc-p/14305000#M177084

Unlock S/4HANA Cloud Secrets: Hybrid Events+APIs Strategy for Seamless BTP Data Flows

2026-02-12T01:30:35.487000+01:00

Strategic Financial Data Extraction from SAP S/4HANA Cloud Public Edition to SAP BTP

Using Transfer Pricing as a Real-World Example

Transfer pricing represents a perfect use case to demonstrate generic financial data extraction strategies from SAP S/4HANA Cloud Public Edition. Multinational organisations need GL, Controlling, Material Ledger, and Asset Accounting postings to flow reliably to external engines hosted on SAP BTP—but Public Cloud’s “no direct database access” constraint demands architecturally sound patterns.

Why Transfer Pricing Perfectly Illustrates the Challenge

The business need: Calculate inter-company markups (cost-plus, resale-minus) using real-time ACDOCA postings across multiple currencies, profit centres, and cost elements.
The constraint: Pure cloud extensibility—no RFCs, no custom ABAP, no direct table extracts.
The solution: Three proven patterns that work for any financial data integration scenario.

Pattern 1: Event Notifications (Real-Time Push Model)

How transfer pricing uses it: GL postings trigger automatic business event notifications routed through SAP Event Mesh to BTP applications.

Event Notification

Generic applicability: Works for any posting-driven process—revenue recognition, inter-company reconciliation, compliance monitoring.

High-level activation:

Integration configuration apps → Activate accounting-related event notifications
Communication scenarios → Configure outbound event destinations
Event Mesh subscription → Point to BTP service endpoint
Payload contains: Company codes, ledger amounts (local/group), profit centres, material valuations

Pattern 2: Standard Query Services (Scheduled Pull Model)

How transfer pricing uses it: BTP service queries S/4HANA nightly for new/changed financial postings.

Query ServiceKey services (release-dependent availability):

Financial line item services → GL/CO/ML/AA postings
Profitability services → Margin analysis data
Material valuation services → Cost component details

Generic applicability: Perfect for scheduled reconciliation, historical backfills, or validation runs.

Pattern 3: Hybrid Extraction (Production Resilience)

Transfer pricing demands 99.9% coverage. Smart architects layer all three patterns:

Use Case	Primary Pattern	Transfer Pricing Example	Generic Use
Real-time GL postings	Event notifications	Invoice → immediate markup	Any posting trigger
Historical catch-up	Standard APIs	Month-end reconciliation	Data migration
Day 1 implementation	Bulk extraction	Full ACDOCA baseline	Initial loads
Custom calculations	BTP processing	Exception overrides	Business rules

Three-tier reference flow:

Hybrid ExtractionBTP Implementation Patterns (Transfer Pricing Example)

Cloud Application Programming Model (CAP)

service FinancialIntegration {
  entity Postings as projection on external financial services;
  entity PricingResults as projection on HANA staging;
}

Pattern: Event handlers + scheduled queries → unified HANA staging → business rules.

ABAP RESTful Application Programming (RAP)

define root view entity FinancialDataView
  as select from standard financial services

Pattern: Analytical CDS views over external data → transactional services.

Architect’s Production Checklist

✅ Tenant validation: Test events/APIs in your specific S/4HANA Cloud environment
✅ Quota management: Monitor Event Mesh throughput + API rate limits
✅ Fallback design: API polling validates event stream completeness
✅ Quarterly readiness: SAP evolves event coverage and API fields continuously
✅ Pure cloud: Zero custom code in production S/4HANA

The Universal Pattern

Transfer pricing proves the strategy works for complex financial scenarios. The same architecture applies to:

Inter-company reconciliation
Revenue recognition automation
Compliance reporting engines
Analytics data pipelines
Any standard data object/model driven process

Universal PatternKey takeaway: This isn’t “just for transfer pricing”—it’s your reusable blueprint for any S/4HANA Cloud → BTP data integration.