Event enabling SAP Data Replication Framework with Advanced Event Mesh & AIFAEM

[AlexPfeil]

Introduction

In today’s interconnected enterprise landscape, real-time data movement and event-driven architectures are no longer optional—they are foundational. SAP offers a powerful trio of technologies to enable this: the SAP Data Replication Framework (DRF), SAP Integration Suite – Advanced Event Mesh (AEM), and the Application Interface Framework Event Mesh Add-On (AIFAEM).

SAPa Data Replication Framework (DRF)

The Data Replication Framework is a tool used to replicate master data accurately and efficiently across SAP and non-SAP systems, ensuring data consistency and integrity through various methods such as real-time replication, scheduled batch processing, and manual replication. It utilizes technologies such as SOAP or IDocs for asynchronous outbound services.

SAP Integration Suite – Advanced Event Mesh (AEM)

AEM is SAP’s enterprise-grade event broker that supports asynchronous, decoupled communication across distributed systems. It enables real-time event streaming, dynamic routing, and scalable integration across hybrid and multi-cloud environments. AEM supports open standards like CloudEvents and integrates with Kafka, REST, and MQTT, making it a versatile backbone for event-driven architectures.

AIFAEM – The Missing Link

To bridge traditional SAP systems like ECC or even S/4HANA with AEM, SAP introduced AIFAEM—an ABAP-based add-on that extends the Application Interface Framework (AIF). AIFAEM allows you to define and expose custom business events based on the BOR (Business Object Repository) framework. These events can then published to AEM in CloudEvents format, enabling seamless integration with modern event consumers.

AIFAEM supports:

• Event creation from both ECC (SAP NW 7.31) and S/4HANA (SAP NW 7.55 and above)
• CloudEvents formatting and structure mapping
• Monitoring via SAP Fiori apps and transaction /AIF/ERR
• Out-of-the-box connectivity to AEM without consuming AIF message quotas

Why This Matters

Together, DRF, AEM, and AIFAEM form a robust pipeline for event-driven data replication. DRF ensures the right data is selected and prepared, AIFAEM transforms it into events, and AEM distributes it across your enterprise landscape. This architecture empowers developers and architects to build responsive, scalable, and loosely coupled systems that are ready for the future of integration.

Disclaimer

The clean core approach for a connection between DRF and AEM, and I would recommend to apply this pattern, would be the Usage of a Standard DRF Replications provided by SAP which target an Iflow on Integration Suite (SOAP, XI or IDoc Sender Adapter) and pass the Event to AEM using the AEM Adapter. This would be a configuration only scenario and also can be monitored with SAP Application Interface Framework. 

The pattern explained in the following is bypassing the BTP Cloud Integration, AIFAEM is connecting directly to AEM. But since DRF does not support a REST connection, AIFAEM has to be involved and therefore a custom ABAP Class is required. Keep in mind that in my example the custom class is quite huge, because it is a copy of the Standard Business Partner Replication Class + adjustments for AIFAEM. Also for AIFAEM further custom objects are required (Action Function Module, custom DDIC objects).

 

How it works

1) DRF Customizing & Custom DRF Class

The Standard Object we are trying to use is 986 - Business Partner. You´ll find it in DRFIMG -> Enhance Default Settings for Outbound Implementations -> Define Business Objects

The corresponding Outbound Implementation (using the Standard SOAP Proxy ) is 986_3.

Since we don´t want to use SOAP, but still want to utilize the Object itself, we need to define a custom Outbound Implementation. This though does not work with 986, that is why I needed to copy 986 to Z_986:

Then we copy the Outbound Implementation 986 to the custom Outbound implementation Z_986_3

The logic behind the Outbound implementation is in a Class using the methods of interface IF_DRF_OUTBOUND. For 986_3 it is CL_MDG_BS_BP_REL_SERVICE_DRF

This class also needs to be copied into a Z-Class. For Z_986_3 I created Z_CL_DRF_2_AIFAEM_BP_REPL:

The class is referencing itself in the Constructor method. This needs to be changed to the new Z-Class. I have uploaded the Z-Class to my Github Repo here.

In IF_DRF_OUTBOUND~SEND_MESSAGE we have the Proxy Call

lo_bp_bupa_outbound->exec_async_out

Here in the parameter lt_bs_bp_data the Business Partner data is passed to the Proxy Method. Unfortunately not in the Format of the Outbound SOAP Interface, but Data Type mdg_bs_bp_t_extern .

With the "Where Used List" of this Data Type and Search (STRG + F) for "Map" I could find the Method CL_MDG_BP_BUPA_SI_OUT->DO_MAPPING_OUTBOUND. So I removed the Proxy Call and added the mapping and AIF Call

see Line 1158 in the Z-Class in the Github Repo mentioned above.

Now we are passing Data Type mdg_bp_bpsuitebulk_rplct_req_m to AIF. This is the Proxy Message type.

Of course our Outbound Implementation needs to be assigned to a Replication Model

This also needs to be activated on "Define Replication Model" Level.

2) AIF Customizing

For AIFAEM we need a Target Data Type with "CONTROLLER" and ""Since we are using a Proxy Data Type, we cannot design the Data Type in SE11, it has to be done either in SAP PO (ESR) and generated or in SPROXY. I decided to go with SPROXY.

• SPXNGENAPPL -> Define Namespace for your Data Type
• SPROXY -> Create -> Data Type. Here we need to reference the Data Type from the Standard Interface

Standard Proxy:

Custom Proxy:

In the Internal View we see the Name of the ABAP Structure we can use in AIF Interface Definition

Since Proxy Structures already use "CONTROLLER" Tables, we cannot name our AEM Controller Structure this way. This is why it is called CONTROLLER1.

Creation of  AIF Interface

Raw Structure = Structure passed from DRF to AIF

SAP Structure = Structure passed from AIF to AEM

AIF Structure Mapping:

Static topic. Can be adjusted to dynamic if needed.

Move-Corresponding, so we don´t have to map the individual Fields

Action:

Since we cannot use "CONTROLLER" which is needed in AIFAEM Standard Action, we need a Custom DRF Action, which is essentially a copy of the Standard Action, but with CONTROLLER1 referenced instead of CONTROLLER --> see Github Repo here 

Test

Let´s say i want to replicate this BusinessPartner:

Testing in DRFOUT:

--> manual Filter criteria

Success in the Logs:

/N/AIF/ERR

I consumed the topic in SAP Cloud Integration:

That´s it! Happy Eventing!