Fehlerbehandlung in Schnittstellen: Retry, DLQ und Monitoring

Der erste Schritt zu einer effektiven Fehlerbehandlung ist die Klassifizierung der Fehler. Nicht jeder Fehler erfordert dieselbe Reaktion. Temporäre Fehler (transient errors) sind vorübergehend und lösen sich von selbst: Netzwerk-Timeouts, überlastete APIs (HTTP 429, 503), kurzzeitige Datenbankausfälle. Diese Fehler können durch automatische Wiederholung (Retry) behoben werden.

Permanente Fehler (permanent errors) hingegen werden durch Wiederholung nicht besser: ungültige Daten (fehlendes Pflichtfeld, falscher Datentyp), fehlende Referenzen (nicht existierender Kunde im ERP), Geschäftslogik-Verletzungen (negative Preise, unmögliche Mengen). Diese Fehler erfordern menschliche Korrektur und müssen in einer Dead Letter Queue gesichert werden.

Die Middleware muss automatisch zwischen diesen Fehlerklassen unterscheiden. HTTP-Statuscodes bieten eine erste Orientierung: 4xx-Fehler (Client-Fehler) deuten auf permanente Probleme hin, 5xx-Fehler (Server-Fehler) auf temporäre. Laut einer Analyse von AWS sind 68 Prozent (Projekterfahrung) aller API-Fehler temporärer Natur und können durch automatische Wiederholung behoben werden (AWS Architecture Center, 2025).

Die Retry-Logik ist die erste Verteidigungslinie gegen temporäre Fehler. Wenn ein API-Aufruf fehlschlägt, wird er nach einer Wartezeit automatisch wiederholt. Die Kunst liegt in der richtigen Konfiguration: Zu aggressive Retries (zu häufig, zu schnell) können ein bereits überlastetes System weiter belasten. Zu konservative Retries (zu selten, zu langsam) verzögern die Verarbeitung unnötig.

Die bewährteste Strategie ist Exponential Backoff mit Jitter: Die Wartezeit zwischen den Versuchen verdoppelt sich mit jedem Fehlversuch (1 Sekunde, 4 Sekunden, 16 Sekunden, 64 Sekunden, 256 Sekunden), und ein zufälliger Versatz (Jitter) verhindert, dass viele gleichzeitig fehlgeschlagene Aufrufe zum exakt selben Zeitpunkt wiederholt werden. Nach einer konfigurierbaren Maximalanzahl von Versuchen (typischerweise fünf) wird die Nachricht in die Dead Letter Queue verschoben.

Die Middleware implementiert die Retry-Logik auf Basis der Fehlerklassifikation: HTTP 429 (Rate Limit) wird mit der im Response-Header angegebenen Wartezeit wiederholt. HTTP 500/502/503 wird mit Exponential Backoff wiederholt. HTTP 400/422 (Validierungsfehler) wird direkt in die Dead Letter Queue verschoben, da ein Retry denselben Fehler produzieren würde. Diese differenzierte Behandlung erreicht eine Verarbeitungsquote von 99,9 Prozent (Projekterfahrung) bei temporären Fehlern.

Die Dead Letter Queue (DLQ) ist das Sicherheitsnetz der Fehlerbehandlung. Nachrichten, die nach allen Retry-Versuchen nicht verarbeitet werden konnten oder von der Validierung als permanent fehlerhaft erkannt wurden, werden in der DLQ gesichert. Keine Nachricht geht verloren -- jede fehlgeschlagene Bestellung, jeder ungültige Artikelstammdatensatz und jeder fehlerhafte Preisimport wird vollständig mit Kontext (Zeitstempel, Fehlergrund, Quellsystem, Nachrichteninhalt) gespeichert.

Die DLQ erfüllt mehrere Funktionen: Sie verhindert Datenverlust (selbst bei schwerwiegenden Fehlern geht keine Information verloren), sie ermöglicht die nachträgliche Verarbeitung (korrigierte Daten können aus der DLQ erneut in die Verarbeitungspipeline eingespeist werden), und sie liefert wertvolle Diagnosedaten (wiederkehrende Fehlermuster in der DLQ weisen auf systematische Probleme hin).

In der Middleware wird die DLQ über ein Dashboard zugänglich gemacht, das dem Administrator eine Übersicht aller nicht verarbeiteten Nachrichten bietet. Für jede Nachricht werden der Fehlergrund, die Anzahl der Retry-Versuche und der vollständige Nachrichteninhalt angezeigt. Der Administrator kann Nachrichten korrigieren und erneut zur Verarbeitung freigeben oder als gelöst markieren.

Das Circuit-Breaker-Pattern schützt die Integration vor Kaskadenausfällen. Wenn ein Zielsystem -- zum Beispiel die SAP-API -- wiederholt Fehler zurückgibt, könnte eine naive Retry-Strategie das Problem verschlimmern: Hunderte parallele Retry-Versuche belasten das ohnehin gestörte System zusätzlich und verzögern die Erholung.

Der Circuit Breaker funktioniert wie ein Schutzschalter mit drei Zuständen: Closed (normal) -- Nachrichten werden normal verarbeitet, die Fehlerrate wird überwacht. Open (gestört) -- wenn die Fehlerrate einen Schwellenwert überschreitet (zum Beispiel 50 Prozent (Projekterfahrung) der letzten 20 Aufrufe), wird der Circuit Breaker ausgelöst. Alle weiteren Aufrufe an das gestörte System werden sofort abgelehnt und in die Queue zurückgestellt, ohne das System zu belasten. Half-Open (Testphase) -- nach einer konfigurierbaren Wartezeit (zum Beispiel 60 Sekunden) lässt der Circuit Breaker einen einzelnen Testaufruf durch. Wenn dieser erfolgreich ist, wechselt der Zustand zurück zu Closed.

Laut einer Studie von Netflix, das den Circuit Breaker als Architekturmuster populär gemacht hat, reduziert das Pattern die Erholungszeit nach Systemstörungen um durchschnittlich 70 Prozent (Netflix Technology Blog, 2024), weil das gestörte System nicht durch zusätzliche Anfragen weiter belastet wird.

Wenn eine Nachricht automatisch wiederholt wird (Retry), besteht das Risiko einer doppelten Verarbeitung: Der erste Versuch war möglicherweise erfolgreich, aber die Bestätigung ging verloren. Der Retry-Versuch verarbeitet die Nachricht ein zweites Mal -- und im schlimmsten Fall wird eine Bestellung doppelt im ERP angelegt.

Die Lösung ist Idempotenz: Jede Nachricht erhält eine eindeutige ID (Idempotenz-Schlüssel). Vor der Verarbeitung prüft die Middleware, ob eine Nachricht mit dieser ID bereits erfolgreich verarbeitet wurde. Wenn ja, wird die Nachricht als 'bereits verarbeitet' markiert und ignoriert. Wenn nein, wird sie normal verarbeitet und die ID als verarbeitet gespeichert.

In der Praxis wird der Idempotenz-Schlüssel aus geschäftsrelevanten Daten abgeleitet: Bei Bestellungen die Shopware-Bestellnummer, bei Artikelstammdaten die Kombination aus Artikelnummer und Änderungszeitstempel, bei Preisen die Kombination aus Artikelnummer, Preisliste und Preiswert. Dieser Ansatz stellt sicher, dass echte Aktualisierungen verarbeitet werden, während identische Nachrichten erkannt und dedupliziert werden.

Wenn eine Bestellung ihren Weg vom Shop über die Middleware zum ERP und weiter zu DATEV nimmt, durchläuft sie mehrere Verarbeitungsschritte und Systemgrenzen. Ohne eine durchgängige Nachverfolgung ist es bei Fehlern nahezu unmöglich festzustellen, an welcher Stelle der Verarbeitungskette das Problem aufgetreten ist.

Die Middleware generiert für jeden eingehenden Vorgang eine eindeutige Korrelations-ID, die an alle nachfolgenden Verarbeitungsschritte und API-Aufrufe weitergegeben wird. Im Fehlerfall kann der Administrator anhand dieser ID den gesamten Verarbeitungsweg im Audit-Log nachvollziehen: Wann wurde die Bestellung empfangen? Wurde sie erfolgreich validiert? An welches System wurde sie weitergeleitet? Wo ist der Fehler aufgetreten?

Reaktive Fehlerbehandlung (auf Fehler reagieren, wenn sie auftreten) ist notwendig, aber nicht ausreichend. Proaktives Monitoring erkennt Probleme anhand von Trends und Anomalien, bevor sie sich auf Geschäftsprozesse auswirken. Die Middleware überwacht kontinuierlich mehrere Kennzahlen.

Das Monitoring wird über ein zentrales Dashboard visualisiert, das Echtzeit-Kennzahlen und historische Trends zeigt. Automatische Alerts werden über konfigurierbare Schwellenwerte ausgelöst und per E-Mail oder Messaging an das Operations-Team gesendet. Unternehmen mit proaktivem Monitoring investieren erfahrungsgemäß 60 Prozent (Projekterfahrung) weniger in die Behebung von Integrationsproblemen als Unternehmen mit rein reaktivem Ansatz (Projekterfahrung).

Ein vollständiges Audit-Log dokumentiert jeden Verarbeitungsschritt in der Middleware: Eingang der Nachricht (Zeitstempel, Quellsystem, Nachrichtentyp), Validierungsergebnis (bestanden/abgelehnt, Fehlerdetails), Transformationsergebnis (Quell- und Zielformat), Übertragung an Zielsystem (HTTP-Status, Antwortzeit, Response-Body) und Retry-Versuche (Zeitpunkt, Fehlergrund, Versuchsnummer).

Das Audit-Log dient mehreren Zwecken: Fehleranalyse (was ist wann und warum schiefgegangen?), Compliance-Nachweis (lückenlose Dokumentation aller Datenbewegungen für die GoBD), Performance-Analyse (wo entstehen Engpässe?) und Streitbeilegung (bei Unstimmigkeiten zwischen Systemen können alle Schritte nachvollzogen werden). Die Aufbewahrungsdauer des Logs wird in Abstimmung mit den regulatorischen Anforderungen konfiguriert (typischerweise 90 Tage für operative Logs, zehn Jahre für buchungsrelevante Vorgänge).

Professionelle Fehlerbehandlung kann auch in bestehenden Integrationen nachgerüstet werden. Wenn eine Shop-Integration bereits produktiv läuft, aber über keine oder unzureichende Fehlerbehandlung verfügt, kann die Middleware schrittweise um Retry-Logik, Dead Letter Queues und Monitoring erweitert werden -- ohne den laufenden Betrieb zu unterbrechen.

Ein Monitoring-System ist nur so gut wie seine Benachrichtigungslogik. Zu viele Alerts führen zur Alert-Müdigkeit -- das Team ignoriert Meldungen, weil es zu viele falsch-positive Alarme gibt. Zu wenige Alerts lassen kritische Probleme unentdeckt. Die Middleware implementiert eine mehrstufige Eskalationslogik, die den Schweregrad des Problems mit der Dringlichkeit der Benachrichtigung verknüpft.

Informelle Hinweise (zum Beispiel eine leicht erhöhte Fehlerrate) werden im Dashboard angezeigt, aber nicht aktiv gemeldet. Warnungen (zum Beispiel Queue-Tiefe über dem Normalwert) erzeugen eine E-Mail an das Operations-Team. Kritische Alerts (zum Beispiel offener Circuit Breaker, DLQ wächst schnell) lösen sofortige Benachrichtigungen über mehrere Kanäle aus. Laut einer Branchenstudie reduziert eine gut konfigurierte Eskalationslogik die mittlere Reaktionszeit auf Integrationsprobleme um 65 Prozent (State of Digital Operations, 2024).

Professionelle Fehlerbehandlung bedeutet nicht nur, Fehler zu erkennen und zu beheben, sondern auch den Geschäftsbetrieb trotz einer Systemstörung aufrechtzuerhalten. Das Konzept der Graceful Degradation beschreibt die Fähigkeit eines Systems, bei Teilausfällen weiterhin eingeschränkt zu funktionieren, statt komplett auszufallen.

Konkret für die Shop-Integration: Wenn das ERP-System nicht erreichbar ist, können Kunden trotzdem weiterhin im Shop bestellen. Die Bestellungen werden in der Queue gepuffert und nach Wiederherstellung automatisch verarbeitet. Preise werden aus dem Cache bedient (möglicherweise mit leichter Verzögerung bei Aktualisierungen). Bestandsanzeigen basieren auf dem letzten bekannten Stand. Der Shop bleibt vollständig nutzbar, während die Middleware im Hintergrund auf die Wiederherstellung des ERP wartet.

Ein weiteres Beispiel für Graceful Degradation ist die Handhabung von Teilfehlern bei Sammeloperationen. Wenn eine Bestandsaktualisierung für 100 Artikel durchgeführt wird und drei davon fehlschlagen, werden die 97 erfolgreichen Updates normal verarbeitet, während die drei fehlgeschlagenen in die Retry-Queue gestellt werden. Laut einer Analyse von AWS erreichen Systeme mit implementierter Graceful Degradation eine 99,95 Prozent Verfügbarkeit aus Kundensicht, selbst wenn Backend-Systeme nur 99,5 Prozent Verfügbarkeit bieten (AWS Architecture Center, 2025).

Die beste Fehlerbehandlung nützt nichts, wenn sie nicht getestet wird. Fehlersimulationen (auch bekannt als Chaos Engineering) überprüfen systematisch, ob die Integration unter Fehlerbedingungen korrekt funktioniert. Typische Testszenarien umfassen: Netzwerkunterbrechung zwischen Middleware und ERP (wird die Queue korrekt befüllt?), API-Timeout bei hoher Last (greift die Retry-Logik?), ungültige Daten vom Quellsystem (wird die Validierung ausgelöst?) und vollständiger Ausfall des Zielsystems (springt der Circuit Breaker an?).

Die Middleware bietet einen Testmodus, in dem Fehler gezielt injiziert werden können, ohne den Produktivbetrieb zu beeinträchtigen. Regelmäßige Fehlersimulationen -- mindestens einmal pro Quartal -- stellen sicher, dass die Fehlerbehandlung auch bei sich ändernden Systemlandschaften zuverlässig funktioniert. Laut einer Studie von Gremlin reduzieren Unternehmen, die regelmäßig Fehlersimulationen durchführen, ihre ungeplanten Ausfallzeiten um 45 Prozent (Gremlin, 2024).