SAP Publishing From STEP

Publishing of data to SAP is handled with an event-based outbound integration endpoint (OIEP).

Inbound integration endpoints (IIEPs) with Match and Merge Processing Engine are used to process acknowledgment messages from SAP to STEP.

A separate OIEP is configured for BP replication and RL (Relationship Link) replication.

As the BP replication reads the events in batches, it exports the batch of entities and uses XSLT to transform this into a SOAP message. The SAP BP / RL replication APIs support receiving and acknowledging multiple BPs in one message.

The event batch size of the OIEP should be limited so that the message size does not grow too big. For example, the STEP XSLT processors are limited to handle files not bigger than a certain size. Refer to the OIEP - Post-processor - Transformation by XSLT topic in the Data Exchange documentation here.

The SOAP messages are delivered to SAP via middleware using, for example, REST Upload, JMS delivery, FTP, etc.

As BP replication acknowledgment comes back from SAP, missing identifiers and status information is updated on the BP entity.

The RL replication uses the same pattern to export, transform, and deliver messages to SAP as the BP replication.

As the RL replication message comes back from STEP, the status is written to STEP.

Correlation of Messages and Data Objects

The async confirmation message can be correlated to the request by a message ID provided by the sender in the request.

The async confirmation message also contains the identifiers of the BP object. Both the sender provider and the receiver created identifiers are included.

Address UUIDs generated by the receiver are not part of the async confirmation.

STEP Solution

Since the STEP Integration Endpoints do not support async message id correlation patterns, the sequence diagrams above outline a simpler solution based on correlating async acknowledgment messages to BP entities. Consequently, the STEP ID of a BP entity published from STEP to SAP must be stored in SAP and must be part of the async acknowledgment message. This is possible since SAP allows BP objects to have an ID that is unique for a specific sender system (STEP).

It is also recommended that each SAP system generate its own BP IDs and that the MDM system store those IDs as Source Record IDs according to the Merge Golden Record Component model.

Since IDs of addresses are not part of the async confirmation message, to refer to the same addresses in later requests, you must send to SAP the ID given to an address by STEP. The ID of an address in SAP is a UUID, which is a generated identifier that can and must be considered globally unique. Therefore, STEP can use the [uuid] STEP ID Pattern for the address, email and phone data container type and the STEP ID of the address can be used in SAP. However, as multiple records in the same SAP system merge into the same Golden Record, the same surviving addresses, emails and phones must be represented by multiple SAP UUID. Refer to the details of handling this in SAP Address Source Record Relations.

Email and Phone Number Approve Trigger

For information on the modeling of Address, Email and Phone Number, refer to the Emails and Phone Numbers and the Approve Trigger section of the SAP Business Partners and Enterprise Structure Definitions topic here.

This approval trigger is invoked by the Match and Merge Importer, by the Matching Event Processor, and after manual merge in the Clerical Review Workflow.

Use the following specific logic:

  • Group addresses, emails and phones by usages and validity dates

    • Each address is a group

    • Allocate the zero-to-many addresses for each email and phone by usage and validity period

    • Make a separate group for each email and phone that are not allocated to at least one address

  • Determine one STEP address ID for each group

    • Priority 1: use STEP ID of address

    • Priority 2: use lowest STEP ID of emails and phones

  • On each email and phone, replace existing STEP address IDs with the set of STEP address ID of each group it is member of.

SAP Address Record relations must be maintained as addresses, emails and phones are approved and after the STEP address ID on email and phone has been maintained.

Validate that the union of all STEP IDs address data containers and STEP address IDs on email and phone data containers each has different SAP UUID for each SAP BP record. This ensures that there are no conflicts of address UUIDs in SAP, even when one BP entity in STEP represents multiple BP records within one SAP system.

Atomic Scopes of Content to Update

When sending data from STEP to SAP, the SAP BP / RL replication web services support different action codes for adding, removing, and replacing different parts of the content of the BP objects.

To keep things simple, it is recommended to always use 'Action Code 04' which:

  • makes modifications to existing information in SAP

  • creates new information present in the message but not present in SAP

  • removes information present in SAP but not present in the message

Message Sequencing

The SAP BP / RL replication web services support ignoring messages that has been superseded by newer messages by including a 'changeOrdinalNumberValue' on the BP XML element.

In STEP, this can be set to system time in milliseconds as the message is generated and exported. This is implemented directly in the XSLT that transforms the exported STEP XML to SOAP messages.

For the inbound integration of acknowledgments from SAP to STEP, it is expected that the transport of messages will preserve the sequence of messages and therefore the latest received message can always be expected to contain the latest information about a given BP. For this reason, STEP ignores the 'changeOrdinalNumberValue' provided by SAP.