Zum Inhalt

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

  1. 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.

  2. ├ľ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

  1. 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.

  2. 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

  1. 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:

  2. 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.