Schnittstellen, die halten: ERP-Anbindung mit Retry und Logging

Fast jedes B2B-Portal und jeder Webshop muss früher oder später ans ERP: Aufträge übergeben, Preise und Verfügbarkeiten ziehen, Kunden- und Artikeldaten abgleichen. Eine solche Anbindung ist schnell „fertig“ — und fällt dann im laufenden Betrieb leise aus. Der Unterschied zwischen einer Schnittstelle, die in der Demo funktioniert, und einer, die im Alltag trägt, liegt selten in der Fachlogik. Er liegt darin, was passiert, wenn etwas schiefgeht.

Warum Schnittstellen leise scheitern

Im Demo-Betrieb läuft alles glatt. Im echten Betrieb kommt irgendwann das Netz weg, das ERP steht im Wartungsfenster, eine Anfrage läuft in einen Timeout, eine Nachricht wird doppelt gesendet oder ein Datensatz kommt in einem unerwarteten Format an. Ohne Vorkehrung führt das zu verlorenen oder doppelten Aufträgen — und oft merkt es niemand, bis ein Kunde reklamiert. Genau diese „schlechten Tage“ entscheiden über die Qualität einer Integration.

Idempotenz: dieselbe Nachricht zweimal darf nicht schaden

Die wichtigste Eigenschaft einer belastbaren Schnittstelle: Wird dieselbe Nachricht versehentlich zweimal übertragen, darf das keinen Schaden anrichten. Erreicht wird das über einen eindeutigen Schlüssel je Vorgang, an dem das Zielsystem eine Wiederholung erkennt und nur einmal verarbeitet. Erst diese Idempotenz macht automatische Wiederholungen überhaupt gefahrlos.

Retry mit Augenmaß

Nicht jeder Fehler ist gleich. Vorübergehende Störungen (Netz, Timeout, kurzer ERP-Ausfall) lassen sich automatisch wiederholen — mit wachsendem Abstand zwischen den Versuchen. Fachliche Fehler (ungültige Daten) dürfen dagegen nicht endlos wiederholt werden; sie gehören nach klarer Kennzeichnung in eine Fehler-Ablage, aus der sich der Vorgang nach Korrektur kontrolliert erneut auslösen lässt. Die saubere Trennung „vorübergehend“ versus „dauerhaft“ ist der Kern eines brauchbaren Retry-Konzepts.

Logging, das im Ernstfall hilft

„Hat funktioniert“ ist kein Log. Nützlich wird es erst, wenn pro Vorgang nachvollziehbar ist: welche Nachricht, wann, mit welchem Status, welcher Antwort und welchem Fehler. Wenn im Ernstfall ein Auftrag fehlt, zählt, dass man in Minuten sieht, was wo hängengeblieben ist — statt in Vermutungen zu suchen. Das ist dieselbe Logik wie beim Audit-Trail eines Störmeldeportals: Nachvollziehbarkeit ist Betriebsfähigkeit.

Asynchron statt blockierend

Ein Portal sollte nicht warten, bis das ERP geantwortet hat. Die Auftragsannahme bleibt schnell und bedienbar; die eigentliche Übertragung läuft im Hintergrund über eine Warteschlange und Worker-Prozesse. So bleibt die Anwendung für den Kunden reaktionsschnell, auch wenn das ERP gerade langsam ist oder kurz nicht erreichbar — die Nachricht wartet einfach, bis es wieder geht.

Aus der Praxis

In einem B2B-Ersatzteil- und Serviceportal und einem CAD-Bestellportal habe ich genau diesen Ansatz umgesetzt: idempotente Übertragungen an ERP- und Fertigungssysteme, automatische Wiederholung bei transienten Fehlern, durchgängiges Logging und die Möglichkeit, fehlgeschlagene Exporte kontrolliert erneut anzustoßen. Der spürbare Effekt ist weniger Feuerwehr im Alltag und mehr Vertrauen in die Zahlen.

Der eigentliche Unterschied

Eine Schnittstelle ist nicht fertig, wenn sie im Normalfall läuft, sondern wenn sie den schlechten Tag übersteht: ERP-Ausfall, doppelte Nachricht, krummes Datenformat. Idempotenz, Retry und Logging sind kein Gold-Plating — sie sind der Unterschied zwischen „läuft in der Demo“ und „trägt im Betrieb“.

---

Sie verbinden Portal oder Shop mit Ihrem ERP und wollen, dass die Anbindung auch am schlechten Tag trägt? Sprechen Sie mich an.