Fehlerbehandlung

Inhalt [ Verbergen ]

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 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.

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.

Fehler

  • Im neuen Workflow komplett anders -> Erklärung für neuen Workflow
  • Jede Standard-Aktion kann Fehler werfen.
  • Endet eine Verarbeitungskette in einem unbehandelten Fehler, wird der Workflow an dieser Stelle abgebrochen, der Vorgang als fehlerhaft markiert und keine weiteren Verabeitungsketten mehr ausgeführt.
  • Mittels Fehlerbehandlungsblock (unter Steuerelementen) kann ein Fehler abgefangen werden.
  • Wird ein Fehler mittels Fehlerbehandlungsblock behandelt, wird die Verarbeitungskette ingesamt als orndungsgemäßt abgearbeitet betrachtet, endet also nicht in einem Fehler.
  • Zudem gibt es ein Workflow-Fehler-Ereignis. Dieses tritt ein, wenn eine Verarbeitungskette in einem Fehler endet. Falls die Verarbeitungskette des Workflow-Fehler-Ereignisses selber in einem Fehler endet, wird der Workflow abgebrochen und auch keine weiteren Workflow-Fehler-Ereignis mehr ausgeführt.
  • Sowohl im Fehlerbehandlungsblock als auch im Workflow-Fehler-Ereignis kann auf den aufgetretenen Fehler via Platzhalter zugegriffen werden:
    • [%$LAST_ERROR%]
    • [%$LAST_ERROR_CODE%]
    • [%$LAST_ERROR_MESSAGE%]
    • [%$LAST_ERROR_NODE_NAME%]
    • [%$LAST_ERROR_NODE_TYPE%]
  • Damit ist es z.B. möglich, abhängig vom Fehlertyp unterschiedlich zu reagieren (via Bedingungen)
  • Ein Fehlerbehandlungsblock besteht aus 2 Teilen (links: Aktionen, deren Fehler abgefangen werden sollen, rechts: Aktionen, die im Fehlerfall ausgeführt werden sollen). Wenn die Aktionen im Fehlerfall selber einen Fehler werfen, endet der Fehlerbehandlungsblock in einem Fehler. Bei Bedarf können Fehlerbehandlungsblock geschachtelt werden.
  • Auf den Fehler einer bestimmten Aktion kann mit den Platzhaltern [%$ActionName.ERROR_CODE%], [%$ActionName.ERROR_MESSAGE%] und [%$ActionName.ERROR%] zugegriffen werden. Der Platzhalter [%$ActionName.ERROR%] enthält optionale Daten, die bei Auftreten eines Fehler mit einem bestimmten Code bereitsgestellt werden. Welche Fehler-Codes bei einer Aktion auftreten können und welche optional Daten jeder Fehler-Code hat kann z.B. im Informationsdialog einer Aktion im Designer eingesehen werden.
  • Jede Aktion kann Fehler-Codes definieren, die auftreten können. Weiterhin gibt es noch den System-Fehler-Code GENERAL, der benutzt wird, wenn eine Aktion einen unbehandelten Fehler wirft.
  • Falls ein Aktions-Plugin deinstalliert oder deaktiviert ist und versucht wird, einen Workflow mit dieser Plugin-Aktion auszuführen, wird ein Fehler mit dem System-Fehler-Code HANDLER_NOT_FOUND geworfen. Dieser kann bei Bedarf etwa mit einem Fehlerbehandlungsblock abgefangen werden.
  • Bei manchen Aktionen wird zwischen technischen und fachlichen Fehlern unterschieden. Ein technischer Fehler resultiert immer in einem Fehler, der explizit behandelt werden muss, ansonsten wird der Workflow abgebrochen. Bei einem fachlichen Fehler endet die Aktion erfolgreich, kann aber Warnmeldungen und andere Resultatwerte bereitstellen. Mit folgenden Platzhaltern kann herausgefunden werden, ob und welcher Fehler auftrat:
    • [%$ActionName.SUCCESS%] Kurzform für (NOT HAS_HARD_ERROR) AND (NOT HAS_SOFT_ERROR). 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:
    • [%$ActionName.HAS_HARD_ERROR%] true, wenn die Aktion einen Fehler geworden hat, der explizit behandelt werden muss ("technischer Fehler").
    • [%$ActionName.HAS_SOFT_ERROR%] true, wenn die Aktion erfolgreich war, aber ein fachlicher Fehler auftrat.
    • [%$ActionName.SOFT_ERRORS%] Liste aller weichen, die währender der Abarbeitung der Aktion auftraten. In der Regel sind die Platzhalter [%$ActionName.SUCCESS%] bzw. [%$ActionName.ERROR_CODE%] ausreichend. Dieser Platzhalter steht zur Verfügung, falls einmal auf alle weichen Fehler explizit zugegriffen werden muss.
    • Die Platzhalter [%$ActionName.ERROR_CODE%], [%$ActionName.ERROR_MESSAGE%] und [%$ActionName.ERROR%] liefern den ersten weichen Fehler zurück, falls existent.

Fehlerbehandlung in Status

Fehlerbehandlung in Status.

Jeder Status hat eine Konfigurationsmöglichkeit für die Behandlung bei Fehlern innerhalb der Abarbeitung. Es kann vorkommen, dass eine Aktion nicht ausgeführt werden kann, wenn z.B. Daten in eine Datenbank geschrieben werden soll und die Verbindung zur Datenbank zu diesem Zeitpunkt nicht besteht. In diesen Fällen muss entschieden werden, ob ein Statuswechsel vorgenommen oder der aktuelle Status beibehalten wird.

Status nicht wechseln

Tritt ein Fehler bei der Verarbeitung von Aktionen auf, wird der Status nicht gewechselt. Es gibt jedoch einen Unterschied zwischen dem Systemstatus Eingegangen und selbst angelegten Status. Kommt es zu Fehlern im Status Eingegangen, werden die Formulardaten nicht angenommen, der Benutzer bekommt die Meldung, dass die Daten nicht verarbeitet werden konnten. Tritt ein Fehler beim Statuswechsel im Posteingang bei einem selbst angelegten Status auf, bleibt der aktuelle Status erhalten und der Postfachbearbeiter erhält eine entsprechende Meldung. Alle Fehler werden im Modul Protokollaufgelistet.

Status trotzdem wechseln

Der Status wird gewechselt, auch wenn Fehler bei der Aktionsverarbeitung aufgetreten sind. 

Fehlerbehandlung in Aktionen

Fehlerbehandlung in Aktionen.

Die Fehlerbehandlung in Aktionen ist eng mit der Fehlerbehandlung der Status verbunden. Die Informationen, ob ein Fehler zum Abbruch der Aktion führte, kommt immer mit der Aktion selbst.

In jeder Aktion gibt es die Auswahlmöglichkeit für den Fehlerfall:

Verarbeitung abbrechen

Kommt es zu Fehlern bei der Aktionsverarbeitung, wird die Aktion abgebrochen und keine weitere Aktion mehr ausgeführt. Diese Information wird an den übergeordneten Status übergeben, der dann wiederum entsprechend seiner Konfiguration den Status wechselt oder nicht.

Verarbeitung fortsetzen

Kommt es zu Fehlern bei der Aktionsverarbeitung, wird dieser ignoriert. Es kommt zwar zu einer entsprechenden Protokollierung, jedoch wird die Verarbeitung ohne Einschränkungen fortgesetzt. Die Ergebnisse der Aktion sind ferner über die entsprechenden Platzhalter abrufbar.

Konfigurierte Aktion

Tritt ein Fehler bei der Aktionsverabeitung auf, wird zu der Aktion (Zielaktion) gesprungen, die in der Auswahlliste Aktion im Fehlerfall gewählt wurde. Aktionen zwischen der fehlerhaften Aktion und der Zielaktion werden nicht ausgeführt.