Receiving data from SAP is handled with inbound integration endpoints (IIEPs) using the Match and Merge Importer processing engine.
Object Identification
To ensure consecutive updates to the same source record are automatically routed to the existing golden record when BPs are received from SAP, the BP internal ID must be mapped to the Source Record ID attribute on the Source System Reference in the Merge Golden Record Component Model.
To ensure survivorship rules for addresses, emails, and phone numbers are handled, address UUIDs from SAP must be mapped to an incoming SAP address UUID attribute on address, email, and phone data containers. Refer to the SAP Address Source Record Relations section of the SAP Business Partners and Enterprise Structure Definitions topic here.
Error Handling
Since errors that must be addressed by business users are expected to be managed in STEP, there is no communication back to the sending SAP application. This also means that for challenges with value harmonization of LOVs, etc., the golden records data model in STEP must be designed to store data that is not harmonized in STEP and to use workflows and business rules to overcome such challenges within STEP.
For more information on error handling, refer to the Replication Error Messages section below.
Message Sequencing
To preserve the sequence of BP (Business Partner) and RL (Relationship Link) replication messages, so that, for example, an RL message for a new BP does not arrive prior to the new BP, one IIEP is used to receive both BP and RL replication messages. This means that the transformation from both BP- and RL- Replication messages must be written in the same XSLT.
Since the inbound integration from SAP to STEP expects that the transport of messages preserves the sequence of messages, the latest received message is expected to contain the latest information about a given BP. For this reason, STEP ignores the 'changeOrdinalNumberValue' provided by SAP.
Source Record Status
Source Record Status is a data container (ID= SAPBPSourceRecordStatusData).
-
Source Record ID - As inbound integrations or merges of existing golden records add source records to the source system relation, survivorship rules must also add those source record IDs as source record status objects, so that 'Is Survivor' and 'Replication Error Messages' can be managed.
-
Is Survivor - As multiple BPs from the same source (SAP) system merge into the same golden record in STEP, a surviving source record, per source system, is determined by survivorship rules.
When a golden record is a reference target of another golden record and the reference is exported to a given source system, it is the surviving source record that must be target of the reference in the message sent to the source system.
-
Handling in Partner Function and RL Replication (BP-to-BP References)
When a reference source or target does not have a surviving source record ID for a given SAP system, the STEP ID must be mapped to the BusinessPartnerInternalID and/or RelationshipBusinessPartnerInternalID in the RL replication message and to the PartnerFunction/PartyInternalID in the BP replication message.
The missing source record ID may be because the record is missing in the target system. Since the integration is asynchronous, the message that creates the target may be in transit and arrive earlier than this message. If not, this replication must fail and the async response should reveal the error, leading to the error workflow where the entity replication is retried exactly once. If the next attempt fails, the entity is placed in a manual fallout task where it is up to a user to resolve the inconsistency in data and resubmit the entity to the target system. Refer to the Error handling workflow information below.
Use the following exact logic for the survivorship rule:
-
Find source record IDs in the source record / non-surviving golden record
-
Add source record IDs in the source record status if they do not already exist
-
Add all source record statuses of non-surviving golden records to the survivor (to cover merge of existing golden records)
-
Determine exactly one surviving source record per source system. The default logic is:
-
Priority 1: survivor is the existing surviving source record of the target golden record
-
Priority 2: survivor is the existing surviving source record of non-surviving golden record (merge of existing golden records)
-
Priority 3: survivor is the new source record ID (update / merge on import)
-
-
-
Replication Error Messages - As 'BP-Replication Confirmation-' and 'RL-Replication Confirmation' messages are received from SAP containing error messages, error messages are written to the replication error messages by survivorship rules.
Separate replication error messages must exist for each atomic scope of data that is replicated, so that errors related to one problem cannot overwrite errors correlated to another problem.
Specifically, BP replication and Relationship Link (RL) replication are two atomic scopes of data that is replicated.
When transforming the SAP response to STEPXML, the error messages should be mapped to an SAP Source Record Status Data Container object.
Use survivorship rules to write error messages to the Source Record Status Data Container objects with the following specific logic:
-
Find target DC by Source System + Source Record ID.
-
Set relevant error message, overwriting any existing error message.
Replication Error Messages Approve Trigger
If a golden record has at least one error message, it must be initiated into the error handling workflow. This determination should be done with an approve trigger running for these scenarios:
-
post survivorship rules on import
-
on auto-merge in the event processor
-
post merge in the clerical review workflow
If the golden record has zero error messages in the Source Record Status data container but it is already in the workflow, it must be removed from the workflow, by letting the workflow transition back to the initial state and reevaluate.
Error Handling Workflow
The error handling workflow must determine the appropriate action for a given error. The recommended logic is:
-
retry the replication once (refer to the Handling in Partner Function and RL Replication section above)
-
if it keeps failing, send it to a manual queue
-
-
When republishing events to the relevant OIEPs, the retry count for the relevant source records must be incremented.
