Wednesday, October 25, 2017

Integrate multiple ECC systems with C4C (using Cloud Platform Integration)


In previous blogs, my colleagues described how to connect C4C to multiple ECC systems. You can find them here and here.

Yet, I wanted to devote another blog to this topic as you can also use SAP Cloud Platform Integration to meet this requirement.
The following picture will show the final setup. No need for developments, just configuration mainly in the middleware.




The starting points

  • Master and transactional data can be replicated bidirectional between the ECC and C4C system 
  • Master and transactional data are not replicated between ECC systems. So no synchronization takes place between the different ECC systems (directly or through C4C). 
  • In this case, master and transactional data was initially loaded from ECC to C4C. So the data in C4C has an ECC external system ID which can be used as identifier in the middleware. It is also possible to use other fields as identifiers.
There is a different approach for the direction of the integration.
For the replication of data from ECC to C4C, the same iflow is copied and deployed multiple times.
For the replication of data from C4C to ECC, there is 1 general iflow deployed (for all the ECC systems).

Within the iflow from ECC to C4C, the right C4C system is determined in the (RFC) connection. So the same iflow is copied and deployed multiple times.



Within the Iflow from C4C to ECC, there is 1 iflow where the right ECC system is determined via routing technique.


Now let’s get into the details.

(Mind you, I will only focus on details that differ from the standard integration setup)

Replication of data from ECC to C4C

Ever tried to deploy the exact same iflow twice? Nope, that won’t work. So, you will have to do some things.
Change the name of the iflow (e.g. Replicate Material from SAP ERP ECCSYSTEM1). Be sure to also change the technical name of the iflow.
In ECC transaction SM59, change the RFC destination by adding the ECC system name in the path prefix. E.g. for materials it would become: /cxf/ERP/COD/MATMAS_CFS.MATMAS05_ECCSYSTEM1
Copy the address into the IDOC connection details of the regarding Iflow


Now the iflow can be deployed successfully. You can apply this to several systems with several master and transactional data iflows.

If you have 2 client on 1 ECC system, you can combine this in 1 iflow. In this scenario, both ECC clients would use the same RFC connection (which is client independent). In C4C you would need to define 1 communication system with 2 clients. A disadvantage would be that you cannot make ECC client specific mappings or logic within the iflow.

Replication of data from C4C to ECC

Now this is the tricky one. You can’t simply copy the iflow and change the connection details as explained above. Instead we can use 1 general iflow, which determined the right ECC system via routing functionality.
  • You don’t have to change the name of the iflow, but if this will clarify things in Cloud Platform Integration; go ahead.

  • In C4C, all the outgoing communication arrangements need to be created per communication system. 
  • The C4C outgoing data flow needs a unique characteristic, which will determine the right ECC system. In our case, the data always has an External System ID (you can also use other data field if necessary). 
  • In the iflow, setup the content modifier so the value of the External System ID (of the incoming message) is taken into account.

    • Setup multiple channels and multiple ECC systems in the iflow, leading to each ECC system (all the blackened parts are the ECC system names) 
    • In the properties of the router, set a condition that compares the value of the ReceiverSystem parameter. This way, the right message is routed to the right ECC system (within the iflow)
    • In the properties of each of the IDOC channels, change the address to the right ECC settings. https://[reverseproxy]:[portnumber]/sap/bc/srt/idoc?sap-client=[client number]. In other words, each of the ECC systems will need a different port number configuration in the reverse proxy. The combination of reverse proxy, port number and (ECC) client number will determine the right ECC system. 
    • You can repeat this for all other iflows. Master data, transactional data and also document flow / customer factsheet requests can be handled the same way.
    That’s it, happy interfacing!

    1 comment:

    1. Great blog Jasper! much simpler and easily extendable to n number of systems.

      ReplyDelete