| ... |
... |
@@ -1,3 +1,5 @@ |
|
1 |
+WIP |
|
2 |
+ |
| 1 |
1 |
{{content/}} |
| 2 |
2 |
|
| 3 |
3 |
{{id name="fig_workflow_overview"/}} |
| ... |
... |
@@ -16,8 +16,7 @@ |
| 16 |
16 |
|
| 17 |
17 |
== Workflowgraph == |
| 18 |
18 |
|
| 19 |
|
-Der //Workflowgraph// stellt das Herzstück des Workflowdesigners dar, mit welchem die Verarbeitung eines Formulars grafisch repräsentiert wird und bearbeitet werden kann. Der Beginn einer jeden Verarbeitung ist mit dem {{formcycle/}}-Symbol markiert: |
| 20 |
|
-[[image:workflow_start.png]] |
|
21 |
+Der //Workflowgraph// stellt das Herzstück des Workflowdesigners dar, mit welchem die Verarbeitung eines Formulars grafisch repräsentiert wird und bearbeitet werden kann. Der Beginn einer jeden Verarbeitung ist mit dem {{formcycle/}}-Symbol markiert. [[image:workflow_start.png]] |
| 21 |
21 |
Der Workflow ist von oben nach unten zu lesen und besteht aus einzelnen //Verarbeitungsketten//. Jede Verarbeitungskette beginnt mit einem [[Ereignis>>||anchor="sec_elements_events"]], welches diese auslöst. Beispielsweise kann der Klick auf einen bestimmten Button im Formular eine Verarbeitungskette starten, in welcher eine [[E-Mail>>doc:Formcycle.Designer.Workflow.Actions.EMail.WebHome]] an den Antragsteller gesendet wird. Wie man an diesem Beispiel sieht, werden innerhalb von Verarbeitungsketten [[Aktionen>>||anchor="sec_elements_actions"]] ausgeführt. Diese Verarbeitungsketten können komplexer werden und sich zum Beispiel abhänging von den Formulareingaben aufsplitten. Diese Abzweigungen werden über [[Bedingungen>>doc:Formcycle.Designer.Workflow.FlowControl.Condition.WebHome]] realisiert. So kann beispielsweise der Workflow so konfiguriert werden, dass eine E-Mail nur dann versendet wird, wenn der Antragsteller auch eine E-Mail angegeben hat. Wenn dies nicht der Fall ist, kann zum Beispiel ein PDF des Formulars erstellt und dieses dem Antragsteller zurückgegeben. Wie man sieht führen Bedingungen dazu, dass sich eine Verarbeitungskette in zwei //Teilverarbeitungsketten// aufteilt. Jede Verarbeitungskette muss in einem [[Endpunkt>>||anchor="sec_elements_endpoints"]] enden. In der Regel ist ein solcher Endpunkt ein [[Status>>doc:Formcycle.Designer.Workflow.States.WebHome]], in dem sich der Vorgang nach Ausführung der Verarbeitung befinden soll. Im Fall von Bedingungen werden die dadurch entstandenen Teilverarbeitungsketten nach Ausführung der geünschten Aktionen wieder zusammen geführt (siehe [[Abbildung>>||anchor="fig_workflow_example_submit"]]). Jede Teilverarbeitungskette kann allerdings auch einen eigenen Endpunkt definieren. Das hier vorgestellte Beispiel ist in der [[Abbildung>>||anchor="fig_workflow_example_submit"]] als Verarbeitungskette im Arbeitsbereich des Workflowdesigner dargestellt. Treffen mehrere Ereignisse gleichzeitig zu, werden die entsprechenden Verarbeitungsketten der Reihe nach von links nach rechts ausgeführt. |
| 22 |
22 |
|
| 23 |
23 |
{{id name="sec_graph_default"/}} |
| ... |
... |
@@ -204,10 +204,8 @@ |
| 204 |
204 |
|
| 205 |
205 |
Sowohl im neuen Workflow als auch in der alten [[Status- & Aktionsverarbeitung>>doc:Formcycle.Designer.Workflow.LegacyWorkflow.WebHome]] gibt es Status. Vorgänge können in beiden Workflows einen Status annehmen. In der alten Status- und Aktionsverarbeitung werden Verarbeitungsketten in den einzelnen Status definiert. Zustandsabhängige Entscheidungen können über Bedingungen an den Aktionen realisiert werden, insbesondere unter Verwendung der Aktion //Statuswechsel//. Verarbeitungsketten werden also über Status ausgelöst. Im neuen Workflow sind Status lediglich Endpunkte. Status beschreiben den Zustand eines Vorgangs und definieren, wer auf disesen Zugriff hat, mehr nicht. Verarbeitungsketten werden über Ereignisse und nicht mehr über Status ausgelöst. Zudem sind die Status des neuen Workflows mit der Formularversion versioniert, d.h. jede Formularversion kann unterschiedliche Status besitzen. Der Status //Eingegangen// ist der Standardstatus und kann weiterhin nicht gelöscht und auch nicht mehr umbenannt werden. |
| 206 |
206 |
|
| 207 |
|
-{{velocity}} |
| 208 |
|
-##== TODO auf Unterseiten == |
| 209 |
|
-## |
| 210 |
|
-##* Aktionen des neuen WF sollten immer auch auf die alten verlinken und umgekehrt. |
| 211 |
|
-##* Bei den Aktionen sollte immer auch im ersten Satz stehen, in welcher Gruppe sie sind |
| 212 |
|
-##* Bei Legacy Aktionen sollte dies gernerell darüber stehen in einem Hinweisfeld. Die Aktionen , welche schon in der Version 6 deprecated waren, sollten dies dann extra im Text erwähnt bekommen. |
| 213 |
|
-{{/velocity}} |
|
208 |
+== TODO auf Unterseiten == |
|
209 |
+ |
|
210 |
+* Aktionen des neuen WF sollten immer auch auf die alten verlinken und umgekehrt. |
|
211 |
+* Bei den Aktionen sollte immer auch im ersten Satz stehen, in welcher Gruppe sie sind |
|
212 |
+* Bei Legacy Aktionen sollte dies gernerell darüber stehen in einem Hinweisfeld. Die Aktionen , welche schon in der Version 6 deprecated waren, sollten dies dann extra im Text erwähnt bekommen. |
