Bidirectional sync between SAP and an external system without an infinite loop

Two integrations that each work perfectly on their own can produce an infinite loop together: each side reports a change, and each change is the reaction to the previous one. This article explains how the loop arises, which two mechanisms break it, which field ties the records in both systems together, and why create and update mappings tend to drift apart.

A record changes in the external system. The integration writes the change to SAP. The return sync picks up the change event from SAP, or finds the change on its next poll, and writes it back to the external system. That write triggers another change event there, and the sequence starts over.

None of the four steps is doing anything wrong. In most systems a write triggers a change event, and for a one-way integration that is exactly what you want. As soon as both sides write, it turns into a cycle that doesn't stop on its own.

A time window that ignores anything arriving shortly after your own write works under light load and breaks as soon as a run takes longer than expected. Two mechanisms that rely on content rather than timing, and need no stored state, are more reliable.

On the SAP side: the last-changed-by user. Many SAP objects record which user last changed them; for the business partner the OData API exposes this as LastChangedByUser (API_BUSINESS_PARTNER in the SAP Business Accelerator Hub (opens in a new tab)). If the integration writes with a dedicated technical user, the return sync excludes that user and no longer sees its own writes. The one condition is that this user is reserved for the integration.

On the external system: compare before writing. External systems often have no such field. The integration then reads the record before writing, compares the fields it is about to write with what's already there, and only writes if something differs. A change that has come full circle carries exactly the values just written, finds no difference, and stops there. The cost is one extra read per record.

For the return sync to know which record in the external system corresponds to which object in SAP, the SAP object needs a field that holds the external identifier. For the business partner that field is BusinessPartnerIDByExtSystem (API_BUSINESS_PARTNER (opens in a new tab)); other objects have their own, and where none exists you add a custom field.

The field does two jobs. It links the records, and it acts as a filter, because only objects with the field filled came from the external system and belong in the return sync. In a one-way integration it looks superfluous and often isn't filled in the mapping. We recommend filling it from the very first direction; if it is empty for existing records, they have to be maintained before you switch the return sync on.

In many integrations, create and update cover different fields. The create mapping comes first and includes everything a new record needs; the update mapping is added later and covers only the fields that mattered at the time.

For a one-way integration that has no consequences. With bidirectional sync, every field that is written back in one direction but not updated in the other drifts a little further with each run, and because both mappings run without errors, no monitoring flags anything.

We recommend keeping a list of the fields that are meant to stay in sync and checking both mappings, in both directions, against that list. A field that isn't on the list isn't transferred in either direction.

Bidirectional sync uses the same technology as one direction, plus three decisions:

1. How does each side recognise its own writes? A technical user and LastChangedByUser on the SAP side, compare-before-write on the external system.
2. Which field links the records? BusinessPartnerIDByExtSystem or its equivalent, filled from the start.
3. Which fields are meant to stay in sync? A list that both mappings are checked against.

If any of the three answers is missing, the sync will still start; the problem shows up later, with data that has already drifted. We recommend switching on the second direction only once all three answers are written down.