Unterprozesse¶

In BPM können Sie neben den im Activity Repository hinterlegten Aktivitätenvorlagen auch ganze Prozesse in einen Prozessschritt einbetten. Dadurch lassen sich große Prozesse kompakter darstellen und ihre visuelle Komplexität reduzieren. Im nächsten Bild enthält der Prozessschritt SubProcess einen Unterprozess.

Ein Unterprozess kann eine Sammlung von Aktivitäten (Prozessschritten) oder einen weiteren Unterprozess enthalten. Das führt zu einer hierarchischen Prozessstruktur, in der aber keine Zyklen erlaub sind. In der folgenden Abbildung finden Sie einen Unterprozess mit Ein- und Ausgabeparametern.

Ein Unterprozess wird wie ein normaler Prozess durch ein eigenes Prozessmodell beschrieben und wie bei Aktivitäten ebenfalls per Drag & Drop einem übergeordneten Prozess hinzugefügt. Er kann in der entsprechenden übergeordneten Prozessvorlage (Elternprozess) referenziert (referenced Prozess) oder eingebettet werden (Embedded-Prozess). Das führt dazu, dass die Unterprozessvorlage entweder als eigenständig (stand-alone) und außerhalb der übergeordnete Prozessvorlage verwaltet oder physisch in der übergeordneten Prozessvorlage integriert wird. Daher werden die referenced also stand-alone Vorlagen auf den AristaFlow Server geladen und vom Template Manager verwaltet, wobei die embedded Templates nur lokal gespeichert werden. Bei referenzierten Unterprozessen kann zusätzlich die Ausführung der entsprechenden Prozessinstanzen aufgespalten werden, wie bei einem Forked (gegabelt) Prozess der Fall ist. Dadurch laufen solche Prozessinstanzen unabhängig und vom übergeordneten Prozess entkoppelt, als wären sie separat gestartet worden.

Nach dem Einfügen öffnet sich ein Wizard-Fenster, in dem Sie den Typ des Unterprozesses embedded, referenced oder forked auswählen können. Sie können zwischen verschiedenen Formen der Einbettung eines Unterprozesses in den Hauptprozess sowie Ausführungsmodi wählen.

Unterprozesstyp: embedded, referenced, forked¶

Embedded: Um als embedded Prozess verwendet zu werden, muss die Unterprozessverwendung im Template-Status auf AS_COPY oder COPY_OR_REFERENCE gesetzt werden. Eine lokale Vorlage, die nicht auf den Server hochgeladen wird, darf nur als eingebettete Kopie eingefügt werden.
Referenced: Wenn der Template-Status des Unterprozesses auf AS REFERENCE oder COPY_OR_REFERENCE gesetzt ist, dann kann er vom Elternprozess referenziert werden. In beiden Fällen, embedded und referenced, wartet der Elternprozess, bis der Unterprozess nach dem Aufruf beendet ist.
- Der Unterschied zwischen embedded und referenced Typen besteht darin, dass der eingebettete Prozess beliebig vom übergeordneten Prozess geändert wird, wobei die Änderungen gleich nach dem Speichern übernommen werden. Dabei geht der Bezug zur Originalvorlage jedoch verloren, so dass die Änderungen von Elternprozess aus nicht auf die Originalvorlage des Uterprozesses übertragen werden. Bei referenzierten Prozessen muss dagegen der geänderte Unterprozess erneut referenziert werden.
Forked: Um als forked Prozess verwendet zu werden, muss das Template als Stand-alone-Prozess lauffähig sein, d.h. im Template-Status muss die Verwendung von TOP-LEVEL-PROCESS ausgewählt sein. Bei verzweigten (forked) Prozessen ist die Unterprozessverwendung nicht relevant (siehe folgendes Bild).
- Sowohl die referenzierten als auch die verzweigten (gegabelten) Prozesse können nur aus dem Template-Manager integriert werden. Bei der forked-Einfügung werden Eltern- und Kindprozess parallel ausgeführt und es entsteht eine parallele Verzweigung. Insofern ist forked kein gewöhnlicher Unterprozess, sondern ein aufgerufener Prozess, der parallel abläuft.

Template löschen

Wird eine Prozessvorlage nicht mehr verwendet, wird sie in den Zustand OUTDATED gesetzt. Dies entspricht logischerweise ihrer Löschung. Sie müssen jedoch auch die Vorlage auf nicht instanziierbar für die oberste Ebene (Top-Level Process Scope) und für die Benutzung als Unterprozess (Sub-Process Scope) setzen, wie in der folgenden Abbildung.

Ein weiterer Vorteil der Unterprozesse neben der Übersichtlichkeit in Vorlagen ist ihre Wiederverwendbarkeit. Ein Unterprozess gleich welcher Art kann wiederverwendet und von mehreren Hauptprozessen aufgerufen werden.

Parameter in Unterprozessen¶

Genauso wie Aktivitäten können auch Unterprozesse Ein- und Ausgabeparameter haben. Unterprozessknoten können nur auf die Datenelemente Ihrer eigenen Prozessvorlage und nicht die des übergeordneten Prozesses zugreifen. Der Elternprozess kann die Datenelemente jedoch an den Unterprozess übergeben. Dann werden alle diese Datenelemente zu Eingabeparametern des Subprozesses, die der Startknoten schreibt. Nach dem Schreiben der Eingabeparameter des Prozesses wird der Startknoten beendet und die normale Ausführung fortgesetzt. Auf diese Weise stehen die Werte der Eingabeparameter allen Prozessschritten des Unterprozesses über den normalen Datenfluss zur Verfügung. Ausgabeparameter sind dementsprechend alle Datenelemente, die der Endknoten liest. Die Ausführung des Endknotens in Unterprozessen beinhaltet noch das Schreiben der Ausgabeparameter im übergeordneten Prozess. Dementspechend stehen die Ausgabeparameter dem Elternprozess zur Verfügung.

Im vorherigen Bild schreibt der Elternprozess den Eingabeparameter inputString, der vom Unterprozess überprüft wird, und der Unterprozess schreibt den Ausgabeparameter outputString, der vom Elternprozess überprüft wird.

Bei forked Templates wird der entsprechende Knoten im Elternprozess jedoch auch unmittelbar nach dem Start der forked Prozessinstanz beendet und nicht erst, wenn die forked Prozessinstanz beendet ist. Offensichtlich können die Ausgabeparameter solcher Unterprozessinstanzen nicht im Elternprozess verwendet werden, da sie nur verzögert und asynchron zur Verfügung stehen.

SAR (Bearbeiterzuordnungsregel) im Unterprozess¶

Zusätzlich zu den normalen Ein und Ausgabe-Parametern von Aktivitäten und Unterprozessen gibt es spezielle Eingabeparameter für die Knoten (Systemparameter). Diese Parameter werden nicht für den Datenfluss im Prozess verwendet, sondern zur Versorgung von Knotenattributen, wie z.B. Bearbeiterzuordnungsregel.

Mit Hilfe dieser Parameter können Sie die Agent-ID vom übergeordneten Prozess an den Unterprozess übergeben, so dass die Schritte im Unterprozess vom gleichen Agent bearbeitet werden wie im Elternprozess. Im Folgenden zeigen wir Ihnen, wie Sie das umsetzen können. Dafür sind aber ein paar Tricks notwendig. Zum Beispiel benötigen wir einen Zwischenschritt, um die Agent-ID an den Unterprozess weiterzugeben, den wir später wieder löschen können.

Unterprozess mit parametrisierten SAR erstellen¶

Im Unterprozess erstellen Sie ein Datenelement für die Agent-ID, deren Wert später aus dem Elternprozess übergeben wird. Verbinden Sie das Datenelement mit dem Startknoten. Setzen Sie beim Anlegen des Datenelements den Wert für "Identifier" auf de.aristaflow.systemdata.NodePerformingAgent.
Öffnen Sie für den Prozessschritt Manueller Schritt Unterprozess den Dialog Staff Assignment Rule und wechseln Sie zu Manual Policy Editing. Geben Sie den folgenden parametrisierten Text als Policy ein:
Agent(id=%i:Agent-ID-Parameter%)
Setzen Sie im unteren Bereich Dependency Type auf Data Element und wählen Sie das neu erstellte Datenelement als Dependency Type Argument aus.

Eingabeparameter für Unterprozess im Eltern Prozess anlegen¶

Im übergeordneten Prozess benötigt der Unterprozess nun einen weiteren Eingabeparameter für dessen neues Datenelement Agent-ID vom Elternprozess. Der Parameter soll nun die ID des Agenten enthalten, der den Prozessschritt Manueller Schritt ausführt.

Dazu legen wir zunächst einen zusätzlichen Dummy-Schritt an, um an diese Daten heranzukommen.
Dann müssen wir die Agent-ID aus dem vorherigen Schritt Manueller Schritt übernehmen. Öffnen Sie dazu den Dialog Staff Assignment Rule für den Schritt Dummy und wählen den Agent aus, in dem Sie die ID vom NodePerforming-AgentID des Schrittes Manueller Schritt(...) unter dem Tab Conditions selektieren. Schließlich klicken Sie auf Add dependency.

Eingabeparameter mit Unterprozess verbinden¶

Im Hintergrund wurde nun ein Systemdatenfluss für die Agent-ID angelegt. Anschließend können Sie den Eingabeparameter für den Unterprozess mit dem Systemdatenelement NodePerforming-AgentID verbinden. Öffnen Sie dazu den Assistenten für den Unterprozess und verbinden Sie auf Seite 5 Parameter Mapping den Eingabeparameter mit dem Systemdatenelement wie in der nächsten Abbildung. Das Ergebnis sieht nun so aus:
Anschließend können Sie den Dummy-Schritt wieder löschen.

Das Datenelement NodePerforming-AgentID kann nun beliebig umbenannt werden (z.B. in Bearbeiter Elternprozess), um den Prozess verständlicher zu machen.