#S4HANA Cloud 2-Tier ERP series: 8 Master Data in 2-Tier ERP

[srivatsan_santhanam]

Welcome back to the next blog in the SAP S/4HANA Cloud 2-tier ERP blog series.

 

In this blog, let’s take a look at master data handling concepts in a 2-tier deployment model.

 

Enterprises worldwide strive to have a clean, duplicity free, accurate master data. Lot of efforts is spent in this direction. A fragmented, inconsistent master data hiders business processes efficiency, introduces reputation risks and might lead to loss of customer loyalty and eventually business loss.

 

Simply put clean master data is fundamental to any enterprise’s success.

 

There are many products from SAP’s stable for master data handling like SAP MDM and SAP MDG. In this blog post we are not going to look at these product capabilities, but going to look at the various approaches I feel are possible in master data handling in a 2-tier deployment.

I see the following possible approaches

1. Headquarters runs MDG addon on SAP ECC or S/4HANA OnPremise and Subsidiary runs S/4HANA Cloud


2. Headquarters runs SAP ECC or S/4HANA OnPremise and Subsidiary runs S/4HANA Cloud – Replication using DRF


3. Headquarters runs SAP ECC or S/4HANA OnPremise and Subsidiary runs S/4HANA Cloud – API approach


4. Headquarters runs SAP ECC or S/4HANA OnPremise & SAP PI/PO/other middleware and Subsidiary runs S/4HANA Cloud – data handling in SAP PO


5. Headquarters runs SAP ECC or S/4HANA OnPremise and Subsidiary runs S/4HANA Cloud – data replication and transformation using SAP CP.

 

Approach 1: Headquarters runs MDG addon on SAP ECC or S/4HANA OnPremise and Subsidiary runs S/4HANA Cloud

In this deployment model, HQ runs SAP ERP or S/4HANA OnPremise and MDG is an addon. The expectation here is to extend the role MDG plays in OnPremise in ensuring a clean and single source of master data to all satellite systems to also to S/4HANA  Cloud.

Existing investments into SAP MDG can be extended to ensure even S/4HANA cloud gets Master Data pushed from SAP MDG to S/4HANA Cloud instance.



In this approach, subsidiaries running S/4HANA  Cloud can seamlessly work with an existing SAP MDG instance to get clean master data and reduces the risk of subsidiaries introducing incomplete, inconsistent local copies of Master Data.

Approach 2: Headquarters runs SAP ECC or S/4HANA OnPremise and Subsidiary runs S/4HANA Cloud – Replication using DRF

 

This approach is pretty similar to the one we saw earlier in Approach 1. In this case, we do not have an SAP MDG instance, but still need ability to send master data maintained in HQ to local subsidiaries running S/4HANA Cloud.

In such cases, DRF comes in handy. We can replicate master data changes carried out centrally either manually or automatically in the background using the data replication framework (DRF). Filters allow us to configure replication settings. (Approach 1 also leverages DRF)



In this case, there is no need for additional investments for customers to ensure master data (Customer, Vendor, Material) are synchronized across HQ and subsidiaries. As I’m leveraging DRF, I’ve limited transformation capabilities in case I need to perform extensive data transformation or need to publish the master data to multiple systems.

Approach 3: Headquarters runs SAP ECC or S/4HANA OnPremise and Subsidiary runs S/4HANA Cloud – API approach

In this approach, I would leverage the whitelisted APIs published on API Hub for S/4HANA  Cloud for CRUD operations of various master data objects.

For a detailed list of APIs available, visit: https://api.sap.com



Here, I do not get any framework support to say which Master Data object has been created newly or changed in HQ. All these logic and transformation logic needs to be a custom solution on HQ side.

The next 2 approaches we are going to discuss will essentially build upon this approach.

Approach 4: Headquarters runs SAP ECC or S/4HANA OnPremise & SAP PI/PO/other middleware and Subsidiary runs S/4HANA Cloud – data handling in SAP PO

Yes, when I was discussing, approach 3, many of us would have thought, why can’t I have SAP PO which will help me in performing data transformation more easily than  writing it as a custom logic on ERP side.

This is also a possibility.



With SAP PO or any other middleware, I get more advantages than a pure API approach we saw earlier:

• Better data transformation handling ability


• Data transformation rules are centralized in my landscape (SAP PO for instance here)


• Ability to propagate master data to multiple systems

 

Approach 5: Headquarters runs SAP ECC or S/4HANA OnPremise  and Subsidiary runs S/4HANA Cloud – data replication and transformation using SAP CP.

This approach is essentially a variant of the Approach 4 we discussed. Here instead of SAP PO, I make use of SAP CP (integration service) capabilities for master data transformation and transfer to subsidiaries running S/4HANA Cloud.

With more and more enterprise adopting a cloud approach, I see Approach 5 getting wider acceptance and be the preferred choice.



Of course for both Approach 4 and Approach 5, you need whitelisted APIs or IDocs on SAP S/4HANA Cloud side to make this communication to work.

I have put forth various approaches I see are possible for master data handling in a 2 tier deployment. Not all master data objects will follow one approach. I will pen another blog on what approach various master data objects (like BP, Material, profit center, cost center, internal order, conditions, tax codes, procurement master like plant, purchasing organization, Bill of material, inspection methods, work center, project master etc…) can use later.

 

For more information on SAP S/4HANA Cloud, check out the following links:

• S/4HANA cloud release information: http://www.sap.com/s4-cloudrelease


• Best practices for all the cloud editions here


• S/4HANA Cloud 2-Tier ERP series: The Collection here

 

Follow us via @SAP and #S/4HANA  or connect with me via srivatsan.santhanam

 

[edda-leonore_seitz]

Interesting Blog. Thanks for explaining so many different possible scenarios. What is the scenario we should recommend our customers/prospects ? What are the advantages/disadvantages/prerequisites of certain scenarios? Are all scenarios supported/planned for upcoming releases ?

[srivatsan_santhanam]

As I mentioned it depends on the usecase. Few master data objects like BP, Product master would be supported via DFR, while for a cost center, GL master, it would a API based approach.

Even in API based approach, it depends if you want to levearge SAP Cloud Integration or SAP PO in OnPrem.

[Former Member]

Thank you Srivatsan – how can we best try to understand in which use case to use which approach? E.g. Why does DFR only support certain master data objects and API for others? Which approach would be the most scalable, i.e. such that I can use the same approach for all objects (as far as possible)? Is there some kind of documentation that lists recommended / supported approaches by master data object? 

[srivatsan_santhanam]

Very valid questions. I intend to address this in my next blog.

 

[former_member237404]

In communication arrangement , additional properties -> replication model  , what replication model we have to fill and how is it defined  in S/4cloud ?

[MPS4HANA]

Thx Srivatsan. Looking forward to read your views on various approach and the decision criteria for adoption a particular approach. Thx in adv. Rgds MP

[Johnny_B_]

Hello Srivatsan,

thank you for the good overview of the possible scenarios. May I ask you about your opinion for the following requirement, which i am trying to implement currently:

• Projects and WBS structures are created in S4 Cloud


• WBS elements shall be replicated to the on-premise HQ ERP (ECC)


• Cost allocations are posted in HQ ERP on the replicated WBS elements


• Cost allocation line items shall be replicated to S4 Cloud, so that the project reports show the figures there

I am struggling to identify the right scenario for this, and I do not know how much of this is probably available out-of-the-box.

For WBS replication, there is an OData API in the Cloud, which I can call from on-premise (this works already)

For cost allocation postings, there is a SOAP API in the cloud, theoretically (I haven't got this running so far)

Or should I rather look for a SCPI scenario, using cloud integration? I would favour this in terms of monitoring and mapping.

What do you think?

Thank you, Johannes

 

 

[srivatsan_santhanam]

You can replicate Projects and WBS using APIs and orchestrate it with SAP Cloud Platform Integration service.

cost allocations on ECC can be posted on S4HC using Journal Entry post API.

BR, Sri

[former_member527299]

Dear Srivatsan, Please advise whether "I will pen another blog on what approach various master data objects (like BP, Material, profit center, cost center, internal order, conditions, tax codes, procurement master like plant, purchasing organization, Bill of material, inspection methods, work center, project master etc…) can use later." has been published. If so please share the link.

[srivatsan_santhanam]

Hi Srinivasa,

Yes.. we will address this as part of the Hybrid Cloud Blog series here:

https://blogs.sap.com/2019/04/13/hybrid-cloud-is-the-new-black/

 

BR, Sri