SAP Community - SAP Event Mesh

Small but Great: Introducing Micro-Integrations for Advanced Event Mesh

2025-12-01T13:22:27.767000+01:00

The Mesh

SAP Integration Suite, advanced event mesh is more than just a broker – it allows you to build a mesh of event brokers. Once on the mesh, events can flow through your enterprise providing a veritable nervous system that allows your company to even become better in what you do – faster, more reactive, more scalable, more flexible, more open to your employee’s ideas and your customer’s and supplier’s technology.

Once on the Mesh

Now we have added to this “more than just a broker” – SAP has just, on November 28th, released Micro-Integrations for SAP Integration Suite, advanced event mesh.

Let’s go back to the second sentence you have read above: once on the mesh, events can flow … Often the question was: how do I get the events on the mesh from my event source, or off the mesh to the event consumer? Micro-Integrations facilitate exactly this on-ramp to and off-ramp from the mesh.

Micro-Integrations

Micro-Integrations are small, lightweight, event-driven integration modules that connect enterprise technologies (legacy and SaaS applications, messaging services, data bases, files, AI agents, etc.) to an event-driven distribution layer, so they can exchange information in real-time. Advanced Event Mesh Micro-Integrations serve as on-ramp and off-ramp to the mesh – a network of meshed SAP Integration Suite, advanced event mesh brokers.

Scope of Micro-Integrations

Micro-Integrations focus on specific, narrowly defined tasks or processes. They are easier to design and change without impact to any other systems because the effect and risk of the change is localized. The reason for this is that a Micro-Integration (MI) does not connect two applications with each other. A MI connects a given application as an event source to the mesh (On-Ramp) or event target from the mesh (off-ramp). Resulting from the event-driven approach and the power of Advanced Event Mesh, high throughput data streams flow faster.

Micro-Integrations include a source or target connector which establishes a data flow between an event distribution layer like an event mesh and some source/target system.

Micro-Integrations are available in the Cloud Console and allow you to manage and observe the state of an integration between your external system and an event broker service or event mesh.

Benefits of Micro-Integrations

Micro-Integrations are highly beneficial for modernizing integrations with event-driven architecture and the benefits they offer include

Greater Agility: easy to change how applications and services interact with one another
Faster data distribution: better real-time performance than traditional integration patterns and fast streaming capabilities
Better/Easy Scalability: improved scalability by use of pub/sub to distribute events and by option to add additional Micro-Integrations to specific task
More Flexibility: different technologies can be used at source or target sides depending on best fit technology, commercials or technology evolution

Available Micro-Integrations

A number of Micro-Integrations are currently available for use with SAP Integration Suite, advanced event mesh and SAP adds new Micro-Integrations to this list frequently. The currently available Micro-Integrations include:

Azure Service Bus
Amazon SNS
Amazon SQS
MQTT
Network files services SFTP
IBM MQ
Google Pub/Sub
AWS SQS
Snowflake
Oracle Advanced Queuing
Salesforce

More Micro-Integrations are planned to be made available.

Pre-Requisites and Commercials

Micro-Integrations require an SAP Integration Suite, advanced event mesh broker – a certain number of Micro-Integrations is included with the bigger AEM brokers. For the current commercial offering an Advanced Event Mesh broker of the 1K tier or higher is required (version 10.2.1 or later). The 1k broker for example includes a usage right for 2 Micro-Integrations which you can choose from the list of Micro-Integrations available for AEM.

Micro-Integrations are supported on Public Regions, Dedicated Regions, and Customer-Controlled Regions.

Understanding Micro-Integrations

A Micro-Integration defines how data should move between an external system and Advanced Event Mesh. A Micro-Integration includes a source or target connector which establishes data flow between an event distribution layer (i.e. Advanced Event Mesh) and some other source or target system.

So, there are two types of Micro-Integrations:

With a target Micro-Integration, data streams from an SAP event broker service to the external system.
With a source Micro-Integration, data streams from the external system to an SAP event broker service.

You decide at creation time whether to create a source or target Micro-Integration. A Micro-Integration contains up to five Flows that share the same connection information but differ in their endpoints. This allows you to group similar integrations and manage them as a single deployment, simplifying configuration and reducing operational costs.

The way forward

Customers with supported brokers can as of today use start using Micro-Integrations – supported again means a 1K broker or higher.

With the feature introduced, we intend to provide it in future via additional channels as well.

This is work in progress, so stay tuned for updates here.

Getting Started

Find additional information on Micro-Integrations for Advanced Event Mesh here:

Documentation

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

IDoc with Integration Suite, Advanced Event Mesh using the Event Add-On

2025-12-18T08:38:25.882000+01:00

In modern SAP landscapes, Intermediate Documents (IDocs) remain a foundational pillar for reliable, standardized data exchange—both within SAP systems and between SAP and external systems. The Event Add-on extends this proven SAP mechanism into today's heterogeneous and event-driven integration architectures by enabling bidirectional IDoc messaging that is code-less, real-time, and flexible. With the Add-On, standard and custom SAP IDocs can not only be processed in their native format but also converted on-the-fly to JSON for seamless delivery to cloud platforms, messaging brokers, or event-driven consumers, and vice versa. This empowers organizations to leverage established SAP interfaces while bridging to modern integration patterns without heavy custom development.

Please also check out the technology comparison in our central blog.

Create Logical System

Transaction: SALE
Select the created Connection
Go to section Basic Settings → Define Logical System
Add New Entry and specify:
- Log.System: Name has to be “LOCAL”
- Name: choose a description

Create Customer Distribution Model

Transaction: BD64
Create Model View and specify:
- Sender: Sending client
- Recipients: Logical system (LOCAL)
- Add message type as required (e.g., MATMAS)

Create IDoc Port

Transaction: WE21
Select the created Connection
Go to section ABAP-PI
Add New Entry and specify:
- Port: choose a name (e.g., ACI_IDOC)
- Description: choose a description
- Function module: /ASADEV/ACI_IDOC_PORT_TRIGGER

Create Partner profiles

Note:

Make sure a Distribution model is available (Transaction BD64)

Transaction: WE20
Open folder: Partner Type LS
Go to section Outbound Options.
- Receiver port: ACI_IDOC
- Basic Type: MATMAS07

Create Outbound Object

Note:

In the example below, we want to trigger an outbound message for SAP material master IDocs (IDoc name “MATMAS”), convert the IDoc payload to JSON and send it to an event broker instance.

Transaction: SPRO
Goto ASAPIO Cloud Integrator → Connection and Replication Object Customizing
Or go directly to transaction: /ASADEV/68000202
Select the created Connection
Go to section Outbound Objects
Add New Entry and specify:
- Object: name of the outbound configuration
- Extraction Func. Module: /ASADEV/ACI_GEN_VIEW_EXTRACTOR
- Message Type: Specific message type (Example: Z_SAP_EM_MATMAS)
- Load Type: Incremental Load
- Trace: activate for testing purposes
- Extraction view name: EDID4
Formatting Function: /ASADEV/ACI_GEN_IDOC_FORMATTER

Set up ‘Event Linkage’

Link the configuration of the outbound object to a Business Object event:

Navigate to Outbound Objects → Event Linkage or use transaction SWE2.
Add New Entry and specify:
- Object Category: BO BOR Object Type
- Object Type: /ASADEV/ID
- Event: ACI_TRIGGER_EVENT
- Receiver Function Module: /ASADEV/ACI_EVENTS_TRIGGER
- Linkage Activated: tick the checkbox
- Check Function Module: /ASADEV/ACI_EVENTS_CHECK

Set-up ‘Header Attributes’

Specific for the IDoc Outbound use-case you have to specify the header attributes. For all details check https://asapio.com/docs/idoc/.

Test the outbound IDoc event creation

Start transaction BD10 to test the described formatter

Welcome you IDoc event in SAP AEM using Try-Me.

Stay tuned and Happy Eventing

Santa learns lessons from the past: Successful Agentic AI needs an Event Driven Architecture

2025-12-18T11:56:50.616000+01:00

Most organisations realise that Agentic AI will become critical to their business. But there is still hesitation about giving up more control to these new agents. What if they make bad decisions, what if they do the wrong thing ?

I’ve been in the technology industry for more decades than I may care to admit. Before joining SAP, I spent 14 years working within Financial Services and Capital Markets. It is interesting to reflect on those times. Many of the challenges back then remain the same today.

In Financial Services, the major players did not hesitate to innovate with new technology – for them it was opportunity. Very early on they realised that trading in “simpler” financial instruments ( e.g. foreign exchange ) did not really need humans shouting excitedly at one another on the (tele)phone. That trading was quickly handed over to computers – and whilst it was perhaps not AI by today’s definition, it was certainly algorithmic and it was most definitely autonomous. Billions still gets traded by these Agentic AI predecessors, all based on the lightning-fast decisions they make ( but operating within parameters and thresholds defined by humans that quantify the risk ).

Decisions are made as a result of an event that arises. Better decisions are made knowing the wider context of that event. Yes, context comes from data. Wider context ( surprise ! ) comes from more and different data. But all that data needs to be super up-to-date, and accurate.

Financial Services firms understood and solved this also. In a 24x7 global market, there is no window for a batch run to load data. Trading systems, market data providers, stock exchanges, market and credit risk systems and more, all needed to be wired together for simultaneous update of data. Plus, it needed to be robust and flexible to add-in other market participants and their systems also.

Most firms adopted architectures built around messaging-oriented middleware, with technologies like Enterprise Service Bus, Message Queue, and Event Bus amongst others, all being variations on a theme that today we call an Event Driven Architecture (EDA). Their appetite for speed pushed the technology to milli-second response times and super high-availability. Equally valuable was that the decoupled publisher-subscriber model allowed much faster and easier recovery if any of the participants in their expanded trading ecosystem did experience a failure.

Perhaps such requirements seem a bit extreme for many companies operating in other industry segments. But the world is increasingly real time for the majority of businesses, and as Agentic AI plays a bigger part in your daily operations, it may be time to reflect on these lessons.

To highlight this more tangibly, I thought about a festive ( but fictional ? ) example where the capabilities of an Event Driven Architecture could really make a difference. So grab a coffee, something sweet to eat ( save the gym for the New Year ) and read on …

Santa Inc refactors gift delivery on an Event Driven Architecture

After decades relying on delivery to every home in sequence, Santa has realised this will no longer scale and he risks missing targets and some serious reputational damage. His operations used to be ok, but the customer base expands every year and getting to all of those in one day is now stretching the imagination.

Production used to be straightforward when it was just teddy bears, dolls, drums and toy trains, but now with games consoles, smartphones and other sophisticated presents it has become necessary to outsource to specialised manufacturing facilities in many countries. The elves have switched roles from sewing and carpentry to now managing supply chains, delivery bottlenecks and stock-outs – they’re stressed and threatening to go on strike ! Managing stock and purchasing was much easier when children used to write letters, but now they post their wish lists on social media – and keep changing their minds based on what is trending ! Logistics was never a problem – Rudolph and the other reindeer managed through even the harshest weather. But now they are obliged to adhere to air-traffic control diversions and compulsory rest stops. Finally, when delivering a present, it was disappointing to find out ( too late ) that the child had been naughty rather than nice. It meant carrying extra payload on the sleigh and unnecessary manufacturing and purchase costs.

Santa has an extensive IT landscape and ecosystem. But he realised even his magical powers were no longer the answer – it was time to transform his operations. But not rip and replace … even with 364 quieter days, that would still be too much work. Besides, most of the individual systems did what they needed to do – it was just they didn’t really react to each other that well. There was a lot of point-to-point connection between the production, inventory, CRM and other systems, with each repeatedly polling the other for updates – a real spaghetti architecture. Adding new suppliers’ systems into this landscape was slow. Recovering from any one system failure, having to replay lost transactions and regain overall confidence in stock quantities and delivery shipments an even bigger nightmare.

All of this was putting huge pressure on the elves. Santa has always been committed to his workforce, and he wanted the team to be happy and motivated. He looked to Agentic AI to help them, to manage the scale and complexity of supply chains. But like his elves, those AI agents would need to be super-smart, reactive, and always up to date with reliable data.

And then the lightbulb went on for Santa. He was reading this article about Event Driven Architecture and realised that would answer so many of these problems. The synchronous and repeated point-to-point communication is taken away. Instead, events are published asynchronously, with brokers distributing and guaranteeing them, to be consumed by any system that is interested – instantly ( super-fast ) and simultaneously ( not each system in turn ). The spaghetti is now replaced by something more like a giant distributed smorgasbord in which everyone ( elves, agents and ecosystem partners ) can share all at once. NOTE: Santa was never a fan of spaghetti but does quite enjoy a good smorgasbord.

With an Event Driven Architecture, Santa could be much more responsive in his production runs and purchasing. Plus, new suppliers could be on-boarded quickly and easily to cater for peaks in toy popularity, as well as getting up-to-date pricing and costs across his ecosystem. On the big night itself, so many of those delivery headaches could now be mitigated. Travel and weather alerts would be provided immediately for dynamic routing updates ( and for Santa, every milli-second matters ). Add to this a real-time feed of naughty-or-nice monitoring data being gathered by event brokers across the globe ( some in very remote locations ) and made available to the dynamic routing algorithm as well as stock logistics teams ( Santa has an increasing network of warehouses that he needs to stop at – he cannot carry everything on his sleigh ).

Santa and his Enterprise Architect ( another Elf ) looked at options and decided on SAP Integration Suite, Advanced Event Mesh. Given that 84% of the world’s global commerce runs on SAP systems, and these already have high-value business events out-of-the-box, it was likely that much of Santa’s ecosystem could be easily included. Even for those using other vendors’ applications, the solution was open to those via industry-standard protocols, plus it was possible to include custom-built events. It did not need rip and replace, and the system could scale by adding more brokers over time to create an event mesh. Even better, that same infrastructure could be used for other event use cases ( Santa wondered about moving into Travel & Entertainment for the rest of the year – perhaps offering trips on the sleigh into low earth orbit – he thought that might become popular ).

Whilst looking at SAP, his Enterprise Architect saw SAP Build Joule Studio, to create the AI agents. That seemed an obvious choice also – many processes would run on SAP, the most relevant and up-to-date operational data resides there, plus it offered a large choice of LLMs across the major providers. Quick to get into production also – because they rapidly needed to regain morale amongst the elves.

So that’s the story of how one globally recognised brand came to explore the benefits of an Event Driven Architecture. If you recognise any similarities to challenges within your own business operation, then I would invite you learn more here. Or, if you would like to see an example that the elves built earlier, then please do look at this short demo.

SAP Integration Suite: Q4/2025 Feature Highlights

2026-01-12T18:00:38.146000+01:00

The fresh batch of features delivered in Q4 2025 brings powerful new tools designed to make your integrations smarter, faster, and more resilient. From AI-powered recommendations that simplify troubleshooting, to streamlined connectivity with top platforms like Amazon Kinesis and Box, these updates are crafted to boost your operational efficiency and keep you ahead of the curve. Read on to explore how these innovations can transform your integration experience.

Artificial Intelligence

AI-based intelligent recommendations for detected API anomalies

This AI enhancement builds on anomaly detection to explain what changed, why it likely happened, and what to do next, cutting triage and speeding recovery. Embedded in API Management, it surfaces guidance alongside alerts with one-click actions and optional “intelligent healing.”

The included capabilities - Insights, Causes, and Recommendations - enable faster response to error spikes, latency surges, and abnormal traffic patterns, improving reliability and operational efficiency for API owners and teams. See how to get started in this blog post and review the Documentation.

Connectivity and Adapters

Amazon Kinesis receiver adapter: facilitates and accelerates connectivity to Amazon Kinesis Data Streams, streamlining data communication and enhancing real-time data processing.
Box receiver adapter: connects SAP Integration Suite to Box and enables you to access components on Box.
Microsoft OneNote receiver adapter: automates common business operations by integrating MS OneNote with other business applications. It connects an SAP Integration Suite tenant to a remote system using HTTP protocol.
Azure Service Bus adapter: connects SAP Integration Suite to Azure Service Bus.
MongoDB receiver adapter: connects SAP Integration Suite to MongoDB.
Poll Enrich Step in FTP sender adapter: reads (poll) messages from FTP server and adds the content to the original message in the middle of the message processing sequence.

New data space integration package

The data space integration package helps supply chain partners exchange data securely and self-sovereignly within data spaces. It includes two components: a data space connector for secure, sovereign data exchange, and a decentralized identity wallet for sharing trustworthy, verifiable data. Read all details in the blog post.

Data Center Availability 🇩🇪 🇮🇹 🇦🇪

Customers can now run SAP Integration Suite in four new data centers: on SAP infrastructure in Frankfurt, Sankt Leon-Rot (both in Germany) and in the United Arab Emirates; and additionally, one in Italy on Amazon Web Services.

Event-driven Integration

Micro-Integrations

Micro-Integrations are small, event-driven connectors that link applications to an Advanced Event Mesh as on-ramps (event sources) or off-ramps (event targets), avoiding brittle point-to-point ties so changes stay localized and low-risk. By focusing on narrowly defined tasks, they are easier to design, adapt, and scale, delivering high-throughput, real-time streams via pub/sub and letting you add more Micro-Integrations per task as demand grows. Available in the Cloud Console, they provide management and observability for integrations between external systems and event brokers or meshes, resulting in greater agility, faster data distribution, and flexibility to use the best-fit technologies at the source and target. Find more details and the currently available micro-integrations in the blog post.

Event Mesh integration with SAP Cloud ALM for health monitoring

SAP Integration Suite’s Event Mesh now integrates with SAP Cloud ALM Health Monitoring to regularly collect and display broker vitals, such as active connections, message consumers, message queues, spool usage, and broker state, on the CALM dashboard. Customers can customize thresholds for each metric (except broker state), view 14 days of history, and receive warning notifications when values reach 80% (orange) and 90% (red) of the defined thresholds, enabling proactive monitoring and alerts for Event Mesh health. Set up and further details can be found here.

Migration support from Event Mesh capability to SAP Integration Suite, advanced event mesh

Great news to facilitate your system modernization: SAP provides technical- and process-oriented migration support to help customers move from the Event Mesh capability in SAP Integration Suite to SAP Integration Suite, advanced event mesh, scaling smoothly from basic scenarios to a richer, more powerful event-driven foundation. This includes support for migrating events so applications can communicate asynchronously in real time across distributed landscapes with support for various protocols, enabling teams to start simple, grow confidently, and modernize without disruption.

B2B Integration

Support for the SFTP adapter and Alerting of failed B2B interchanges in Trading Partner Management

SAP Integration Suite’s Trading Partner Management now supports SFTP (Secure File Transfer Protocol), available in both standard and premium editions and via the SAP BTP Enterprise Agreement. Users can read and write files to their own or trading partners’ SFTP servers and, when defining systems, can choose SFTP sender and receiver adapters.

Additionally, SAP Integration Suite extends Trading Partner Management by publishing B2B interchange data to SAP Cloud ALM for centralized monitoring and rapid detection of failed transactions. Using SAP Cloud ALM, you can configure granular scenario specific alerts that filter by details such as trading partners or message types to receive targeted notifications and act quickly on issues.

Process Integration

Basic authentication on Edge Integration Cell

SAP Integration Suite’s Edge Integration Cell now supports basic HTTP authentication using a client ID and client secret during temporary connectivity loss to SAP BTP. This enables simple sender authentication for testing with minimal configuration and allows integration flow processing and API artifact invocations using clientId and clientsecret while SAP BTP is unreachable.

Advanced checks in Groovy scripts

SAP Integration Suite’s Cloud Integration designer now offers advanced checks for Groovy scripts, helping developers analyze and prepare custom integration flows for future runtime version upgrades. A new “ensure upgrade readiness” guideline recommends supported libraries and classes and can automatically update scripts to align with upgrade requirements. See all information in the respective documentation.

Service interface artifact creation In Cloud Integration

SAP Integration Suite Cloud Integration now supports creating and editing service interface artifacts directly in the workspace, aligning with an API first outside in development approach and supporting existing Enterprise Services Repository use cases. These artifacts enable proxy generation in ABAP backends for smooth integration into ABAP based systems. The capability is available in the multi cloud environment and allows native creation of service interface artifacts in your Cloud Integration tenant.

Local OData API Access & SAP HANA Support

See details and demo in the video:

----

For a sneak peek into what’s in store for 2026, check out the road map explorer and the SAP TechEd 2025 News Guide
Join the integration community and connect with other integration developers!

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.

Why Your SAP Upgrades Keep Breaking (And How Event-Driven Architecture Fixes It)

2026-01-21T06:35:24.315000+01:00

Why Your SAP Upgrades Keep Breaking (And How Event-Driven Architecture Fixes It)

If you’ve ever delayed an S/4HANA upgrade because of custom code anxiety, you’re not alone. Many SAP teams genuinely want to move faster and adopt new innovations , but tightly coupled extensions, brittle integrations, and years of accumulated technical debt often get in the way.

During my session at SAP DevtoberFest 2025 : Clean Core, Event-Driven: Unlocking SAP Value with Advanced Event Mesh

this challenge came up repeatedly. So, I decided to turn that conversation into a blog . Not as a theoretical exercise, but as a practical guide to one of the most important architectural shifts in modern SAP landscapes: clean core enabled by event-driven architecture (EDA).

What is a clean core and why it matters

A clean core is the strategic foundation for modern SAP landscapes. It means keeping the SAP digital core lean and standard, while moving custom logic, integrations, and nonessential processes to side‑by‑side extensions. This approach reduces upgrade risk, improves performance, lowers operational cost, and makes it possible to adopt new SAP innovations faster and with less friction.

Instead of modifying the core directly, customization happens around it.

Why does this matter? Because a clean core directly translates to:

Improved performance: Core resources focus on essential business processes, reducing latency and improving throughput.
Higher stability: Fewer custom touch points mean fewer failure surfaces and easier upgrades.
Lower maintenance cost: Less bespoke code reduces debugging, regression testing, and emergency fixes.
Faster innovation: Standard APIs and modular extensions speed onboarding, refactoring, and new feature delivery.
Stay Current: Clean core means reduced complexities and challenges in upgrading to new releases and faster adoption of new features and capabilities

Why achieving clean core is hard ?

If clean core is so clearly beneficial, why isn’t everyone already there!!??

Because real-world SAP landscapes are messy.

Most enterprises face a set of recurring obstacles that erode the clean core ideal:

Insufficient extensibility: Legacy systems and older extension points force code changes in the core.
Integration complexity: Tightly coupled point-to-point interfaces are fragile to change.
Data rot: ROT = Redundant, Obselete and Trivial – data in custom fields and tables that erode trust in master data.
High upfront investment: Code analysis, data cleanup, and process rework require time and budget before benefits appear.
Skills and tooling gaps: Cloud-native extension patterns and event thinking require new skills and practices.
Hybrid landscapes: On-prem, multicloud, and different SAP systems introduce compatibility and governance issues.

Extensibility as a clean core dimension

Extensions are inevitable and necessary. The key question isn’t whether you extend SAP, but how you do it. Clean core demands that:

Custom logic must not tamper with core objects
Extensions are decoupled from SAP standard
Only upgrade-stable mechanisms are used

SAP formalizes this approach through the Clean Core Strategy Pyramid.

The strategy emphasizes a shift away from traditional, "monolithic" customizations that modify the digital core, moving instead toward a side-by-side extensibility model.

By leveraging the SAP Business Technology Platform (BTP) and utilizing stable APIs and events, businesses can decouple their custom logic and integrations from the standard S/4HANA system.

The goal is simple but powerful: Eliminate technical debt and adopt innovation without disruption.

Event-driven architecture: the clean core enabler

Adopting event-driven architecture (EDA) is a practical way to decouple systems and preserve a clean core.

At its heart, EDA treats business changes as events that are published by a source and consumed by one or many subscribers. This replaces brittle point-to-point integrations with a publish/subscribe model where extensions live outside the core.

EDA doesn’t just support clean core , it actively enforces it.

Key EDA advantages for SAP landscapes

Asynchronous communication: Producers and consumers evolve independently.
Unlimited fan-out: Publish once, deliver to many subscribers without changing the producer.
Scalability and resilience: Brokers absorb bursts and ensure reliable delivery and ordering.
Side-by-side extensibility: Consumers implement business logic externally, protecting the core from bespoke changes.

Events as nouns, verbs, and properties

A simple, practical but highly effective way to being with EDA is to visualize business processes as events and further design these events is to describe them with three parts:

Noun: the object that changed (for example, BusinessPartner, Order, MaterialMaster, etc).
Verb: the change that occurred (created, updated, cancelled, etc.).
Properties: attributes that describe the event (IDs, timestamps, locations, reasons).

Micro integrations: a new, pragmatic integration paradigm

Micro integrations are small, single-purpose components that produce or consume events. Think of them as integration-focused microservices: modular, decentralized, and easy to scale. Any component that onloads events to a broker is a source micro integration. Anything that consumes events from a broker is a target micro integration.

How micro integrations support clean core

Externalize custom logic: Transformations, validations, and routing live outside SAP core.
Reduce coupling: Systems publish events; any number of consumers can subscribe without impacting others.
Independent scaling: Deploy micro integrations close to sources or targets and scale them separately.
Operational visibility: Centralized monitoring and an event catalog make integrations discoverable and governable.

Real-world scenario: business partner events

Imagine an S/4HANA publishing BusinessPartner created events to a SAP BTP Advanced Event Mesh. Instead of hardcoding point-to-point calls, the event is published once and delivered to:

A SAP Integration Suite iFlow that pushes partner records to a Salesforce in under 1 second
A CAP application that enriches the partner data and makes it available in a cannonical model for other consumers
A Snowflake connector which takes SAP events and updates datawarehouse tables for advanced analytics
An increasing number of downstream services and funcationalities that bring new business value.

Each of those consumers is a micro integration. They scale independently, can be updated without touching the core, and receive only the events they subscribe to. The result is a leaner S/4HANA core, faster onboarding for new consumers, and more predictable upgrades.

Practical next steps

You don’t need a big-bang transformation to get started:

Identify a single usecase to productize as events (for example, business partner or inventory events).
Model each event as Noun-Verb-Properties
Start with a source micro integration at the edge to publish, and a single target micro integration to consume.
Introduce an event catalog and basic access controls to document ownership and usage rules.
Measure event reuse and track the event reuse index to demonstrate value.

Conclusion

Clean core is achievable when extensibility and integrations are treated as products rather than throwaway code.

By combining:

Event-driven architecture
Micro integrations
A governed event mesh

Teams can decouple logic from the SAP core, scale consumption independently, and evolve systems safely over time.

The payoff is real:

Fewer upgrade headaches
Faster time to value

A more resilient, future-ready SAP landscape

Event Enabling Idocs rapidly and almost effortlessly via BTP Integration Suite, Cloud Integration

2026-01-29T16:22:32.332000+01:00

1) Introduction

In the past we have published a couple of Blogs where we describe how to event enable Idocs via Event Enablement AddOn or Application Interface Framework. Another possibility with the least configuration on the ERP (ECC or S/4) System is the usage of the HTTP Port and SAP Cloud Integration. This Blog will demonstrate how to easily accomplish this + how to dynamically add Topic Values with the Help of the Partner Directory in SAP Cloud Integration.

2) ERP Customizing

Let´s start with the Definition of the Logical System in Transaction SALE

I have defined this Logical System for the Connection to AEM via Cloud Integration

In SM59 I have already prepared a Destination to SAP Cloud Integration Iflow receiving the Idocs:

Of course later we´ll have to make sure that the Iflow Address and the endpoint in this Destination are the same. Based on this Destination we create a Port in WE21:

Then we´ll need a Partner Profile in WE20 with the Receiver Port we just created. Let´s say we want to distribute Vendor Master Data with CREMAS:

Also we´ll need a Distribution Model in BD64:

(Only the Receiver CPI_AEM relevant here)

That is all we have to do on the ERP! Let´s switch to the Cloud Integration.

2) SAP Cloud Integration

Static Topic

In my Github Repo I have provided a Template Iflow you can upload into your Cloud Integration Package

First thing is to configure the Sender Address and Role:

In the Content Modifier Step we retrieve the Idoc Headers from the Payload:

Then, depending if the Idoc has a CIMTYP or not, we put together the Topic.

With CIMTYP:

Header "Topic" = "${header.SAP_IDoc_EDIDC_SNDPRN}/${header.SAP_IDoc_EDIDC_MESTYP}/${header.SAP_IDoc_EDIDC_IDOCTYP}/${header.SAP_IDoc_EDIDC_CIMTYP}"

Without CIMTYP the Topic is filled like this: "${header.SAP_IDoc_EDIDC_SNDPRN}/${header.SAP_IDoc_EDIDC_MESTYP}/${header.SAP_IDoc_EDIDC_IDOCTYP}"

So if I have an CREMAS07 Idoc from my System T33, the Topic would be

T33CLNT800/CREMAS/CREMAS07

If this is already enough for you, you can ignore or even remove the 2 Groovy Scripts after the Router in the Iflow.

The only Thing left of course is the Receiver Channel. Here we have to maintain the Connection Parameters

That´s it. You can deploy the Iflow!

Dynamic Topic with PartnerDirectory

If we want to include Parts of the Payload into the Topic, we´ll have to get it via Xpath. This could be easily done via Content Modifier, but to keep everything dynamic in one Iflow, I decided to implement 2 Groovy Scripts. 1st Script is retrieving the XPaths I set up for my Idoc Type in the Partner Directory. 2nd Script performs the XPath on the Body and puts together the Topic.

In order to enable this, i added the switch "GetDynamicTopicFromPartnerDirectoy"

The Maintainence of the Idoc-specific XPaths happens in the Partner Directory. So in Monitor -> Integration and APIs -> Partner Directory

The PartnerID is always <MESTYP>.<IDOCTYP>.<CIMTYP> (if CIMTYP exists) or <MESTYP>.<IDOCTYP> (no CIMTYP). In my Case it is CREMAS.CREMAS07. I have defined these 3 XPaths

Test

Now let´s test the Scenario. I set the Log Level on the Iflow to "Trace" and set up a Consumer on Advanced Event Mesh TryMe Feature on Topic "T33CLNT800/>"

Now let´s send a Vendor from the ERP System Transaction BD14:

Result:

Let´s check in WE05:

Now let´s check the Trace in SAP Cloud Integration Message Monitoring:

Here we can see at the Receiver Channel Step the dynamic Topic we produced:

Also on Advanced Event Mesh we can see the result in TryMe:

Dynamic Topic and Conversion with Custom Exit Iflow

Let´s say I want to convert the XML into a JSON and Filter out some Fields. For that I would use a custom exit, because that would be Idoc specific.

For this I added the Switch "CallCustomExit"

I configured the address to dynamically set the Address based on the Message- and Idoc Type, so here the complete Address would be "/IdocEventing/CREMAS/CREMAS07"

For the Custom Exit i added another Iflow into the GIT Repo:

For a Filter i choose to define a Message Mapping. You can use a different Step if you prefer. For a Mapping I need the XSD for this Idoc. This can be exported in the ERP System, Transaction WE61:

Now just import it into Cloud Integration

Create a Message Mapping:

and add it into your Mapping (Source and Target)

First I map all Fields with this Button:

Then I disable the Structures I don´t want to map

I disabled everything except EDI_DC40 and E1LFA1M. Then I saved and added the json Conversion to my Iflow:

Test

Let´s test again:

(Same Procedure as above, Send Vendor with BD14)

Result: Dynamic Topic is the same, Payload has been mapped and converted:

Pretty Printed in Notepad++:

That´s it! Happy Eventing!

Tweaks for RAP BO events addressing filtering (before send) and too small payload (callbacks needed)

2026-02-03T15:18:52.529000+01:00

Are you working on modernizing your SAP integrations, or looking for better ways to integrate with clean core compliance? But when you've looked at "Event Objects" from the SAP Business Accelerator Hub, you have found that it's not exactly matching your needs? Too many events are fired (can I filter?). The callback API is too time-consuming/unwanted. Or maybe you are simply interested in how ABAP RESTful Programming Model (RAP) Events work, how you can use and/or extend SAP Standard events?

In this blog I'll go through first some basic info and then start to showcase some tips / tweaks / workarounds you may or may not be aware about. Let's go.

1 ABAP RESTful Programming Model (RAP) Events Intro

I'll keep this very brief as the meat of this blog is to go into the nitty-gritty details. But, for the uninitiated, RAP BO events are events that have been built with the RAP framework which can easily integrate with event brokers, such as SAP Business Technology Platform's Event Mesh or Advanced Event Mesh. They are a sort of modern version of BTEs. You may refer to a previous blog of mine where I go into one full end-to-end example, showcasing how to find SAP standard events and then use them: Working with RAP BO Events end-to-end . The short version is that all events can be found on the SAP Business Accelerator Hub -> Your SAP Product -> Events.

2 Too many events are fired / I want to filter

This is probably one of the most common discussion points when I work with my customers. More often than not a "Created" or even more interestingly, a "Changed" event is simply fired too often for the actual integration needs. So what can we do here? In essence we have 3 main options:

Integration middleware handles filtering (= no changes in SAP system, use event as is)
1. This can be desirable if there are lots of receiving systems that need to receive information for a certain object, and maybe each of them would like to filter a little different. The middleware receives the event as it happens and can then handle the distribution accordingly. This way 1 single event could be the foundation of several functioning integrations (instead of several point-to-point integrations). The quote-on-quote downside to this is that you would of course increase the complexity in the middleware itself, but again if the same event benefits several receivers, this could be a good option.
Extend SAP standard event to include filtering fields (= extension development in your SAP system, use extended event, not standard)
1. This can be used if you know for sure you always want to filter out certain types of objects, that none of the integrated systems would want to be informed about. The quote-on-quote downside here is that we need to create an extension. Secondly, we first have to check if the SAP Standard RAP BO in question even allows behavior extensions. If not, we cannot use this option at all.
Use custom event in combination with SAP Standard event as a workaround (= custom development in your SAP system, use custom event, not standard)
1. Same as for the previous one, this option can be used if we know for a fact we always want to filter away certain objects. We can use this over the extend option, if for example the extension was not possible, or if the extension possibilities do not suffice (for example we need to add fields that are not easily associated in the RAP BO, or we need some complex logic and checking before we send an event)

As this blog focuses on RAP, I'll skip the first option and let the integration gurus tackle that one. Let's take a closer look at the other two...

2.1 Extend SAP standard event

If we found a suitable SAP standard RAP BO event and all we want is to add a few filter fields, we can do that with what is called Derived Events. Please refer to this page for details: Derived Business Events | SAP Help Portal

For my showcase I'll be using R_SalesOrderTP~Changed event. First of, we need to check if the behavior definition of the BO allows extensions. Open it and check for the word "extensible" somewhere at the beginning of the definition + on the entity which has the event (so we need two extensible).

If it's there, we can proceed. Next we can also check the event itself and the payload (if no parameter statement is written there, the payload is the key field(s) of the BO alone).

2.1.1 Create derived event payload with filter fields

Before we extend the behavior, we need a custom payload that includes our filter fields. Create a new data definition root entity and define your custom payload. For example:

@AccessControl.authorizationCheck: #NOT_REQUIRED
@EndUserText.label: 'Sales Ord. ext. event for derived event'
define root view entity ZP_SalesOrder_EventExt as select from I_SalesOrder
{
  key SalesOrder,
  .context.attribute: 'xsapordtype'
  SalesOrderType,
  .context.attribute: 'xsapslsorg'
  SalesOrganization,
  .context.attribute: 'xsapbillplc'
  _BillingPlan.BillingPlanCategory,
  DistributionChannel,
  OrganizationDivision,
  SoldToParty,
  CustomerGroup,
  ShippingCondition,
  IncotermsClassification,
  OverallSDProcessStatus
}

Few points:

Key fields must match the RAP BO you are extending
You can access fields just like the standard RAP BO and also associated fields (I showcase this with BillingPlanCategory above). Note, we focus only flat structures, so the associated field needs to be 1:1 (for deep structures, please refer to chapter 3).
With above, we created exactly 3 filter fields: Sales Order Type, Sales Organization, and Billing Plan Category. Filters must have the annotation "Event.context.attribute" and must start with "xsap"!

2.1.2 Extend standard RAP BO behavior to create a derived event (with our custom payload)

Now we are ready to extend the behavior definition as per usual practice: find/display it in the project explorer - right click - New Behavior Extension. Here type out your derived event, for example:

extension
//using interface i_salesordertp
;
extend behavior for SalesOrder {
  managed event ZZChangedExtended on Changed parameter ZP_SalesOrder_EventExt;
}

Few notes on the above:

First of I want to start with the interface commented away above. Bear with me, this is important to understand!
In RAP it is always best to interact with RAP BOs via their interface, if there is one (not to be confused with a basic interface view, such as I_SalesOrder or I_Customer etc., which reads from the DB table). In the case of R_SalesOrderTP, it has a transactional interface called I_SalesOrderTP. This interface is meant as a stable "API" to interact with the BO, and is usually released with C1/C0 contracts for clean core compliance. So in truth, we should be using the interface as we are extending this BO, but as you see above, it's commented away. That is because we must, in this case. I_SalesOrderTP does not include any of the events, and because we need those, we cannot use the interface in this case. What this means is that my extension behavior definition, as of right now, must be saved as "Standard ABAP" and cannot be assigned to a package with an ABAP Cloud software component. HOWEVER, this is clean core compliant, because R_SalesOrderTP is released with a C0 contract for extension, thus allowing such extensions. The problem is that the syntax check for ABAP for Cloud Development only checks for C1 contracts (which is missing on R_SalesOrderTP behavior), which is why, as of right now, we have to save this as Standard ABAP, meaning a "level B" extension which is clean core compliant (it would have been "level C", if R_SalesOrderTP hadn't had the C0).
The rest is quite straight forward. We say which entity we are extending (SalesOrder, using the alias in the behavior definition) and we are stating the Changed event to be extended with ZZChangedExtended with our own payload we previously created.

2.1.3 Create Event Binding for derived event

Next up we need an Event Binding for our derived event. As a small side note: if you only intend to consume your own derived within your SAP system (the same system) and not send it out to an event broker, then you would not need an event binding.
Create a new Event Binding object (Business Service - Event Binding or just search for event binding in the new ABAP object dialog) and add the event we just created to it:

Note that we of course refer to the SAP Standard RAP BO, which now includes our derived event thanks to the extension we just did.

2.1.4 Configure Event Channel to include your derived event

Lastly, to send our derived event to an event broker, we need to add it to our event channel. Assuming you already prepared an event channel (refer to my other blog linked above for more info on that), go to /n/IWXBE/CONFIG, select your event channel and go to Outbound Bindings.

Click the create button to add the event binding you just created. It could look something like this:

The above means that my Event Mesh on my BTP subaccount receives the SAP standard Sales Order Created event, and my own derived Sales Order Changed event.

And that's it: now we are ready for filtering or for simply getting the larger payload as per our derived event.

2.1.5 Adding Filters

In the same location as we were (/n/IWXBE/CONFIG -> Event Channel -> Outbound Bindings) click on the button Filters at the top. Open up the folder Outbound Bindings for your event channel and click on your derived event. Clicking on the plus-button shows all available filter fields, in this example:

Create a filter, for example that only Sales Order Type "OR" should be sent to out:

2.1.6 Subscribe to the event on your event broker

To receive this derived event for example in Event Mesh on SAP BTP, you need of course a corresponding queue and then add the subscription for this new derived event. In my example:

2.1.6 Test example

I changed a sales order in my system and saved. This now triggered my derived changed event, which I can see in the events monitoring transaction /n/IWXBE/EVENT_MONITOR (select event channel, click on Outbound Events, double-click on derived event)...

...and on SAP BTP Event Mesh where I added the subscription:

Here we can only see what's sitting in the queue. So let me consume the message in the test tool to show the same payload as in our monitor:

Awesome! We succeeded and this concludes the extend event option.

2.2 Use custom event in combination with SAP Standard event

This is an interesting one and in my experience comes with some confusion attached to it. I have heard sentences such as "But can't we just create a custom event instead of the standard one and use that?" And the simple answer to that is yes, but no 😊. Let me explain...

Now of course if we create our own, custom RAP BOs, we can add events to them. That is clear. And within that custom BO you decide when that event is fired. Clear and no problem. But this is all custom.

And now, if you want "your custom event" to be trigged during SAP standard processing, well no, SAP standard can't do that, as it does not know your custom event exists. And if you are thinking to use user exits or BAdIs to do this; think again, because it would be wrong to do so. User exits and BAdIs are called while the processing has not yet completed. Meaning at this point, in theory, something could still go wrong (no update in DB), but you already triggered your event. So, do not do this, ever! The point of the event framework is to inform about a state change. So you only want to do that, if the state change has actually occurred, meaning after the DB is fully updated.

So what else then, you wonder? That's where the SAP standard event comes in (which yes, is fired AFTER the state change occurred and all processing has completed). The SAP Standard event will trigger, and thus if you want more flexibility than just explored in the previous option with the extension of the SAP standard event, that's when we can try to combine standard with custom event.

Essentially, this is the pattern:

SAP standard process does something, which triggers an event for a certain object. This triggering happens at the exact time you want, but the SAP Standard event does not fulfill your requirement (and we can't / don't want to do a derived event)
You will create a custom event on a "dummy" RAP BO which includes the exact payload you need (flat structure for EM, it can be a deep one for AEM).
You will create a local event listener (within your SAP system) for the SAP standard event that triggers at the right moment. Within this local consumption you can now do any ABAP logic you may need. Complex filtering. Complex data collection (calling BAPIs or other things) etc.
Once all your data validation and collection is done, you fill the payload format of your custom event and finally you trigger your custom event (with a slight workaround, as events can only be raised from with the RAP BO itself)
You only configure your custom event in the event channel for the event broker. The event arriving there is ready to be consumed with all needed fields and only events are that are really expected are arriving there.

Let's do this example now. We stick with R_SalesOrderTP, this time using Created as the SAP Standard event.

Let's assume I don't just want to send all sales order that are created. Sales order type filtering is not good enough. In fact, it matters whether a product is sold that has certain characteristics, for example. As a simplified example here, I will only check the product type of the product, but hopefully this gives you some ideas; we could check anything at this point.

2.2.1 Create custom event

Our custom event doesn't need much of a BO. Meaning we don't want to (re)create read/update/delete etc. functionality, but this is purely for defining how the event payload should look like and for triggering the custom event.

In my example I took it a step further: what if I create a generic "event forwarder", that could potentially be used together with many SAP standard objects? Now, this isn't to say that I recommend this approach, in fact quite the opposite. And depending on your exact requirement, this may definitely the wrong approach. But I did this also in an effort to answer if this is at all feasible.

If having an event trigger with only key field information and then having a subsequent callback API later in the integration is a good pattern for you, then this could potentially help you, as you could reuse it for several use cases.

But, if instead you want something very specific, for example only forward my object under certain circumstances and including already all data needed, then of course it makes more sense to create a tailored custom event, with the exact payload of that object you want.

So please bear that in mind as we continue with this example. With this example I handle only a generic key-field based payload.

2.2.1.1 Custom entity data definition

We start of course with the data definition. Custom entity is in my opinion the best, as again we don't actually need any read or update functionality, but we simply describe our event payload at this point (and here you could have a large flat/deep structure):

@EndUserText.label: 'Event Forwarder BO'
define root custom entity ZR_EventForwarder
{
  key ObjectKey  : abap.string;
  key ObjectType : zevent_fwd_object;
}

2.2.1.2 Custom entity behavior definition

Next we need the behavior that will include our custom event:

unmanaged implementation in class zbp_r_eventforwarder unique;
strict ( 2 );

define behavior for ZR_EventForwarder
lock master
authorization master ( instance )
{
  field ( readonly ) ObjectKey, ObjectType;
  event ForwardEvent;
}

Finally, let ADT generate the BP implementation for you (we do not need to fill any of the methods but so it's properly created (again, we need no read/save methods etc.)). So I will not paste the whole Class/or Local Types.

Instead, what we need to do here is now offer an option to "raise" our custom event "ForwardEvent" from outside this BO. The "raise entity event" command is not allowed outside the RAP BO itself. So instead, we need to encapsulate it in a way that ABAP code from outside this behavior pool can call it. For this we need 2 things:

"Local event handler" (not actually inheriting anything => chose this to separate it from other, standard RAP BP behavior methods)
Method in the global class that can be called from other ABAP code

Let's start with the "local event handler". Within the section Local Types of your behavior implementation class, add something this:

class lcl_event_handler definition friends zbp_r_eventforwarder.
  public section.
    class-methods on_forward_event importing it_events type zbp_r_eventforwarder=>tt_events.
endclass.

class lcl_event_handler implementation.
  method on_forward_event.
    raise entity event zr_eventforwarder~forwardevent from it_events.

  endmethod.
endclass.

Note the "friends" command in the class definition. This is needed to be able to access private/protected class variables from the behavior pool (raising our entity event).

And in the Global Class, we change it as follow (full code copied):

class zbp_r_eventforwarder definition public abstract final for behavior of zr_eventforwarder.
  types tt_events type table for event zr_eventforwarder~forwardevent.

  public section.
    constants:
      co_type_salesorder    type zevent_fwd_object value 'SALESORDER'.
    class-methods raise_forward_event
      importing it_events   type tt_events.


endclass.

class zbp_r_eventforwarder implementation.
  method raise_forward_event.
    " tell RAP framework that we are in a SAVE sequence (otherwise it thinks
    " we are in the middle of a MODIFY)
    cl_abap_tx=>save( ).
    " trigger event (only allowed during SAVE)
    lcl_event_handler=>on_forward_event( it_events ).
  endmethod.
endclass.

We did 3 main things: a global type for the event payload table, a constant to distinguish different types of RAP BO that I mean to handle with my generic one (right now only one) and, most importantly, a global class method that can be called from other ABAP code.

2.2.1.3 Event Binding

As before, we need an event binding if we want to forward this to an event broker:

(Namespace, object type etc. can be freely chosen.)

And that's all for our custom event. Remember that the only purpose of this custom event is to offer a way to define the payload and to trigger it. Any functionality, such as filtering, complex validation or data selection etc. we do when the real SAP standard event is triggered. Meaning in the local consumption.

2.2.2 Local consumption of SAP Standard event

Now I won't go into step-by-step on this one, as I have done this already on the above linked blog post of mine. Please check there if the below steps are not enough for you.

I have an ABAP Class, abstract, final with the "for events of" functionality, where once again we must type R_SalesOrderTP here (and not I_SalesOrderTP, which would have been the preferred option). This means my class has to be again saved as "Standard ABAP" and cannot be in an ABAP for Cloud Development package. But this is clean core compliant, as explained above.

In Local Types I have my local class that inherits from cl_abap_behavior_event_handler and I add a method for the Created event:

class lcl_event_cons definition inheriting from cl_abap_behavior_event_handler.

  private section.
    methods:
      consume_created for entity event instances for salesorder~created.
endclass.

And here the implementation of that method (we'll go through it one by one below):

    data: lt_fwd_event  type zbp_r_eventforwarder=>tt_events.
    
    " go through RAP BO entity instances that triggerd the event
    " (should only be 1 as we listend to sales order (header) created)
    loop at instances into data(instance).
      " get data needed for complex filtering
      select salesorderitem, product, \_product-producttype
        from i_salesorderitem
        where salesorder = @instance-salesorder
        into table (lt_items).

      " check if sales order should be handled (forwarded to event broker)
      if line_exists( lt_items[ producttype = 'HAWA' ] ). 
        " this sales order is now filtered OK and will be added to the forwarding instances
        append initial line to lt_fwd_event assigning field-symbol(<fs_event>).
        <fs_event> = value #( objectkey  = instance-salesorder
                              objecttype = zbp_r_eventforwarder=>co_type_salesorder ).
      else.
        continue. " we are not interested in this Sales Order
      endif.
    endloop.

    " now that we checked all instances, only those that we filtered will be forwarded
    if lt_fwd_event is not initial.
      zbp_r_eventforwarder=>raise_forward_event( lt_fwd_event ).
    endif.

We create an internal table of the payload type that is the custom event (we created a global type in the behavior definition)
We loop through all instances that were sent by the SAP standard event (since this is a sales order (header), this will only ever include 1)
As we loop, we select some additional data to do "some complex logic" for checking if this sales order should be forwarded or filtered out.
Once all requirements are met for forwarding the sales order, we fill the custom event payload table.
When the looping is done, we check if any sales orders remained (if we have any custom event payload) and if yes, we now call the method we offered on the custom event RAP BO behavior as global class method and give it the payload we just filled.

And that's all 😲😀

2.2.3 Finishing

As before, we need to configure our custom event (binding) in the event channel in order to forward it to the event broker:

On the event broker, we need to subscribe to that topic, to receive it there:

To summarize, this is what will happen:

A user creates any sales order
R_SalesOrderTP-Created is triggered
Our local consumption of the SAP standard event is called: our local consumption checks if the sales order has any items with products of product type HAWA. If yes, we add it to be forwarded. If no, we disregard it.
If we had any sales order to forward, the ZR_EventForwarder behavior is called via workaround (a little bit nasty by just calling the global class but I could not think of any other way. For example we can't use an action, as actions are invoked via EML MODIFY, which in turn does not allow for RAISE EVENT). This triggers the ZR_EventForwarder-EventForwarded event with our payload
The custom event is forwarded to event broker

2.2.4 Testing

Let's test this. I create a new sales order and I include 1 item that has a product of type HAWA. Meaning my filtering will allow this sales order and eventually trigger my custom event.

Let's see what the event monitor says:

And consuming this message in BTP Event Mesh:

3 I want a larger payload

This is without a doubt the 2nd most discussed topic when talking event based integrations. In order to avoid callback APIs, maybe this is the way to go for you. As of right now, SAP Standard delivers notification events only, meaning small payloads to allow for the creation of fast, simple, integrations that can be easily reused.

You may already noticed that we already covered this in chapter 2. Both when extending the SAP standard event or when creating a custom event to work in combination with standard: I showcased how we can decide our own payload. So far I have only mentioned flat structures, as that is the only type that is supported by Event Mesh on SAP BTP. If you have a need for deep structure payloads, you may want to consider to upgrade to Advanced Event Mesh instead. And instead of creating a brand new example, please check out this blog post by a colleague that goes into deep payload: RAP Events with AEM 3 - Creating Events with deep payload.

Conclusion / Final Words

I hope this blog post helps and gives some ideas how far you can take RAP BO events and influence your integration landscape, in a positive way (of course, that's the end goal).

Is there anything I've missed? Another requirement that you would like to solve with eventing? Or any other questions or comments/feedback? Let me know in the comments and let's see 😊

Integration Suite in 2025 & 2026

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

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

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

Modernize Integrations:

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

End of maintenance. Time is ticking!

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

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

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

Edge Integration Cell

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

Cloud ALM

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

Innovations in 2025

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

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

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

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

Some of the use cases are:

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

MCP Gateway
Agent Orchestration
AI Gateway
Agent Identity Verification
LLM connector

AI for Integration (features in IS)

Joule
Anomaly detection
API traffic predictions
Script Optimization
Configuration Agent

2026 SAP Integration Suite Strategic Outlook:

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

Roadmap for SAP Integration Suite:

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

SAP Codejam on Event Driven Build Process

2026-02-03T18:32:00.943000+01:00

I recently participated in an SAP Code Jam focused on building event-driven processes using SAP Integration Suite (Advanced Event Mesh) and SAP Build Process Automation. The Session was ably conducted and managed by @ajay_soreng and @Rekha_DR .

Codejams are my favorite community events. It pure code with access to the best of SAP in terms of tools, license and expertise. In this session we had a hands-on and walkthrough of a realistic end-to-end scenario rather than a theoretical demo.

The core use case was triggered by a Business Partner creation event in a simulated SAP S/4HANA Cloud system. Once the Business Partner was created and tagged, an event was published to SAP Advanced Event Mesh, where I configured topics, queues, and subscriptions to reliably route the event.

As you see in the below soln. diagram, an event is triggered by App. The advanced event mesh is configured to handle these events and appropriately route it to the build process and finally allow user to act on it.

Event Triggered from a Mock UI:

Configure the Broker Manager - The best part of this code jam:

The plethora of options of Event mesh were made available to us. The Queues, RDPs, Connectors, Tyr me's etc. was a learning experience.

As for the use case,

using a REST Delivery Point, the event was forwarded from Advanced Event Mesh to SAP Build Process Automation, which automatically triggered a business process. From there, the flow combined event-driven automation with human interaction—a user approval step in the SAP Build Inbox—followed by an asynchronous call to a simulated third-party badge system.

The process paused, waited for a callback, and then resumed to complete the flow with a final notification and badge ID.

What stood out most was seeing how cleanly systems were decoupled. The event producer had no awareness of the consumers, and SAP Build acted purely as an orchestrator reacting to events. Configuring and testing this live made the benefits of event-driven architecture very tangible.

Overall, I enjoyed the Code Jam as it was a great practical deep dive into how SAP Advanced Event Mesh and SAP Build Process Automation.

Thanks to all the developer advocates, especially @ajmaradiaga for compiling the content on integration suite and adv. event mesh.

Until the next code jam - Ciao !

JMS Mastery Series Part 1 - The Async Awakening

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

The Async Awakening: Why Synchronous Integration is Holding You Back

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

Introduction

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

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

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

This three-part series explains:

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

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

Key Takeaways

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

The Synchronous Trap: When Defensive Design Hurts

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

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

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

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

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

In synchronous chains, these effects compound.

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

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

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

Common Async Candidates

These integration patterns rarely need synchronous processing:

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

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

When Synchronous IS the Right Choice

Not everything should be asynchronous. Synchronous is correct when:

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

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

The Hidden Costs

Simple to understand ≠ simple to operate reliably at scale.

What works smoothly in development often becomes problematic in production:

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

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

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

A Practical Decision Framework

Instead of defaulting to sync, use this framework:

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

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

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

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

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

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

A Note on Advanced Hybrid Patterns

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

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

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

However, implementing these patterns requires significant infrastructure:

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

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

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

Architect's Note: Even Synchronous Can Be Loosely Coupled

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

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

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

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

Synchronous Patterns with some Async Benefits

With some adapters we can achieve higher decoupling:

CI HTTP Adapter with Retry:

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

CI SuccessFactors OData V2 adapter with Retry:

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

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

Conclusion: Rethinking the Default

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

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

Key takeaways:

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

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

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

Coming up in Part 2: The JMS Revolution

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

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

JMS Mastery Series Part 3 - JMS in Production

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

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

Confessions of a JMS Advocate (Part 3 of 3)

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

Considerations and Limitations

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

Queue Limits

SAP Help: JMS Resource Limits and Optimizing Their Usage

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

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

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

Other limits are generous and should not require workarounds:

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

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

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

Dead Letter Queue Handling

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

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

API Operations

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

Best Practices and Recommendations

Common Misconception: Exception Subprocess Pattern

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

Keep Initial iFlow Simple

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

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

Queue Architecture for Complex Flows

How many queues for a long, complex flow?

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

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

But balance it: Consider the JMS queue limit constraint.

Retry Strategy

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

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

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

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

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

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

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

Retry configuration best practices

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

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

Leverage Adapter-Level Retries

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

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

Event-Driven Architecture (EDA) vs. JMS

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

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

Yes, but for different reasons than you might think.

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

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

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

When Event Broker Excels: Pub-Sub Patterns

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

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

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

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

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

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

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

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

Cost Considerations

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

SAP S/4HANA Integration

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

Advanced EDA Requirements

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

Example use cases:

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

JMS: The King of CI Workflow Async Processing

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

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

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

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

Know which kingdom you're in:

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

Final Thoughts

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

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

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

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

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

Share your thoughts

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

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

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

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

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

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

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

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

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

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

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

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

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

We look forward to your active participation and valuable feedback.

Joule Is Not a Chatbot: How AI Agents on SAP BTP Help North American Utilities Reduce Risk

2026-02-09T10:02:41.303000+01:00

Joule Is Not a Chatbot: How AI Agents on SAP BTP Help North American Utilities Reduce Risk

Introduction: The Misunderstanding That Holds Utilities Back

Across North America, utilities are under pressure to modernize customer experience while reducing operational risk. When SAP introduced Joule, many utility teams assumed it was “just another chatbot.” It isn’t.

Joule is an AI agent framework that understands business context, triggers governed processes and interacts with SAP systems safely — something a traditional chatbot cannot do.

Utilities don’t need another conversational interface. They need intelligent agents that reduce risk, automate decisions, and protect the clean core.

This is where the SAP BTP AI Foundation becomes the strategic control plane, allowing utilities to innovate without modifying their S/4HANA or IS-U core—preserving a Clean Core while delivering cutting-edge automation.

⭐Why Joule Is More Than a Chatbot

During my learning journey with Joule, one misconception stood out immediately: many people assume Joule is “just another chatbot.” But when you look at how it works on SAP BTP, it becomes clear that Joule is fundamentally different.

A chatbot answers questions. A Joule Agent acts.

Intent Detection: Unlike a chatbot that triggers keywords, Joule identifies a utility consumer's true intent (e.g., a "high bill" might actually be a "meter dispute").
Policy Enforcement: Joule checks SAP BTP Business Rules before any transaction occurs.
Action-Oriented: It initiates the SAP Build Process Automation workflow directly.
Reliable (RAG): Joule leverages Retrieval-Augmented Generation via the SAP HANA Cloud Vector Engine to provide answers grounded in actual utility regulatory manuals, eliminating hallucinations.
Responsible: Every action follows SAP BTP’s security framework, ensuring PII is masked and every interaction is auditable.

In regulated industries like utilities, this shift from conversational assistance to policy-driven automation is significant. It’s not about chatting — it’s about operational discipline.

⭐The Real Problem: Utilities Don’t Need Chatbots — They Need Governance

Most utilities already experimented with chatbots. The results were predictable:

Inconsistent answers
No integration with IS‑U
No audit trail
No process governance
High risk of incorrect customer commitments

A chatbot can talk. An AI agent can act — safely, consistently, and with full traceability.

That difference is everything.

⭐A Reference Architecture Use-Case

A large North American utility was struggling with high operational risk in its customer contact center. Agents were making inconsistent decisions about:

High‑bill disputes
Move‑in/move‑out exceptions
Meter investigation requests
Payment arrangement eligibility

The utility deployed Joule AI agents on SAP BTP, connected to IS‑U through Integration Suite.

Based on scenario modelling and validated utility process patterns, this agent‑orchestrated design is expected to:

reduce manual exceptions by ~35%, and
improve billing accuracy by ~18%. These are directional estimates, not production KPIs.

This is the difference between a chatbot and an AI agent.

⭐Architecture: How AI Agents Actually Work in a Utility Landscape

The architecture relies on the SAP BTP AI Foundation. Joule acts as the orchestration layer, while SAP Integration Suite serves as the governed gateway to the IS-U backend. By utilizing SAP Build Process Automation, we ensure that the AI agent never executes a 'Write' command directly to the ERP; instead, it triggers a governed workflow that includes Human-in-the-Loop approval for high-risk billing adjustments.

⭐How It Works: The 5‑Step AI Agent Flow

1. Intent Identification: Joule receives a request and identifies the underlying business need.

2. Policy Check: The agent checks eligibility and risk flags against business rules.

3. Workflow Trigger: SAP BTP initiates a governed workflow via SAP Build.

4. Human-in-the-Loop Validation: High-value billing exceptions are routed to a supervisor’s 'My Inbox' for final sign-off.

5. Clean Core Integration: Integration Suite updates IS-U (Billing, FICA, or Device Management) via OData APIs, keeping the core clean.

This is what separates a safe enterprise AI agent from a generic chatbot.

⭐Why This Matters for Utilities

Utilities operate in a world where:

Every customer interaction is regulated
Every billing decision must be auditable
Every exception has financial impact
Every process must protect the clean core

AI agents on SAP BTP give utilities:

Governed automation
Consistent decisions
Reduced operational risk
Faster customer resolution
A clean core that stays clean

This is not hype — it’s a practical modernization path.

⭐Key Takeaways

Governed Framework: Joule is an agent, not a chatbot.
SAP BTP is the control center, ensuring safe, auditassssble and compliant actions.
Utilities reduce risk by routing all decisions through workflows and rules.
Integration Suite protects the clean core by using OData/API-led connectivity instead of legacy 'Z' enhancements.
AI agents deliver measurable impact: fewer exceptions, faster resolution, higher accuracy.
Rapid ROI: Leveraging pre-built SAP Discovery Center missions for Joule allows utilities to move from pilot to production in under 90 days.

⭐Conclusion: The Future of Utility Modernization Is Agent‑Driven

Utilities don’t need conversational gimmicks. They need AI agents that understand processes, enforce rules, and reduce risk.

Joule + SAP BTP delivers exactly that.

This is the next evolution of utility modernization — and it’s already happening across North America.

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Step 4: generate the MTA deployment descriptor:

npm install
cds build --production
cds add mta

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

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

cds build
cf deploy mta_archives/your-archive.mtar

Step 6: Testing the Integration

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Step 5: Prepare the MTA Deployment Descriptor

npm install
cds build --production
cds add mta

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

Step 6. Crucial Workaround: Mocking the Management Endpoint

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

Workaround:

1). create event mesh service instance & key

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

With below parameters:

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

Then create a service key and copy its value.

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

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

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

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

5). add below topic subscription to the queue

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

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

Step 7: Build and Deploy

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

Step 8: Testing

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

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

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

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

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

Introduction

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

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

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

This article applies to:

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

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

Prerequisits:

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

Migration Steps

Step 1: Create RFC-Destinations.

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

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

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

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

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

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

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

Step 2: Add Certificates to the Trust Store.

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

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

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

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

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

Step 4: Activate BC-Set.

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

Transaction: SCPR20

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

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

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

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

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

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

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

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

Add Event Linkages for the new message type:

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

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

Step 6: Add validation Instance for the SAP BTP.

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

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

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

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

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

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

Cloud response should be 200 OK.

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

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

Migration Completed

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

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

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

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

Introduction

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

🟢 Delivered Roadmap Item

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

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

1️⃣ Overview: Why Discover and Publish Events

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

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

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

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

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

3️⃣ Register and Configure Your Advanced Event Mesh Instance

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

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

Note: Only shared events will show up in Developer Hub

4️⃣ Discover Events in SAP Developer Hub

Steps to explore events once the destination is set:

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

Browse events grouped by application domain

5️⃣ Create Products and Publish Events

Explain how to group events into products and publish them:

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

Summary

In this blog you learned how to

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