Zwei Varianten eines Prozesses mit der Nachbildung eines Screenflows mit Alternativen, einmal komplett in einem Prozessmodell, im anderen Fall ist der Screenflow in einen Aufrufprozess ausgelagert. Die Prozesse werden im Buch im Abschnitt 6.3 erläutert.
Download
Kurs buchen Scrfl-1.0.bos
Kurs buchen Scrfl-2.0.bos
Voraussetzungen
- Bonita BPM Community Edition installiert. Die Prozesse wurden mit Version 6.2.3 getestet. Andere Versionen ab 6.1 sollten in der Regel aber auch funktionieren.
- Organisationsstruktur „BPMSOrga“ auf dem Bonita Server veröffentlicht (Anleitung hier).
Verwendete Features von Bonita
- Sequenzfluss, Start- und Endereignis, Benutzer-Task, Prozessvariable, Formulare für Benutzertasks
- Exklusiver Gateway, Default-Fluss
- Vorgang (Setzen von Variablenwerten am Ende der Ausführung eines Tasks), Groovy-Skript
- Dynamische Label und Beschreibungen im Portal
- Verschiedene Interaktionselemente, Validierungen, Eingabehilfen, mehrseitiges Formular, bedingt eingeblendete Interaktionselemente, Schaltflächen mit Aktionen
- Akteurfilter
- Einbindung Javascript
- Aufrufaktivität, Aufruf eines anderen Prozesses, Datenmapping (im zweiten Beispiel)
Anleitung
- Datei downloaden und abspeichern, in Bonita Studio importieren, ausführen.
- Hat man in „Allgemeine Daten erfassen“ Präsenzkurs gewählt, so wird man nach Abschluss direkt zum Task „Daten Präsenzkurs erfassen“ weitergeleitet, ohne dass man diesen Task explizit aufrufen muss. Entsprechend gelangt man nach Auswahl des Online-Kurses zum Task „Daten Online-Kurs erfassen“.
Hinweise
- Im ersten Prozess sind die drei ersten Tasks, die eigentlich einen Screenflow abbilden sollen, ohne Aufrufaktivität direkt im Prozess modelliert. Normalerweise landet man nach Abschluss eines Tasks zunächst auf einer Bestätigungsseite, auf der man den nächsten Schritt auswählen kann. Dies unterbricht den nahtlosen Screenflow. Daher wurde die von Bonita bereitgestellte HTML-Datei bonita_auto_redirect_confirm.html (Download unter http://community.bonitasoft.com/projects/automatic-confirmation-template) eingebunden, die dafür sorgt, dass der Dialog des nächsten Tasks direkt ohne zusätzlichen Mausklick eingeblendet wird, wenn es sich um denselben Benutzer handelt. Die HTML-Datei wird in dem Task unter „Anwendung / Bestätigung“ als „Bestätigungslayout“ eingetragen („Bestätigungsmeldung“ kann ein beliebiger Text sein, z. B. „Bitte warten“). Über Akteur-Filter wird der Task „Daten Präsenzkurs erfassen“ bzw. „Daten Online-Kurs erfassen“ genau demjenigen Benutzer zugeordnet, der „Allgemeine Daten erfassen“ ausgeführt hat.
- Im zweiten Prozess ist „Buchungsdaten erfassen“ zu einer Aktivität zusammengefasst, die Details des Screenflows sind in einem aufgerufenen Prozess modelliert.
- Eigentlich müsste man nach dem Rücksprung auch wieder dafür sorgen, dass derselbe Benutzer zugeordnet wird. Das wurde hier weggelassen, so dass nach dem Rücksprung der Task „Allgemeine Daten erfassen“ bei jedem Benutzer erscheint, wenn der aktive Benutzer den Task abbricht und über „Release“ freigibt. Die Problemstellung ist vergleichbar der in „Beschaffungsantrag Eink eind“ beim Task „Beschaffungsantrag auf Vollständigkeit prüfen“ und könnte im allgemeinen Fall mit einem vergleichbaren Akteur-Filter gelöst werden. Da es sich im vorliegenden Fall um den ersten Task handelt, könnte man hier auch – wesentlich einfacher – den Prozessinitiator zuordnen.
- Da man nach „Daten Präsenzkurs erfassen“ bzw. „Daten Online-Kurs erfassen“ auch wieder innerhalb des Screenflows zurückspringen können soll, wurde auch bei diesen Tasks das Skript eingebunden. Daher wird nach Abschluss der Datenerfassung anschließend auch der nächste Task „Buchung prüfen“ sofort ohne die zwischengeschaltete Bestätigungsseite angezeigt. Normalerweise würde man die Prüfung aber von einem anderen Mitarbeiter ausführen lassen. Dieser erhält den Task ganz gewöhnlich in seine Taskliste.
Benutzer
Der Prozess kann von jedem Benutzer aus BPMSOrga gestartet werden.
Passwort für alle Benutzer: bpm