Hängende Bestellungen und Störungen: Fehlersuche im Bestellfluss

Zwei Systeme können sich über einen Auftrag uneinig sein, ohne dass im Shop eine Fehlermeldung erscheint: Der Vorgang ist im Shopsystem gespeichert, während die Warenwirtschaft ihn nie erhalten hat. Ein hängender Auftrag lässt sich deshalb nicht am Shopsystem allein diagnostizieren; die Bestellbestätigung an die Kundschaft entsteht dort, bevor der Vorgang das Zielsystem erreicht. Arbeiten Sie den Weg vom Auslöser bis zur Übernahme im Ziel durch und halten Sie je Fall fest, an welcher Station er stehen geblieben ist. Den Aufbau des Ablaufs selbst behandelt Bestellabwicklung automatisieren.

Übergeben Sie Bestellungen von Hand, etwa per Export und Import, gelten die Schritte 1 bis 3 ebenfalls; einen Antwortcode gibt es dort nicht.

Was Sie vorab brauchen

• Zugang zu den Bestelldaten im Shopsystem und zum Protokoll beider Seiten oder zum Bericht des ausführenden Dienstes
• die Kennung, mit der die Übertragung arbeitet: Bestellnummer, Belegnummer oder ein eigener Schlüssel je Vorgang
• den Bestellzeitpunkt mit Zeitzone und das Zeitfenster, dem der Vorgang zugeordnet wird
• eine Beschreibung des Wegs: Auslöser (Ereignis oder Zeitplan), Stationen dazwischen (Warteschlange, Vermittler) und Zielsystem
• ein Zielwert dafür, wie lange ein Vorgang unübertragen liegen darf
• eine Person, die den Fall nach dem Nachziehen prüft und die Kundschaft informiert

Schritt für Schritt: Eine hängende Bestellung eingrenzen

Schritt 1: Den Umfang feststellen

Vergleichen Sie die Bestellzahl je Stunde im Shopsystem mit der im Zielsystem, nur für den betroffenen Weg. Das Ergebnis ist entweder ein einzelner Vorgang oder ein Zeitfenster, in dem mehrere fehlen. Liegt ein Zeitfenster vor, sitzt die Ursache im Weg zwischen den Systemen; betrifft es einen einzelnen Vorgang, entscheidet der Vergleich seiner Daten. Diese Zuordnung ist eine redaktionelle Einordnung, keine Messung. Ergebnis: ein Vorfall mit Zeitraum und betroffenem Weg in Ihrer Hand.

Schritt 2: Dieselbe Kennung auf beiden Seiten suchen

Suchen Sie nach der Kennung, nicht nach Name, Betrag oder Datum. Drei Ergebnisse sind möglich: Die Kennung fehlt im Zielsystem, sie kommt genau einmal vor oder sie kommt mehrfach vor. Zählen Sie zusätzlich Datensätze und Betragssumme beider Seiten: Ein fehlender und ein doppelter Vorgang über denselben Betrag lassen beide unverändert, deshalb entscheidet der Vergleich der Kennungen. Ergebnis: eine der drei Feststellungen, schriftlich notiert.

Schritt 3: Das Protokoll der Übergabe lesen

Prüfen Sie zuerst, ob das Protokoll für den Zeitraum vollständig ist. Ordnen Sie dem Vorgang dann jeden Versuch zu. Auswertbar ist das nur, wenn jeder Eintrag dieselben Felder trägt: Zeitstempel mit Zonenangabe im Format nach RFC 3339 Abschnitt 5.6, Kennung, Richtung, Antwortcode, Versuchszähler und Status. Der Antwortcode führt zur nächsten Prüfung. Führt das Protokoll keinen Eintrag zu dem Vorgang, ist für ihn entweder kein Lauf gestartet, oder die Protokollierung hat ihn nicht festgehalten: weil sie abgeschaltet war, weil Einträge verworfen oder überschrieben wurden oder weil eine Datenquelle ausgefallen ist. Für Felder, Abgleich und Alarm aller Übergaben: Fehler bei der Datensynchronisation.

Schritt 4: Den Antwortcode einordnen

Die Tabelle ordnet die Codes des HTTP-Standards der nächsten Prüfung zu.

Antwort	Bedeutung nach RFC 9110	Nächste Prüfung
409 Conflict	Konflikt mit dem vorhandenen Stand der Zielressource (Abschnitt 15.5.10)	Vorgang im Zielsystem suchen: Liegt die Kennung schon vor?
429 Too Many Requests	zu viele Anfragen in einem Zeitraum (RFC 6585, Abschnitt 4)	Wartezeit aus dem Feld Retry-After einhalten
500 Internal Server Error	unerwarteter Fehler des Zielservers (Abschnitt 15.6.1)	Fehlerprotokoll des Zielsystems anfordern
502 Bad Gateway	Vermittler hat eine ungültige Antwort erhalten (Abschnitt 15.6.3)	Station zwischen den Systemen prüfen
503 Service Unavailable	vorübergehende Überlast oder geplante Wartung; die Antwort kann Retry-After nennen (Abschnitte 10.2.3 und 15.6.4)	Wartezeit abwarten und Versuche zählen
504 Gateway Timeout	Vermittler hat keine rechtzeitige Antwort erhalten (Abschnitt 15.6.5)	Zeitüberschreitung und Zielsystem prüfen
keine Antwort	Eine nicht-idempotente Anfrage soll der Absender nicht automatisch wiederholen, solange er nicht weiß, dass ihre Semantik doch idempotent ist oder dass die erste Anfrage nie angekommen ist (Abschnitt 9.2.2)	Erst den Stand im Zielsystem prüfen, dann wiederholen

Der Code ersetzt nicht den Blick in beide Systeme. Ein 504 sagt, dass die Antwort ausblieb; ob die Anfrage verarbeitet wurde, zeigt das Zielsystem.

Schritt 5: Wiederholung und Doppelprüfung

Eine Anfrage ist nach RFC 9110 Abschnitt 9.2.2 idempotent, wenn die beabsichtigte Wirkung mehrerer gleicher Anfragen dieselbe ist wie die einer einzelnen. PUT, DELETE und die sicheren Methoden wie GET und HEAD sind idempotent, POST ist es nicht: Trifft dieselbe Anlage zweimal ein, kann der Auftrag doppelt entstehen. Nicht-idempotente Anfragen soll ein Client nicht automatisch wiederholen, solange er nicht weiß, dass ihre Semantik doch idempotent ist oder dass die erste Anfrage nie angekommen ist (ebenfalls Abschnitt 9.2.2). Redaktionelle Empfehlung: Geben Sie jedem Vorgang einen Schlüssel mit, den das Zielsystem speichert und gegen den es jede weitere Zustellung prüft, und wiederholen Sie erst nach dieser Prüfung.

Schritt 6: Nachziehen und die Ursache abstellen

Tragen Sie den Vorgang im Zielsystem nach, wenn keine Wiederholung mehr läuft, und gleichen Sie Bestand, Rechnung und Zahlung ab, damit er nur einmal geführt wird. Informieren Sie die Kundschaft, wenn sich der Versand verzögert; die Bestellbestätigung aus dem Shop beweist nicht, dass die Warenwirtschaft den Auftrag erhalten hat: Bestellstatus und Kundenmitteilungen. Damit derselbe Fehler früher auffällt: Abgleich und Alarm nach Shop-Ausfall: Monitoring und Notfallplan.

Fehlerbaum: vom Symptom zur Ursache

Die Tabelle führt vom Symptom über die erste Prüfung zur möglichen Ursache und Behebung. Sie verkürzt die Schritte oben, wenn Sie vor einem konkreten Fall stehen.

Symptom	Erste Prüfung	Mögliche Ursache	Behebung
Bestellung fehlt im Zielsystem, das Protokoll hat keinen Eintrag	Vollständigkeit des Protokolls prüfen, dann nach der Kennung durchsuchen	Kein Lauf ausgelöst (fehlender Statuswechsel, Filter, Warteschlange ohne Abnehmer) oder die Protokollierung hat den Vorgang nicht festgehalten (abgeschaltet, verworfen, überschrieben, Datenquelle ausgefallen)	Auslöser und Filter prüfen, Rückstand in der Warteschlange abarbeiten, Protokollierung prüfen
Bestellung fehlt, das Protokoll zeigt 502 oder 504	Weg zwischen Shopsystem und Zielsystem prüfen	Der Vermittler erreicht das Ziel nicht oder nicht rechtzeitig	Verbindung und Zeitüberschreitung prüfen, Versuch nach Wegfall der Störung wiederholen
Bestellung fehlt, das Protokoll zeigt 429 oder 503	Feld Retry-After im letzten Versuch	Überlast oder Wartung; der Versuch wurde verworfen, statt die genannte Wartezeit abzuwarten	Wartezeit einhalten, Wiederholungen mit Zähler und Obergrenze
Bestellung fehlt im Suchfenster, das Zielsystem hat sie aber verarbeitet	Zeitzone und Suchfenster vergleichen	Die Systeme protokollieren in verschiedenen Zeitzonen; der Vorgang liegt außerhalb des Suchfensters	Zeitstempel mit Zonenangabe vergleichen, Zeitdienst prüfen
Bestellung liegt doppelt im Zielsystem	Kennung und Versuchszähler vergleichen	Nach einem Abbruch erneut gesendet, das Ziel prüft keine Kennung	Schlüssel je Vorgang einführen, zweiten Datensatz stornieren
Bestellung liegt im Zielsystem, aber ohne Positionen oder mit falscher Lieferadresse	Nutzlast im Protokoll mit der Anzeige im Shop vergleichen	Die Übertragung sendet nur einen Teil der Felder, oder ein erforderliches Feld hat sich nach einer Änderung geändert	Feldumfang dokumentieren; Ablehnung wegen einer Schemaänderung sichtbar machen
Bestellung mit vielen Positionen fehlt, kleine kommen an	Größe der Nutzlast im Protokoll prüfen	Die Nutzlast überschreitet eine Größengrenze, oder die Verbindung bricht vor dem Ende ab	Größengrenze beim Ziel erfragen, Verbindung prüfen, Prüfsumme nach RFC 9530 Abschnitt 2 einsetzen
Die Bestellung fehlt auch im Shopsystem	Shopprotokoll und Zahlungsstatus prüfen	Die Bestellung ist im Shop nie entstanden: abgebrochener Checkout, abgelehnte Zahlung oder doppelter Klick	Liegt nicht an der Übergabe; den Vorgang im Checkout prüfen
Seit einer Änderung am Zielsystem fehlen alle neuen Bestellungen	Antworten und Feldliste prüfen	Das Ziel lehnt die Nutzlast wegen eines fehlenden oder geänderten Feldes ab	Feldliste abgleichen, Prüfung vor der Freigabe einbauen
Bestellungen eines Kanals fehlen, die übrigen kommen an	Auslöser und Konto des betroffenen Kanals prüfen	Für diesen Kanal fehlt der Auslöser, ein Filter greift, oder das Konto ist gesperrt	Kanalkonfiguration prüfen, Zugangsdaten erneuern

Eine Prüfsumme hilft nur, wenn beide Seiten sie auswerten; nach RFC 9530 Abschnitt 2 darf der Empfänger sie ignorieren.

Drei Grenzen der Protokollierung gehören zur Ursachensuche dazu. Ist die Protokollierung für ein System nicht eingeschaltet, gehen die Informationen verloren; reicht der Speicher nicht, können Protokolleinträge verworfen oder überschrieben werden; fällt eine Datenquelle aus, entsteht ein falsches Bild der Lage (BSI IT-Grundschutz-Kompendium, Baustein OPS.1.1.5 Protokollierung, Edition 2023, Abschnitte 2.1, 2.2 und 2.7). Derselbe Baustein verlangt synchrone Systemzeiten und ein einheitliches Datums- und Zeitformat (Anforderung A4); NIST SP 800-92 nennt in Fußnote 24 einen Zeitdienst wie NTP (RFC 5905). Die Bausteine binden nur, wenn Gesetz oder Vertrag auf sie verweisen; prüfen Sie die Protokollierung stichprobenartig nach Ihrer Protokollierungsrichtlinie (Anforderung A3).

So prüfen Sie das Ergebnis

• Zu jedem Fall können Sie sagen, ob er im Zielsystem fehlt, einmal oder mehrfach vorliegt.
• Für jeden fehlenden Vorgang gibt es einen Protokolleintrag mit Antwortcode oder einen belegten Grund, warum keiner existiert.
• Jede Wiederholung trägt dieselbe Kennung wie der erste Versuch, und das Zielsystem prüft diese Kennung.
• Nachgezogene Vorgänge sind in Bestand, Rechnung und Zahlung nur einmal vorhanden.
• Die Zeitstempel beider Seiten tragen eine Zonenangabe und liegen innerhalb der Abweichung, die Sie zulassen.
• Kein Versuch wurde wiederholt, ohne die im Feld Retry-After genannte Wartezeit einzuhalten.
• Die Kundschaft des betroffenen Vorgangs hat eine Mitteilung mit Grund und neuem Termin erhalten.

Wann Sie Hilfe holen sollten

Holen Sie Unterstützung, wenn die Ursache in einem System liegt, das Sie nicht selbst betreiben, oder wenn zwischen Shop und Warenwirtschaft mehrere Stationen vermitteln. Für die Art der Anbindung führt Schnittstellen im Shop-Umfeld weiter, für die Systemauswahl Warenwirtschaft für Onlinehändler und für den Fall, dass der Weg ganz ausfällt, Shop-Ausfall: Monitoring und Notfallplan. Welche Fristen für die Aufbewahrung von Bestell- und Protokolldaten gelten, hängt von Ihrer Buchführung ab und ist nicht Teil dieses Artikels; klären Sie das mit Ihrer Steuerberatung.