I am writing this blog to talk about my experience with having C4C as the frontend connecting to multiple ERP backends,

Enterprises have multiple ERP backends, either due to complexity of the Business Units, acquisitions, or mergers. For a global sales or service leader, sometimes its imperative to get information across BUs with trends that can affect pipeline for example, and have a call to action message for sales team. C4C also has extended app, which features latest RUI version of CRM, and is device agnostic.

Some of the the components that need to be completed are listed below. They do not represent the complete list of work needed.

ID mapping – Make sure that for automated interfaces, id mapping is working, and for manual loads, based on system instance id, you have right ids mapped for integration. This is important if you want to use ERP IDs in C4C for these objects.

Communication Arrangements – Communication Arrangements is an important aspect to monitor payloads. You will need at least 2 arrangements for each object depending on number of ERP you are connecting to single C4C tenant.

 

Multiple ERP BAdI – This is an important BAdI to determine which ERP the payload goes out to, and creates subsequent process documents. An example for the BAdI is shown below. An example would be which ERP does the pricing request call gets routed?

Codelist mapping – Important to note here is that you have to create a code list mapping group, one per ERP. This is the most important aspect of the integration, as different ERP can have different names/codes for same C4C code.

Once the codelist mapping group has been created, corresponding codelists need to be mapped. Inheritance concept applies.

Source system identifier – It is important to consider the source system identifier field on master data and transaction objects to easily differentiate for users visually, and via search query, which source system is originating system of record. For example, in case of multiple accounts with same name in two ERPs, apart from number range and other differentiators, this field can be used to build queries based on business role fro example.

PI namespace – Since we had 2 ERP to integrate with, we used the concept of “tracks” for each integration. For each track of integration, we placed those customized mappings into its own custom namespace

Please revisit the blog, as I will update the blog with new URLs and learnings.

To report this post you need to login first.

10 Comments

You must be Logged on to comment or reply to a post.

  1. Ankur Godre

    Hi Rohit,

    Please also share with the community on few more critical aspects for this scenario:

    1. Did you connected two ERP systems with C4C for same data objects or different ?
    2. How was the number range managed if multiple ERP had same object being replicated between the ERP and C4C?
    3. What level of Custom development was done to accomplish this requirement?

    BR
    Ankur

    (0) 
    1. Rohit Agarwal Post author
      • We connected 2 ERPs for same data objects, however, this is not a limitation, and project teams can integrate different data objects as needed.
      • We had a mixed approach for automated vs manual loads. For example, in case of accounts, which is automated load, we chose C4C number range, and used ERP id as external id, along with the system identifier KUT field. So, for example, ABC Corp is a customer in both ERP (123 and 789), then C4C Id will be ABC (ERP ID – 123), and XYZ (ERP ID – 789). In case the same customer has same id (very rare), we can still use multiple C4C id irrespective of sap ERP id. In case of manual loads, for example employees, we added 8 in front of one of the ERP Ids for id mapping, so that we dont have any conflicts. However, we kept C4C Id as leading id. Important to note here, that we did not merge data from two ERP. We created two instances always if data was present from multiple ERP.
      • There was not CD done. Minor KUT fields were added to fill in system identifier.

      There will also be an upcoming blog by my colleague @Tim Chang, who will deep dive into the technical challenges faced from SDK perspective as well.

      (0) 
      1. Ankur Godre

        Thanks for updating Rohit – so was this one way integration or was there data flow from C4C to ECC as well, for Accounts? If C4C to ECC data flow was there then how were number ranges managed for this?

        BR
        Ankur

        (0) 
        1. Rohit Agarwal Post author

          There was 2 way data flow for tickets, and other transactions as well. For accounts, we locked down the SP/SH etc, as we wanted one source of truth. However, we managed prospects going to ERP using MDG. C4C no range was unique, and we used the same one for prospects as well. We hid the C4C id, as customer was mostly looking for ERP ID after conversion.

          (0) 
  2. Tobias Träger

    Hi Rohit,

    could you give some more input about your following mention : “For example, in case of multiple accounts with same name in two ERPs, apart from number range and other differentiators, this field can be used to build queries based on business role fro example.”

    I’m facing the challenge to integrate 2 ERPs into one C4C too and the approach seams to be quite the same like we intent. As the master data is quite different for both systems and the users will barely need to see the Data from both Systems we intend to make a “hard” Role cut there. This would also prevent users from choosing the wrong customer in an opportunity -> no questions “why is that quote not in my erp system, I triggered it from the C4C opportunity”.

    could you give me some info, how that could be realize. So far we were told that it’s possible to do, but I didn’t get any details on it.

    Thanks

    Tobias

    (0) 
    1. Rohit Agarwal Post author

      We did not make a partition of same customer names (for example 3M) from two ERP based on business role. We had a KUT, which was filled based on which system it was coming from, for eg, values will be ERP1, and ERP2. Then we created custom queries for search objects, such as opportunities, quotes, my acocunts etc globally, and restricted them based on sales org, which was unique acorss the 2 ERP. you could use the KUT for system identifier to create search query as well, and limit the data.

      (0) 
  3. Thierry CRIFASI

    The recipient determination BADI you are referring to is not available for service tickets. What solution would you recommend in this instance to determine the right ERP?

    Could we have the logic in the PI integration flow?

    (0) 

Leave a Reply