Zuverlässige Integrationen: Wiederholungen, unklarer Versand und Abstimmung

Zuverlässigkeit bedeutet, den Geschäftsvorfall wiederherstellen zu können, wenn eine HTTP-Antwort, ein Worker oder eine Netzwerkbestätigung fehlt. „Dreimal wiederholen“ ist keine finanzielle Wiederherstellungsstrategie. Manche Fehler lehnen eine Anfrage eindeutig ab. Andere entstehen, nachdem eine nummerierte Rechnung oder Geldbewegung bereits verbindlich gespeichert wurde.

Ein Identitätsverzeichnis erhalten

Speichern Sie Quelltransaktions-ID, Integrationsnamensraum, Belegart, Fingerabdruck der Anfragedaten, Produkt-ID beziehungsweise Nummer und das letzte bekannte Ergebnis. Erfassen Sie für Geldbewegungen die Quell-ID der Zahlung oder Rückerstattung und die zugehörige Rechnung. Schützen Sie das Verzeichnis vor beiläufigen Änderungen: Eine nach einer Zeitüberschreitung geänderte ID hebelt den Duplikatschutz aus.

Die dauerhafte Belegidentität in OrdoGrid ist nach Unternehmen, Integration und Belegart abgegrenzt. Bewegungsidentitäten gelten innerhalb von Unternehmen und Integration über verschiedene Rechnungen und Bewegungsarten hinweg. Das Neuerstellen oder Rotieren eines Schlüssels gibt diese Identitäten nicht frei. Erhalten Sie dabei den Integrationsnamensraum, damit die Verbindung zum ursprünglichen Geschäftsvorfall bestehen bleibt.

Beide Ebenen des Duplikatschutzes verwenden

Senden Sie Idempotency-Key bei wiederholbaren Schreibvorgängen. Eine identische HTTP-Wiederholung liefert die zwischengespeicherte Antwort, soweit verfügbar. Derselbe Schlüssel mit einem anderen Anfrageinhalt wird abgelehnt. Seine Lebensdauer von 24 Stunden und seine Bindung an den API-Schlüssel ersetzen keine stabilen external_id-Werte.

Dauerhafte Belegwiederholungen geben die erste abgeschlossene Belegantwort zurück. Wiederholte Bewegungsanfragen geben die ursprüngliche Bewegung mit dem aktuellen Zahlungsausgleich und replayed: true zurück. Verwenden Sie diese Kennungen auch nach Ablauf des Antwortcaches oder dem Austausch von Zugangsdaten für den Abgleich. Erzeugen Sie nicht bei jedem Versuch eine neue Identität des finanziellen Geschäftsvorfalls.

Vor der Wiederholung das Ergebnis einordnen

Bei EXTERNAL_ID_REUSED können auch nichtfinanzielle Änderungen an Erstellungsdaten entscheidend sein. Vergleichen Sie deshalb den gesamten ursprünglichen Anfrageinhalt, nicht nur Rechnungssummen. Eine Ausführungsreservierung kann ablaufen, während die dauerhafte buchhalterische Identität bestehen bleibt. Behandeln Sie einen fortgesetzten Vorgang als Wiederherstellung dieses Datensatzes und nicht als neues Geschäftsereignis.

Verwenden Sie in Ihrem Client begrenzte Warteintervalle mit zufälliger Streuung für wiederherstellbare Konkurrenzsituationen oder vorübergehende Verfügbarkeitsfehler. Die Verantwortung für Wiederholungsbudget und maximales Rückstandsalter liegt im Betrieb. Es handelt sich um Entscheidungen für Ihre Integration, nicht um Produktgarantien.

Speicherung des Belegs und Netzwerkaustausch unterscheiden

Ein Versandvorgang kann zuerst die Rechnung erstellen und anschließend auf ein Netzwerkproblem stoßen. Suchen Sie den finanziellen Datensatz und untersuchen Sie den Übertragungszustand getrennt. Ein bekanntermaßen abgelehnter Versand kann mit denselben ausgestellten Bytes erneut versucht werden, soweit dies zulässig ist. Eine mehrdeutige Übertragung könnte das Netzwerk bereits erreicht haben; der automatische erneute Versand bleibt deshalb angehalten.

Die Invoice-Response-Spezifikation von OpenPeppol unterscheidet Netzwerkbestätigung und geschäftliche Entscheidung des Käufers. Eine zugestellte Nachricht belegt weder Zustimmung noch Zahlungseingang. Führen Sie Zahlungsausgleich, Transportzustand und Kundenantwort in getrennten Überwachungsfeldern.

Beispiel: Wiederherstellung nach Schlüsselrotation

Die ERP-Rechnung order-4711 wurde unter dem Namensraum erp erstellt; ihre erfolgreiche Antwort ging verloren. Danach wird der Schlüssel rotiert. Der Konnektor beginnt mit /me, bestätigt dasselbe Unternehmen und denselben Namensraum und sucht anschließend order-4711. Er findet die bestehende nummerierte Rechnung, anstatt sie erneut auszustellen.

Später synchronisiert der Konnektor eine Anzahlung mit derselben Quellidentität der Zahlung. Die wiederholte Bewegungsanfrage identifiziert den ursprünglichen Geldeintrag, statt eine weitere Anzahlung hinzuzufügen. Hätte der Konnektor den Schlüssel unter einem anderen Namensraum angelegt und eine neue Rechnungs-ID erfunden, wäre der vorgesehene Wiederherstellungsvertrag umgangen worden.

Geschäftsvorfälle statt nur Verfügbarkeit überwachen

Verfolgen Sie unbearbeiteten Rückstand, ältesten angehaltenen Eintrag, erfolgreiche Speicherungen, dauerhafte Zuordnungsablehnungen, unklare Übertragungen und Abstimmungsdifferenzen. Zählen Sie Anfragen getrennt von Geschäftsereignissen: Eine Wiederholung ist kein neuer Umsatz. Protokollieren Sie bereinigte Fehlercodes, IDs und Zeitpunkte; zeichnen Sie niemals Bearer-Geheimnisse auf.

Lesen Sie alle Listenseiten mit konsistenten Filtern. Überschneidet sich ein Extrakt mit laufenden Schreibvorgängen, halten Sie sein Zeitfenster fest und stimmen Sie spätere Änderungen ab. Bestimmen Sie anhand Ihres tatsächlichen Serviceprozesses Alarmverantwortung und Eskalationsweg für wachsenden Rückstand oder finanzielle Differenzen.

Wiederherstellung abnehmen und den Betrieb übergeben

Prüfen Sie verlorene Antwort, gleichzeitige Erstellung, abgelaufenes HTTP-Wiederholungsfenster, Schlüsselrotation, abgelehnten Versand und unklaren Versand. Die Abnahme verlangt eine finanzielle Identität je Ereignis, erwarteten Zahlungsausgleich, keinen doppelten Übertragungsversuch im unklaren Fall und den Nachweis, dass eine Vertretung die Warteschlange bearbeiten kann.

Stimmen Sie nach einer Störung die gesamte betroffene Grundgesamtheit ab, bevor Sie die Wiederherstellung erklären. Übergeben Sie Entscheidungstabelle, Schlüsselverantwortung, Ablageort des Identitätsverzeichnisses, Wiederholungsverfahren und Anbieterkontakt. Offene geschäftliche Fälle gehen mit Auswirkung und nächster Maßnahme an das Finanzteam. Nutzen Sie Störungsbearbeitung für die Koordination und API-Integration für den ursprünglichen Schnittstellenvertrag.