Introduction
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.
What we are talking about
Existing High-Level Architecture
Proposed High-level Architecture
A clean Business Process is always key to starting with
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.
Without strategy execution is aimless
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.
Embracing Event-Driven Approach
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.
Also If you want to know step by step configuration for building event driven Integration, please have a look at this amazing end to end blog by iamdipan
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"
}
}
let's Connect the dots
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.
On a final note
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!
- SAP Managed Tags:
4 Comments
