Unser erstes Beispiel ist sehr einfach. Es geht hier nur darum, die grundsätzliche Funktionsweise zu zeigen.

Wenn dieser Workflow gestartet wird, geht er automatisch in die erste Transition (die keine Bedingungen enthält), dann automatisch in die zweite Transition (die ebenfalls keine Bedingungen enthält) und beendet sich dann schlicht.

Import: (Anleitung)

Workflow_WF_automated_1.xml

Nachdem der Workflow gestartet wurde, ist er praktisch sofort beendet und Sie können ihn in den Logs finden.

Fachliche und technische Ebene

Wie Sie an diesem Beispiel gut erkennen können, kann solch ein funktionsloses Workflow-Diagramm im ersten Schritt einfach erstellt werden, um den generellen Ablauf Ihres Prozesses abzubilden. Das kann direkt durch eine Fachabteilung geschehen oder in Zusammenarbeit mit dieser. In einem weiteren Schritt kann dann der Workflow von der IT-Abteilung mit technischem Leben gefüllt werden, ohne dass die Fachabteilung damit belastet werden muss. Natürlich mag die ein oder andere Rücksprache nötig sein, wenn irgendein Schritt technisch so nicht möglich ist, aber im Allgemeinen funktioniert diese Trennung sehr gut.

Unser nächstes Beispiel ist an sich auch banal. Wir wollen hier zeigen, wie Entscheidungen getroffen werden können und dass es mehrere End-Zustände geben kann.

Die jeweils obere Transition erzeugt eine Zufallszahl zwischen 0 und 1. Ist die Zufallszahl größer als 0.5, gilt die Bedingung als erfüllt. Die obere Transition wird immer zuerst geprüft, weil sie eine höhere Priorität hat. Fällt die Prüfung negativ aus, wird die untere Transition geprüft und da diese keine Bedingung hat, greift sie dann immer.

Starten Sie den Workflow ein paar Mal und sehen Sie sich die unterschiedlichen End-Zustände an, die erreicht werden. Sehen Sie sich zudem die Log-Meldungen an. In der oberen Transition wird mit der Funktion log workflow message(a) jeweils die erzeugte Zufallszahl geloggt.

Import: (Anleitung)

Workflow_WF_automated_2.xml

Das folgende Beispiel zeigt eine Kombination der ersten beiden Beispiele.

Wir verwenden aber nur eine Transition, in der eine Zufallszahl generiert wird (also wie die jeweils obere Transition in Beispiel 2). Klappt das beim ersten mal nicht, startet die zyklische Transitionsprüfung (über die Wartezeit in den Zuständen) weitere Versuche, bis es klappt.

Starten Sie den Workflow ein paar Mal und warten Sie jeweils, bis die Jobs nicht mehr sichtbar sind. Sehen Sie sich danach die Log-Meldungen an.

Import: (Anleitung)

Workflow_WF_automated_3.xml

Der zyklische Retry über die Wartezeit ist eher für Situationen wie ein nicht erreichbares System gedacht. D. h. wir probieren es hier nicht wie verrückt hochfrequent erneut, sondern nach einer sinnvollen (intern festgelegten) Wartezeit. In unserem Beispiel können wir aber durchaus etwas flotter vorgehen, deswegen möchten wir das folgende Beispiel zeigen, in dem der Workflow praktisch auch sofort fertig ist, selbst wenn die Zufallszahl ein paar mal nicht das in den Bedingungen erforderte Ergebnis liefert. Die Transitionen in die Retry-Zustände haben jeweils eine niedrigere Priorität und greifen deshalb immer dann, wenn die Zufallszahl nicht den Bedingungen entspricht.

Import: (Anleitung)

Workflow_WF_automated_3_tuned.xml

Nun machen wir es uns ein bisschen schwerer. Statt in einer Transition eine Zufallszahl direkt zu generieren, rufen wir als Aktion in der ersten Transition ein Profil auf, in dem die Zufallszahl generiert wird.

Die Zufallszahl geben wir dann vom Profil aus zurück an die Workflow-Variable VAR_RANDOM und nutzen diese in den Bedingungen von Transition 2.

Starten Sie den Workflow ein paar Mal und sehen Sie sich danach die Log-Meldungen an. Im Tab Logs daneben finden Sie das als Aktion gestartete Profil.

Import: (Anleitung beachten!)

Profile-Generate_random_number_for_WF.pak (zuerst importieren)

Workflow_WF_automated_4.xml

Wenn wir hier nun einen Retry haben möchten, müssen wir etwas anders vorgehen als im ersten Beispiel 3, weil wir den Check ja erst nach der ausgeführten Aktion in der Transition davor durchführen können. Wir müssen also prinzipiell wie im zweiten Beispiel 3 vorgehen.

Import: (Anleitung beachten!)

Profile-Generate_random_number_for_WF_retry.pak (zuerst importieren)

Workflow_WF_automated_4_retry.xml

Dieses Beispiel ist aufgebaut wie Beispiel 4. Allerdings rufen wir hier das Profil Vertical_integration auf, das seinerseits in seiner Quellstruktur drei Sub-Profile aufruft (und um das Beispiel einfach zu halten, verwenden wir jeweils das selbe Sub-Profil für jeden der drei Aufrufe).

Jedes dieser Sub-Profile generiert eine Zufallszahl. Aus diesen drei Zufallszahlen erzeugen wir dann einen Durchschnittswert und geben diesen an den Workflow zurück.

Wir haben hier stark abstrahiert, um das Prinzip zu zeigen. Die Idee ist hier, dass Sie sich aus drei Quellen Daten holen (das können Dokumente sein oder Sensoren oder Kafka-KSQL-Abfragen (noch nicht verfügbar) oder was auch immer). Die Daten werden dann analysiert und das Ergebnis dieser Analyse entscheidet den weiteren Verlauf im Workflow. Die verwendeten Sub-Profile können also als dynamischer, gekapselter Self-Service-Zugang zu allen möglichen verteilten Systeme verstanden werden. Ihre Sub-Profil-Struktur ist das je nach Bedarf verbindende Gewebe, die Data Fabric.

Starten Sie den Workflow und sehen Sie sich danach die Log-Meldungen an. Im Tab Logs daneben finden Sie das als Aktion gestartete Profil.

Import: (Anleitung beachten!)

Profile-Generate_random_number_for_WF_2.pak (zuerst importieren)

Profile-Vertical_integration.pak (als Zweites importieren)

Workflow_WF_automated_5.xml

Hier ein kleiner Einblick in das Integrations-Profil. Sie sehen die Sub-Profil-Quellstruktur und in der Zielstruktur den Aufruf der Sub-Profile und die Kalkulation der durchschnittlichen Zufallszahl, die dann an den Workflow zurück gegeben wird.

Wenn wir hier nun einen Retry haben möchten, müssen wir vorgehen wie im zweiten Beispiel 4.

Import: (Anleitung beachten!)

Profile-Generate_random_number_for_WF_2_retry.pak (zuerst importieren)

Profile-Vertical_integration_retry.pak (als Zweites importieren)

Workflow_WF_automated_5_retry.xml

Siehe Abschnitt Zyklische Workflows.

Siehe Abschnitt Sub-Workflows.