Standard-Aufruf und Anzeige eines Workflow-Schrittes

 Der Standardfall ist $param[wf_step_position]=``Main'', der auch bei nicht gesetztem $param[wf_step_position] gewählt wird. Hier wird die HTML-Anzeige bzw. der Aufruf aller Module des Schrittes eingebettet in einen vorgegebenen Rahmen. In der Ausgabe erscheint zunächst der Name des Workflows, evtl. Warnungen über überschrittene Zeitfristen.

Darauf werden mit der Funktion 'wf_handle_parent_steps' aus 'lib-workflow-subworkflow.inc.php' der Reihe nach die indirekten Parent-Schritte - beginnend beim top-Schritt - des durch $param[wf_step] gegebenen Schrittes aufgerufen, um eine kurze Anzeige (bzw. evtl. Steuerung) des Zustands des unter ihnen liegenden Subworkflows zu ermöglichen. Es werden hier pro Parent-Schritt nur Module vom Typ ``parent'' (und nicht Module vom Typ ``normal'') verwendet, und zwar wird jeweils die Modul-Funktion ``head'' aufgerufen. Das Array $control_args für diese 'head'-Aufrufe der Parent-Module enthält dabei folgende Parameter:

• [step_nr:]Schrittnummer des jeweiligen Parent-Schrittes
• [parent_args:]Array, das Variablen enthält, die von den indirekten Parents dieses aufgerufenen Parents übergeben werden, beim Aufruf des top-Schrittes ist dieses Array leer.
• [output_off:]boolsches Flag, falls 'true' sollte Ausgabe auf Stdout während des Aufrufes des Parent-Moduls unterlassen werden, um von den Modulen des Schrittes selbst die Ausgabe bestimmen zu lassen. Ist in diesem Fall 'false'.

Die Rückgabe jeder 'head'-Funktion eines Parent-Moduls sollte ein Array sein, das folgende Parameter enthält:

• [parent_args:]Array von Variablenzuweisungen, die von diesem Parent an alle (rekursiven) Kinder (d.h. an darunterliegende Parents des Schrittes und den eigentlichen Schritt selbst) über $control_args[parent_args] (siehe oben) übergeben werden sollen. Das hier zurückgegebene Array wird dabei mit den bereits vorhandenen Variablendefinitionen der höheren Parents vereinigt (die beiden Arrays werden rekursiv ``gemerget'').
• [subworkflow_mode_old:]boolsches Flag, falls 'true', so wird dem Workflow-System angezeigt, dass hier nicht der aktuelle Durchlauf des unter dem Parent-Schritt liegenden Subworkflows bearbeitet wird, sondern ein ehemaliger, bereits abgeschlossener Durchlauf. Dann wird vom Workflow-System kein Workflow-Status (z.B. Schritt offen oder erledigt, Subworkflow aktiv oder nicht) unter diesem Parent-Modul angezeigt bzw. keine Möglichkeiten zur Änderung des Workflow-Status gegeben.
• [strict_subworkflow:]boolsches Flag, falls 'true', wird von diesem Parent bestimmt, dass Module in Schritten des Subworkflows darunter nur dann aufgerufen werden, d.h. Änderungen nur dann möglich sind, wenn dieser Subworkflow auch aktiv ist.

Erst nach den Parent-Schritten werden der Reihe nach alle Module des gegebenen Schrittes $param[wf_step] mit Modulfunktion ``main'' aufgerufen. Bei jedem dieser Aufrufe hat das Aufruf-Parameter-Array $control_args folgenden Inhalt:

• [step_nr:]Schrittnummer des Schrittes selbst
• [step_name:]Name des Schrittes, d.h. Wert des Attributes 'name' aus der Relation 'workflow_schritt'.
• [parents:]Liste der Schrittnummern aller indirekten Parents, vom direkten Parent bis zum top-Schritt.
• [isextrapage:]boolsches Flag, das hier stets 'false' ist, um anzuzeigen dass das Modul innerhalb eines Workflow-Schrittes und nicht einer Extrapage aufgerufen wird. Dies bedeutet z.B. auch, dass der Parameter 'step_nr' als Schrittnummer und nicht als Extrapagenummer zu interpretieren ist.
• [subworkflow_mode_old:]boolsches Flag, siehe Rückgabe der 'head'-Funktion eines Parent-Moduls oben.
• [strict_subworkflow:]boolsches Flag, das identisch mit dem 'strict_subworkflow'-Flag des direkten Parent-Schrittes ist (siehe Rückgabe der 'head'-Funktion eines Parent-Moduls oben).
• [parent_args:]Array, das Variablen enthält, die die Parent-Schritte über die 'head'-Funktion an die Module dieses Schrittes übergeben (siehe Rückgabe der 'head'-Funktion eines Parent-Moduls oben).

Der Aufruf der Module des Schrittes erfolgt aber nur, wenn bestimmte Bedingungen erfüllt sind. Damit kann man eine zu frühe Bearbeitung dieser Schritte verhindern:

Hierbei spielt eine Rolle, ob die Abhängigkeiten für einen Schritt selbst strikt sind oder nicht. Die Abhängigkeiten eines Schrittes sind strikt, falls das Attribut 'abhaengigkeiten_sind_strikt' aus der Relation 'workflow_schritt' für diesen Schritt 'true' ist oder falls der Parameter 'abhaengigkeiten_sind_strikt' in der Relation 'workflow_param' vorhanden und gleich 'true' ist. In diesem Fall werden die Module des Schrittes nur aufgerufen, falls der Subworkflow, zu dem dieser Schritt gehört, aktiv ist und alle normalen Abhängigkeiten des Schrittes erfüllt sind.

Weiterhin werden die Schritt-Module dieses Schrittes auch nur dann aufgerufen, wenn bei jedem der Parent-Schritte bereits alle deratigen strikten Abhängigkeiten erfüllt sind. Ist nämlich bei einem der Parents eine solche strikte Abhängigkeit (Abhängigkeiten für den Parent selbst sind strikt und zugleich der Subworkflow in dem dieser sich befindet, nicht aktiv oder existieren unerfüllte, normale Abhängigkeiten für den Parent) nicht erfüllt, so wird bereits dessen 'head'-Funktion und auch die 'head'-Funktion aller darunterliegender Parents nicht mehr ausgeführt.

Jeder Parent-Schritt, d.h. jedes Parent-Modul eines Parents, hat darüberhinaus die Möglichkeit, das Aufrufen von Schritt-Modulen des darunterliegenden Subworkflow zu verbieten, falls der Subworkflow nicht aktiv ist. Dazu kann in der Rückgabe der 'head'-Funktion des Parent-Moduls der Parameter 'strict_subworkflow' auf 'true' gesetzt werden.

Damit werden die Schritt-Module des Schrittes selbst nur dann aufgerufen, wenn eine der folgenden Bedingungen erfüllt ist:

• Einer der Parents setzte das Flag 'subworkflow_mode_old' in seiner Rückgabe auf 'true' und kündigte damit an, dass Module von Schritten des Subworkflows darunter nicht auf Daten des evtl. gerade aktiven Subworkflow-Durchlaufes zugreifen, sondern nur zum Nach-Bearbeiten eines früheren Durchlaufes aufgerufen werden.
• Das Flag 'subworkflow_mode_old' ist 'false' (d.h. normale Bearbeitung des evtl. gerade aktiven Durchlaufes des Subworkflow dieses Schrittes), bei keinem Parent gibt es unerfüllte strikte Abhängigkeiten, der Subworkflow des Schrittes ist nicht aktiv, aber der direkte Parent setzte das Flag 'strict_subworkflow' auf 'false' und für den Schritt selbst sind die eigenen Abhängigkeiten nicht strikt.
• Das Flag 'subworkflow_mode_old' ist 'false' (d.h. normale Bearbeitung des evtl. gerade aktiven Durchlaufes des Subworkflows dieses Schrittes), bei keinem Parent gibt es unerfüllte strikte Abhängigkeiten, der Subworkflow dieses Schrittes ist aktiv und alle normalen Abhängigkeiten dieses Schrittes sind erfüllt oder für den Schritt selbst sind die Abhängigkeiten nicht strikt.

Während seiner Ausführung kann ein Modul praktisch beliebige Dinge tun, vor allem sollte es aber ggf. Datenbank-Operationen durchführen und eine passende Ausgabe auf Stdout erzeugen.

Um innere Abhähngigkeiten (im Schritt selbst) zu realisieren, dient die globale Variable $param[intern_conditions_not_satisfied]. Jedes Modul des Schrittes hat die Möglichkeit den Wert dieser Variable auf 'true' zu setzen, um dem Workflow-System so mitzuteilen, dass in diesem Schritt noch unerfüllte, innere Abhängigkeiten vorhanden sind, und er somit noch nicht als 'erledigt' gekennzeichnet werden kann.