Many organizations with an SAP-centric ERP landscape are embarking on business transformation journeys, moving from SAP ECC to S/4HANA. At the middleware layer, this shift is accompanied by migrating from the trusted workhorse SAP PI/PO to the more modern SAP Integration Suite. To support customers on this path, SAP continues to innovate — for example, by introducing support for pipeline approach in migration tooling, providing Clean Core modernization recommendations, and much more.
Today, let’s explore one specific area: IDoc-based scenarios in SAP PI/PO and their evolution in a cloud-native world.
IDoc has long been a reliable standard for data interchange in SAP, especially in B2B contexts. While IDocs are still supported in SAP Integration Suite via native IDOC adapter, modern cloud-native integration architectures increasingly emphasize open standards and protocols like OData, REST APIs, AMQP and so on. In line with this, SAP recommends adopting modern patterns such as events and APIs instead of IDocs, aligning with the broader Clean Core philosophy.
This article demonstrates how an IDoc-based scenario in SAP PI/PO can be migrated to Integration Suite through modernization — not merely a lift-and-shift approach. While modernization may take more effort initially, it delivers long-term benefits: interoperability, cloud-native agility, future readiness to absorb SAP released innovation and upgrades. The good news? With the Clean Core modernization recommendations for IDocs. released in Q2 2025, migration assessment reports now directly suggest API and event-based alternatives to achieve the same functional requirement.
Let’s illustrate this with an example.
In our SAP PI/PO system, we have an outbound IDoc interface (ADRMAS03) used to push Business Partner (BP) address changes to an external application, SAP Commerce Cloud, through REST API.
When we run the scenario evaluation using Migration Assessment capability of Integration Suite, on this SAP PI/PO system, the report (with the new recommendations feature) suggests usage of Business Events and APIs, as modern successors to the ADRMAS03 IDoc.
In the Recommendations sheet of the report, we can see the Modernization Recommendation applicable for this interface, for each modernization category.
Further, in the API Recommendations and Business Event Recommendations sheets, we can notice relevant APIs (SOAP, OData) and events being recommended.
We can explore the schema (list of fields and whether its for bulk request or delta), mode (push/pull), pattern (sync/async) from SAP business accelerator hub. Selecting the right one is a combined architectural & functional design decision. In any case, always prioritize standard APIs and events before considering custom implementations — this is the essence of the Clean Core approach.
For our scenario, we use the BP Change event to receive a notification whenever an address-related attribute of a Business Partner changes in S/4HANA. The necessary backend setup in S4HANA such as outbound channel creation, bindings, etc. are completed. When a BP address change occurs, an event is triggered to SAP Event Mesh.
Then, we consume this event in a Cloud Integration iFlow. Since the event payload only contains minimal details (event type and BP number), we enrich it by calling an S/4HANA OData API (as recommended in the migration assessment) to fetch detailed BP address information.
From the S4HANA system, let us modify some address related attributes for a BP#.
Following is the OData adapter configuration. We fetch the BP number from the event payload using a content modifier and assign to exchange property, for using in the Odata call.
Next, we transform this enriched response into the schema expected by the target application — matching the existing interface design from SAP PI/PO (screenshot below for reference).
Thus, we have modernized an idoc based SAP PI/PO interface into one that leverages modern cloud native patterns such as APIs and event, without losing the functional need. This pattern is significant given that the communication with external application is API based. IDoc usage still makes sense in certain scenarios, especially for EDI (Electronic Data Interchange) with external partners. Therefore, this type of extensive evaluation is required to ensure adoption of best-fit integration architecture.
The bottom line is that migration isn’t simply a lift-and-shift undertaking; it’s a strategic modernization initiative. Ultimately, thoughtful architectural decisions guided by each business scenario are key to reaping long term benefits. This is why modernization takes time — and why it’s important to start your SAP PI/PO to Integration Suite journey early, leveraging the available time to build a future-ready, clean-core integration landscape.
Many organizations with an SAP-centric ERP landscape are embarking on business transformation journeys, moving from SAP ECC to S/4HANA. At the middleware layer, this shift is accompanied by migrating from the trusted workhorse SAP PI/PO to the more modern SAP Integration Suite. To support customers on this path, SAP continues to innovate — for example, by introducing support for pipeline approach in migration tooling, providing Clean Core modernization recommendations, and much more.Today, let’s explore one specific area: IDoc-based scenarios in SAP PI/PO and their evolution in a cloud-native world.IDoc has long been a reliable standard for data interchange in SAP, especially in B2B contexts. While IDocs are still supported in SAP Integration Suite via native IDOC adapter, modern cloud-native integration architectures increasingly emphasize open standards and protocols like OData, REST APIs, AMQP and so on. In line with this, SAP recommends adopting modern patterns such as events and APIs instead of IDocs, aligning with the broader Clean Core philosophy.This article demonstrates how an IDoc-based scenario in SAP PI/PO can be migrated to Integration Suite through modernization — not merely a lift-and-shift approach. While modernization may take more effort initially, it delivers long-term benefits: interoperability, cloud-native agility, future readiness to absorb SAP released innovation and upgrades. The good news? With the Clean Core modernization recommendations for IDocs. released in Q2 2025, migration assessment reports now directly suggest API and event-based alternatives to achieve the same functional requirement.Let’s illustrate this with an example.In our SAP PI/PO system, we have an outbound IDoc interface (ADRMAS03) used to push Business Partner (BP) address changes to an external application, SAP Commerce Cloud, through REST API.When we run the scenario evaluation using Migration Assessment capability of Integration Suite, on this SAP PI/PO system, the report (with the new recommendations feature) suggests usage of Business Events and APIs, as modern successors to the ADRMAS03 IDoc.In the Recommendations sheet of the report, we can see the Modernization Recommendation applicable for this interface, for each modernization category.Further, in the API Recommendations and Business Event Recommendations sheets, we can notice relevant APIs (SOAP, OData) and events being recommended.We can explore the schema (list of fields and whether its for bulk request or delta), mode (push/pull), pattern (sync/async) from SAP business accelerator hub. Selecting the right one is a combined architectural & functional design decision. In any case, always prioritize standard APIs and events before considering custom implementations — this is the essence of the Clean Core approach.For our scenario, we use the BP Change event to receive a notification whenever an address-related attribute of a Business Partner changes in S/4HANA. The necessary backend setup in S4HANA such as outbound channel creation, bindings, etc. are completed. When a BP address change occurs, an event is triggered to SAP Event Mesh.Then, we consume this event in a Cloud Integration iFlow. Since the event payload only contains minimal details (event type and BP number), we enrich it by calling an S/4HANA OData API (as recommended in the migration assessment) to fetch detailed BP address information.From the S4HANA system, let us modify some address related attributes for a BP#.Following is the OData adapter configuration. We fetch the BP number from the event payload using a content modifier and assign to exchange property, for using in the Odata call.Next, we transform this enriched response into the schema expected by the target application — matching the existing interface design from SAP PI/PO (screenshot below for reference).Thus, we have modernized an idoc based SAP PI/PO interface into one that leverages modern cloud native patterns such as APIs and event, without losing the functional need. This pattern is significant given that the communication with external application is API based. IDoc usage still makes sense in certain scenarios, especially for EDI (Electronic Data Interchange) with external partners. Therefore, this type of extensive evaluation is required to ensure adoption of best-fit integration architecture.The bottom line is that migration isn’t simply a lift-and-shift undertaking; it’s a strategic modernization initiative. Ultimately, thoughtful architectural decisions guided by each business scenario are key to reaping long term benefits. This is why modernization takes time — and why it’s important to start your SAP PI/PO to Integration Suite journey early, leveraging the available time to build a future-ready, clean-core integration landscape. Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
