It might sound a bit strange, but already we have had this question quite a couple of times. In quite some occasions, acquisitions or multiple local implementations have resulted in single customers having multiple SAP implementations. This is not necessarily a problem in the back end, but when aiming at a single 360 degrees customer overview, you require a single truth both in reporting as well as in your customer-facing applications. Integrating with multiple backends from that standpoint is not exceptional, so let me share some of my findings on integrating multiple backends with a single C4C instance with you.
As there is detailed information on the SAP ECC integration available on the SAP Help portal, let me focus on the C4C side here.
Communication ArrangementsIn order to have our C4C system communicate with 2 ECC systems for business partner replication, we have created two communication systems. One for ECC system A and one for ECC system B.
When setting up the interface, we can choose between basic authentication and SSL client certificate authentication. For technical reasons, we have implemented both methods. Basic for system A and certificate based for system B.
Configuration of the iFlowsSince we are also making some customisations to the mappings in our iFlows, we use Eclipse for the configuration. But you can also do the configuration directly in the HCI WebUi.
You can download Eclipse JEE Luna from:
Because we need to configure the iFlows for one ECC system based on basic authentication (so with userID and Password) we needed to deploy a Basic Authentication Artifact:
You can use any name and description. The user and password should correspond to the user and password as configured in the technical data of your communication arrangement.
After downloading the HCI package ‘SAP Cloud for Customer Integration with SAP ERP’ you import the relevant iFlows in Eclipse (Replicate Business Partner from SAP ERP, as well as address and contact address) … twice! So one set of iFlows for ECC system A and one set of iFlows for ECC system B.
Rename the iFlows to distinguish between both you ECC systems, since you need to change the properties for all iFlows to refer to the correct ECC systems (ECC system A and ECC system B) and their properties. Renaming the iFlow can be done with right mouse click on the iFlow and choosing ‘refactor’ -> ‘rename’. You also need to change the names accordingly in the Manifest.MF of the iFlows.
Next you need to maintain the properties for the iFlows and the respective ECC systems. For the ECC system with which we communicate by means of basic authentication the settings are as follows:
In the credential name you enter the name of the deployed artifact for basic authentication.
For the ECC system with which we communicate by means of certificate based authentication the settings are as follows:
Here you need to add the necessary certificate.
Master data challengesOne of the biggest challenges we have faced (and always will in complex integrations), is the ownership of the data. As an example, with 2 backend ECC systems, both containing data on the same customer, what mechanism will take care of conflicts? Should one of them be leading? Should most recent changes always persist? Or do we require a more complex Master Data Management solution?
Here, the discussion opens up. Different scenarios are available, and it is up to you to choose wisely.
Let’s for instance assume that we have a customer ‘1234’, persisting in both ECC systems.
In the standard 1-way integration scenario, system B will overwrite changes from system A and vice versa. In some cases, this might be ok, but in others it might not.
A solution could be to have systems A and B communicate prior to interfacing, or a solution could be to have system A tell system B to tell C4C about the change in customer data, or vice versa. A third solution could be to have 2-way synchronisation in place, where a change from system A will for instance result in an update in system B.
We are currently in the process of investigating the scenario where the two ECC systems first 'debate' about the correct and complete customer data, and then interface an 'enriched' set of data to Cloud for Customer, allowing us to have a complete customer overview, supported by both backend systems in Cloud for Customer.
Any hints and tips are welcome, and hope that we can share good news soon.