Error handling

When everything works out smoothly, each action completes normally and the workflow is successful. Unfortunately, errors may always happen occassionally, such as when the internet connection is not working, when the server does not have any empty memory left, or when an external service is not available. When you designer a workflow, you should always consider which errors may happen and how you wish to proceed in case they do happen.

This help page explains what happens when an error occurs in the workflow and how you can react to errors.

Error types

With very few exceptions, every action can result in an error. Each action can result in different kind of errors. If you want to learn which error can occur, click on the icon to the top right of an action. This open an info window which shows all possible kinds of errors. Errors are categorized into two different types:

• Hard errors, which are displayed in red. A hard error usually indicates a technical issue, such as a missing internet connection.
• Soft errors, which are displayed in orange. A soft error usually indicates an issue in the business logic, such as when you access a non-required upload field, but no file was uploaded for that upload field.

For each error, the info window shows the corresponding error code. Hover over the error code to view a short explanation when that error may occur. Later in the workflow, you can use variables to check which kind of error occurred.

In addition to the error codes specific to each action, the following error codes also exist:

GENERAL

This error code is used when an unexpected error occurred during an action, which was not converted into a custom error code by the action itself. This may indicate a programming error, bad data or a severe server issue.

HANDLER_NOT_FOUND

This error is used when the processing logic of an action could not be found. Usually this happens when the workflow contains an action provided by a plugin; and that plugin was either uninstalled or is currently deactivated.

Wenn ein bestimmter Fehler eintritt, ist es möglich, dass weitere Daten bereit gestellt werden, die den Fehler genauer beschreiben. Welche Daten bereit gestellt werden, hängt von der Aktion und dem Fehler-Code ab. Beispielsweise kann bei der Aktion HTTP-Request der Fehler-Code SERVER_ERROR auftreten, wobei zusätzlich noch der HTTP-Status-Code und die Statusnachricht als Daten bereit gestellt werden. Im Informationsdialog wird für jeden Fall angezeigt, welche zusätzlichen Daten bereit gestellt werden. Auf diese kann ebenfalls per Platzhalter zugegriffen werden.

Verhalten im Fehlerfall

Im Folgenden wird kurz beschrieben, was passiert, wenn eine Aktion in einem Fehler endet. Hier muss auch zwischen harten (technischen) und weichen (fachlichen) Fehlern unterschieden werden.

Harter Fehler

Tritt ein harter Fehler auf, so wird die Aktion abgebrochen und ein Protokolleintrag mit Resultat Fehler angelegt, in dem der Fehler-Code sowie weitere Informationen protokolliert werden. Ist keine Fehlerbehandlung eingestellt, wird weiterhin die gesamte Verarbeitungskette des Ereignisses abgebrochen, weitere ausstehende Verarbeitungsketten anderer Ereignisse werden nicht mehr ausgeführt. Der Workflow endet in einem Fehler und die generische Fehler-Abschlussseite wird dem Nutzer angezeigt, der das Formular abgeschickt hat. Ist dies nicht gewünscht, gibt es zwei Möglichkeiten, den Fehler abzufangen und darauf zu reagieren.

Zum Einen kann die Aktion in einen Fehlerbehandlungsblock gezogen werden. Im Fehlerzweig des Fehlerblocks kann dann getan werden, was notwendig ist, um den Fehler zu behandeln. Wurde der Fehler so behandelt, endet der nicht mehr in einem Fehler. Dieser Variante hat den Vorteil, dass direkt auf konkreten Fehler einer bestimmten Aktion reagiert werden kann. Beispielsweise kann beim Versenden einer E-Mail eine andere E-Mail-Adresse versucht werden. Sollte im Fehlerzweig erneut ein Fehler auftreten, endet der Fehlerblock in einem Fehler und die Verarbeitungskette sowie der Workflow werden abgebrochen. Es ist aber möglich, Fehlerblöcke zu schachteln, um auch Fehler im Fehlerzweig abzufangen.

Zum Anderen ist es auch möglich, ein sogenanntes Fehlereigniss in den Workflow einzufügen. Dieses tritt immer dann ein, wenn in irgendeiner Verarbeitungskette ein unbehandelter Fehler auftritt, der den Workflow abbrechen würde. Inbesonders bedeutet dies, dass das Fehlereignis nicht eintritt, falls der Fehler bereits mit einem Fehlerblock behandelt wurde. Nach Ausführung der Verarbeitungskette eines Fehlereignisses wird der Fehler als behandelt betrachtet und der gesamte Workflow als erfolgreich. Das heißt, dem Nutzer wird etwa keine Fehlerseite beim Absendendes des Formulars angezeigt. Ein Fehlereigniss eignet sich dann, wenn eine allgemeine Aktion im Fehlerfall ausgeführt werden soll, etwas durch Versenden einer E-Mail an einen Administrator. Sind in einem Workflow mehere Fehlereignisse angelegt, werden diese der Reihe nach ausgeführt. Falls in der Verarbeitungskette eines Fehlereignisses selber ein unbehandelter Fehler auftritt, wird der Workflow mit einem Fehler abgebrochen und keine weiteren Fehlereignisse ausgeführt.

Weicher Fehler

Tritt ein weicher Fehler auf, wird die Aktion trotzdem als erfolgreich betrachtet und die nächste Aktion normal ausgeführt, als ob der Fehler nicht aufgetreten sei. Inbesonders werden also auch keine Fehlerbehandlungsblöcke oder Fehlereignisse ausgeführt.

In diesem Sinne können weiche Fehler auch als Warnungsmeldungen verstanden werden. Im Protokoll wird ein Eintrag mit dem Resultat Warnung angelegt. Mittels Platzhaltern kann geprüft werden, ob bei einer Aktion ein weicher Fehler auftrat ([%$Aktionsname.HAS_SOFT_ERROR]). Weiterhin kann mit dem Platzhalter [%$Aktionsname.SUCCESS], ob die Aktion erfolgreich war, also weder ein harter noch weicher Fehler aufgetreten ist.

Schließlich ist noch anzumerken, dass eine Aktion mehrere weiche Fehler (Warnungen) erzeugen kann.

Platzhalter

Es gibt verschiedene Platzhalter, um herauszufinden, welcher Fehler aufgetreten ist. Im Folgenden findet sich eine Liste aller verfügbaren Platzhalter.

[%$Aktionsname.SUCCESS%]

Entweder true oder false. Gibt an, ob die Aktion erfolgreich war, also weder ein harter noch ein weicher Fehler aufgetreten ist. In der Regel sollte dieser Platzhalter ausreichen und verwendet werden. In einigen Fällen kann es notwendig sein, zwischen Fehlerarten zu unterscheiden. Dann können folgende Platzhalter genutzt werden:

[%$Aktionsname.HAS_HARD_ERROR%]

Liefert true zurück, wenn die Aktion einen harten (technischen) Fehler geworden hat, der explizit behandelt werden muss, etwa mit einem Fehlerblock oder Fehlerergnisse. Harter Fehler resultieren in einem Abbruch des Workflow, wenn diese nicht behandlet werden. Andernfalls wird false zurückgeliefert.

[%$Aktionsname.HAS_SOFT_ERROR%]

Liefert true zurück, wenn die Aktion einen oder mehrere weiche (fachliche) Fehler erzeugt hat. Bei einem weichen Fehler wird der Workflow normal fortgesetzt. Andernfalls wird false zurückgeliefert.

[%$Aktionsname.SOFT_ERRORS%]

Liste mit allen weichen Fehler, die aufgetreten sind. [%$Aktionsname.SOFT_ERRORS[0]%] ist der erste weiche Fehler, [%$Aktionsname.SOFT_ERRORS[1]%] der zweite weiche Fehler, und so weiter. Für jeden weichen Fehler kann auf code (Fehler-Code), message (Fehlernachricht) und data (Daten des Fehlers) zugegriffen werden. Beispielsweise ist [%$Aktionsname.SOFT_ERRORS[2].message%] die Fehlernachricht des dritten weichen Fehlers. Die Anzahl der weichen Fehler kann mittels [%$Aktionsname.SOFT_ERRORS.length()%] ermittelt werden.

[%$Aktionsname.ERROR_CODE%]

Liefert den Fehler-Code zurück, falls bei Ausführung der Aktion ein harter oder weicher Fehler auftrat. Bei mehreren weichen Fehlern wird der Fehler-Code des zuerst aufgetretenen weichen Fehlers zurückgeliefert. Beispielsweise gibt es bei der Aktion die HTTP-Request unter Anderem die Fehler-Codes CLIENT_ERROR und SERVER_ERROR.

[%$Aktionsname.ERROR_MESSAGE%]

Liefert die Fehlernachricht zurück, falls bei Ausführung der Aktion ein harter oder weicher Fehler auftrat. Bei mehreren weichen Fehlern wird die Fehlernachricht des zuerst aufgetretenen weichen Fehlers zurückgeliefert. Die Fehlernachricht ist in der Regel ein kurzer englischer Satz mit Details zum Fehler.

[%$Aktionsname.ERROR%]

Liefert die zusätzlich bereitgestellten Daten im Fehlerfall zurück, falls bei Ausführung der Aktion ein harter oder weicher Fehler auftrat. Bei mehreren weichen Fehlern wird der Fehler-Code des zuerst aufgetretenen weichen Fehlers zurückgeliefert. Welche Daten bei welchem Fehler-Code zurückgeliefert werden, ist für jede Aktion unterschiedlich und kann im Informationsfenster jeder Aktion eingesehen werden. Bei der Aktion HTTP-Request beispielsweise kann mit [%$Aktionsname.ERROR.responseCode%] auf den Status-Code der HTTP-Antwort zugegriffen werden, falls der Fehler-Code SERVER_ERROR oder CLIENT_ERROR vorliegt.

[%$LAST_ERROR_CODE%], [%$LAST_ERROR_MESSAGE%] und [%$LAST_ERROR%]

Liefert den Fehler-Code, die Fehlernachricht beziehungsweise die zusätzlichen Daten des zuletzt aufgetretenen Fehlers zurück. Besonders nützlich Dieser Platzhalter ist dieser Platzhalter im Fehlerzweig eines Fehlerblocks, um nicht jedesmal auf den konkreten Namen einer Aktion referenzieren zu müssen. Ebenso kann dieser Platzhalter in einem Fehlerereignis genutzt werden.

[%$LAST_ERROR_NODE_NAME%] und [%$LAST_ERROR_NODE_TYPE%]

Liefert den Namen und den technischen Typ der Aktion zurück, die zuletzt einen Fehler geworfen hat.