Einführung

Ein Workflow besteht aus mehreren Workflow-Schritten. Zwischen diesen bestehen verschiedene Arten von Abhängigkeiten, die festlegen, wann ein Schritt bearbeitet bzw. als abgeschlossen gekennzeichnet wird.

Die Schritte sind dabei in verschiedenen Ebenen angeordnet. Ein Schritt einer bestimmten Ebene kann dabei mehrere Schritte der darunterliegenden Ebene, die für sich gesehen einen eigenen Workflow - einen sogenannten Subworkflow - bilden, beinhalten. Ein solcher Schritt wird dann als Parent-Schritt oder kurz Parent des darunterliegenden Subworkflows bezeichnet. Der Subworkflow unter dem Parent-Schritt besteht dabei genau aus allen Schritten, die diesen Schritt als Parent-Schritt haben. Der Subworkflow kann dabei innerhalb des gesamten Workflows mehrmals durchlaufen werden, d.h. der Subworkflow ist zu einem bestimmten Zeitpunkt entweder aktiv oder inaktiv (siehe Abbildung und ). Die Steuerung der Abläufe des Subworkflows übernimmt der Parent-Schritt. In ihm wird entschieden, ob der Subworkflow unter ihm derzeit aktiviert werden muss, und es werden Parameter für den Subworkflow-Durchlauf festgelegt. Wird der Subworkflow aktiviert, so muss er i.a. selbst vollständig durchlaufen werden, bis er wieder inaktiv wird. Es besteht aber auch eine Abhängigkeit vom Subworkflow zum Parent zurück. Der Parent-Schritt selbst kann erst dann abgeschlossen werden, wenn der Subworkflow im Moment nicht mehr aktiv ist (Subworkflow-Abhängigkeit, siehe Abbildung ). Das Subworkflow-Konzept erlaubt Rekursion, d.h. ein Schritt in einem Subworkflow kann selbst wieder Parent-Schritt eines Subworkflows sein.

 

Abbildung:  aktiver Subworkflow

 

Abbildung:  inaktiver Subworkflow

Im folgenden wird der Subworkflow, in dem ein gegebener Schritt enthalten ist, der Subworkflow dieses Schrittes genannt. Davon zu unterscheiden ist der Subworkflow unter einem (Parent-)-Schritt. D.h. auch bei Parent-Schritten ist der Subworkflow dieses Parent-Schrittes der Subworkflow indem dieser enthalten ist und nicht der Subworkflow unter diesem Parent.

Zwischen Schritten eines bestimmten Subworkflows (auf der gleichen Workflow-Ebene) können nun sogenannte normale Abhängigkeiten bestehen. Ein Schritt hängt dabei von einem anderen Schritt (im folgenden Bedingungs-Schritt genannt) ab. Ein Schritt kann erst bearbeitet werden, wenn der Bedingungs-Schritt schon erledigt ist, d.h. die Abhängigkeit erfüllt ist (siehe Abbildung ). Es besteht hierbei die Möglichkeit pro Schritt festzulegen, dass diese Bedingung gelockert wird. Dann besagt die Abhängigkeit der beiden Schritte nur, dass der abhängige Schritt erst dann erledigbar ist, d.h. als abgeschlossen markierbar ist, wenn der Bedingungs-Schritt, erledigt ist (siehe Abbildung ). Der zuerst genannte Fall mit normalen Abhängigkeiten, die die Bearbeitungsmöglichkeit und nicht nur das als 'erledigt' Markieren eines Schrittes regeln, heißen strikte normale Abhängigkeiten.

 

Abbildung:  strikte normale Abhängigkeit

 

Abbildung:  nicht-strikte normale Abhängigkeit

Das Konzept der normalen Abhängigkeiten erlaubt aber nicht nur normale Abhängigkeiten zwischen Schritten des gleichen Subworkflows, sondern folgende Erweiterung: Ein gegebener Schritt kann normal abhängig von einem anderen Schritt sein, dessen Parent-Schritt (direkter oder) indirekter Parent-Schritt des gegebenen Schrittes ist. Dabei ist ein indirekter Parent-Schritt eines gegebenen Schrittes entweder dessen (direkter) Parent-Schritt selbst oder ein Parent-Schritt eines Schrittes, der schon ein indirekter Parent-Schritt des gegebenen Schrittes ist (parent, grandparent, grandgrandparent, ...: alle Parents rekursiv, siehe Abbildung ). Damit schließt die neue Möglichkeit für normale Abhängigkeiten zwischen Schritten, die ursprüngliche, nämlich im gleichen Subworkflow zu sein, ein. Es ist bei dieser allgemeineren Festlegung immer noch möglich festzustellen, ob eine normale Abhängigkeit erfüllt ist oder nicht, d.h. ob der Bedingungs-Schritt erledigt oder nicht erledigt ist. Dies wäre nicht der Fall, wenn der Subworkflow, in dem der Bedingungs-Schritt enthalten ist, gerade nicht aktiv ist. Ist nämlich ein Schritt aktiv, d.h. sein Subworkflow ist aktiv, so sind alle Subworkflows, in denen die indirekten Parents liegen, aktiv, und damit auch alle Schritte in diesen Subworkflows der indirekten Parents aktiv. Also ist auch der Bedingungs-Schritt aktiv.

 

Abbildung:  normale Abhängigkeit über Subworkflow-Ebenen hinweg

Als letzte Möglichkeit für eine Abhängigkeit von Schritten in einem Workflow gibt es die Loop-Abhängigkeit. Mit ihr sind Schleifen innerhalb eines Teiles eines Subworkflows (d.h. innerhalb der gleichen Workflow-Ebene) möglich. Dafür gibt es einen bestimmten Typ von Schritt, die Loop-Schritt. Von diesen aus besteht die Möglichkeit einen bestimmten Teil des Subworkflows, d.h. bestimmte, durch normale Abhängigkeiten verbundene Schritte des Subworkflows, die im aktuellen Durchlauf des Subworkflows bereits als erledigt markiert wurden, wieder als offen (als nicht vollständig erledigt, siehe Abbildung ) und damit als neu bearbeitbar zu kennzeichnen.

 

Abbildung:  Loop-Abhängigkeit

Insgesamt hat damit ein Schritt im Workflow zu einem Zeitpunkt genau einen der 3 Zustände 'inaktiv', 'offen' oder 'erledigt'. Er befindet sich im Zustand 'inaktiv', wenn sein Subworkflow nicht aktiv ist. Ist sein Subworkflow aber aktiv so kann ein Schritt im Zustand 'offen' oder 'erledigt' sein. Ist er dabei im Zustand 'offen', so muss er noch bearbeitet und erledigt werden. Bearbeitet werden kann er aber erst, wenn alle seine strikten Abhängigkeiten erfüllt sind. Erst nach Bearbeitung, kann er als erledigt markiert werden und damit in den Zustand 'erledigt' versetzt werden. Dabei kann der Schritt selbst entscheiden, ab wann die Möglichkeit besteht ihn hiermit abzuschließen. Diese Art der Abhängigkeit heißt innere Abhängigkeit eines Schrittes. Das Erfüllt- oder Nicht-Erfüllt-Sein dieser inneren Abhängigkeiten wird dabei selbst vom Schritt und nicht von der globalen Workflow-Steuerung geprüft.

Zusätzlich zu normalen Schritten, d.h. Schritten die keine spezielle Steuerungsmöglichkeit für den Workflow enthalten müssen, gibt es die bereits oben genannten Parent-Schritte, die Subworkflows unter ihnen steuern, und Loop-Schritte die Schleifen realisieren, sowie in einem Subworkflow die sogenannten End-Schritte, die es ermöglichen einen Subworkflow abzuschließen, d.h. ihn wieder inaktiv zu machen, wenn er komplett durchlaufen wurde.

Jeder Schritt im Workflow-System besteht selbst aus einem oder mehreren Modulen. Jedes dieser Module ist dabei in einer eigenen php-Datei implementiert und bekommt pro Schritt und Workflow, für das es aufgerufen wird, eigene Parameter. Ähnlich wie bei den Schritten selbst gibt es meherer Typen von Modulen, nämlich 'normal', 'parent', 'loop' oder 'end'. Jeder Schritt kann dabei Module vom Typ 'normal' enthalten. Aber nur ein Parent-Schritt kann Module vom Typ 'parent', nur ein Loop-Schritt kann Module vom Typ 'loop' und nur ein End-Schritt Module vom Typ 'end' enthalten. Diese Module vom Typ 'parent', 'loop' und 'end' haben einen komplexeren Aufbau (besondere Funktionen bzw. Funktions-Rückgaben) als die Module vom Typ 'normal' (normale Module), um die Workflow-Steuerungsfunktionen ihres Schrittes zu realisieren. Daher werden verschiedene Typen von Modulen unterschieden.

Jeder Workflow ist außerdem so aufgebaut, dass er auf der obersten Ebene nur aus einem Parent-Schritt mit einem Subworkflow darunter besteht, der den gesamten Workflow steuert bzw. zur Übersicht über den ganzen Workflow dient. Dieser Parent-Schritt wird daher im folgenden top-Schritt oder Übersichts-Schritt genannt.

Außer Workflow-Schritten kann ein Workflow noch sogennante Extrapages enthalten. Diese haben keinerlei Abhängigkeiten und können zu jeder Zeit im Workflow-Ablauf aufgerufen bzw. ausgeführt werden, z.B. um allgemeine Verwaltungsoperationen zu ermöglichen. Jede Extrapage kann dabei ähnlich wie ein Workflow-Schritt aus mehreren Modulen vom Typ 'normal' aufgebaut sein.