Automatisierte Workflows (Beispiele)
Beispiel 1 (Durchlauf ohne Bedingungen)
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)
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.
Beispiel 2 (Entscheidungsbaum)
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)
Beispiel 3 (Durchlauf mit Bedingungen und Retry) (und Tuning-Variante)
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)
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.
Wichtiger Hinweis: Beachten Sie aber bitte, dass man gut über solche Konstrukte nachdenken sollte, um nicht unnötig die Performance zu belasten oder gar einen Speicher- oder Festplattenüberlauf zu erzeugen. Wir haben in die Transitionen zurück von den Retry-Zuständen eine wait-Funktion eingebaut, die hier zwar auf 0 Sekunden steht, aber bei Bedarf können Sie hier die Retries etwas drosseln.
Import: (Anleitung)
Workflow_WF_automated_3_tuned.obj
Beispiel 4 (Verwendung von Profilen) (und Retry-Variante)
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)
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.
Wichtiger Hinweis: Beachten Sie aber bitte, dass man gut über solche Konstrukte nachdenken sollte, um nicht unnötig die Performance zu belasten oder gar einen Speicher- oder Festplattenüberlauf zu erzeugen. Probieren Sie Profil-Aufrufe in einer Schleife immer zuerst auf Ihrem Test-System aus und setzen Sie die wait-Zeit in der Bedingung von Transition retry out hoch genug, damit Sie nicht zu viel Schaden anrichten können, wenn es einmal versehentlich zu einer Endlos-Schleife kommt. Sie werden Ihr System überlasten, wenn es zu hunderten oder tausenden Profil-Aufrufen kommt. Wenn Sie alles richtig machen, ist es aber kein Problem. Nur ein wenig Vorsicht bitte. Hinweis: Siehe auch Abschnitt Zyklische Workflows (→ Linearer Ausstiegspunkt). Hinweis: Verwenden Sie in einem solchen Konstrukt nie asynchrone Profile, sondern nur synchrone. Setzen Sie also nie die Checkbox Im Hintergrund ausführen.
Import: (Anleitung beachten!)
Profile-Generate_random_number_for_WF_retry.pak (zuerst importieren)
Workflow_WF_automated_4_retry.obj
Beispiel 5 (Vertikale Integration mit Sub-Profilen) (und Retry-Variante)
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)
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.
Wichtiger Hinweis: Beachten Sie aber bitte, dass man gut über solche Konstrukte nachdenken sollte, um nicht unnötig die Performance zu belasten oder gar einen Speicher- oder Festplattenüberlauf zu erzeugen. Probieren Sie Profil-Aufrufe in einer Schleife immer zuerst auf Ihrem Test-System aus und setzen Sie die wait-Zeit in der Bedingung von Transition retry out hoch genug, damit Sie nicht zu viel Schaden anrichten können, wenn es einmal versehentlich zu einer Endlos-Schleife kommt. Sie werden Ihr System überlasten, wenn es zu hunderten oder tausenden Profil-Aufrufen kommt. Wenn Sie alles richtig machen, ist es aber kein Problem. Nur ein wenig Vorsicht bitte. Hinweis: Siehe auch Abschnitt Zyklische Workflows (→ Linearer Ausstiegspunkt). Hinweis: Verwenden Sie in einem solchen Konstrukt nie asynchrone Profile, sondern nur synchrone. Setzen Sie also nie die Checkbox Im Hintergrund ausführen.
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.obj
