Zwei einzeln fehlerfreie Integrationen ergeben zusammen eine Endlosschleife. Wie sie entsteht, wie eigene Schreibvorgänge erkannt werden, welches Feld die Datensätze verbindet und warum Anlege- und Update-Mapping auseinanderlaufen.
Zwei Integrationen, die einzeln fehlerfrei laufen, erzeugen zusammen eine Endlosschleife: Jede Seite meldet eine Änderung, und jede Änderung ist die Reaktion auf die vorige. Dieser Beitrag beschreibt, wie die Schleife entsteht, mit welchen zwei Mechanismen sie unterbrochen wird, welches Feld die Datensätze beider Systeme verbindet und warum Anlege- und Update-Mapping auseinanderlaufen können.
Ein Datensatz ändert sich im Fremdsystem. Die Integration schreibt die Änderung nach SAP. Die Gegenrichtung erhält das Änderungsevent aus SAP oder findet die Änderung bei der nächsten Abfrage und schreibt sie zurück ins Fremdsystem. Dieser Schreibvorgang löst dort erneut ein Änderungsevent aus, und der Ablauf beginnt von vorn.
Keine der vier Stationen arbeitet fehlerhaft. Ein schreibender Aufruf löst in den meisten Systemen ein Änderungsevent aus, und das ist bei einer Integration in eine Richtung das gewünschte Verhalten. Sobald beide Seiten schreiben, wird daraus ein Kreislauf, der ohne Gegenmaßnahme nicht endet.
Ein Zeitfenster, das alles kurz nach dem eigenen Schreibvorgang ignoriert, funktioniert bei geringer Last und versagt, sobald ein Lauf länger dauert. Verlässlicher sind zwei Mechanismen, die auf Inhalten beruhen und keinen gespeicherten Zustand benötigen.
Auf der SAP-Seite über den letzten Änderer. Viele SAP-Objekte führen mit, welcher Benutzer sie zuletzt geändert hat; der Geschäftspartner stellt dafür in der OData-API das Feld LastChangedByUser bereit (API_BUSINESS_PARTNER im SAP Business Accelerator Hub). Schreibt die Integration mit einem eigenen technischen Benutzer, schließt die Rückrichtung genau diesen Benutzer aus und sieht ihre eigenen Schreibvorgänge nicht mehr. Voraussetzung ist, dass dieser Benutzer für nichts anderes verwendet wird.
Auf der Gegenseite über den Inhaltsvergleich. Fremdsysteme führen ein solches Feld häufig nicht. Dann liest die Integration den Datensatz vor dem Schreiben, vergleicht die zu schreibenden Felder mit dem Bestand und schreibt nur bei einer Abweichung. Eine zurücklaufende Änderung trägt exakt die Werte, die gerade geschrieben wurden, findet keinen Unterschied und endet dort. Der Vergleich kostet einen zusätzlichen Leseaufruf pro Datensatz.
Damit die Rückrichtung weiß, welcher Datensatz im Fremdsystem zu welchem Objekt in SAP gehört, benötigt sie ein Feld im SAP-Objekt, das die Kennung der Gegenseite trägt. Beim Geschäftspartner ist das BusinessPartnerIDByExtSystem (API_BUSINESS_PARTNER); andere Objekte haben eigene Felder, und wo keines vorhanden ist, wird ein kundeneigenes Feld angelegt.
Das Feld hat zwei Aufgaben: Es verknüpft die Datensätze, und es dient als Filter, denn nur Objekte mit gefülltem Feld stammen aus dem Fremdsystem und gehören in die Rückrichtung. Bei einer Integration in eine Richtung wirkt es überflüssig und wird im Mapping häufig nicht befüllt. Wir empfehlen, es von der ersten Richtung an zu füllen; ist es bei Bestandsdaten leer, müssen diese nachgepflegt werden, bevor die Rückrichtung aktiviert wird.
In vielen Integrationen decken Anlegen und Update unterschiedliche Felder ab. Das Anlege-Mapping entsteht zuerst und enthält alles, was ein neuer Datensatz benötigt; das Update-Mapping kommt später und beschränkt sich auf die Felder, die zum damaligen Anlass benötigt wurden.
Bei einer Integration in eine Richtung bleibt das ohne Folgen. Bei bidirektionalem Abgleich läuft jedes Feld, das in einer Richtung zurückgeschrieben, in der anderen aber nicht mitgeschrieben wird, mit jedem Durchlauf weiter auseinander, und weil beide Mappings jeweils fehlerfrei arbeiten, meldet kein Monitoring einen Fehler.
Wir empfehlen eine Liste der Felder, die synchron gehalten werden; beide Mappings werden in beiden Richtungen gegen diese Liste geprüft. Ein Feld, das nicht auf der Liste steht, wird in keiner Richtung übertragen.
Bidirektionaler Abgleich verwendet dieselbe Technik wie eine Richtung, ergänzt um drei Antworten:
LastChangedByUser auf der SAP-Seite, Inhaltsvergleich auf der Gegenseite.BusinessPartnerIDByExtSystem oder ein entsprechendes Feld, von Anfang an gefüllt.Fehlt eine der drei Antworten, läuft der Abgleich trotzdem an; der Fehler zeigt sich später, mit Daten, die bereits auseinandergelaufen sind. Wir empfehlen, die zweite Richtung erst zu aktivieren, wenn alle drei Antworten dokumentiert sind.
Weiterlesen
Termin buchen
Sprechen Sie uns an. Wir unterstützen bei Schleifenschutz, Verknüpfungsfeld und Feldliste, bevor die zweite Richtung aktiviert wird.
Schreib uns oder buche direkt ein kurzes Meeting.
