Fachbeitrag · Wirtschaftsinformatik ·
Fehlerwarteschlangen: Warum eine problematische Nachricht nicht endlos erneut verarbeitet werden sollte
Eine Schnittstelle reagiert vorübergehend nicht. Eine erneute Verarbeitung kann in diesem Fall sinnvoll sein. Anders ist es bei einer Nachricht, deren Inhalt für den Empfänger dauerhaft unverständlich bleibt. Wird derselbe Fehler immer wieder ausgeführt, entstehen zusätzliche Last, unübersichtliche Protokolle und unter Umständen blockierte Folgeaufträge. Eine eigene Fehlerwarteschlange trennt solche Fälle vom normalen Arbeitsfluss und schafft einen kontrollierten Weg für Untersuchung, Korrektur und gegebenenfalls erneute Verarbeitung.
Vorübergehende und dauerhafte Fehler trennen
Ein Verbindungsabbruch oder ein kurzfristig nicht verfügbarer Dienst kann nach einer Wartezeit verschwinden. Ein fehlendes Pflichtfeld oder ein unbekanntes Datenformat ändert sich dagegen durch bloßes Wiederholen nicht. Die Unterscheidung ist im Einzelfall nicht immer eindeutig. Deshalb braucht der Verarbeitungsablauf begrenzte Versuche, nachvollziehbare Fehlergründe und einen Übergang in einen gesonderten Zustand. Eine Nachricht gilt dort nicht als fachlich erledigt. Sie ist zur Untersuchung zurückgestellt und bleibt einem verantwortlichen Prozess zugeordnet.
Ein Wiederholungsbudget festlegen
Ein vereinfachtes Beispiel betrifft einen automatischen Stammdatenimport. Ein Datensatz enthält eine unbekannte Einheit. Nach wenigen unveränderten Versuchen wird er aus dem normalen Verarbeitungspfad genommen. Weitere gültige Datensätze können nach den vereinbarten Abhängigkeitsregeln weiterlaufen. Das Wiederholungsbudget orientiert sich am erwarteten Fehlertyp und an der Belastung der Zielsysteme. Ein schneller Dauerlauf ist keine Zuverlässigkeitsstrategie. Auch ein großer Abstand zwischen Versuchen hilft nicht, wenn eine dauerhaft fehlerhafte Nutzlast unverändert zurückgesendet wird.
Rückführung als eigenen Schritt behandeln
Nach der Untersuchung wird entschieden, ob die ursprüngliche Nachricht erneut verarbeitet, eine korrigierte Fassung erzeugt oder der Vorgang fachlich abgeschlossen wird. Die Beziehung zwischen Original und Korrektur bleibt nachvollziehbar. Eine stabile Vorgangskennung schützt davor, dass bereits eingetretene Teilwirkungen bei der Rückführung unbemerkt doppelt entstehen. Dazu muss bekannt sein, an welcher Stelle der erste Versuch tatsächlich scheiterte. Ein Fehler nach einer erfolgreichen Buchung ist anders zu behandeln als ein Fehler vor jeder Änderung.
Bestand und Alter überwachen
Eine Fehlerwarteschlange ist kein Archiv, in dem Fälle unbeachtet verschwinden dürfen. Neben ihrer Größe sind Alter, Fehlergruppen, betroffene Fachobjekte und Bearbeitungsverantwortung wichtige Betriebsinformationen. Sensible Inhalte werden nicht unnötig in Fehlermeldungen kopiert. Die Aufbewahrung folgt dem abgestimmten Verfahren, ohne aus technischen Beispielen pauschale rechtliche Fristen abzuleiten. Das Ziel bleibt ein überprüfbarer Umgang mit Ausnahmen: begrenzte automatische Wiederholung, klare Zuständigkeit und eine kontrollierte Entscheidung über jeden nicht regulär abgeschlossenen Vorgang.
Technical insight · Business information systems ·
Dead-letter handling: Why a problematic message should not be retried indefinitely
An interface is temporarily unavailable. Retrying may be useful in that situation. A message whose content remains permanently unintelligible to its recipient is different. Repeating the same failure creates extra load, noisy logs and potentially blocked follow-up work. A separate error queue removes such cases from normal processing and provides a controlled route for investigation, correction and possible reprocessing.
Distinguish temporary from persistent failure
A connection interruption or briefly unavailable service can recover after a delay. A missing required field or unknown data format will not repair itself through repetition. The distinction is not always immediately clear. Processing therefore needs bounded attempts, meaningful failure reasons and a transition to a separate state. A message in that state is not completed in business terms. It is awaiting investigation and remains assigned to an accountable process.
Define a retry budget
Consider an automated master-data import containing a record with an unknown unit. After a limited number of unchanged attempts, that record is removed from the regular path. Other valid records can proceed according to the agreed dependency rules. The retry budget should match the expected failure and the load imposed on destination systems. A rapid endless loop is not a reliability strategy. Longer intervals also cannot resolve a permanently invalid payload if it is repeatedly sent without any correction.
Treat re-entry as a separate operation
After investigation, decide whether to process the original message again, create a corrected version or close the business exception. The relationship between the original and its correction remains traceable. A stable business identifier helps prevent re-entry from silently duplicating partial effects that already occurred. This requires knowing where the first attempt actually failed. A failure after a successful update needs different treatment from one that happened before any change.
Monitor age as well as volume
An error queue is not an archive in which cases may disappear unnoticed. Its size, item age, failure groups, affected business objects and responsible owners are useful operational information. Sensitive contents should not be copied unnecessarily into error messages. Retention follows the agreed procedure without deriving universal legal periods from technical examples. The objective is a testable exception process: limited automatic repetition, clear ownership and a controlled decision about every transaction that did not finish through the normal route.