Dieses Kapitel liefert einige Beispiele dafür geben, wie Workflow-Prozesse aufgebaut werden können, wie Sie parallele Handlungsstränge einbauen können und wie Benutzeraufgaben zu einer Ablehnung führen können.
Workflow-Modul Richtlinien:
Übergänge und Sequenzflüsse
Übergänge zwischen Prozessschritten werden im Diagramm auf Sequenzflüsse (Pfeile) gemappt. Das Mapping ist jedoch nicht in allen Fällen 1:1.
Dies sind die üblichen Arten von Übergängen:
Einzelner Übergang von einer Aufgabe zu einer anderen Aufgabe

Zwei Übergänge von einer Aufgabe, eine „Accept“ und eine “Reject”
Dies sind zwei Sequenzflüsse im Diagramm, die jedoch auf einen Übergang in der Datenbank gemappt sind. Sie teilen sich daher dieselbe Benutzerrolle, dieselbe Nachricht, denselben Mailversand, dieselben Voraussetzungen und Auswirkungen.

Parallelisierende und zusammenführende Übergänge mit nur einer Aufgabe im jeweiligen Strang
Dies sind zwei Sequenzflüsse im Diagramm, die jedoch auf einen Übergang in der Datenbank gemappt sind. Sie teilen sich daher dieselbe Benutzerrolle, dieselbe Nachricht, denselben Mailversand, dieselben Voraussetzungen und Auswirkungen.

Übergang zur zusammenführenden Aufgabe

Sequenzfluss der zu einem Abschluss-Event führt
Dieser Sequenzfluss besitzt keine Konfiguration, Voraussetzungen oder Auswirkungen.

Sequenzfluss der zu einer Parallelisierung führt
Dieser Sequenzfluss besitzt keine Konfiguration, Voraussetzungen oder Auswirkungen.

Mehrfache Parallelisierung und Zusammenführung
Ein ungültiger Fall im Workflow-Modul liegt vor, wenn ein Workflow „T1“ sich in zwei parallele Workflows „P1“ und „P2“ gabelt UND ein weiterer Workflow „T2“ sich ebenfalls in dieselben parallelen Workflows „P1“ und „P2“ verzweigt.
Dies führt zu einem ungültigen BPMN-Diagramm wie dem folgenden:

Das korrekte BPMN-Diagramm zu diesem Fall sieht so aus:

“P1” & “P1-2” können dieselbe Benutzerrolle besitzen, sodass die Benutzeraufgaben in dieselbe Workbox gehen.
Gleiches gilt für “P2” & “P2-2”.
Übliche Anwendungsfälle für Workflow-Prozesse
Workflow-Prozess ohne Benutzeraufgabe der durch ein Attribut ausgelöst wird
In diesem Workflow existiert nur ein Sequenzfluss der durch ein Attribut ausgelöst wird, hier repräsentiert durch ein „Start-Event“, eine Auswirkung hat und dann abgeschlossen wird, hier repräsentiert durch ein „End-Event“.

Workflow-Prozess mit zwei Benutzeraufgaben
Im folgenden Diagramm beinhaltet der Workflow ein “Start-Event”, zwei Benutzeraufgaben (Tasks) sowie ein “End-Event”.

Workflow-Prozess mit einer Parallelisierung und einer Zusammenführung
Dieses Diagramm enthält ein “Start-Event”, vier Benutzeraufgaben (Tasks) und ein “End-Event”.
“Task 1” teilt sich in die zwei parallelen Aufgaben “Parallel Task 1” & “Parallel Task 2”, beide vereinen sich in einer “Join Task” bevor das Diagramm mit einem “End-Event” abschließt.

Workflow-Prozess mit einer Ablehnung
Dieser Workflow enthält ein “Start-Event” und drei Benutzeraufgaben (Tasks).
“Task 1” führt bei Akzeptanz zu “Task 2”, bei Ablehnung zu “Reject Task 3”.
Um einen Übergang als Ablehnungsübergang (Reject) einzustellen, selektieren Sie diesen und aktivieren Sie den Schalter Reject flow.
