Maintaining External ID Mappings

When an object is replicated from SAP S/4HANA, the cloud CRM assigns its own Internal ID and saves the object’s ID from the sending system as the corresponding External ID in the External ID Mapping. Depending on the configuration, the internally assigned ID can match or differ from the External ID. Whether the IDs are the same or different, the External ID Mapping entry is always created and is necessary for referencing objects.

The internal ID is usually assigned automatically based on the configured number ranges. However, it can also be affected by the received replication message. The following screenshot, which we already saw in the previous lesson, shows the field ReceiverInternalID.

The ReceiverInternalID field is typically used in the following two cases:

• The sending system knows the object’s ID in the receiving system and sends it for further reference. SAP S/4HANA performs this.
• If the object is being replicated for the first time, the field can influence the assigned ID in the receiving system, as long as it falls within the configured number range. This is typically handled in the message mapping in Cloud Integration.

When an object is replicated from a source system to a target system, the target system can acknowledge receipt by sending a Confirmation Message back to the source system. The confirmation message includes the ID assigned in the target system, so the source system knows the ID in the target system.

Example: A Business Partner is sent from SAP S/4HANA to the cloud CRM. The cloud CRM responds with the Confirmation Message back to SAP S/4HANA, which includes the cloud CRM’s business partner ID. SAP S/4HANA stores this ID in the Unified Key Management, which is the equivalent of the cloud CRM’s External ID Mapping. Therefore, SAP S/4HANA knows the ID of the business partner in SAP Sales and Service Cloud Version 2 and can send it along if needed.

Confirmation messages can be turned on or off per integration scenario. While using them is recommended, it is not always required. It’s usually sufficient when one system can translate them. However, this depends on the integration scenarios and the system landscape.

• For the uni-directional product replication from SAP S/4HANA to the cloud CRM, where internal and external IDs are often the same, they can usually be turned off.
• For bi-directional integration of business partners between SAP S/4HANA and the cloud CRM, where new prospects can be created in the cloud CRM and later, during account conversion, sent to SAP S/4HANA with different IDs in each system, it is highly recommended.

Especially if there are more systems integrated than just SAP Sales and Service Cloud Version 2 with SAP S/4HANA, for instance, custom integrations with third-party systems, it might make sense to have IDs of other systems available in each system.

When replicated objects contain references to other objects, these are usually IDs from the sending system, and the referenced object’s ID in the receiving system might differ. This is also true for the previously shown Business Partner message that contains a reference to the sales organization. The sales organization ID in the message’s InternalID field refers to SAP S/4HANA, which is an External ID from the cloud CRM’s perspective. Therefore, SAP Sales and Service Cloud Version 2 must resolve it using the External ID Mapping.

This means the sales organization and the related External ID Mapping entry must already exist in the cloud CRM to successfully process the received business partner message. There are two ways to accomplish this:

1. The sales organization must have been replicated. In this case, the External ID Mapping is written automatically.
2. The sales organization must have been created manually or migrated. In this case, the External ID Mapping must be maintained manually or included as part of the migrated dataset.

The business partner and the sales organization show dependencies between different objects or object types. This creates a dependency hierarchy that outlines the order in which objects must be created or replicated to prevent errors caused by missing dependencies. The following graphic provides an overview of the objects discussed in this course and their dependencies.

With the replication of objects, the External ID Mapping is written automatically. However, the External ID Mapping for a specific object can also be created or edited manually. This is typically necessary when objects are created manually in the cloud CRM. Reasons for doing so can include, for example,

• Only a small subset of objects is needed, which doesn’t justify the effort of setting up the replication, especially when the affected objects don’t change often, resulting in low effort from double maintenance in two systems.
• Not all the information needed in the target system is present in the source system.

The organizational model is an example where these circumstances sometimes apply, and it is also used in this course to demonstrate the manual External ID Mapping.

All objects relevant to integration require an External ID. When an object is replicated from an External System, it is assigned an Internal ID, and the ID Mapping with the External ID is automatically written.

ID Mapping stores these IDs, which are from SAP Sales and Service Cloud Version 2’s perspective, External IDs, while local IDs are also known as Internal IDs. An external ID always belongs to a communication system.

If exchanged messages reference objects that haven't been replicated but were created locally in SAP Sales and Service Cloud Version 2, the ID mapping must be maintained manually. Common examples of this are Sales Organizations and Product Hierarchy/Categories.

The organizational structure in SAP Sales and Service Cloud Version 2 should mirror SAP S/4HANA. The following graphic shows the SAP S/4HANA organization chart on the right and the corresponding structure in SAP Sales and Service Cloud Version 2 on the left.

Since maintaining the organizational structure in SAP S/4HANA is more complex, spread across multiple transactions, and no single transaction shows all relevant org units with their integration IDs on one screen, the S/4 part is represented as a chart rather than a screenshot.

Since this course concentrates on the integration aspect, maintaining the organizational structure itself isn't explained here. However, it’s helpful to know where you can find the information.

You can access the organizational structure in the two solutions as follows:

• SAP S/4HANA: Use transaction SPRO and navigate to SAP Reference IMG→Enterprise Structure.
• The maintenance is divided into Definition and Assignment, with different kinds of organizational units located in different sub-paths, such as Financial Accounting for the Company and Sales and Distribution for Sales Organizations, Sales Offices, and Sales Groups.
• SAP Sales and Service Cloud Version 2: Navigate to User Menu→Settings→Company→Organizational Structure.
• In the cloud CRM, you can manage and assign different units in one location. It’s important to assign the correct functions to the organizational units; otherwise, replicated objects, such as products or business partners, may not be processed correctly later.

The IDs in this course’s SAP Sales and Service Cloud Version 2 demo system were intentionally selected to differ from those in SAP S/4HANA. This is mainly achieved by adding a prefix, which could also be applied during the replication of organizational units. The prefix is a configurable parameter in the organizational structure-related integration flows, as shown in the following image with the example of the integration flow Replicate Sales Organization from SAP S/4HANA.

Once the organizational structure in SAP Sales and Service Cloud Version 2 is set up and the SAP S/4HANA IDs are known, the External ID Mapping can be maintained in the cloud CRM.

To maintain the External ID Mapping, open the user menu and go to Settings→Integration→External ID Mapping.

Since ID Mappings are always created within the context of a specific communication partner, you need to select the object type you want to maintain a mapping for, labeled with Mapping Of, and choose the Communication System ID, which is T41CLNT400 in our example. Then, you can choose Search to show available object instances.

While the ID, Name, and Communication System ID columns will display values for all records, the External ID column will only show a value if the corresponding object instance has an External ID assigned, whether it was created automatically during replication or manually.

The following video shows how to maintain the organizational units relevant to this course. All of them can be found in the Mapping Of dropdown in the submenu of Organizational Units.

The mapping entries in the demo environment are as follows:

Generally, External ID Mapping is only needed for object instances that will be referenced by other replicated objects. In this course, these are Business Partners and Products. These two objects usually don’t reference the company directly; therefore, maintaining the companies’ ID mapping isn’t necessary for these examples. However, it has been kept for the sake of completeness.

For the other mappings, keep in mind that even if the internal and external IDs are the same, you still need to create a mapping entry!

Please note that for certain integration scenarios, External ID Mappings for other objects might be required. The sales organizations have been chosen here for demonstration purposes because they are prerequisites for many other objects.