Exploring Integration Options available in SAP Master Data Governance on S/4HANA
(Vijayaprabakaran Sankar holds the role of an SAP Integration Architect, with a primary focus on SAP Integration solutions. His expertise encompasses a broad spectrum within the realm of SAP Integration, notably including the SAP Integration Suite, SAP Process Integration/Process Orchestration (SAP PI/PO), and Event-Driven Architecture, with a specialization in Event Mesh and Azure Service Bus.)
SAP Master Data Governance (MDG) is a comprehensive solution that enables organizations to manage their critical master data effectively and maintain data consistency across various systems. However, the success of MDG implementation often depends on its ability to seamlessly integrate with other SAP and non-SAP applications within an enterprise landscape.
In this blog post, we will explore the integration options available in SAP MDG, highlighting how they enable organizations to streamline their master data management processes and drive business value.
Scenarios need to be considered:
A customer operating a diverse range of systems, including multiple SAP instances, non-SAP systems, and third-party applications, all containing master data that needs to be shared across the organization. To optimize the flow of master data, the customer has taken the strategic step of implementing SAP Master Data Governance on S/4 HANA within their landscape. Their overarching objective is to harmonize master data management by seamlessly integrating all the systems within their landscape with SAP MDG.
In this context, we will encounter the following scenarios:
- Scenario 1: SAP MDG on S/4 Hana Integration with SAP S/4 Hana or SAP ECC Systems
- Scenario 2: SAP MDG on S/4 Hana Integration with Non-SAP Systems and Third-Party Applications
Scenario 1: SAP MDG on S/4 Hana Integration with SAP S/4 Hana or SAP ECC Systems
The replication of master data from the SAP Master Data Governance (MDG) system into SAP S/4HANA and SAP ECC systems can be orchestrated with the help of the Data Replication Framework (DRF).
- Data replication begins with creating or modifying master data in SAP MDG. This data covers entities like customers, products, vendors, etc. When changes occur, a Change Request (CR) is generated and goes through an approval workflow process. Approved CRs move ahead.
- Data fields are mapped from MDG to the target SAP S/4HANA or ECC, with transformations and filters to send specific data objects to the specific target system applied.
- After approval and validation, data is triggered for replication. Communication channels, like IDocs or Web Services, are chosen based on configuration for data transfer via DRF.
- It is recommended to utilize Web Services over IDocs for this communication.
More details about the Data Replication Framework configuration can be found in the following link. https://help.sap.com/docs/SAP_S4HANA_ON-PREMISE/6d52de87aa0d4fb6a90924720a5b0549/236d552f22654f759b5533b2d22ecbb3.html
Scenario 2: SAP MDG on S/4 Hana Integration with Non-SAP Systems and Third-Party Applications
In scenario 2, the customer expresses a desire to connect SAP MDG with non-SAP systems and third-party applications. To accommodate this requirement, the following five options can be considered, depending on the specific circumstances.
Option 1: EDA – Using Standard Events (Notification Events)
Option 1 involves harnessing the power of Event-Driven Architecture and the Event Enablement Framework within SAP S/4 Hana to seamlessly integrate SAP MDG with all other systems.
With the Event Enablement Framework, any data object creation, or modification (including deletion) triggers a notification event and sends it to the Event Mesh. This event includes event type and Object ID details and the size of the message is very minimal. In this option, the subsequent OData call needs to be initiated either from SAP Cloud Integration or the target system to get and access the full object details based on the Object ID.
The standard events and OData APIs available in S/4 Hana can be found in the following link.
OData APIs : https://api.sap.com/products/SAPS4HANA/apis/ODATA
It’s important to highlight that the standard OData API does not contain key mapping and target system information, essential for identifying the target system and its corresponding ID in SAP MDG. Consequently, there is a need to enhance the OData API by incorporating these critical key mapping and target system details.
The step-by-step guide for the Notification Events pushed to Event Mesh with SAP Event Enablement Framework can be found in the following blog written by Syed Ejazuddin.
Note that utilizing SAP MDG’s Event Enablement Framework, events can only be sent to Event Mesh and not to other event brokers.
Option 2: EDA – Using NetWeaver Addon (Data Events)
In this option, the SAP Netweaver add-on for Event Enablement will be used to transmit data events with complete details directly to the Event Mesh. This eliminates the need for subsequent calls.
However, it’s worth noting that this option requires customization to ensure data events are triggered with all necessary details.
The step-by-step guide for the Data Events pushed to Event Mesh with SAP Event Enablement Add-on can be found in the following blog written by Fiona Zhang.
It should be noted that in addition to sending events to Event Mesh, events can also be sent to other event brokers using the SAP Netweaver add-on for Enablement Framework.
Option 3: Using DRF Framework, Event Mesh, and SAP Cloud Integration
In this option, we combine the DRF Framework with Event Mesh, and Cloud Integration to transmit full object details to the Event Mesh via SOAMANAGER’s web service setup, without needing extra calls or customization. It should be noted that the web services also include information about target systems and key mapping.
However, due to the message’s large size and the potential that not all object details are needed by the target system, data security concerns may arise.
The standard web services available in S/4 Hana can be found in the following link.
Option 4: Using DRF Framework and SAP Cloud Integration
This option involves using the DRF framework and SAP Cloud Integration as the traditional integration method. When an object undergoes creation, modification, or deletion in SAP MDG, the DRF framework pushes the data to SAP Cloud Integration through web services. SAP Cloud Integration then determines how to route the object to the target system based on predefined logic.
It should be noted that in this setup, any future addition of new systems will require updates to the logic within SAP Cloud Integration to accommodate the changes.
Option 5: EDA – Using Azure Service Bus and API Management
For customers with a diverse landscape including Non-SAP systems, third-party systems, and Azure-based applications, this option offers an effective solution. It combines Event Mesh, Azure API Management, Azure Service Bus, and SAP Cloud Integration to streamline event handling.
Here’s how it works:
- When an object is created or modified, a notification event is generated using the Event Enablement framework. This event is sent to the Event Mesh.
- The Event Mesh triggers a webhook, which forwards the event to Azure Service Bus. This ensures that events are available in both Event Mesh and Azure Service Bus for further processing. In the future, there’s a plan to introduce an Event connector, currently in Beta, which will enable bidirectional event transmission between Event Mesh and Azure Event Grid inbuilt.
- By leveraging Azure API Management, the need for a cloud connector is eliminated when making OData service calls to fetch complete details, as these services are published in API Management.
This approach optimizes event handling and integration for customers with a diverse system landscape, offering flexibility and potential for future enhancements.
The OData API needs to be enhanced in this option as well to include the key mapping and target system details, as in option 1.
SAP MDG offers a variety of integration options that can be used to connect it to other systems. Of course, it’s worth noting that other alternative integration approaches also exist. The selection of the integration option is purely based on the specific needs and integration strategy of the enterprise.
I trust this blog post has provided valuable insights. Please let me know if you have any questions.
Thanks to Pramod Ramamurthy, Rakhi Bose, and Anusha Pati for your valuable input on the solution design.