Sub-Workflows (Beispiele)
Ein Sub-Workflow ist einfach nur ein Workflow, der von einem anderen Workflow gestartet wurde.
Das ist an sich erst mal banal, aber man kann das auf zwei verschiedene Arten tun.
Asynchrone Sub-Workflows (automatisiert)
Sehen wir uns den folgenden einfachen Workflow an.
Wenn dieser Workflow gestartet wird, geht er automatisch in die Transition (die keine Bedingungen enthält). Dort wird ein Sub-Workflow gestartet.
Import: (Anleitung)
Workflow_WF_sub_wait.obj (zuerst importieren)
Hier der einfache Sub-Workflow. Wenn dieser gestartet wird, geht er ebenfalls automatisch in die Transition, wartet 60 Sekunden lang und beendet sich dann.
Wie ist das Verhalten des Eltern-Workflows?
Nachdem der Eltern-Workflow den Sub-Workflow gestartet hat, beendet er sich einfach, d. h. er wartet nicht auf die Beendigung des Sub-Workflows. Der Sub-Workflow beendet sich dann nach 60 Sekunden. Sie sehen den Eltern-Workflow also sofort in den Logs und den Sub-Workflow 60 Sekunden lang in den Jobs und danach erst in den Logs.
Synchrone Sub-Workflows (automatisiert)
Was kann also getan werden, wenn wir im Eltern-Workflow warten möchten, bis der Sub-Workflow beendet ist?
Direkt ist das im momentanen Workflow-Framework nicht vorgesehen, aber es gibt einen kleinen Trick, mit dem wir das erreichen können.
Import: (Anleitung)
Workflow_WF_sub_wait.obj (zuerst importieren)
Der erste Schritt ist wie beim asynchronen Beispiel, d. h. wir starten den Sub-Workflow (sie können den Sub-Workflow von oben verwenden).
Danach fügen wir aber einen Zustand mit automatischer Transitionsprüfung und Wartezeit ein, d. h. die folgende Transition wird initial und dann zyklisch bis zum Ende der Wartezeit geprüft.
In der Transition prüfen wir lediglich mit der Funktion workflow exists(a), ob es den Sub-Workflow noch gibt. Und nur wenn es ihn nicht mehr gibt, sind die Bedingungen der Transition erfüllt und der Eltern-Workflow beendet sich ebenfalls. Hinweis: Siehe auch Funktion is workflow in state(a,b).
D. h. Sie sehen für etwa 60 Sekunden beide Workflows in den Jobs (der Eltern-Workflow kann wegen der zyklischen Prüfung etwas länger laufen) und danach beide in den Logs.
Hinweis zu Variablen
Die Variablen des Eltern-Workflows werden an den Sub-Workflow übergeben (aber nicht alle). Im Sub-Workflow können die Variablen des Eltern-Workflows geändert werden, allerdings muss man dazu auf eine spezielle Art die ID des Eltern-Workflows übergeben werden, weil diese nicht direkt an den Sub-Workflow übergeben wird. Siehe dazu die Dokumentation der Funktion add/set workflow variable(a,b,c,d).
Warum Sub-Workflows?
Wenn Sie eine einfache/überschaubare Aufgaben zu lösen haben, besteht normalerweise keine Notwendigkeit Sub-Workflows einzusetzen. Es mag sogar einfacher sein, keine zu verwenden.
Wenn Sie aber mit einer komplexen Aufgabe konfrontiert sind, kann es Sinn machen, diese in Teil-Aufgaben zu zerlegen und evtl. diese wieder in Teil-Aufgaben. Das erleichtert die Modellierung, erhöht die Übersichtlichkeit und vereinfacht auch im letzten Schritt die technische Implementierung. (Zudem laufen die Sub-Workflows, wenn Sie mehrere anstoßen, parallel, was ein deutlicher Performance-Vorteil sein kann.)
Wenn hierbei auf der höchsten/gröbsten Ebene eine Teil-Aufgabe angestoßen wurde, wird es in manchen Fällen notwendig sein, erst weiter zu gehen, wenn die angestoßene Teil-Aufgabe erledigt ist. Und dafür können synchrone Sub-Workflows eingesetzt werden.
Sub-Workflows in Profilen
Bisher haben wir alles aus der Perspektive von Workflows betrachtet. Aber wir können das auch umdrehen, d. h. wir verwenden ein Profil und starten in diesem einen oder mehrere Workflows mit der Funktion start new workflow(a,b). Im Prinzip hat das Profil dann Sub-Workflows.
Siehe Abschnitt Profile als Workflow-Master.