08. Schreiben, Idempotenz und Parallelität

Robuste Integrationen zeichnen sich nicht dadurch aus, dass nie etwas schiefgeht. Sie zeichnen sich dadurch aus, dass derselbe Schritt nach einem Fehler sicher erneut versucht werden kann.

Die Schnittstelle als Produkt

Idempotenz verbindet ein externes Ereignis dauerhaft mit genau einem X-ERP-Vorgang. RowVersion oder ein vergleichbarer Versionswert schützt vor verlorenen Updates, wenn Anwender und Integration parallel arbeiten.

So wird die Anbindung robust

1. Erzeugen Sie pro Geschäftsvorgang einen stabilen Idempotenzschlüssel.
2. Suchen Sie vor POST/Retry nach diesem Schlüssel und speichern Sie die X-ERP-ID.
3. Lesen Sie vor Update den aktuellen Stand und dessen Versionsinformation.
4. Senden Sie nur freigegebene Änderungen; behandeln Sie Konflikte als eigene Warteschlange.
5. Wiederholen Sie nur nachweislich transiente Fehler mit begrenztem Exponential Backoff und Jitter.
6. Stoppen Sie bei fachlichen Fehlern und verlangen Sie Korrektur.

Produktionsreife nachweisen

• Derselbe Request kann mehrfach eintreffen, wirkt aber einmal.
• Parallele Benutzeränderung wird erkannt, nicht überschrieben.
• Retryzahl und Gesamtdauer sind begrenzt.
• Dead-Letter-/Klärungsfälle besitzen Kontext und Eigentümer.

Fehler, die erst im Betrieb teuer werden

• Jeder Fehler wird mit Retry beantwortet.
• PUT sendet veraltetes Gesamtobjekt und löscht neue Werte.
• Zufällige UUID pro Retry verhindert das Wiederfinden des ursprünglichen Vorgangs.

Das nehmen Sie mit

Schreiben wird zu einer kontrollierten Zustandsmaschine statt zu einer Folge hoffnungsvoller HTTP-Aufrufe.

Weiterführender Link / Quelle

Weiterführende Themen

1. Für Integrationsspezialisten – APIs und externe Systeme anbinden › 07. Belege und Lager kontrolliert anbinden
2. Für Integrationsspezialisten – APIs und externe Systeme anbinden › 09. Fehlerdiagnose, Logging und Wiederanlauf
3. Für Integrationsspezialisten – APIs und externe Systeme anbinden › 10. Test, Abnahme und Produktionsbetrieb

Häufige Fragen