Skip to Content

In this blog I would like to share with you a solution approach on replicating account relationships from ERP to SAP Hybris Cloud for Customer (C4C). This topic recently came up in a discussion I had with a customer on their business partner replication setup:

Integration Scenario and setup:

Replicate Business Partner from SAP ERP to C4C.

Example:
The users maintains in SAP ERP an account (ID: 1000) with the partner function “WE”  (related to customer ID 2000) and “RE”  (related to customer ID 3000).
In C4C the user maintains for the account with the external ID 1000 manually the relationship “ZZ”.

Accounts are being replicated including their SAP ERP partner function to C4C (Replication direction only from SAP ERP –> C4C). 
In C4C the partner function ends up in the account relationships. In C4C users can add additional C4C specific relationships.
As in the given example the SAP ERP system is the master for the accounts, the replication back to the SAP ERP is not implemented.

Problem:

When changes in SAP ERP  trigger an update on the account in C4C the previously added C4C specific relationships will be deleted.

This happens because the business partner replication from SAP ERP to C4C is a full transmission of all data of the replicated business partner. Hence, the C4C specific relationship gets deleted with the update from SAP ERP as the information is not available there.

Solution:

In the middleware the payload of the C4C inbound web service to replicate the business partners needs to be adjusted.

The payload of the ERP specific partner function looks like this – the action code “04” indicates an update of the node.

<PartnerFunction actionCode=‘04‘>

                <RelationshipCategoryCode>WE</RelationshipCategoryCode>

                <PartyInternalID>2000</PartyInternalID>

        </PartnerFunction>

        <PartnerFunction actionCode=‘04‘>

                <RelationshipCategoryCode>RE</RelationshipCategoryCode>

                <PartyInternalID>3000</PartyInternalID>

         </PartnerFunction>

In order to suppress now the change on the customer specific relationship the action code “06” needs to be maintained in the payload for the relationship type “ZZ”:


     <PartnerFunction actionCode=‘06‘>

           <RelationshipCategoryCode>ZZ</RelationshipCategoryCode>

     </PartnerFunction>


In addition the partner function code “ZZ” need to be mapped in the code list mapping against the C4C specific code, which must not be overwritten. Hence the partner function code used in the payload can be any code as long it is mapped against the proper code in C4C.



To report this post you need to login first.

6 Comments

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

  1. Marcus Echter

    One addition to this blog: We have implemented the special handling of partner functions as described above not only for partner functions mapped to C4C relationships (non-employee related), but also for partner functions mapped to the C4C account team (employee-related).

    (0) 
    1. Dedeepya Reddy

      Thanks Bernd for this Blog.

      Does action code = 6 here mean “No Action”?

      By passing this action code does the framework understand to not update the existing content but add this new relationship only?

      Is this action code implemented only for this scenario?

      BR Dedeepya

      (0) 
      1. Marcus Echter

        Hi Dedeepya,

        yes exactly – “06” means “No action”. This action code is implemented on every segment of all webservices, however you need to pass over a node identifier (ID, UUID or similar) to uniquely identify the BO node which shall not be changed.

        The implementation of “06” for the partner functions (PF) is a special one: It simulates an LCTI false handling per PF code. Also you do not need to know the specific node IDs of the PF assignments which shall not be changed! By handing over a PF with this action code you indicate that the sent image is not complete wrt to this PF and any already existing node instances for this PF (which do not come as part of the message) shall not be deleted. The partnerFunctionLCTI only relates to the whole PF segment as such, i.e. all PF codes, and is even not fully implemented for this segment (we only support LCTI true). Hence we have implemented a special logic to support the above described use-case of not sending the complete PF list from ECC.

        Regards, Marcus

        (0) 
    2. Jan Vosecky

      Hi Marcus,
      We are facing the same problem as described in this blog. Could you please give us some hints how to set up in HCI the workaround solution that you and Bernd presented?

      In order to suppress now the change on the customer specific relationship the action code “06” needs to be maintained in the payload for the relationship type “ZZ”

      We have configured standard HCI iflows using Eclipse, but are not familiar with custom iflow development. Therefore any tips you may give us will be very welcome.
      Thanks!

      Best regards, Jan

      (0) 
  2. Akshay Bhandari

    ​Hello Bernd,

    BW C4C integration

    I need some clarification if you have worked in this area of integration between BW system is as below. We have connected SAP BW system 7.4 with SAP C4C system 1702 (Cloud for Customer) using ODP connection.

    1. When the data for the datasource is previewed in C4C system the data is being properly displayed. But when the data is extracted in BW system and the datasource is previewed instead of the data the UUID is displayed.Eg. In case datasource CODOPPH – we require Opportunity name (DOC_UUID) and Opportunity ID (DOC_ID) the fields are displayed correctly i.e we are able to view the Opportunity name and Opportunity ID at the C4C end. But in case of BW UUID is displayed for Opportunity name and opportunity id is displayed correctly.

    How can the exact description/name of the Opportunity can be extracted in the BW system from SAP C4C System.Could you please help us out in this regards

    Many Thanks

    Akshay

     

    (0) 

Leave a Reply