- Erste Schritte
- Erstellen
- Fügen Sie einen KI-Agent zu einem Workflow hinzu
- Rufen Sie eine externe API auf
- Eingehende E-Mails verarbeiten
- Einen Slack-Benachrichtigungs-Workflow erstellen
- Eine menschliche Genehmigung zu einem Workflow hinzufügen
- Erstellen Sie einen Chat Agent-Workflow
- Fehler behandeln
- Grundlagen des Debuggens
- Human-in-the-Loop: Eskalation oder menschlicher Schritt
- Auswerten Ihrer Workflows
- Bereitstellen und ausführen
- Beispiele
- Referenz (Reference)
Fehlerbearbeitung
Wie ein Knotenfehler über das Fehler-Handle des Knotens an einen separaten Pfad weitergeleitet werden kann und wie die Fehlerdetails über Variablen verfügbar gemacht werden.
Die Fehlerbehandlung ist ein Mechanismus pro Knoten, der steuert, was passiert, wenn ein Knoten während eines Laufs fehlschlägt. Standardmäßig stoppt ein fehlgeschlagener Knoten den gesamten Workflow. Durch das Verbinden des Fehler-Handle des Knotens wird der Fehler an einen separaten Pfad weitergeleitet, wo der Workflow den Fehler überprüfen und darauf reagieren kann.
Wie es funktioniert
Jeder Knoten, der die Fehlerbehandlung unterstützt, hat eine Registerkarte Fehlerbehandlung in seinem Eigenschaftenbereich. Der Umschalter Fehlerbehandlung aktivieren auf dieser Registerkarte fügt dem Knoten einen Fehlerausgabehandle hinzu, einen zweiten Ausgabe-Connector mit der Bezeichnung Fehler unter dem Hauptausgabehandle auf der rechten Seite des Knotens, der aktiviert wird, wenn der Knoten fehlschlägt. Die meisten Knoten unterstützen die Fehlerbehandlung.
Wenn ein Knoten mit verbundenem Fehler-Handle fehlschlägt, folgt die Ausführung dem Fehlerpfad, anstatt den Workflow anzuhalten. Die Fehlerdetails werden als Variable verfügbar, die spätere Knoten lesen können.
Wenn ein Knoten ohne verbundenes Fehler-Handle fehlschlägt, wird die Ausführung auf diesem Knoten angehalten. In einer Testausführung wird der Fehler auf der Registerkarte Vorfälle unterhalb der Arbeitsfläche angezeigt. In einer bereitgestellten Ausführung wird die Ausführung angehalten, bis Sie sie wiederholen oder abbrechen, wie Wiederholen und Abbrechen beschrieben.
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, folgt die Ausführung dem Fehlerpfad. Wenn kein Fehler-Handle verbunden ist, schlägt der Workflow fehl.
Error-Handles konfigurieren
Wenn Sie Fehlerbehandlung aktivieren auf der Registerkarte Fehlerbehandlung des Eigenschaftenbereichs aktivieren, wird dem Knoten das Fehlerhandle hinzugefügt. Durch Verbinden des Fehler -Handles mit einem anderen Knoten auf der Arbeitsfläche wird der Fehlerpfad verkettet. Ein Knoten ohne Fehler -Handle unterstützt keine Fehlerbehandlung, sodass jeder Fehler den Workflow anhält.
Das Fehlerobjekt
Wenn ein Fehler-Handle verbunden ist und der Knoten fehlschlägt, sind die Fehlerdetails als $vars.<nodeName>.error verfügbar. Das Objekt verfügt über die folgenden Felder:
code: Ein maschinenlesbarer Code, der den Fehlertyp identifiziert.message: Eine visuell lesbare Beschreibung dessen, was schief gelaufen ist, die für die Protokollierung oder die Anzeige für einen Benutzer geeignet ist.detail: Eine technische Beschreibung des Fehlers, einschließlich Stack-Traces (die Liste der Aufrufe, die zum Fehler geführt haben) oder dienstspezifische Informationen, sofern verfügbar.category: Die Fehlerkategorie, die verwandte Fehlertypen gruppiert.status: Der HTTP-Statuscode, der zum Fehler gehört, z. B.404oder500. Wird für HTTP-bezogene Fehler ausgefüllt.
Das Fehlerobjekt ist nur im Error-Pfad verfügbar. Der Zugriff auf $vars.<nodeName>.error im Success-Pfad gibt „undefined“ 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. Der HTTP-Anforderungsknoten ist 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, folgt die Ausführung nach konfigurierten Wiederholungen dem Fehlerpfad zum Skriptknoten, der das vollständige Fehlerobjekt erhält.
Bei einer erfolgreichen Ausführung wird der Erfolgspfad ausgeführt und der Fehlerpfad wird übersprungen:
Bei einer fehlgeschlagenen Ausführung wird stattdessen der Fehlerpfad ausgeführt:
Muster
Dies sind gängige Ansätze für die Behandlung, Protokollierung, Wiederholung und Eskalation von Fehlern. Sie alle basieren auf dem oben beschriebenen Error-Handle pro Knoten: Ein verbundener Error-Handle leitet Fehler an einen separaten Pfad weiter, auf 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
Wiederholen mit Limit
Dieses Muster entspricht Fehlern, die wahrscheinlich vorübergehend sind, z. B. Netzwerkzeitüberschreitungen, Ratenlimits oder Dienstausfä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.
Benachrichtigen und beenden
Dieses Muster entspricht nicht bearbeitbaren Fehlern, die menschliche Aufmerksamkeit erfordern. Auf dem Fehlerpfad wird eine Benachrichtigung über eine HTTP-Anforderung oder einen Integrationsknoten gesendet, dann beendet ein Terminate -Knoten den Workflow mit einer Ausgabevariablen, die eine beschreibende Nachricht wie $vars.step1.error.message enthält.
Fallback-Wert
Dieses Muster eignet sich für Vorgänge, die möglicherweise fehlschlagen, aber einen sicheren Standardwert haben, der es dem Workflow ermöglicht, sinnvoll fortzufahren. Auf dem Error-Pfad legt ein Script-Knoten die erwartete Ausgabe auf einen Standardwert fest und führt anschließend wieder in den Hauptpfad, als wäre der Vorgang erfolgreich gewesen.
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 Vorgängen, die nicht sicher wiederholt werden können: Vorgänge mit Nebenwirkungen, wie das Schreiben von Daten oder das Senden einer Nachricht, können Duplikate erzeugen, wenn sie wiederholt werden. Wiederholungseinstellungen gehören nur zu Vorgängen, die mehr als einmal ausgeführt werden können, ohne Duplikate zu erstellen.
- Lassen von Fehler-Handles nicht verbunden: Ein Knoten, dessen Fehler-Handle nicht verbunden ist, schlägt den gesamten Workflow bei einem Fehler fehl. Ein Workflow, der nach einem Fehler fortgesetzt werden soll, benötigt einen verbundenen Fehlerpfad.
Nächste Schritte
- Fehler behandeln: eine Schritt-für-Schritt-Aufgabe, die einen Fehlerpfad erstellt.
- Die Flow-Arbeitsfläche: Der Arbeitsbereich, einschließlich des Panels unter der Arbeitsfläche.
- Variablen und Datenfluss: Wie Daten zwischen Knoten mit
$varsübergeben werden. - Debugging-Grundlagen: Tipps zur Untersuchung von Fehlern während einer Debugausführung.
- Community: Stellen Sie Fragen und teilen Sie Workflows mit anderen Buildern im UiPath Forum.