SAP BTP – IS – How to become a SAP Integration Suite Consultant beyond SAP CPI – SAP EM/AEM Part II

Disclaimer: This isn’t a tutorial about how button click works. No, the audience of this post are engineers with all levels of experience, from Junior up to Senior, which might have fallen into that “I’m SAP CPI”. My goal has been to help you move from just obvious to”Architectural Thinking – SAP BTP Integration Suite Consultant”. You got the basics, now let’s move on.

Introduction

In my last post, we talked about SAP APIM. Today we are going to talk about Event-Driven Architecture (EDA) using SAP Event Mesh (EM) and Advanced Event Mesh (AEM).

This is the first of four posts (the last one a summary because I will not explain SAP CPI, I’m expect that you know already), and we will navigate you through how to stop being “SAP CPI Developer” and become an SAP Integration Suite Consultant – “Generals”.

Second we will start with SAP Event Mesh (EM) and Advanced Event Mesh (AEM).

Sun Tzu once said: “In the midst of chaos, there is also opportunity.”

In our world, logistics is how we handle data flow. If you are simply connecting dots, you are creating disorder. But when you leverage the synergy of the entire Suite—especially the SAP Event Mesh (EM/AEM)—you finally bring order to the chaos or stantard events or custom events over the event-driven architecture.

The “General” vs. The “Soldier” (A quick story)

Let me show you a imaginare conversation conversation

The following dialogue illustrates a common situation in integration projects when SAP BTP EM/AEM is treated as an afterthought instead of an architectural capability.

Enterprise Architect / Solution Architect

Our client is already using SAP standard events and custom events for others process.

For critical processes, we can’t afford to lose messages or have the S/4HANA tied up during maintenance.

We need a clean, resilient design.

How do we test this with SAP Event Mesh and SAP Advanced Event Mesh before moving to custom events?

SAP CPI Developer

Honestly… I’m a bit scared of that. I don’t really get how Pub-Sub or Topics work. EDA sounds way too complex. Can’t we just keep it simple? The partner calls my CPI endpoint via HTTPS, I try to post to SAP, and if it fails, I’ll just trigger an error email or a basic retry.

Enterprise Architect / Solution Architect

I get the fear. But in an event-driven world, control doesn’t disappear—it just shifts.

The Event Mesh becomes our safety net. The partner publishes, the broker holds the message, and CPI/S4 only consumes it when they’re ready. If S/4 is offline, the message doesn’t die.

We don’t kill the CPI with retries..

(Awkward silence)

SAP BTP – Integration Suite Consultant

I get the concern, but in an event-driven world, control doesn’t disappear—it shifts.

The Event Mesh becomes our safety net. The partner publishes, the broker holds the message, and CPI/S4 only consumes it when ready.

If S/4 is offline, the message doesn’t die. We stop killing the CPI with retries.

Let’s run a PoC with standard events first to prove the resilience.

Final Proposal: SAP BTP Integration Suite Consultant

When you move to Event Mesh, you aren’t just changing an endpoint. You’re redefining where the “safety” happens.

Standard SAP Events → SAP Event Mesh: Native, simple, and perfect for the SAP ecosystem.Custom/Multi-platform Events → Advanced Event Mesh (AEM): This is for the heavy lifting—more protocols, more capacity, and massive decoupling.Stop guessing with Pub-Sub: We don’t throw messages into the dark. The producer publishes, the broker saves it, and CPI subscribes only when it’s ready.Kill the fear of losing data: In a synchronous world, a crash kills the message. With AEM (AMQP), that message sits there safely until it’s processed.

Charting New Responsibilities on the possible migration from external vendors: Who Does What?

To witness the transformation from Soldier – SAP CPI to General – SAP BTP Integration Suite Developer, one must reconfigure their mindset, gain governance experience, and, most importantly, understand the clear boundaries of authority for each role.

Integration Architect

This is the person who draws the “road map.” When migrating from an external broker, they ensure the architecture isn’t just a “copy and paste” job.

Messaging Patterns: Decides how to translate patterns from the old broker to SAP (e.g., transforming a RabbitMQ “Exchange” into “Topics” and “Queues” in AEM).Topic Strategy: Defines the Topic Hierarchy (Taxonomy). In AEM, this is vital for enabling intelligent routing and message filtering.Payload Definition (CloudEvents): Encourages the use of the CloudEvents standard so that events remain platform-agnostic, facilitating future scalability.Global Error Handling: Defines the Dead Letter Queue (DLQ) policy. If an event fails within SAP, where does it go? How is it reprocessed?

Solution Architect

The Solution Architect doesn’t just look at the code; they look at how the broker fits into the corporate ecosystem and the budget.

Tool Selection (EM vs. AEM): Decides whether the scenario requires the standard Event Mesh (native, simple, S/4HANA events) or Advanced Event Mesh (high volume, multi-cloud, complex protocols like MQTT/Solace).Business Continuity: Defines SLAs. If the previous broker offered global redundancy, they ensure AEM delivers the same level of resilience.TCO Analysis (Total Cost of Ownership): Evaluates the cost of data egress from external brokers versus the savings of keeping traffic within the SAP BTP backbone.Security & Governance: Defines how identities (OAuth, certificates) will be migrated to ensure only authorized systems publish or subscribe to events.

SAP BTP Integration Consultant

This is the person with hands-on expertise (EM, AEM) who ensures the data flow never stops.

Protocol Mapping: If the legacy broker used JMS and SAP EM uses REST/AMQP, they configure the adapters and protocol bridges.Event Mesh/AEM Configuration: Creates the Queues, Topic Subscriptions, and manages the Bridges between different data centers or clouds.Consumer Implementation: Within SAP Integration Suite (CPI), they configure iFlows to be “Event-Driven.” Instead of polling for data, they set up Webhooks or AMQP senders to react instantly.Performance & Throttling: Ensures the flow from AEM doesn’t “overwhelm” the S/4HANA backend by configuring concurrency limits and backpressure.Technical Migration: Executes the Cutover plan. They handle moving pending messages from the old broker to the new one without loss or duplication.

Image 1 – SAP Integration Suite Consultant

​  Disclaimer: This isn’t a tutorial about how button click works. No, the audience of this post are engineers with all levels of experience, from Junior up to Senior, which might have fallen into that “I’m SAP CPI”. My goal has been to help you move from just obvious to”Architectural Thinking – SAP BTP Integration Suite Consultant”. You got the basics, now let’s move on.IntroductionIn my last post, we talked about SAP APIM. Today we are going to talk about Event-Driven Architecture (EDA) using SAP Event Mesh (EM) and Advanced Event Mesh (AEM).This is the first of four posts (the last one a summary because I will not explain SAP CPI, I’m expect that you know already), and we will navigate you through how to stop being “SAP CPI Developer” and become an SAP Integration Suite Consultant – “Generals”.Second we will start with SAP Event Mesh (EM) and Advanced Event Mesh (AEM).Sun Tzu once said: “In the midst of chaos, there is also opportunity.”In our world, logistics is how we handle data flow. If you are simply connecting dots, you are creating disorder. But when you leverage the synergy of the entire Suite—especially the SAP Event Mesh (EM/AEM)—you finally bring order to the chaos or stantard events or custom events over the event-driven architecture.The “General” vs. The “Soldier” (A quick story)Let me show you a imaginare conversation conversationThe following dialogue illustrates a common situation in integration projects when SAP BTP EM/AEM is treated as an afterthought instead of an architectural capability. Enterprise Architect / Solution ArchitectOur client is already using SAP standard events and custom events for others process.For critical processes, we can’t afford to lose messages or have the S/4HANA tied up during maintenance.We need a clean, resilient design.How do we test this with SAP Event Mesh and SAP Advanced Event Mesh before moving to custom events?SAP CPI DeveloperHonestly… I’m a bit scared of that. I don’t really get how Pub-Sub or Topics work. EDA sounds way too complex. Can’t we just keep it simple? The partner calls my CPI endpoint via HTTPS, I try to post to SAP, and if it fails, I’ll just trigger an error email or a basic retry.Enterprise Architect / Solution Architect I get the fear. But in an event-driven world, control doesn’t disappear—it just shifts.The Event Mesh becomes our safety net. The partner publishes, the broker holds the message, and CPI/S4 only consumes it when they’re ready. If S/4 is offline, the message doesn’t die.We don’t kill the CPI with retries..(Awkward silence)SAP BTP – Integration Suite ConsultantI get the concern, but in an event-driven world, control doesn’t disappear—it shifts.The Event Mesh becomes our safety net. The partner publishes, the broker holds the message, and CPI/S4 only consumes it when ready.If S/4 is offline, the message doesn’t die. We stop killing the CPI with retries.Let’s run a PoC with standard events first to prove the resilience.Final Proposal: SAP BTP Integration Suite ConsultantWhen you move to Event Mesh, you aren’t just changing an endpoint. You’re redefining where the “safety” happens.Standard SAP Events → SAP Event Mesh: Native, simple, and perfect for the SAP ecosystem.Custom/Multi-platform Events → Advanced Event Mesh (AEM): This is for the heavy lifting—more protocols, more capacity, and massive decoupling.Stop guessing with Pub-Sub: We don’t throw messages into the dark. The producer publishes, the broker saves it, and CPI subscribes only when it’s ready.Kill the fear of losing data: In a synchronous world, a crash kills the message. With AEM (AMQP), that message sits there safely until it’s processed.Charting New Responsibilities on the possible migration from external vendors: Who Does What?To witness the transformation from Soldier – SAP CPI to General – SAP BTP Integration Suite Developer, one must reconfigure their mindset, gain governance experience, and, most importantly, understand the clear boundaries of authority for each role.Integration ArchitectThis is the person who draws the “road map.” When migrating from an external broker, they ensure the architecture isn’t just a “copy and paste” job.Messaging Patterns: Decides how to translate patterns from the old broker to SAP (e.g., transforming a RabbitMQ “Exchange” into “Topics” and “Queues” in AEM).Topic Strategy: Defines the Topic Hierarchy (Taxonomy). In AEM, this is vital for enabling intelligent routing and message filtering.Payload Definition (CloudEvents): Encourages the use of the CloudEvents standard so that events remain platform-agnostic, facilitating future scalability.Global Error Handling: Defines the Dead Letter Queue (DLQ) policy. If an event fails within SAP, where does it go? How is it reprocessed?Solution ArchitectThe Solution Architect doesn’t just look at the code; they look at how the broker fits into the corporate ecosystem and the budget.Tool Selection (EM vs. AEM): Decides whether the scenario requires the standard Event Mesh (native, simple, S/4HANA events) or Advanced Event Mesh (high volume, multi-cloud, complex protocols like MQTT/Solace).Business Continuity: Defines SLAs. If the previous broker offered global redundancy, they ensure AEM delivers the same level of resilience.TCO Analysis (Total Cost of Ownership): Evaluates the cost of data egress from external brokers versus the savings of keeping traffic within the SAP BTP backbone.Security & Governance: Defines how identities (OAuth, certificates) will be migrated to ensure only authorized systems publish or subscribe to events.SAP BTP Integration ConsultantThis is the person with hands-on expertise (EM, AEM) who ensures the data flow never stops.Protocol Mapping: If the legacy broker used JMS and SAP EM uses REST/AMQP, they configure the adapters and protocol bridges.Event Mesh/AEM Configuration: Creates the Queues, Topic Subscriptions, and manages the Bridges between different data centers or clouds.Consumer Implementation: Within SAP Integration Suite (CPI), they configure iFlows to be “Event-Driven.” Instead of polling for data, they set up Webhooks or AMQP senders to react instantly.Performance & Throttling: Ensures the flow from AEM doesn’t “overwhelm” the S/4HANA backend by configuring concurrency limits and backpressure.Technical Migration: Executes the Cutover plan. They handle moving pending messages from the old broker to the new one without loss or duplication.Image 1 – SAP Integration Suite ConsultantConclusion — Part IIBeing a pro means knowing that CPI is not a shock absorber. Using Event Mesh or AEM is how you build a system that can actually handle the “real world events” (where systems go offline and things break).In the next part III, we’ll talk about the monst complex one, we are going to speak with T-REX – SAP Integration Advisor – B2B EDI Integrations.Kind regards,Viana.References links compilation:Get Started with SAP Integration Suite, Advanced Event MeshSAP COURSE – FREE – Discovering Event-Driven Integration with SAP Integration Suite, advanced event meshWhat Is SAP EventMesh ?What’s New for Event Mesh ?REST APIs for SAP Event Mesh Default PlanEvent-driven ArchitectureUnderstanding Event Driven ArchitectureWhat Is SAP Integration Suite, Advanced Event Mesh ?SAP Integration Suite, Advanced Event Mesh – Getting StartedAfter the learn path, check those blogs and try to replicate just to learn.Now is funny, I will provide some blogs from that past 2021 when I touch SAP EM for the first time, the AEM was in creationSAP CPI – Event Driven Architecture (Z Event) with S4HANA and SAP EMSAP EM – Webhook mechanism – SAP CPISAP CPI – Cloud Event Broker – SAP EM for asynchronous patternsSAP EM – Event Broker for Events S4HANAAfter those blogs together with colleague @ Andrzej Halicki we wrote the SAP Enterprise Messaging in 2021, the E-bite is not available the content and with AEM comes to be obisoletSAP CPI – Cloud Event Broker – SAP EM for asynchronous patternsSAP EM – Event Broker for Events S4HANASAP Cloud Platform Enterprise Messaging – Making S/4HANA Event Notification EasyCloud Integration – Connecting to Messaging Systems using the AMQP AdapterIDoc with Integration Suite, Advanced Event Mesh using the Event Add-OnSAP Event Mesh vs. SAP Integration Suite, Advanced Event MeshIDoc with Integration Suite, Advanced Event Mesh – Process Integration meets EventingSAP Integration Suite, Advanced Event Mesh Blog CollectionGet Started with SAP Integration Suite, advanced event meshAdvanced Event Mesh: Basic Concepts Advanced Event Mesh: Create your first event brokerSAP Advanced Event Mesh – Manage Advance Event Mesh with API’s Automating Advanced Event Mesh Broker Creation Advanced Event Mesh: ReplayAdvanced Event Mesh: Queue Enabling In-Order processing with SAP Integration Suite, advanced event mesh Partitioned QueuesSecuring SAP Advanced Event Mesh: OAuth Configuration and SEMP API IntegrationAdvanced Event Mesh: Client Authentication – Basic / OAuth Advanced Event Mesh Connectors and Easy Event-Driven Example of S/4HANA with Amazon S3 IntegrationComplete Guide: Setting Up CAP Plugin for Advanced Event Mesh with OAuth Authentication Configure SAP Integration Suite, Advanced Event Mesh Distributed TracingEvaluate SAP Integration Suite, Advanced Event Mesh Datadog Distributed TracingAdvanced Event Mesh:TroubleshootingWhy Event-Enabling MDG with SAP BTP Advanced Event Mesh is a Game ChangerSAP Event Mesh Architecture PatternsSAP Advanced Event Mesh – Manage Advance Event Mesh with API’s    Read More Technology Blog Posts by Members articles 

#SAP

#SAPTechnologyblog