Keep the core clean blog series: Re-Designing SAP ECC based Order to Cash Scenario for SAP S/4HANA Implementation with SAP BTP

In most of the SAP S/4HANA Implementations, project Order to Cash is a very common workstream, and Implementing this workstream is quite a challenge because this workstream consists of integration between multiple systems and most importantly adhering keeping the core clean at the same time while development is key, on top of that in most of the cases customer uses non-sap system such as salesforce, third-party shipping provider, third party e-commerce which restrict you to use standard Integration Package, apparently that was the case for us in one of the SAP S/4HANA Implementation Project.

For us, it was a bit more challenging because the customer was using SAP ECC for quite a long period of time and had done all the development in SAP ABAP and didn’t use any middleware such as SAP PI/PO.

Looking at the tight deadline I could have done pretty much lift and shift but then the core would have been flooded with a couple of custom development which we want to avoid. We wanted to keep the core clean so re-designing the whole process with SAP BTP was the way forward. And in this blog, I would share the story of how I have re-designed the old SAP ECC Order to Cash Process using SAP BTP for  SAP S/4HANA.

Though we all are embracing keeping the core clean heavily in our technical Implementation, it always starts with a clean business process and clean data. I strongly believe it’s very important to make sure your business processes are aligned with SAP standards before going to any technical development.

Definitely, every customer has their own business processes but it’s very important to stick to the standard processes, it not only helps in operation but also it does in Implementation.

Below is the picture master and transactional data flow. 

Well, whether you are catching fish or going to play in the football world cup, it’s very important to have the correct strategy in place. While making the development strategy there are a couple of things I always kept in mind A) Scalability B) Flexibility C) Real Time D) Decoupling E) Fault tolerance and that’s why event-driven Integration was my first choice. The event-driven approach is nothing new but for the SAP world, it’s completely new territory. Thanks to SAP BTP Event Mesh, SAP’s Enterprise Event Enablement Add-on, SAP’s Standard  OData API, and Integration Suite to make it not only looks easy but also makes the whole development easier.

Well, I am a fan of an event-driven approach whether it comes to developing BTP-based extension and Integration, it always gives you an extra edge. I believe SAP has done a pretty good job with enterprise event enablement addon and event mesh which was a key component in my design as well. The event-driven approach has a lot to offer when it comes to benefits such as scalability, flexibility, fault tolerance, responsiveness, etc. One of the key requirements from the customer was updating the data in real time between systems that’s why choosing an event-driven approach was key.

Interested to know more about SAP Event Mesh, Event-Driven Architecture for SAP Solutions, please visit this page in SAP Discovery Center.

There are three components that play key roles in any event-driven approach, Publisher, message broker, and subscriber/Consumer. In this case, SAP S/4HANA acts as a message publisher, SAP Event Mesh in BTP act as a Message Broker, and SAP Cloud Integration act as a Consumer.

E.G: A Material Master has been created in S/4HANA System then SAP Event Enablement Addon takes care of publishing/notifying this event to SAP Event Mesh Topics, from topics it would go to the corresponding subscribed queue and finally queue to Consumer which could be SAP Cloud Integration or your CAP Based extension Application. It’s very important to note that S/4HANA most likely publishes very minimal information to event mesh like the Material number, type of events, date time, etc. which is not enough to build transformation logic, that’s why a call back is necessary which would extract the necessary information required for transformation.

Below is the JSON structure of event notifications which get published from SAP S/4HANA

{ "specversion": "string", "type": "string", "source": "string", "subject": "string", "id": "string", "time": "2022-10-21T23:34:06.263Z", "datacontenttype": "string", "data": { "Product": "string" }
}

This is the most important part of this blog because in this part I am going to discuss how we implemented each sub-processes, In this part of the blog I am going to discuss the enterprise Integration Patterns, Standard S/4HANA API has been used, Standard Business Events and In-App Extensibility options we have used to facilitate some requirements. 

Integration Name Direction of Integration S/4HANA API S/4HANA Business Events Non-SAP System Usage of In-App Extensibility
Customer Master Salesforce to SAP S/4HANA Business Partner API NA Salesforce Yes, storing Salesforce ID as a custom field in the Customer Master
Sending Webshop User to Salesforce as contact Salesforce to Magento Webshop NA NA Salesforce and Magento NA
Customer Contact Accreditation Updating Contact from S/4HANA to Webshop Business Partner API Business Partner Changed Events Magento Webshop Yes, A custom Checkbox Field Called Approved for Order Creation has been created to Identify Customer contacts who could place an order in Webshop.
Sending Material Master Data to Salesforce Sending Product Master Data from S/4HANA to Salesforce on creating new master data or changing existing master data. Product Master API Product Business Events (Created and Changed) Salesforce Yes, A Salesforce Product ID to maintain a mapping between S/4HANA and Salesforce
Sending Warehouse Stock, Product Availability, List Price, Customer Specific Price S/4HANA to Webshop

Warehouse Product  Stock API

Product Availability API

List Price API

Customer-Specific Price API (Sales Order Simulation)

NA Webshop (Magento) NA
Online Webshop/ Commerce Order Integration with S/4HANA Webshop to S/4HANA

S/4HANA Sales Order API

NA Webshop Magento Yes, Webshop Order Number to maintain mapping, Basic CC info in encrypted form  to print on the order confirmation form for pre-paid orders
Sending Offline Order information to Webshop and Salesforce

S/4HANA to Salesforce

S/4HANA to Webshop

(many times some customers don’t create orders from the webshop, they get directly created in S/4HANA by the Back office)

S/4HANA Sales Order API

Sales order API to retrieve details about Sales order

Business Partner API

Business Partner API to Retrieve the customer Details and Addresses like Ship to Party Adress

Sales Order created Business Events

Salesforce

Magento

NA
Sales Order Status Update S/4HANA to Webshop (magento)

Outbound Delivery API

S/4HANA Sales Order API

Outbound Delivery Business Events (Incl Goods Issue, Picking)

Sales Order changed Business Events

Webshop (Magento) NA
Sending Customer Invoices to Webshop S/4HANA to Webshop Billing Document API to Retrieve Customer Invoice and PDF Billing Documents Business Event Magento NA

Enterprise Integration Patterns

There is a standard partner (Rojo Consultancy) Integration package available for developing Integration between salesforce and SAP S/4HANA but unfortunately, we couldn’t use it because data flow and processes were a bit different for our customer scenario. 

In order to connect with Salesforce, Salesforce Adapter by Rojo Consultancy or Open Connector API for Salesforce could be used, we used the SAP Open connector. 

Magento Webshop Provides REST API to build Integration.

Pattern 1. Sending Information from Non-SAP System  to SAP S/4HANA

Salesforce webhook notifies the configured consumer on changing and creating a new account, In this case, the SAP Event Mesh Message Queue is the consumer. SAP Event Mesh Message Queue is subscribed further in the SAP Cloud Integration flow using AMQP Adapter. Once Iflow gets triggered it makes further Salesforce API Call to retrieve more information, make the required message mapping and call the SAP S/4HANA  API to create master Data. This is also the case for

Pattern 2: Sending Information from SAP S/4HANA to Non-SAP System

This scenario is valid for such scenarios when we want to send real-time data (master or transactional) such as Material Master, Sales Order Status, and Customer Invoices from S/4HANA to other Systems.

Pattern 3: Timer-based SAP Cloud Integration Job to send Details from S/4HANA to Non-SAP System

Sometimes we need to send information in bulk like List Price for all Products, Daily Warehouse Stock, and History of orders, etc. for such kind of scenario Event driven is not a good option rather daily night job is better.

Pattern 4: Retrieving SAP  Information On-demand basis

Also sometimes Information is needed on-demand basis such as customer-specific prices or real-time warehouse stock, In order to handle such scenarios we created REST API using SAP Cloud Integration which is being called directly from Webshop (In this case) for validation while the customer places an order or check the customer specific price.

Similar approaches could be applied to SAP Cloud ERP Projects also, Most of the APIs and Business Events are available for Cloud ERP as well. Though I didn’t want to make it a very long blog because always want to keep it short and crisp so people could spend their minimal time reading to learn something new and don’t get bored, it’s not always possible. I hope this blog will not bore you, let me know your view in the comment section. If you like this blog, Please like comment, and share it with your colleague. Based on the reader’s reaction I would make part 2 of it which would be in a bit more technical detail. Meanwhile, enjoy the read, and happy Halloween!