In one of the previous blog post, SAP Cloud Integration was introduced as new integration option for SAP IBP. Subsequent blog posts covered technical topics for creating integration flows based on SAP delivered packages and flows for different integration scenarios. These blog posts in addition to highlighting why organizations should consider SAP CI as part of their IBP integration strategy, covered fundamental set-up and configuration steps for using it for integrating SAP IBP with S/4 Hana Cloud.

In this blog, we explore a real-world example of an organization using Cloud Integration to overcome complex integration challenges for their IBP HPA implementation. We share details of challenges, key architectural decisions, and lessons learned from this complex supply chain planning implementation. This blog highlights a proven integration approach that offers valuable learnings for organizations navigating similar challenges.

Integration challenges: Distributed landscape

The organization in focus like other large manufacturing organizations operates an extensive global supply chain. Their landscape includes:

• Multiple ERP system distributed globally
• Large product portfolio with complex supply chain spread across locations using different systems

The key challenge was to integrate data from multiple SAP and Non-SAP systems. The integration approach needs to be flexible enough to support multiple source system integration with SAP IBP.

Key decision: Cloud Integration or Real Time Integration

One of the most critical decisions in any IBP implementation is to choose the right integration tool for IBP.  From release 2508 onwards, RTI and SAP CI are the two integration tools available to integrate SAP IBP HPA with SAP S4 Hana private cloud.

The sample customer’s implementation team made an early decision to go with a standalone CI integration approach for IBP. Some of the drivers for this decision were:

• Cloud Integration works well with all SAP and non-SAP ERP systems, compared to RTI which is restricted only to S/4HANA Private edition
• Readily available Cloud Integration expertise within the organization
• Operational planning is carried out in ERP system, ruling out need for Order based planning in IBP
• Business followed monthly planning cycle, with delta data load planned daily

Additionally, the availability of prepackaged reusable assets for SAP Cloud Integration supports accelerated implementation and reduces time to value significantly. It provides comprehensive connectivity options for diverse landscape, and it being under active development from SAP keeps your integration architecture future ready. Its web-based centralized monitoring and error handling capabilities help in reducing the overall maintenance cost. Because of these inherent advantages of SAP CI, the implementation team decided to go with standalone SAP CI integration architecture.

As real-time data sync capability was not needed, RTI didn’t offer any additional business value in comparison to CI in this scenario. However, depending on your business needs, Operational planning (OBP) in IBP and real time sync capabilities could be essential, in that case CI can be used in conjunction with RTI. As per SAP guidelines, integration architecture can utilize both the integration technologies following way:

• RTI used for integrating master data and order data from S/4 Hana Private edition
• SAP Cloud Integration (CI) used for all other integration scenarios such as Key Figures or other non-standard objects.

Following SAP help portal page helps you find right integration tool for your business needs: Finding the Right Integration Tool | SAP Help Portal

Integration design philosophy: keep interfaces “Lean” and “Scalable”

An important contributing factor to the successful implementation of CI for SAP IBP was to keep interfaces simple. The customer's implementation team followed a clear guiding principle that Cloud Integration (CI) should be used only for transporting data from one system to another. It should not be used for deriving any business logic. Cloud Integration (CI) is best used for:

• Data transportation
• Data format transformation and technical validation
• Security handling

Business rules, process logic, and calculations were handled in the source or target system. This approach of preprocessing data in source or target system, made sure CI flows are simple, maintainable and reusable.

Preprocessing of data in source system:

To keep the core and IBP Add-on clean on the S/4 Hana, the implementation team decided to use extended CDS views for data preprocessing in S/4 Hana. Cloud integration flows read data directly from CDS views, avoiding modification of extractors and therefore sticking to clean core best practices.

How it works: Multi layered CDS views were created for preprocessing data in S/4 Hana:

1. Reuse layer CDS views: Built on IBP add-on staging tables and raw tables (for additional data), this layer provided filtered data. As these CDS view also included data from raw tables, any custom data fields not available in IBP add-on staging tables were captured in these CDS views
2. Consumption layer CDS views: This is primarily used for renaming S/4 fields to IBP fields. Reuse layer CDS views served as input for these CDS views. CI flows read data directly from these CDS views.

Above approach along with Change Data Capture (CDC) capability for CDS extraction allows delta loads for master data and S/4 Hana execution transaction data.

Reusable integration flows in CI:

SAP CI provides prepackaged reusable integration flows, that can be used to integrate all master data and transaction data types with minimal configuration changes. For the sample customer, data integration is executed by running a single prepackaged reusable CI iflow. One reusable integration flow handles all integration scenarios – all master data and key figures, with the help of flexible parameters. These parameters define:

• Source CDS view to read in S/4 Hana
• Target Master data and Key figures in IBP
• Transfer mode: delta or full load

By sticking to preprocessing within the source system using CDS views and integrating using reusable flow, solution is flexible to accommodate future requirements. Any future business requirements can be handled by extending CDS views in the source system, avoiding any changes in the integration layer.

Integration with non-SAP system:

To integrate non-SAP ERP systems, data from multiple ERP systems is first integrated into a Data warehousing system. In Data warehousing system similar CDS view dependent process is used to preprocess data and then a reusable CI flow is used to pull data into IBP. This unified approach means consistent data structure regardless of the source system type.

Back integration to S4 Hana system:

IBP add-on staging tables enable a fire and forget approach for integrating planning output data from IBP to S/4 Hana. CI delivers data to S/4 IBP add-on tables and S/4 process them independently.  

With this lean integration approach, figure below shows high level data flow between different systems:

 Key takeaways: Some of the key learnings from this successful implementation of CI integration are:

• Evaluating business requirements to select the right integration tool for your implementation. Depending on specific scenarios, CI only integration strategy can be effective.
• Keep integration lean and focus on data transport only. Push transformation and business logic in source and target systems
• Availability of prepackaged integration flow helps in accelerated implementation, and results in scalable and low maintenance integration solution