Ein roter Knoten erklärt noch keine Zuständigkeit
Eine abgebrochene Ausführung ist zunächst nur ein technisches Ereignis. Für den Betrieb muss klar sein, welcher Vorgang betroffen ist, ob bereits etwas geändert wurde und wer die Bearbeitung übernimmt. Diese Angaben gehören in die Fehlermeldung.
n8n unterstützt einen zugeordneten Fehlerworkflow, der mit einem Error Trigger beginnt. Darüber lassen sich beispielsweise Benachrichtigungen auslösen. Offizielle Anleitung. Der Inhalt der Meldung und die anschließende Arbeit müssen zum Unternehmen passen.
Drei unterschiedliche Ausgänge
Ein vorübergehend nicht erreichbarer Dienst kann einen begrenzten neuen Versuch rechtfertigen. Eine fehlende Kundennummer braucht dagegen eine inhaltliche Klärung. Und ein unbekannter Ausgang nach einer Auftragserstellung verlangt zuerst den Blick ins Zielsystem.
Diese Fälle sollten unterschiedliche Status erhalten. Wenn alle nur „Fehler“ heißen, muss der Bearbeiter jeden Vorgang neu untersuchen. Geeignete Bezeichnungen wären beispielsweise „erneuter Versuch geplant“, „Angabe fehlt“ und „Zielsystem prüfen“.
Wiederholungen begrenzen
Legen Sie Anzahl und Abstand der Versuche fest. Wiederholungen ohne Obergrenze können Kosten erzeugen und einen gestörten Dienst zusätzlich belasten. Nach dem letzten Versuch muss der Vorgang sichtbar offen bleiben und einer Person zugeordnet werden.
Vor jeder Aktion mit Außenwirkung ist zu klären, ob eine Wiederholung zulässig ist. Eine Datei erneut zu lesen ist etwas anderes als dieselbe Nachricht noch einmal zu versenden. Der Zusammenhang wird im Artikel über doppelte Vorgänge ausführlicher erklärt.
Bei größeren Importen hilft es, API-Limits und Stapelgrößen gemeinsam zu planen. So lässt sich unterscheiden, ob ein einzelner Datensatz fehlerhaft ist oder der Dienst vorübergehend keine weiteren Anfragen annimmt.
Eine brauchbare Fehlermeldung
Ein fiktives Beispiel: „Vorgang V-1042: Übertragung ins Auftragsprogramm nicht bestätigt. Dokument wurde gelesen, Auftragsergebnis ist unklar. Bitte anhand der Vorgangskennung im Zielsystem prüfen. Kein automatischer Neuversuch.“ Diese Meldung ermöglicht eine konkrete Handlung.
Der vollständige Inhalt des Kundendokuments muss dafür nicht in einen allgemeinen Teamkanal kopiert werden. Ein Link auf einen zugriffsgeschützten Vorgang ist häufig ausreichend. Technische Details können getrennt für die zuständige Betreuung verfügbar sein.
Fehler absichtlich auslösen
Testen Sie einen ungültigen Eingang, einen nicht erreichbaren Dienst und einen Abbruch nach einem bereits erledigten Schritt. Prüfen Sie dabei auch, ob die zuständige Person die Meldung tatsächlich erhält. Ein eingerichteter Alarm hilft wenig, wenn er in einem unbetreuten Postfach landet.
Dokumentieren Sie schließlich den manuellen Ersatzweg. Dazu gehören der Speicherort offener Vorgänge und die Regel, wie nach einer Störung wieder übernommen wird. Sonst arbeitet das Team dieselben Fälle parallel noch einmal ab.
Quellen und weiterführende Grundlagen
Über den Autor
Julian Süllner hat Provehor gegründet und führt das Unternehmen als Geschäftsführer. Er verantwortet Produktentwicklung, Kundenprojekte und die Ratgeber auf dieser Website.