Fehlerbehandlung automatisierter Abläufe

Jeder fehlgeschlagene Schritt braucht einen sicheren nächsten Schritt: Daten korrigieren, den Versuch begrenzt wiederholen, das Zielergebnis prüfen oder den Fall übergeben. Maßgeblich ist der Zustand des Geschäftsvorgangs. Ein fehlgeschlagener Workflow-Lauf belegt nicht, dass eine zuvor gesendete Aktion wirkungslos blieb.

Fehler einordnen

HTTP-Statuscodes helfen bei der Einordnung, ersetzen aber weder den Antwortkörper noch die Dokumentation der konkreten API. 429 steht für zu viele Anfragen. Ein Timeout ohne Antwort lässt das Ergebnis einer gesendeten Änderung offen.

Fehlerursachen voneinander trennen

Fehler entstehen aus einer ungültigen Zustandsmaschinen-Definition, einem fehlgeschlagenen Arbeitsschritt oder einer vorübergehenden Störung wie einer Netzwerkunterbrechung. Diese Ursachen verlangen unterschiedliche Reaktionen: Eine Definitionsabweichung muss korrigiert werden, eine vorübergehende Störung kann einen erneuten Versuch erlauben.

Amazon Step Functions unterscheidet Fehler anhand von Namen, die groß- und kleinschreibungssensitiv sind. Eingebaute Fehlernamen beginnen mit States.; andere Namen können ebenfalls gemeldet werden, dürfen aber nicht mit diesem Präfix beginnen.

Fachlichen Zustand festhalten

Trennen Sie die technische Ausführung vom Ergebnis des Vorgangs. Für eine Materialanforderung können die Zustände noch nicht gesendet, in Bearbeitung, übernommen, zur Korrektur und Ergebnis unklar sinnvoll sein.

Das ist ein Entwurf für den eigenen Ablauf, keine zugesagte Plattformfunktion. „Übernommen“ braucht einen geeigneten Nachweis aus dem Zielsystem.

Halten Sie Vorgangskennung, betroffene Aktion und eine bekannte Zielkennung zusammen. Damit lässt sich ein offener Fall wiederfinden. Die Absicherung gegen eine zweite fachliche Wirkung bei wiederholten Ereignissen braucht eine eigene Regel.

Zeitüberschreitungen gezielt prüfen

Ein Zeitüberschreitungsereignis kann eine eigene Prüfroute auslösen, statt den Fall nur als allgemeinen Fehler zu behandeln. Für zeitüberschrittene Ausführungen von Standard-Workflows in Step Functions lassen sich TIMED_OUT-Ereignisse über einen EventBridge-Bus erkennen und eine Folgeaktion aufrufen. Das ist ein möglicher technischer Prüfweg, ersetzt aber nicht die Klärung des fachlichen Ergebnisses.

Die im RFC 6585 beschriebenen zusätzlichen HTTP-Statuscodes sind optional; Server müssen ihre Unterstützung nicht anbieten. Ein unbekannter Statuscode wird von Clients als allgemeiner Fehler derselben Klasse behandelt. Legen Sie daher die Zuständigkeit nicht allein anhand eines einzelnen Statuscodes fest.

Wiederholungen begrenzen

Legen Sie fest, welche Fehler einen neuen Versuch erlauben, wie lange gewartet wird und wann die Versuche enden. Gestaffelte Wartezeiten können gleichzeitige Folgeanfragen verteilen.

Bei einer Aktion mit Außenwirkung reicht die Fehlerklasse allein nicht. Ist nach einem Timeout unklar, ob ein Datensatz angelegt wurde, prüfen Sie zuerst das Zielergebnis. Ohne verlässliche Zuordnung oder geeigneten Wiederholungsschutz bleibt der Fall zur Prüfung offen.

Rangfolge der Fehlerbehandlungsmaßnahmen nach Risiko und Priorität

Fehler gezielt auffangen

Amazon Step Functions kann Fehler für bestimmte Zustände abfangen oder fehlgeschlagene Zustände erneut ausführen. Auffänger sind für Task-, Parallel- und Map-Zustände verfügbar, nicht aber für Fehler der obersten Ausführungsebene. Planen Sie deshalb schon beim Entwurf, welche Fehler ein einzelner Schritt behandeln soll und welche den gesamten Lauf betreffen.

Für erwartbare Fehler auf oberster Ebene muss die aufrufende Anwendung die Behandlung übernehmen oder die Ausführung in einen übergeordneten Workflow einbetten, der untergeordnete Workflows aufruft.

Bei Amazon-Lambda-Aufrufen sollten Produktionsabläufe auch Ausnahmen des Dienstes und des SDK berücksichtigen. Step Functions nennt dafür Lambda.ServiceException und Lambda.SdkClientException als Ausnahmen, die der Produktionscode behandeln können muss. Ordnen Sie solche technischen Fehler einer ausdrücklich festgelegten Fehlerbehandlung zu, statt sie mit fachlich ungültigen Vorgangsdaten gleichzusetzen.

Offene Fälle zuweisen

Ein einzelner ungültiger Datensatz kann zur Korrektur in eine Prüfwarteschlange gehen, während andere gültige Fälle weiterlaufen. Scheitern viele Fälle an derselben Verbindung, muss zusätzlich die gemeinsame Störung bearbeitet werden.

Geben Sie eine Datenkorrektur an die fachlich zuständige Stelle und eine Verbindungsstörung an die technische Betreuung. Der Hinweis sollte den Fall und die nächste Handlung benennen. Als Endzustand kommen ein bestätigtes Ergebnis, eine begründete Verwerfung oder ein weiterhin sichtbar ungeklärter Fall infrage.

Prüfroute vorab festlegen

Prüfen Sie bei der Übergabe anhand der Vorgangskennung, ob der Zielvorgang existiert und zum erwarteten Geschäftsschritt passt. Halten Sie anschließend fest, ob das Ergebnis bestätigt, verworfen oder eine weitere Prüfung erforderlich ist.