top of page
Writer's pictureKevin Wilson

Integration considerations between S/4HANA and SFDC

One of our chief architects, via our Partner Adaptive Brane, Ash, was working an integration POC between S/4HANA (S4) and Salesforce (SFDC).


Here are some key learnings that he'd like to share:

  1. Data Residency and Ownership: We (Architecture) wrestled for a long time on the foundational question of which of the two systems should be the system of record for customer master data. After tabling the idea of a bi-directional sync, it quickly became apparent to us that the data models and governing data creation features in the two systems are quite different. So we eventually chose S4 as the master with SFDC set up as the subscriber to customer master data changes. We also explored the notion of using external data objects in SFDC to represent Customer master data but found this to be an overly chatty and heavy approach with degradation in out of the box features for SFDC.

  2. Integration Architecture: Batch vs real time was the next decision we had to make. We found SFDC's Rest APIs were quite well defined and it was quite easy to set up a CDC (Change data capture) pattern from S4 to SFDC. Further, to simplify the integration, we updated the SFDC lightning components such that all customer master updates in SFDC were first saved to S4 and then relied on the real time sync to update SFDC. So there was another benefit of real time integration. Please also consider SFDC's API governor limits when planning your integration. There are more layers to parse through around this subject and the journey maybe different for you.

  3. Overlapping functionality and SAP's Customer Management add-on: This is another topic that requires consideration. What processes would you want to house in SFDC and which ones should you have invoked in S4 - especially if you are using the customer management add on. In an ideal world, you would have mutually exclusive sets of business processes

  4. Security, OAuth and Roles: It would be nice to have a clean set of enterprise roles to model your application roles around but customers implementing CRM for the first time need to go through a discovery and definition phase. In our case, not only do we have roles normalized across the two systems, we were under mandate to support principal propagation across both systems. So if user Jane Doe logged in to SFDC via SSO, every api invoked (using OAuth) that updated the state of S4 would be executed under her role (not a generic integration user). This is tricky to pull off and perhaps excessive but it depends on the security controls you want to have in place.

There were many other key decisions made during the POC but we believe getting the ball rolling on some of the above considerations will go a long way in paving the way for others...


Ping us if you would like to know more on SFDC integration within the SAP landscape.

153 views0 comments

Comments


bottom of page