Posted on

Verbessertes Error Handling mit K2 Smartforms 1.0.6

Unter den zahlreichen Verbesserungen in SF 1.0.6 findet sich auch die verbesserte Fehlerbehandlung. War es in der Vergangenheit noch so, dass alle Fehler zur Laufzeit eines K2 Smartforms direkt in einem Popup dargestellt wurden, kann man nun mit einer Regel ggf. Fehler abfangen und zum Beispiel nach Abhängigkeit des Fehlertyps mit einer eigenen, benutzerfreundlichen Fehlermeldung arbeiten oder auf eine passende Landingpage weiterleiten.

Fehler abfangen

Das funktioniert pragmatisch auf View- und Formularebene und zwar über sog. View-Methoden. Jede Ansicht und jedes Formular haben ab sofort entsprechende Methoden im Rules Wizard. Somit ist es möglich ein ganzes Set an Regeln auszuführen, falls auf der Ansicht oder dem Formular ein Fehler auftritt.

error_1

 Welche Informationen gibt es über den Fehler?

Die Details zum Fehler findet man im Kontext Browser unter den System Values. Es wird unterschieden zwischen

  • Error Message
  • Error Details
  • Error Type

error_2Basierend auf diesen Informationen kann man nun eine eigene Fehlerbehandlung implementieren, zum Beispiel anhand des Error Type

error_3

error_4

Und entsprechend dann darauf reagieren

error_5

 

Try-Catch-Funktion

Zusätzlich zu den View- und Form Methoden gibt es auch eine neue Condition (“error occured”) und eine neue Action (“stop rule execution”) in dem Rules Designer. Kombiniert man beide, kann man eine Art “Try-Catch” Funktion implementieren.

error_6

Im folgenden Beispiel wird eine SmartObject Methode ausgeführt welche intern einen Webservice nutzt. Antwortet der Service nicht, kann man dies mit einer eigenen Meldung dem Anwender verdeutlichen 🙂

error_7

In Verbindung mit dem Multilingual Control kann man die Fehlermeldungen bzw. Seiten übrigens auch mehrsprachig gestalten!

Weitere Informationen zu dem Thema Error Handling gibt es wie immer auf der K2 Website! (Knowledge  Base)

Posted on

Exception Handling in K2 Workflows: Retry anstatt Restart!

Diejenigen die regelmäßig Workflows designen, werden bestätigen dass das Thema Exception Handling nicht zu unterschätzen ist. Angenommen ein Workflow sieht vor, dass zu einem bestimmten Punkt diverse Manager, Kunden, Teams in mehreren Freigabeschritten involviert waren, danach Berechtigungen auf Objekte schon entsprechend umgestellt wurden etc. – durch eine Unachtsamkeit im WF Design läuft der Workflow nun auf Fehler.

Bei manchen Systemen ist man nun gezwungen die Workflowinstanz zu beenden und muss von vorne beginnen. Gerade wenn der “alte” Workflow schon diverse Änderungen am Element oder abhängigen Elementen durchgeführt hat, kann dies zu echten Problemen führen. Ganz abgesehen davon, dass man nicht wieder die selben Personen mit den gleichen Arbeitsschritten (Freigabe, Kommentieren usw.) zum gleichen Element involvieren will.

Man stellt also fest dass eine Instanz einen Fehler verursacht hat. Es ist immer eine gute Idee sich den Prozessverlauf anhand des Viewflow Control zu verdeutlichen, denn dort wird entsprechend markiert an welcher Stelle der Fehler auftrat.

error

 

Genauere Details liest man dann im K2 Error Reporting ab, zu finden im K2 Workspace oder K2 Process Portal im SharePoint.

errordetails

 

Angenommen ich hätte den Fehler bereits lokalisiert und wüsste dass er durch externe Datenfelder (zB SharePoint Feldwert, SAP Wert, SQL etc) verursacht wurde, könnte ich den Fehler im betroffenen Backend beheben und danach in der Maske (oben) auf Retry klicken. Dies hätte zur Folge dass der Workflow in der gleichen Version ab dem Fehler weiterläuft, allerdings mit aktualisierten Daten aus den Backends und der Fehler würde nicht mehr auftauchen. In dem Beispiel würde dann also nicht mehr versucht durch 0 zu dividieren.

D.h. für Fehler die klar auf externe Quellen zurückzuführen sind, müssen wir nicht eine neue Workflow Version bereitstellen sondern können sofort nach Anpassung der Daten über diese einfache Retry Funktion den Workflow fortführen.

Etwas problematischer wird es allerdings, wenn der Fehler nicht auf externe Daten zurückzuführen ist, sondern auf einen “echten ” Fehler im Workflow Design selbst. In diesem Beispiel habe ich den Fehler natürlich provoziert.

errordesign

 

Doch selbst dieser Designfehler führt nicht dazu dass ich den Workflow komplett abbrechen und wieder neustarten muss. Zunächst muss der Fehler behoben und eine die verbesserte Workflow Version bereitgestellt werden. Anstatt durch 0 wollte ich eigentlich durch 2 dividieren.

fixeddesign

 

Mit Hilfe des K2 Process Management Tools kann ich nun die laufende (fehlerhafte) Instanz aktualisieren und durch ein Upgrade mit der neuen Version fortführen.

retryvs

 

Das Ergbnis sieht dann so aus

viewflow fixed

 

Der Workflow konnte ohne Neustart die letzten Schritte durchführen, es mussten keine Personen bereits erledigte Arbeit wiederholen. Nice 🙂