- Einleitung
- Erste Schritte
- Prozessmodellierung mit BPMN
- Grundlagen der Prozessmodellierung
- Öffnen der Modellierungsarbeitsfläche
- Modellierung Ihres Prozesses
- Ausrichten und Verbinden von BPMN-Elementen
- Autopilot for Maestro (Vorschau)
- Prozess-Repository
- Prozessmodellierung mit Fallverwaltung
- Entwerfen eines persistenten Fallentitätsschemas
- Definieren von Fallschlüsseln (System vs. extern)
- Erstellen von Task-E/A- und Write-Back-Verträgen
- Austrittsregeln und Beendigung der frühen Phase
- Modellieren von primären und sekundären Phasen
- Auslösen eines Falls aus Data Fabric
- Implementieren von Personas und Berechtigungen auf Phasenebene
- Festlegen von SLAs und automatisierten Eskalationsregeln
- Konfigurieren einer Nacharbeitsschleife (Wiedereintritt)
- Verwalten von Live-Fallinstanzen: Anhalten, migrieren und wiederholen
- Maestro-Komponentenwörterbuch für die Fallverwaltung
- Prozessmodellierung mit Flow
- Prozessimplementierung
- Debugging
- Simulieren
- Veröffentlichen und Aktualisieren von agentischen Prozessen
- Häufige Implementierungsszenarien
- Extraktieren und Validieren von Dokumenten
- Prozessabläufe
- Prozessüberwachung
- Prozessoptimierung
- Referenzinformationen
Fehler pro Knoten werden in Flow behandelt, die Knotenfehler an einen separaten Pfad weiterleiten und Fehlerdetails über Variablen bereitstellen.
Dieser Leitfaden umfasst Folgendes:
Die Fehlerbehandlung in Flow ist ein Mechanismus pro Knoten, mit dem Sie steuern können, was passiert, wenn ein Knoten während der Ausführung fehlschlägt. Standardmäßig stoppt ein fehlgeschlagener Knoten den gesamten Prozess. Sie können dies überschreiben, indem Sie ein Fehler-Handle verbinden, um Fehler an einen separaten Pfad weiterzuleiten, in dem Sie den Fehler überprüfen und darauf reagieren.
Wie es funktioniert
Jeder Knoten, der die Fehlerbehandlung unterstützt, hat ein Fehler-Handle – einen Ausgabe-Connector unten rechts neben dem Knoten, der aktiviert wird, wenn der Knoten fehlschlägt. Nicht alle Knoten unterstützen die Fehlerbehandlung; nur diejenigen mit dem Flag supportsErrorHandling machen ein Fehler-Handle verfügbar.
Wenn ein Knoten mit verbundenem Fehler-Handle fehlschlägt, wird die Ausführung an den Fehlerpfad weitergeleitet, anstatt den Prozess anzuhalten. Die Fehlerdetails werden als Variable verfügbar, die Sie in nachgelagerten Knoten lesen können.
Wenn ein Knoten ohne verbundenes Fehler-Handle fehlschlägt, schlägt der gesamte Prozess sofort fehl. Der Fehler wird im Ausführungsbereich unter der Registerkarte Vorfälle angezeigt.
Wiederholungen von HTTP-Anforderungen
Der HTTP-Anforderungsknoten unterstützt konfigurierbare Wiederholungen. Wenn Wiederholungen konfiguriert sind, versucht der Knoten die angegebene Anzahl von Malen, bevor der Fehler-Handle ausgelöst wird. Wenn alle Wiederholungen fehlschlagen und ein Fehler-Handle verbunden ist, wird die Ausführung zum Fehlerpfad weitergeleitet. Wenn kein Fehler-Handle verbunden ist, schlägt der Prozess fehl.
Konfigurieren von Fehlerbehandlungen
Ein Fehler-Handle wird verlinkt, indem der Fehler-Handle-Connector des Knotens (unten rechts) mit einem anderen Knoten auf der Arbeitsfläche verbunden wird. Ein Knoten ohne Fehler-Handle-Connector unterstützt keine Fehlerbehandlung, sodass jeder Fehler den Prozess anhält.
Das Fehlerobjekt
Wenn ein Fehler-Handle verbunden ist und der Knoten fehlschlägt, sind die Fehlerdetails als $vars.<nodeName>.error verfügbar. Dieses Objekt verfügt über die folgenden Felder:
code
Ein maschinenlesbarer Fehlercode, der den Fehlertyp identifiziert.
Meldung
Eine visuell lesbare Beschreibung dessen, was schief gelaufen ist. Verwenden Sie diese Option für die Protokollierung oder Anzeige von Fehlerinformationen.
Detail
Eine detaillierte technische Beschreibung des Fehlers, einschließlich Stack-Traces oder dienstspezifische Informationen, falls verfügbar.
Kategorie
Die Fehlerkategorie, die verwandte Fehlertypen gruppiert.
Status
Der HTTP-Statuscode, der dem Fehler zugeordnet ist. Wird für HTTP-bezogene Fehler ausgefüllt (z. B. 404 oder 500).
Das Fehlerobjekt ist nur auf dem Fehlerpfad verfügbar. Der Zugriff auf $vars.<nodeName>.error auf dem Erfolgspfad gibt undefiniert zurück.
Beispiel aus der Praxis
In diesem Beispiel wird ein HTTP-Anforderungsknoten verwendet, um eine externe API mit einem Skriptknoten im Fehlerpfad aufzurufen, der den Fehler protokolliert.
Ein HTTP-Anforderungsknoten wird auf der Arbeitsfläche platziert und mit der Ziel-URL konfiguriert. Sein Fehler-Handle ist mit einem Skriptknoten verbunden. Der Skriptknoten liest das Fehlerobjekt wie folgt:
const error = $vars.httpRequest1.error;
return {
failed: true,
reason: error.message,
httpStatus: error.status,
detail: error.detail
};
const error = $vars.httpRequest1.error;
return {
failed: true,
reason: error.message,
httpStatus: error.status,
detail: error.detail
};
Wenn die HTTP-Anforderung erfolgreich ist, folgt die Ausführung dem Erfolgspfad und der Skriptknoten wird übersprungen. Wenn die Anforderung fehlschlägt (nach konfigurierten Wiederholungen), wird die Ausführung an den Skriptknoten weitergeleitet, der das vollständige Fehlerobjekt erhält.
Muster
Dies sind gängige Ansätze für die Behandlung, Protokollierung, Wiederholung und Eskalation von Fehlern. Sie alle bauen auf dem oben beschriebenen Fehlerhandle pro Knoten auf: Ein verbundenes Fehlerhandle leitet Fehler an einen separaten Pfad weiter, bei dem das Fehlerobjekt unter $vars.<node>.error verfügbar ist.
Protokollieren und fortfahren
Dieses Muster entspricht nicht-kritischen Vorgängen, bei denen der Workflow auch dann fortgesetzt werden soll, wenn ein Schritt fehlschlägt. Das Fehler-Handle des Knotens stellt eine Verbindung mit einem Skriptknoten her, der den Fehler protokolliert, und verbindet sich dann wieder mit dem Hauptpfad, sodass die Ausführung fortgesetzt wird.
// Script node on the error path
console.log('Non-critical step failed:', $vars.step1.error.message);
return null; // downstream nodes handle null gracefully
// Script node on the error path
console.log('Non-critical step failed:', $vars.step1.error.message);
return null; // downstream nodes handle null gracefully
Mit Limit wiederholen
Dieses Muster entspricht wahrscheinlich vorübergehenden Fehlern wie Netzwerk-Timeouts, Ratenlimits oder temporäre Ausfälle. Für den HTTP-Anforderungsknoten versucht die integrierte Anzahl der Wiederholungen die Anforderung erneut, bevor das Fehler-Handle ausgelöst wird, und nur der endgültige Fehler leitet an den Fehlerpfad weiter. Wiederholungseinstellungen gehören nur zu idempotenten Vorgängen.
Alarmieren und beenden
Dieses Muster entspricht nicht bearbeitbaren Fehlern, die menschliche Aufmerksamkeit erfordern. Auf dem Fehlerpfad wird eine Benachrichtigung gesendet (über eine HTTP-Anforderung oder einen Integrationsknoten), dann beendet ein Beendigungsknoten mit dem Status Failed und einer beschreibenden Meldung wie $vars.step1.error.message den Workflow.
Ausweichwert
Dieses Muster entspricht Vorgängen, die fehlschlagen können, aber einen sicheren Standardwert haben, der es dem Workflow ermöglicht, sinnvoll fortzufahren. Auf dem Fehlerpfad setzt ein Skriptknoten die erwartete Ausgabe auf einen Standardwert und verbindet sich dann mit dem Hauptpfad wieder, als wenn der Vorgang erfolgreich war.
Häufige Fehler
- Fehler im Hintergrund protokollieren – Fehler auf dem Fehlerpfad sollten immer protokolliert werden, auch wenn der Workflow fortgesetzt wird. Silent-Fehler sind später schwer zu diagnostizieren.
- Wiederholen von nicht-idempotenten Vorgängen – Vorgänge mit Nebenwirkungen (Schreiben von Daten, Senden einer Nachricht) können bei Wiederholung Duplikate erzeugen. Wiederholungseinstellungen gehören nur zu Vorgängen, die mehr als einmal ausgeführt werden können, ohne Duplikate zu erstellen.
- Fehler-Handles nicht verbunden lassen – Ein Knoten, dessen Fehler-Handle nicht verbunden ist, schlägt den gesamten Prozess bei einem Fehler fehl. Workflows, die nach einem Fehler fortgesetzt werden sollen, benötigen einen verbundenen Fehlerpfad.
Zugehörige Seiten
- Fehler behandeln – Schritt-für-Schritt-Aufgabe: Erstellen eines Fehlerpfads durchgängig
- Die Arbeitsfläche – Übersicht über den Arbeitsbereich einschließlich des Ausführungsbereichs
- Variablen und Datenfluss – wie Daten mithilfe von
$varszwischen Knoten übergeben werden. - Effektive Debugging – Tipps zur Untersuchung von Fehlern im Debug-Modus
- Dieser Leitfaden umfasst Folgendes:
- Wie es funktioniert
- Wiederholungen von HTTP-Anforderungen
- Konfigurieren von Fehlerbehandlungen
- Das Fehlerobjekt
- code
- Meldung
- Detail
- Kategorie
- Status
- Beispiel aus der Praxis
- Muster
- Protokollieren und fortfahren
- Mit Limit wiederholen
- Alarmieren und beenden
- Ausweichwert
- Häufige Fehler
- Zugehörige Seiten