| XML-Element: | schritt | DB-Relation: | workflow_schritt |
| XML-Attribute: | [workflow] | DB-Attribute: | workflownummer |
| nummer | schrittnummer | ||
| name | name | ||
| typ/[typ2] | typ | ||
| [vorgaenger] | voriger_schritt | ||
| [nachfolger] | naechster_schritt | ||
| [sub_anfang] | erster_subschritt | ||
| [sub_ende] | letzter_subschritt | ||
| [vater] | parent_schritt | ||
| erklaerung | erklaerung | ||
| abhaengigkeiten_sind_strikt | abhaengigkeiten_sind_strikt | ||
| status | status | ||
| subworkflow_aktiv | subworkflow_aktiv | ||
| durchlaufnummer | durchlaufnummer | ||
| erledigt_datum | erledigt_datum | ||
| frist_datum | frist_datum | ||
| bemerkung | bemerkung | ||
| subworkflow_nummer_prefix |
Hiermit sind die Schritte des neuen Workflows definierbar. Das Attribut
``nummer'' ist ein (kurzer) String, der den Schritt eindeutig
identifiziert. Es wurde String, und nicht etwa Integer, als Datentyp
gewählt, um hierarchische Nummerierung wie z.B. 2.5.1 (für Subworkflow-Hierarchien)
zu ermöglichen.
Die Nummern können weitgehend automatisch (in hierarchischer Form) generiert werden. Es sollte jedoch stets einen obersten top-Schritt geben, dessen Nummer im Konfigfile angegeben werden muss. Dieser oberste Schritt dient einerseits der Strukturierung und seine Schrittseite dient der Übersicht über den gesamten Workflow. Damit ``workflow.php'' später diesen Schritt kennt, sollte er im Moment stets den Namen ``top'' erhalten.
Kinder-Schritte innerhalb eines Subworkflows erhalten bei Nicht-Angabe
der Nummer automatisch die Nummer des Parent-Schrittes konkateniert
mit einem ``.'' und einer Nummer entsprechend ihrer Reihenfolge
im Subworkflow. Es besteht aber mit dem speziellen XML-Attribut ``subworkflow_nummer_prefix''
im XML-Element des Parent-Knotens die Möglichkeit, ein anderes Präfix
statt der Nummer des Parents verknüpft mit dem String ``.''
für den automatischen Schrittnamen zu wählen. Z.B. wird man i.d.R.
im top-Schritt subworkflow_nummer_prefix='''' (leerer String)
benutzen, um auf der eigentlich obersten Workflow-Ebene nur einfache
Nummern, wie z.B. ``1'', für die Schritte und nicht etwa ``top.1''
zu erhalten.
Die automatische Nummerierung der Schritte bereitet allerdings ein
Problem: Schrittnummern identifizieren einen Schritt, z.B. werden
beim Definieren einer Abhängigkeit zwischen zwei Schritten die Schrittnummern
angegeben. Da also beim Erstellen der Konfiguration für das Festlegen
von z.B. Abhängigkeiten die Schrittnummern benötigt werden, gibt es
ein Konzept, um einem bestimmten Attribut eines bestimmten Elementes
im XML-Baum, dessen Wert noch nicht bekannt ist (da er erst später
vom Erstell-Skript automatisch hinzugefügt wird), einen globalen Alias-Namen
(unabhängig vom gegebenen Element bzw. Attribut) zuzuordnen. Statt
den Wert des XML-Attribut des jeweiligen XML-Elements explizit anzugeben,
gibt man (im XML-Element) statt dessen ein XML-Attribut mit Namen
``alias:<aliasname>'' und dem Name des zu repräsentierenden
Attributs als Wert an. Z.B. definiert alias:anmeldung=''nummer''
als Attribut in einem bestimmten Schritt-Element den Alias ``anmeldung''
für das (zukünftige) Attribut ``nummer'' des bestimmten Schritt-Elementes.
Für ein gewöhnliches XML-Attribut, in dessen Wert ein solcher Alias
vorkommen und (später) ersetzt werden soll, wird statt dem normalen
Namen des XML-Attributs der Name ``aliased:<gewöhnlicher Attributname>''
verwendet und im Wert des Attributs kann dann ein Alias mit ``@(<aliasname>)''
referenziert werden. Z.B. würde für die XML-Attribut-Zuweisung aliased:schritt=''@(anmeldung)''
innerhalb eines beliebigen Abhängigkeits-Elements irgendwo innerhalb
des XML-Baumes (falls der Alias wie im obigen Beispiel definiert wäre)
der String ``@(anmeldung)'' im Attribut ``schritt'' der
Abhängigkeit durch das später erstellte Attribut ``nummer''
des Schritt-Elements aus dem vorigen Beispiel ersetzt werden. So kann
man Abhängigkeiten von Schritten im XML-File angeben, ohne die später
automatisch errechnete Nummer des Schrittes zu kennen.
``name'' ist ein String, der als kurzer Titel für den Schritt
steht.
Das Attribut ``typ'' hat als mögliche Werte ``normal'', ``parent'' (Parent-Schritt eines Subworkflows), ``end'' (Subworkflow-Ende) oder ``loop'' (Schleifenbildungs-Schritt). Bei einem Schritt, der ein subworkflow-Element (s.u.) als Kind hat, bei einem Schritt, der ein workflow_schleifenstart-Element als Kind hat oder einem normalen Schritt muss das Attribut nicht mitangegeben werden. Somit ist i.a. nur ein Schritt mit typ=''end'' als Subworkflow-Ende zu kennzeichnen.
Das Attribut ``typ2'' wird nur intern verwendet, um ``typ'' -Werte auf die Attributs-Werte in der Datenbank abzubilden.
Die (Darstellungs-)Reihenfolge der Schrittseiten (die ``Navigierungs-Reihenfolge `` der Schrittseiten als Web-Seiten ), die völlig unabhängig von den (normalen) Abhängigkeiten zwischen den Schritten ist, wird durch die Attribute ``vorgaenger'' und ``nachfolger'' beschrieben. Diese werden i.a. aber automatisch durch die Nummern der Schritte, die im schritt-Element vor bzw. nach diesem schritt-Element definiert sind, ersetzt, falls nicht angegeben.
Bei einem Parent-Schritt eines Subworkflows werden mit den Attributen ``sub_anfang'' und ``sub_ende'' der Navigations-Beginn (1. Seite) bzw. das Navigations-Ende (letzte Seite) eines Subworkflows spezifiziert. Auch sie müssen nicht mit angegeben werden, sondern werden aus der Verschachtelungsstruktur des subworkflow-Elementes unter dem schritt-Element, das als Container für die schritt-Elemente des Subworkflows dient, bestimmt.
Der Parent-Schritt des Subworkflows, zu dem der aktuell beschriebene Schritt gehört, wird durch das Attribut ``vater'' beschrieben und kann auch aus der Struktur automatisch erkannt werden.
``erklaerung'' ist ein String, der auf der jeweiligen Schrittseite mit angezeigt wird, um dem Benutzer eine kurze Beschreibung des Schrittes zu geben.
Um festzulegen, ob die Abhängigkeiten des Schrittes strikt sein sollen, d.h. der Schritt erst bearbeitbar (nicht nur erledigbar) sein soll, wenn alle Abhängigkeiten erfüllt sind, oder nicht , enthält das Attribut ``abhaengigkeiten_sind_strikt'' entsprechend ``1'' oder ``0'' als boolschen Wert.
``status'' hat als mögliche Werte ``offen'' oder ``erledigt''. Beim Anlegen eines Workflows ist i.a. nur ``offen'' sinnvoll, was auch bei Nicht-Angabe dieses Attributs als default genommen wird.
Bei Parent-Schritten gibt ``subworkflow_aktiv'' als boolscher Wert (``0'' oder ``1'') an, ob der Subworkflow unter dem Parent-Schritt aktiv ist. Auch hier ist meist nur ``0'' sinnvoll, was auch der Standardwert ist.
Ähnliches gilt für ``durchlaufnummer'', das die Anzahl Durchläufe eines Subworkflows unter einem Parent-Schritt oder einer Schleife eines Schleifenbildungsschrittes zählt. Es hat als default-Wert ``0''.
Auch das ``erledigt_datum'' muss nicht spezifiziert sein, da i.a bei einem neuen Workflow noch kein Schritt erledigt ist. Das ``frist_datum'' dagegen kann , vor allem für Schritte direkt unterhalb vom top-Schritt, falls gewünscht als SQL-Timestamp (z.B. 2001-09-08), angegeben werden.
Das Attribut ``bemerkung'' steht für den Wert der Bemerkung
(eine Art Notiz-Funktion) zu einem Schritt. Dieser wird später stets
auf der Schrittseite angezeigt und kann geändert jederzeit werden.
Bei Bedarf kann hiermit ein String für den initialen Wert angegeben
werden.
Das subworkflow-Element dient nur der Strukturierung im XML-File und hat selbst keine Entsprechung in der Datenbank (zumindest nicht als ein einzelner Tupeleintrag innerhalb einer Tabelle). Es kennzeichnet die Zugehörigkeit der in ihm enthaltenen Schritte zu einem Subworkflow. Es selbst ist Kind des Schritt-Elements des Parent-Schrittes. Da die Implementierung nicht mehrere, verschiedene Subworkflows unter einem Parent-Schritt ermöglicht, hätte man es auch in der Definition des Konfigformats weglassen können.