K2 Lizensierung & SharePoint Skalierung

Es gibt immer wieder Missverständnisse im Zusammenhang der K2 Lizenzkosten mit SharePoint. Grundsätzlich muss betont werden, dass K2 (egal ob Blackpearl, Smartforms oder Connect) technisch komplett unabhängig von einem SharePoint Server funktioniert. D.h. bei der K2 Software handelt es sich keinesfalls um ein SharePoint Add-on, sondern vielmehr um eine eigenständige Plattform die sich in SharePoint integrieren lässt.

Logischerweise schlägt diese Tatsache dann bei der Lizensierung im Zusammenhang mit SharePoint durch. Denn hat man K2 einmal bezogen, wirkt sich aufgrund dieser technischen Unabhängigkeit eine Skalierung der SharePoint Farm nicht auf die K2 Lizenzkosten aus.

Das bedeutet beim denkbar einfachsten Setup befindet sich ein K2 Server in der Landschaft und dieser bedient eine SharePoint “Farm” mit einem WFE Server.

initsetup

Typischerweise wächst im Laufe der Zeit die Last auf dem SharePoint Server und man muss die Farm skalieren. Es werden dann n WFE Server ergänzt. Da K2 wie oben beschrieben unabhängig vom SharePoint läuft, bedeutet diese Skalierung nicht dass pro neuem SharePoint WFE auch ein neuer K2 Server gekauft / lizensiert / installiert werden muss.

3xwfe

 

Von der Lizensierung her gibt es also keine Verbindung zum SharePoint Server. Natürlich wird der K2 Server im obigen Beispiel irgendwann an die Auslastungsgrenze stoßen – auch hier: maßgeblich hierfür ist nur die Last auf dem K2 System – dann muss die K2 Farm um einen weiteren K2 Server erweitert (und somit lizensiert) werden. Diese Maßnahme hat keinen Einfluss auf die SharePoint Farm.

Eine weitere Funktion, die dank dieser unabhängigen Architektur unterstützt wird, ist das Betreiben von unterschiedlichen SharePoint Servern mit einem einzigen K2 Server. K2 differenziert aus Produktsicht nicht zwischen SharePoint 2007, 2010 und 2013 (aktuell Site im SP2010 Modus, 2014 kommt für SP2013 eine K2 App in den SharePoint Store).

spversionsk2

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 🙂