Fehlerbehandlung

Geht alles gut, wird jede Aktion erfolgreich ausgeführt und der Workflow endet im Erfolg. Leider ist es in der Praxis so, dass Fehler aus verschiedenen Gründen auftreten können, etwa wenn es keine Internetverbindungs gibt, die Festplatte voll ist oder ein externer Dienst nicht erreichbar ist. Daher ist es wichtig, bei jedem Workflow auch immer daran zu denken, welche Fehler passieren können und wie im Fe der erste weiche Fehlerfall vorgegangen werden soll.

Dieser Artikel beschreibt, welche Möglichkeiten es im Workflow gibt, Fehler zu erkennen und darauf zu reagieren.

Fehlerarten

Bis auf wenige Ausnahmen kann es bei jeder Aktion vorkommen, dass ein Fehler auftritt. Welche Fehler auftreten können, erfahren Sie, wenn Sie auf das -Symbol rechts oben an einer Aktion klicken. Es öffnet sich dann ein Fenster mit Informationen zu möglichen Fehlerarten. Dabei ist zu unterscheiden zwischen:

• Harter (technischen) Fehler. Diese werden rot dargestellt. Ein harter Fehler tritt in der Regel aufgrund technischer Probleme auf, etwa wenn kein Internetzugang besteht.
• Weicher (fachlicher) Fehler. Diese werden orange dargestellt. Ein weicher Fehler tritt in der Regel aufgrund fachlicher Probleme auf, etwa wenn auf die Datei eines Upload-Felds zugegriffen wird, welches kein Mussfeld ist und für das keine Datei hochgeladen wurde.

Für jeden Fehler wird im Informationsdialog der Fehler-Code angezeigt. Mittels Platzhalter kann später dieser Code geprüft werden, um herauszufinden, welcher Fehler auftrat. Beim Überfahren des Fehler-Codes mit der Maus wird ein kurzer Informationstext angezeigt, welcher den Fehler näher beschreibt.

Zusätzlich gibt es noch folgende System-Fehler-Codes, die bei jeder Aktion eintreten können:

GENERAL

Dieser Fehler-Code wird verwendet, wenn bei der Ausführung einer Aktion ein unerwarteter Fehler eingetreten ist, der von der Aktion selber in keine vordefinierten Fehler-Code umgewandelt wurde.

HANDLER_NOT_FOUND

Dieser Fehler-Code wird verwendet, wenn für eine Aktion die Abarbeitungslogik nicht gefunden werden konnte. In der Regel tritt dieser Fall ein, wenn ein Aktion verwendet wird, welche durch ein Plugin bereitgestellt wird und dieses Plugin entweder deinstalliert oder deaktiviert ist. Es sollte sich dann an einen Administrator gewendet werden.

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 harten Fehlers zurück. Besonders nützlich 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 harten Fehler geworfen hat.