CIM Usage Guidelines

For all accelerator use cases involving the synchronization of entities between multiple systems (for example, customer profiles), the Global Data System APIs are responsible for generating and maintaining universal identifiers for all entities. Also known as "global" identifiers, these values represent a single, globally unique ID for any given instance of an entity. These values are typically assigned to the id property of any given CIM object (for example, Customer.id) in all Process APIs, where the representation of the object is expected to be the "golden copy" of it. All other system identifiers are treated as external, and thus may be found in the externalIds property where needed.

For System APIs, however, the id property of any given CIM object will be set to the identifier understood by that system on all request/response messages. If supported, the universal identifier will be found in the externalIds property with an external ID type of "GLOBAL" or "MDM". The intent behind this approach is to keep the interpretation of the identifiers for a target system as being from the perspective of that system, rather than from the Global Data repository. The same applies to most Experience APIs as well.

The following table describes a series of API calls involving a customer profile update published from Salesforce, where the customer exists in the Global Data repository but does not yet exist in SAP, to help clarify identifier usage.

In this example, the Salesforce Experience API expects the value of the incoming Customer.id property to be of type SALESFORCE_CORE. For an existing customer, the request should also contain an external ID of type MDM, which is the global identifier for this profile. To call the Customers Process API, the Customer.id value must be set to the Global Party identifier while the original Salesforce identifier is mapped as an external ID. The Process API can use same value for updating Global Data, because the Global Party System API expects the global identifier as input. To create a new profile in SAP ECC, however, the Process API provides the Global Party identifier as an external ID because the SAP System API would expect an SAP identifier (since we are creating a new profile in this case, the Customer.id value would actually be set to null in the request).

In CIM, most enumerations are defined as plain strings instead of static enumerations or as complex types (for more normalized structures). We support two distinct types of enumerations: those used as discriminators for polymorphism, and those that represent a coded value from a static list.

For discriminators, such as the partyInstance property of the Party type, the values for these will contain the actual type name (for example, Individual). As new child types extending a given base type added, the list of values for that discriminator property will grow.

For properties, such as partyStatus, on the other hand, the list of values would generally be static and usually pre-defined. Since static value lists often differ from organization to organization (or even between applications), however, most have been defined as simple strings rather then actual enums. This approach also makes the model more flexible when the list may change over time, such as a property that represents an editable picklist in a Salesforce object.

In the first version of the CIM libraries created for use by Accelerator assets, objects were structured to support a great deal of flexibility when it comes to composition. Put simply, applications had the ability to represent entities either as flat structures, where references to other entities are provided as strings, or as tree structures, where child or referenced entities are embedded as part of other objects.

In the current version of CIM, the number of cases where this is supported has been significantly reduced. In fact, it is only supported - and in limited fashion - within the individual libraries of related types of an entity group.