Zusammenfassung
Bei Process-aware Information Systems (PAIS) ist manchmal ein flexibles Abweichen vom starr vormodellierten Geschäftsprozess notwendig. So sollen Benutzer in Ausnahmesituationen oder zur Korrektur von Fehlern im Prozess vor- und zurückspringen können. Dieses Thema wurde bisher in der wissenschaftlichen Literatur kaum betrachtet und ist in kommerziellen Prozess-Engines nur unzureichend umgesetzt. Deshalb werden hierzu in diesem Beitrag sehr umfassende Anforderungen dargestellt und eine formale Ausführungssemantik zur Realisierung von Sprüngen zur Ausführungszeit (Runtime) der Prozesse entwickelt. Diese berücksichtigen nicht nur (simple) Vor- und Rückwärtssprünge innerhalb von Sequenzen, sondern auch parallel ausgeführte Zweige und Schleifen. Zudem ist das Verhalten übersprungener Aktivitäten zur Modellierungszeit (Buildtime) konfigurierbar. So können diese nachgeholt werden oder die Ergebnisse (Output-Daten) ihrer früheren Bearbeitung bleiben erhalten.
This is a preview of subscription content, log in via an institution to check access.
Notes
Es wurde mit folgenden Suchbegriffen, jeweils in Kombination mit jump, gesucht: business process, workflow und „process engine“. Außerdem wurde nach „forward jump“ sowie „backward jump“ in Kombination mit process gesucht.
Dies gilt generell: Wird für eine Akt. a der RepeatMode(a) = Discard festgelegt, so macht ausschließlich der ContinueMode(a) = Abort Sinn, weil die Output-Daten der Akt. a bei ihrer späteren erneuten Ausführung ohnehin nicht berücksichtigt werden.
Außerdem werden, wie bereits in Abschnitt 3.1 beschrieben, Benutzer-Berechtigungen zur Sprungauslösung, etc. definiert. Die Anforderungen A1 bis A6 gelten also auch im Zusammenspiel mit Parallelitäten.
Wenn die Ausführung einer Kompensationsaktivität fehlschlägt, so kann diese (ggf. nach einer gewissen Wartezeit) erneut versucht werden. Schlagen auch diese Versuche fehl, so hat die Prozess-Engine keine andere Möglichkeit, das trotzdem in den Zustand Compensated zu wechseln, damit die Ausführung der Prozessinstanz fortgesetzt werden kann.
Successor*(x) berechnet die im Kontrollfluss indirekt (d. h. transitiv) auf x folgenden Aktivitäten (ohne Berücksichtigung von Schleifenkanten). Predecessor*(x) berechnet die indirekt vor x gelegenen Aktivitäten. Entsprechende Funktionen werden ohnehin für die reguläre Ausführungssemantik (Abschnitt 4.1) benötigt.
Im Falle von State(v)=Failed und bei Join-Knoten hängt es wieder von dem im Einzelfall festgelegten Ausführungsverhalten ab, ob State(a) tatsächlich (bereits) geändert wird (vgl. Abschnitt 4.1). Dies soll hier nicht weiter betrachtet werden, da dies unabhängig von Sprüngen ist.
Auch hier muss bei einer Akt. n mit Join-Semantik (d. h. mehrere eingehende Kontrollfluss-Kanten) das im Einzelfall festgelegten Ausführungsverhalten berücksichtigt werden.
Damit Ergebnisdaten zum Kontrollieren vorhanden sind, muss die Akt. a zuvor beendet worden sein (State(a) = Completed). Da die Ergebnisdaten aber ohnehin kontrolliert und ggf. angepasst werden, sollen sie auch verwendet werden, wenn Akt. a zuvor fehlerhaft beendet wurde (State(a) = Failed).
Dieses Flag wird nach Beendigung jeder Aktivität auf false zurückgesetzt, so dass eine möglicherweise stattfindende spätere erneute Ausführung (z. B. innerhalb einer Schleife) regulär erfolgt.
Literatur
Reichert M, Weber B (2012) Enabling flexibility in process-aware information systems: challenges, methods, technologies. Springer, Berlin, Heidelberg
Bauer T (2017) Anforderungen an vormodellierte Flexibilität für den Kontrollfluss von Geschäftsprozessen. Proc. Informatik 2017, Workshop zum Stand, den Herausforderungen und Impulsen des Geschäftsprozessmanagements, Chemnitz, S 799–813
Bauer T (2018) Vormodellierte Flexibilität für Geschäftsprozesse. Proc. Modellierung 2018, Workshop Requirements Engineering and Business Process Management, S 201–213
Russell N, ter Hofstede A (2006) Workflow control-flow patterns: a revised view. BPM center report BPM-06-22
Reichert M, Dadam P, Bauer T (2003) Dealing with forward and backward jumps in workflow management systems. Softw Syst Model 2(1):37–58
Reichert M (2000) Dynamische Ablaufänderungen in Workflow-Management-Systemen. Dissertation, Universität Ulm, Fakultät für Informatik
Weske M (2007) Business process management—concepts, languages, architectures. Springer, Berlin, Heidelberg
IBM (1996) FlowMark—Programming Guide, Version 2 Release 2, Document Number: SH19-8240-01
IBM (2014) WebSphere process server knowledge center. https://www.ibm.com/support/knowledgecenter/SSQH9M_7.0.0
IBM (2017) Business process manager. https://www.ibm.com/support/knowledgecenter/en/SSFPJS_8.6.0
Bauer T (2017) Vormodellierte Flexibilität in Prozess-Management-Systemen: Anforderungen, Vorgehensweisen, Lösungsansätze. Technical Report. HNU Working Paper 37
Management Group (2011) Business Process Model and Notation (BPMN) 2.0. http://www.omg.org/spec/BPMN/2.0. Zugegriffen: 29.6.2018
Reichert M, Kolb J, Bobrik R et al (2012) Enabling personalized visualization of large business processes through parameterizable views. Proc. 27th Symposium On Applied Computing, Trento, S 1653–1660
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
About this article
Cite this article
Bauer, T. Ausführungssemantik für Sprünge in Geschäftsprozessen. Datenbank Spektrum 18, 99–111 (2018). https://doi.org/10.1007/s13222-018-0291-z
Received:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s13222-018-0291-z