Workflows

Workflows implementieren Geschäftsprozesse oder Teile dieser. Ein einfaches Beispiel ist folgendes:

Workflows dienen in Schleupen.CS der Orchestrierung von Services. Orchestrierung im Vergleich zu Choreographie ist dabei die Umsetzung der Anforderung, das System nachvollziehbar erweitern / anpassen zu können, da die Workflows per BPMN modelliert werden und eine Ablaufsteuerung ("der Dirigent") existiert.

Die Workflows selber werden meist als sogenannte Prozessmanager umgesetzt, koordinieren also langlaufende Geschäftsprozesse über mehrere Bounded Contexts hinweg.

Lang laufende Transaktionen

Dinge laufen leider nicht immer wie erwartet - so könnte beispielsweise der Aufruf des Services in Schritt (5) in obiger Abbildung fehlschlagen. Hierbei ist in manchen Fällen wünschenswert, eine Transaktion um die Orchestrierung der Service-Aufrufe zu fahren, ohne das 2Phasen-Commit-Protokoll mit spezifischen, Technologie-affinen Implementierungen nutzen zu müssen. Hierzu erweitern wir in einigen Fällen die Prozessmanager zu sogenannten  Sagas. Dies ist eine Lösungsmöglichkeit für verteilte, lang laufende Transaktionen.

In unserem Beispiel wird die Transaktion dann im Fehlerfall bei einer Saga wie folgt zurückgerollt:

1. Die Gesamt-Transaktion wird durch Aufruf des ProcessServices (= Workflow) gestartet.
2. Bei Aufruf des Service wird im ersten Bounded Context eine lokale Transaktion ausgeführt und bei committed.
3. Analog wird in Schritt 3 eine lokale Transaktion ausgeführt.
4. In Schritt 4 wird in diesem Beispiel ebenfalls eine lokale Transaktion ausgeführt, die allerdings scheitert.
5. Die lokale Transaktion wird zurückgerollt.
6. Da die Gesamt-Transaktion nun zurückgerollt werden soll, muss hier die in Schritt 3 ausgeführte Operation zurückgenommen, d.h. kompensiert werden (Kompensation).
7. Analog erfolgt hier ebenfalls Rollback durch Kompensation.

Damit das auch sicher funktioniert, muss die Kompensation idempotent sein!

Anmerkung: Siehe auch Transaktionen.

Resiliente Service-Anbindung

Wie in Kommunikationsarten beschrieben, werden die orchestrierten Services durch die Workflow-Implementierung nicht synchron, sondern asynchron per Request-Reply aufgerufen. Der Grund hierfür ist, das System widerstandsfähiger zu machen. Die Anbindung der Services ist über unsere BusinessProcessEngine einfach, die Workflow-Implementierungen auf Basis von primär BPMN-Modellen generiert werden.

Der Ablauf ist dabei in folgender Abbildung exemplarisch dargestellt:

Ablauf

1. Die Nachricht wird in die Request-Queue eingestellt.
2. Der Business Event Dispatcher (BED, Windows-Dienst) holt die Nachricht aus der Request-Queue.
3. Der BED ruft den Ziel-Service auf.
4. Der BED nimmt die Antwort des Service-Aufrufs entgegen und stellt sie in die Reply-Queue ein.
5. Der Workflow nimmt diese Antwort aus der Reply-Queue.

Nutzungskontexte

Workflows haben prinzipiell zwei Nutzungskontexte in Schleupen.CS. Zum einen stellen sie eine grobgranulare Steuerung von Geschäftsprozessen dar, die aus grobgranularen, fachlichen Schritten eines Geschäftsprozesses bestehen.

Als Beispiel betrachten wir hierzu folgenden Bestell-Prozess des Architektur-Beispiels 'Bibliotheksverwaltung'.

Wichtig hier bei ist, dass die Schritte allesamt fachlicher und nicht technischer Natur sind. Aktivitäten wie "Daten sammeln" wären technische Aktivitäten, die hier nicht hin gehören. Derartige grobgranulare Workflows sind in GP-Komponenten verortet. Dabei kann es aber sein, dass der gesamte Geschäftsprozess sich auf mehrere Bounded Contexts verteilt:

Zum anderen stellen Workflows feingranulare asynchrone ActivityServices dar, um Services, die in GP-Komponenten angeschlossen werden, nicht zu groß werden zu lassen.

Denn eine Aktivität wie beispielsweise 'Buch bereitstellen' würde bei einem synchronen Anschluss und direkter Implementierung einen "großen" Services nach sich ziehen, die mit hoher Wahrscheinlichkeit in ein Client-seitige Timeout münden würden. Um dieses zu vermeiden, können man die Schritte des Workflows der GP-Komponente splitten und kleinere Services aufzurufen. Dadurch würde aber die Idee des grobgranularen Ablaufs kaputt gehen. Als Lösung dürfen daher in Ländern / Provinzen Workflows implementiert werden, die semantisch länger laufende ActivityServices darstellen.

Derzeit müssen Workflows - obwohl diese eigentlich in Ländern / Provinzen ActivityServices darstellen - eine ProcessService-Schnittstellen implementieren.