Ein Workflow legt einen Datensatz in einem Remote-System an, erreicht dann jedoch beim Warten auf die Antwort die Zeitüberschreitung. Die Ausführung wird als fehlgeschlagen markiert. Ein Bediener klickt auf „Wiederholen“, woraufhin das Remote-System erneut dieselbe Anlegeanforderung erhält.
Nichts in dieser Abfolge erfordert einen ungewöhnlichen Ausfall. Es handelt sich um eine normale Folge der Ausführung von Aufgaben über ein Netzwerk hinweg. Wenn ich n8n-Automatisierungen entwerfe, betrachte ich das Wiedergabeverhalten als Teil der Geschäftslogik des Workflows.
Verleihen Sie dem Vorgang eine stabile Identität
Eine Ausführungs-ID gibt Auskunft darüber, welcher Versuch ausgeführt wurde. Sie identifiziert jedoch nicht unbedingt den jeweiligen Geschäftsvorgang. Wenn der Workflow erneut gestartet wird, versucht die neue Ausführung möglicherweise weiterhin, denselben Auftrag zu exportieren.
Ich bevorzuge einen Vorgangschlüssel, der sich aus dem Mandanten, dem Quelldatensatz, der Aktion und der entsprechenden Version zusammensetzt. So sollte beispielsweise der Export einer bestimmten Revision einer Bestellung bei wiederholten Versuchen denselben Schlüssel haben, während der Export einer späteren Revision einen anderen Schlüssel haben sollte.
Der Schlüssel muss in einem System gespeichert werden, das die Eindeutigkeit unter Parallelität gewährleisten kann. Wenn in zwei getrennten Schritten geprüft wird, ob ein Wert bereits vorhanden ist, und dieser anschließend eingefügt wird, entsteht eine Race-Bedingung, wenn zwei Worker gleichzeitig starten.
Nebenwirkungen eingrenzen
Reine Transformationen lassen sich in der Regel leicht wiederholen. Das Versenden einer Nachricht, das Erstellen einer Rechnung oder die Änderung des Lagerbestands erfordern eine sorgfältigere Abgrenzung.
Meine bevorzugte Vorgehensweise ist es, den beabsichtigten Vorgang zu protokollieren, ihn atomar zu beanspruchen, den externen Dienst – sofern unterstützt – mit einem Idempotenzschlüssel aufzurufen und die Referenz des Anbieters zu protokollieren. Ein Timeout führt zu einem ungewissen Vorgang, der abgeglichen werden muss; er sollte nicht automatisch als Nachweis für einen Fehler gewertet werden.
Wenn der Anbieter keine Idempotenz unterstützt, suche ich nach einer zuverlässigen Möglichkeit, die Abfrage über eine externe Referenz durchzuführen. Wenn keine der beiden Optionen zur Verfügung steht, benötigt der Workflow möglicherweise eine Überprüfungswarteschlange. Ein zweiter Blindversuch ist eine geschäftliche Entscheidung, insbesondere wenn die Aktion nicht ohne Weiteres rückgängig gemacht werden kann.
Trenne Fehler, bei denen ein erneuter Versuch möglich ist, von reparierbaren Daten
Ein vorübergehender Verbindungsfehler lässt sich möglicherweise später beheben. Eine fehlende Kunden-ID hingegen in der Regel nicht. Bei abgelaufenen Zugangsdaten ist möglicherweise ein Mitarbeiter erforderlich, während bei einer Ratenbegrenzung eine Verzögerung und eine geringere Anzahl gleichzeitiger Zugriffe erforderlich sein können.
| Misserfolg | Workflow-Antwort |
|---|---|
| Vorübergehender Dienstfehler | Begrenzte Wiederholungsversuche mit zunehmender Verzögerung und Jitter |
| Ungültiger Quelldatensatz | Quarantäne mit einem verständlichen Validierungsgrund |
| Ungewisser externer Schreibvorgang | Abgleich anhand der Vorgangsreferenz durchführen |
| Fehlende Berechtigung | Beenden Sie den betroffenen Vorgang und fordern Sie eine Konfigurationswiederherstellung an |
Für die Wiederholungsrichtlinie muss außerdem ein Gesamtzeitbudget festgelegt werden. Eine Automatisierung, die tagelang Wiederholungsversuche durchführt, kann eine Aktion ausführen, nachdem sich ihr geschäftlicher Kontext bereits geändert hat. Ältere Aufgaben sollten mit einer Ablauffrist versehen sein oder einer erneuten Berechtigungsprüfung unterzogen werden.
Genügend Zustandssinformationen speichern, um die Ausführung fortzusetzen
Ich richte dauerhafte Kontrollpunkte an aussagekräftigen Geschäftsgrenzen ein. Wenn ein Export erfolgreich war, die Benachrichtigung jedoch fehlgeschlagen ist, sollte sich die Wiederherstellung auf die Benachrichtigung konzentrieren. Das erneute Ausführen des gesamten Workflows ab seinem Auslöser ist nur dann sinnvoll, wenn jede vorherige Aktion gefahrlos wiederholt werden kann.
Jeder Checkpoint sollte zwischen ausstehenden, laufenden, abgeschlossenen, fehlgeschlagenen und unklaren Aufgaben unterscheiden. Ein laufender Vorgang benötigt zudem eine Lease- oder Wiederherstellungsregel, damit ein abgestürzter Worker diesen nicht dauerhaft besitzt.
Die Protokolle sollten den Vorgangsschlüssel, die Versuchsnummer, die externe Referenz und die Workflow-Version enthalten. Ich vermeide es, in jeder Fehlermeldung vollständige Kundendaten anzugeben, wenn eine kontrollierte Referenz die Untersuchung unterstützen kann.
Teste das ungünstige Timing
Bevor ich mich auf eine Automatisierung verlasse, simuliere ich einen Fehler unmittelbar vor und unmittelbar nach ihrer wichtigsten externen Aktion. Außerdem führe ich dieselbe Eingabe zweimal aus und starte zwei Versuche gleichzeitig.
Diese Überprüfungen zeigen mehr als nur eine weitere erfolgreiche Demonstration. Ein sinnvoller Arbeitsablauf kann verdeutlichen, was bereits erledigt wurde, was noch ungewiss ist und welche Maßnahme ein Bediener sicher wiederholen kann.
Aktualisiert am 25. September 2026.