Fehler-Typen

Die Fehler, die bei der Ausführung Ihrer Automation auftreten können, können in verschiedene Kategorien eingeteilt werden:

Dauerhafte Fehler

Angenommen, Sie verwenden den Webhook Baustein und haben eine URL eingegeben, die nicht existiert. Ultradox wird versuchen, diese URL aufzurufen, und jedes Mal, wenn der Baustein ausgeführt wird, schlägt er wieder fehl.

Sie könnten auch einen JavaScript Baustein mit fehlerhaftem Code erstellen. Die Ausführung des Skripts schlägt jedesmal fehl, wenn Sie den Baustein ausführen, bis Sie den Code korrigieren.

Dauerhafte Fehler sind zum Glück leicht zu beheben. Korrigieren Sie einfach die Automation oder den Code Ihres Skripts.

Temporäre Fehler

Temporäre Fehler können auftreten, wenn ein von Ihnen genutzter Service derzeit nicht verfügbar ist. Diese Fehler sind nicht so leicht zu beheben, da sie nach der Wiedererreichbarkeit des Dienstes nicht mehr so einfach zu reproduzieren sind.

Fehlermeldung

Durch die Fehlermeldung können Fehler unterschieden werden. Die Meldung enthält Informationen über die Fehlerursache und könnte lauten wie folgt:

Failed to process template, incomplete tag=Hallo ${nam

Diese Meldung weist auf einen permanenten Fehler in Ihrer Vorlage hin, der leicht zu beheben sein sollte.

Die Fehlermeldung könnte aber auch so aussehen:

Received exception executing http method GET against URL https://www.theservice.com: Connection timed out: connect

Es scheint ein temporärer Fehler zu sein, da der Service nicht antwortet und einen Timeout verursacht hat.

Regeln zur Fehlerbehandlung

Jeder Baustein kann mit einem Satz von Regeln zur Fehlerbehandlung konfiguriert werden. Wenn keine Regeln angegeben sind, wird Ultradox sofort einen Fehler melden.

 Um die Regeln zur Fehlerbehandlung zu konfigurieren, klicken Sie auf das Fehler-Symbol, das Sie rechts in der Symbolleiste des Bausteins finden.

Sie können mehrere Regeln definieren, die mit verschiedenen Fehlermeldungen übereinstimmen, und festlegen, wie Ultradox mit den entsprechenden Fehlern umgehen soll.

Angenommen, Sie haben eine App erstellt, die den aktuellen Benutzer und die Uhrzeit beim Start der App in ein Google Tabellendokument einträgt.

Wenn der Google-Service derzeit nicht verfügbar ist und einen Fehler auslöst, sollten Sie diesen Fehler einfach ignorieren und mit Ihrer Automation fortfahren.

In diesem Fall können Sie eine Regel definieren, nach der jeder Fehler in diesem Baustein ignoriert werden soll:

Falls Fehlermeldung passt	Versuche	Dann
.*	0	Fehler werfen

Was erfolgt bei dieser Konfiguration?

Die erste Spalte enthält einen regulären Ausdruck, der die passende Fehlermeldung beschreibt. In diesem Beispiel wird dieser mit jeder Fehlermeldung übereinstimmen.

In der zweiten Spalte wurde die Anzahl der Versuche angegeben, die durchgeführt werden sollen, wenn ein Fehler mit der passenden Meldung festgestellt wird. Sie ist auf 0 gesetzt, so dass keine Wiederholungsversuche durchgeführt werden.

Die dritte Spalte gibt an, ob der Fehler ausgelöst (= geworfen) oder ignoriert werden soll, wenn die maximale Anzahl von Wiederholungen erreicht wurde. Da wir die Anzahl der Wiederholungen auf Null gesetzt haben, wird der Fehler sofort ignoriert und es werden keine Wiederholungen durchgeführt.

Automatische Wiederholungsversuche

Lassen Sie uns nun die Fehlerbehandlung verbessern, indem wir die Anzahl der Wiederholungen konfigurieren. Wiederholungen sind nur sinnvoll, wenn Sie auf einen temporären Fehler stoßen, wie z.B. ein Verbindungs-Timeout.

Daher werden wir eine Reihe von Wiederholungsversuchen nur für Fehlermeldungen hinzufügen, die der ersten Regel entsprechen.

Falls Fehlermeldung passt	Versuche	Dann
.*timed out.*	3	Fehler werfen
.*	0	Fehler ignorieren

Die Regel beginnt mit .* mit einem beliebigen Zeichen, folgt dann mit Timeout und schließlich mit .*, das wiederum einem beliebigen Zeichen entspricht. Die vollständige Regel passt zu jeder Fehlermeldung, die den Text timed out enthält.

Alle anderen Fehler entsprechen der nächsten Regel.

Diese Konfiguration führt zu folgendem Verhalten:

Wenn ein Timeout auftritt, wiederholt Ultradox automatisch die gleiche Aktion bis zu dreimal. Die Verzögerung zwischen den Wiederholungsversuchen wird bei jedem Versuch größer, damit sich die Chance erhöht, dass der Service wieder erreichbar ist.

Wenn auch der dritte Versuch fehlschlägt, wirft Ultradox den Fehler und bricht den Ablauf ab, wenn der Fehler nicht an anderer Stelle aufgefangen wird.

Jeder andere Fehler in diesem Baustein wird einfach ignoriert.

Versuche Baustein

Jetzt, da Sie wissen, wie man Regeln zur Fehlerbehandlung für einen Baustein konfiguriert, können wir unser Wissen über die Fehlerbehandlung auf das nächste Level bringen.

Mit den Versuche Bausteinen können Sie eine Reihe von Schritten durchführen, wenn Sie einen bestimmten Fehler festgestellt haben.

Sie können beispielsweise eine E-Mail an den Entwickler eines Services senden, wenn der Service auch nach mehrmaligem Versuch nicht antwortet.

Wenn Sie einen Versuche Bausteinen in den Ablauf ziehen, fügt er automatisch auch einen Fange Fehler Bausteinen und den entsprechenden Ende Bausteinen hinzu.

Sie können dann eine Reihe von Bausteinen nach dem Versuch, aber vor dem Fange Fehler Bausteinen platzieren.

Wenn einer dieser Bausteine einen Fehler auslöst, können Sie ihn abfangen und eine Reihe von Schritten ausführen, die Sie direkt nach dem Fange Fehler Bausteinen ausführen:

Die folgenden Bausteine versuchen

Der Webhook Lade Kunde wird aufgerufen

Der Webhook Inventar wird aufgerufen

Fange Fehler ab

Sende E-Mail mit Betreff Fehler bei  ${now;datetime(op=short)} an [email protected]

Ende der fehleranfälligen Bausteine

Unabhängig davon, auf welchem der verschachtelten Bausteine der Fehler auftritt, wird die Ausführung unmittelbar nach dem Fange Fehler Baustein fortgesetzt.

Mit dieser Methode können Sie auch Ihre komplette Automation in einen Versuche / Fange Fehler Baustein packen und die Fehler in einem Google-Tabellendokument protokollieren.

Sie können Versuche / Fange Fehler Bausteine schachteln, um eine detaillierte Fehlerbehandlung durchzuführen.

Fehler werfen

Manchmal ist es sinnvoll, den eigenen Fehler zu werfen. Wenn Sie eine Automation erstellt haben, die von Ihrer eigenen Anwendung aufgerufen wird und die übergebenen Daten nicht verarbeitet werden können, können Sie die Automation stoppen indem Sie den Fehler werfen.

Dies ist sehr sinnvoll, wenn Sie Subflows erstellen, die aus verschiedenen Anwendungen oder Automationen aufgerufen werden können.

Eigene Fehler können wie Systemfehler behandelt und abgefangen werden.

Questions and Feedback

If you have any comments on this page, feel free to add suggestions right to the Google document that we are using to create this site.

If you are not yet member of the Ultradox community on Google+, please join now to get updates from our end or to provide feedback, bug reports or discuss with other users.

Last Updated: 10/17/18