Skip to Content

When setting up an integration between C4C and a remote system, you need to create a so-called “Communication System” which represents the remote system in C4C and consists of one or several “System Instances” – which are in fact separate clients/tenants on the same physical system. Whereas the communication system is only used for grouping purposes and does not have any impact on the runtime behavior of the integration as such, the system instance is the actual logical system used by the integration runtime to derive the correct ID and code list mapping as well as to check the consistency of the message header, i.e. if the sending system of a received payload is configured in C4C or if the message has been sent by an arbitrary system.

The system instance has multiple identifiers which are used for different purposes, especially when integrating with an SAP ERP/CRM system. In a lot of customer implementations it turned out it is not really clear when to use which of these identifiers and how they should be setup. This blog provides some details around this topic.

As said above the communication system does not play any role in integration and is only used for semantically grouping system instances. But from a conceptual point of view the communication system represents a physical system, while the system instance represents a client/tenant on this system (i.e. logical system). Only the latter is relevant for integration and all dependent functionalities (e.g. ID mapping, code list mapping).

A system instance within a communication system can be identified based on either of the following 3 identifiers:

  • System Instance ID: C4C ID of the system instance -> typically this identifier is used in a 3rd party integration scenario
  • Business System ID: external ID used in SAP on-premise systems -> typically this identifier is used in a webservice-based integration scenario with SAP on-premise systems (Note: This ID needs to be the same as defined in SAP ERP)
  • IDoc Logical System ID: external ID used in SAP on-premise systems -> typically this identifier is used in an IDOC-based integration scenario with SAP on-premise systems (Note: This ID needs to be the same as defined in SAP ERP, transaction BD54)

A C4C inbound message contains both the sender and receiver system as part of the message header. The receiver system is always the short tenant ID of the C4C tenant which can be found under “My System” in the Communication Arrangement:

/wp-content/uploads/2016/09/pic_1033296.png

The interesting part is the sender system (i.e. sending system instance) as it has 3 different identifiers – either one of them can be used in the message header to derive the configured system instance ID in C4C.

Example:

Let’s assume we have a communication system SBQ with 1 system instance containing the following identifiers:

  • System Instance ID: SBQ_200
  • Business System ID: SBQ/200
  • IDOC Logical System ID: SBQCLNT200

Here is how the message header needs to look like in case either of the 3 different ID types is used:


1. System Instance ID:

     <SenderParty>

         <InternalID schemeID=”CommunicationSystemID” schemeAgencyID=”310”>

               SystemInstanceID, e.g. SBQ_200

          </InternalID>

     </SenderParty>

2. Business System ID:

     <SenderBusinessSystemID>BusinessSystemID, e.g. SBQ/200</SenderBusinessSystemID>

3. IDoc Logical System ID:

     <SenderParty>

         <InternalID schemeID=”LocalSystemID” schemeAgencyID=”310”>

               IDocLogicalSystemID, e.g. SBQCLNT200

          </InternalID>

     </SenderParty>

All of the 3 excerpts of message headers are semantically correct and will be able to successfully derive the same system instance. The integration scenario determines which identifier is to be used: 1. is used in a 3rd party integration, 2. in a webservice-based integration with an SAP OP system and 3. in an IDOC-based integration with an SAP OP system. Our pre-delivered integration flows already take the different usages of the system instance identifiers into account and map the correct ID (2. vs. 3.) as part of their HCI/PI message mappings.

What you can see in the example above as well is that the various IDs on a system instance can very well be different and do not need to be the same as I have already read in some blogs. Actually, it is best practice to define different values for the 3 IDs in order to be sure when you are talking about which ID.

Hope this clarifies some of the confusion and uncertainty around this topic.

To report this post you need to login first.

1 Comment

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

Leave a Reply