event handling in business processes
TRANSCRIPT
E V E N T H A N D L I N G I N B U S I N E S S P R O C E S S E S
flexible event subscription for business process enactment
sankalita mandal
business process technology group
hasso plattner institute
digital engineering faculty
university of potsdam
potsdam germany
dissertation
zur erlangung des akademischen grades eines
ldquodoctor rerum naturaliumrdquondash dr rer nat ndash
date of defense 17122019
December 2019
This work is licensed under a Creative Commons License Attribution ndash 40 International This does not apply to quoted content from other authors To view a copy of this license visit httpscreativecommonsorglicensesby40 Supervisor Prof Dr Mathias Weske University of Potsdam Reviewers Prof Dr Matthias Weidlich HU Berlin and Dr Remco Dijkman Eindhoven University of Technology Sankalita Mandal Event Handling in Business Processes copy December 2019 Published online at the Institutional Repository of the University of Potsdam httpsdoiorg1025932publishup-44170 httpsnbn-resolvingorgurnnbndekobv517-opus4-441700
A B S T R A C T
Business process management (BPM) deals with modeling executingmonitoring analyzing and improving business processes During exe-cution the process communicates with its environment to get relevantcontextual information represented as events Recent development ofbig data and the Internet of Things (IoT) enables sources like smartdevices and sensors to generate tons of events which can be filteredgrouped and composed to trigger and drive business processes
The industry standard Business Process Model and Notation (BPMN)provides several event constructs to capture the interaction possibilitiesbetween a process and its environment eg to instantiate a process toabort an ongoing activity in an exceptional situation to take decisionsbased on the information carried by the events as well as to chooseamong the alternative paths for further process execution The specifi-cations of such interactions are termed as event handling However ina distributed setup the event sources are most often unaware of thestatus of process execution and therefore an event is produced irre-spective of the process being ready to consume it BPMN semanticsdoes not support such scenarios and thus increases the chance of pro-cesses getting delayed or getting in a deadlock by missing out on eventoccurrences which might still be relevant
The work in this thesis reviews the challenges and shortcomings ofintegrating real-world events into business processes especially the sub-scription management The basic integration is achieved with an architec-ture consisting of a process modeler a process engine and an eventprocessing platform Further points of subscription and unsubscriptionalong the process execution timeline are defined for different BPMNevent constructs Semantic and temporal dependencies among eventsubscription event occurrence event consumption and event unsub-scription are considered To this end an event buffer with policies forupdating the buffer retrieving the most suitable event for the currentprocess instance and reusing the event has been discussed that sup-ports issuing of early subscription
The Petri net mapping of the event handling model provides our ap-proach with a translation of semantics from a business process perspec-tive Two applications based on this formal foundation are presentedto support the significance of different event handling configurationson correct process execution and reachability of a process path Pro-totype implementations of the approaches show that realizing flexibleevent handling is feasible with minor extensions of off-the-shelf processengines and event platforms
iii
Z U S A M M E N FA S S U N G
Das Prozessmanagement befasst sich mit der Modellierung Ausfuumlh-rung Uumlberwachung Analyse und Verbesserung von Geschaumlftsprozes-sen Waumlhrend seiner Ausfuumlhrung kommuniziert der Prozess mit sei-ner Umgebung um relevante Kontextinformationen in Form von Er-eignissen zu erhalten Der juumlngste Fortschritt im Bereich Big Data unddem Internet der Dinge ermoumlglicht Smart Devices und Sensoren eineVielzahl von Ereignissen zu generieren welche gefiltert gruppiert undkombiniert werden koumlnnen um Geschaumlftsprozesse zu triggern und vor-anzutreiben
Der Industriestandard Business Process Model and Notation (BPMN)stellt mehrere Ereigniskonstrukte bereit um die Interaktionsmoumlglich-keiten eines Prozesses mit seiner Umgebung zu erfassen Beispielswei-se koumlnnen Prozesse durch Ereignisse gestartet laufende Aktivitaumlten inAusnahmefaumlllen abgebrochen Entscheidungen auf Basis der Ereignisin-formationen getroffen und alternative Ausfuumlhrungspfade gewaumlhlt wer-den Die Spezifikation solcher Interaktionen wird als Event Handling be-zeichnet Allerdings sind sich insbesondere in verteilten Systemen dieEreignisquellen des Zustands des Prozesses unbewusst Daher werdenEreignisse unabhaumlngig davon produziert ob der Prozess bereit ist siezu konsumieren Die BPMN-Semantik sieht solche Situationen jedochnicht vor sodass die Moumlglichkeit besteht dass das Auftreten von rele-vanten Ereignissen versaumlumt wird Dies kann zu Verzoumlgerungen odergar Deadlocks in der Prozessaufuumlhrung fuumlhren
Die vorliegende Dissertation untersucht die Maumlngel und Herausfor-derungen der Integration von Ereignissen und Geschaumlftsprozessen ins-besondere in Bezug auf das Subscription Management Die grundlegendeIntegration wird durch eine Architektur erreicht die aus einer Prozess-modellierungskomponente einer Ausfuumlhrungskomponente und einerEreignisverarbeitungskomponente besteht Ferner werden Points of Sub-scription and Unsubscription fuumlr verschiedene BPMN-Ereigniskonstrukteentlang der Zeitachse der Prozessausfuumlhrung definiert Semantischeund temporale Abhaumlngigkeiten zwischen der Subscription dem Auftre-ten dem Konsumieren und der Unsubscription eines Ereignisses wer-den betrachtet In dieser Hinsicht wird ein Event Buffer diskutiert wel-cher mit Strategien zum Update des Puffers zum Abruf der geeignetenEreignisse fuumlr den laufenden Prozess sowie zur Wiederverwendungvon Ereignissen ausgestattet ist
Die Abbildung des Event Handling Modells in ein Petri-Netz versiehtden beschriebenen Ansatz mit einer eindeutigen Semantik Basierendauf diesem Formalismus werden zwei Anwendungen demonstriert diedie Relevanz verschiedener Konfigurationen des Event Handlings fuumlr
v
eine korrekte Prozessausfuumlhrung aufzeigen Eine prototypische Imple-mentierung des Ansatzes beweist dessen Umsetzbarkeit durch geringeErweiterungen bestehender Software zur Prozessausfuumlhrung und Ereig-nisverarbeitung
vi
P U B L I C AT I O N S
The supporting publications for the research work presented in thisthesis are
bull Sankalita Mandal and Mathias Weske ldquoA Flexible Event Han-dling Model for Business Process Enactmentrdquo In 22nd IEEE Inter-national Enterprise Distributed Object Computing Conference EDOCIEEE Computer Society 2018 pp 68ndash74 DOI 101109EDOC201800019 URL httpsdoiorg101109EDOC201800019
bull Sankalita Mandal Matthias Weidlich and Mathias Weske ldquoEventsin Business Process Implementation Early Subscription and EventBufferingrdquo In Business Process Management Forum - BPM ForumVol 297 Lecture Notes in Business Information Processing Sprin-ger 2017 pp 141ndash159 DOI 101007978-3-319-65015-9_9 URLhttpsdoiorg101007978-3-319-65015-9_9
bull Sankalita Mandal Marcin Hewelt and Mathias Weske ldquoA Frame-work for Integrating Real-World Events and Business Processes inan IoT Environmentrdquo In On the Move to Meaningful Internet Sys-tems OTM 2017 Conferences - Confederated International ConferencesCoopIS CampTC and ODBASE Proceedings Part I Vol 10573 Lec-ture Notes in Computer Science Springer 2017 pp 194ndash212DOI 101007978-3-319-69462-7_13 URL httpsdoiorg10
1007978-3-319-69462-7_13
bull Sankalita Mandal ldquoA Flexible Event Handling Model for Us-ing Events in Business Processesrdquo In Proceedings of the 9th In-ternational Workshop on Enterprise Modeling and Information SystemsArchitectures Vol 2097 CEUR Workshop Proceedings CEUR-WSorg 2018 pp 11ndash15 URL httpceur-wsorgVol-2097paper2pdf
bull Luise Pufahl Sankalita Mandal Kimon Batoulis and MathiasWeske ldquoRe-evaluation of Decisions Based on Eventsrdquo In Enter-prise Business-Process and Information Systems Modeling - 18th Inter-national Conference BPMDS Vol 287 Lecture Notes in BusinessInformation Processing Springer 2017 pp 68ndash84 DOI 101007978-3-319-59466-8_5 URL httpsdoiorg101007978-3-31959466-8_5
bull Sankalita Mandal Marcin Hewelt Maarten Oumlstreich and MathiasWeske ldquoA Classification Framework for IoT Scenariosrdquo In Busi-ness Process Management Workshops - BPM 2018 International Work-shops Vol 342 Lecture Notes in Business Information Processing
vii
Springer 2018 pp 458ndash469 DOI 101007978-3-030-11641-5_36URL httpsdoiorg101007978-3-030-11641-5_36
bull Sankalita Mandal ldquoEvents in BPMN The Racing Events DilemmardquoIn Proceedings of the 9th Central European Workshop on Services andtheir Composition (ZEUS) Vol 1826 CEUR Workshop Proceed-ings CEUR-WSorg 2017 pp 23ndash30 URL httpceur-wsorgVol-1826paper5pdf
bull Maximilian Voumllker Sankalita Mandal and Marcin Hewelt ldquoTest-ing Event-driven Applications with Automatically Generated Ev-entsrdquo In Proceedings of the BPM Demo Track and BPM Disserta-tion Award co-located with 15th International Conference on BusinessProcess Management Vol 1920 CEUR Workshop ProceedingsCEUR-WSorg 2017 URL httpceur-wsorgVol-1920BPM_2017_paper_182pdf
bull Jonas Beyer Patrick Kuhn Marcin Hewelt Sankalita Mandal andMathias Weske ldquoUnicorn meets Chimera Integrating ExternalEvents into Case Managementrdquo In Proceedings of the BPM DemoTrack 2016 Co-located with the 14th International Conference on Busi-ness Process Management Vol 1789 CEUR Workshop ProceedingsCEUR-WSorg 2016 pp 67ndash72 httpceur-wsorgVol-1789
bpm-demo-2016-paper13pdf
In addition to above publications I was also involved in the followingresearch indirectly contributing to this thesis
bull Marcin Hewelt Felix Wolff Sankalita Mandal Luise Pufahl andMathias Weske ldquoTowards a Methodology for Case Model Elicita-tionrdquo In Enterprise Business-Process and Information Systems Model-ing - 19th International Conference BPMDS Vol 318 Lecture Notesin Business Information Processing Springer 2018 pp181ndash195DOI 101007978-3-319-91704-7_12 URL httpsdoiorg10
1007978-3-319-91704-7_12
bull Adriatik Nikaj Sankalita Mandal Cesare Pautasso and MathiasWeske ldquoFrom Choreography Diagrams to RESTful InteractionsrdquoIn Service-Oriented Computing - ICSOC 2015 Workshops - WESOAVol 9586 Lecture Notes in Computer Science Springer 2015 pp3ndash14 DOI 101007978-3-662-50539-7_1 URL httpsdoiorg101007978-3-662-50539-7_1
viii
A C K N O W L E D G M E N T S
The journey of a PhD thesis takes lot more than just the scientific con-tributions promised in it The past four years made me stronger as aresearcher as a colleague and also as a person I always see my life asan expanding collage of experiences and now that I look back I realizethere are so many people who added colors to it
Speaking of the researcher life I am so glad that I ended up beinga PhD student under Prof Mathias Weskersquos supervision I appreciatehow you give us the freedom of finding our interest areas while guidingus to take the right decisions I have been privileged to be a part of theBPT ecosystem that you drive so efficiently At the same time beingpart of the HPI research school was a great exposure to the work beingdone in other streams of computer science
I am grateful that Prof Matthias Weidlich and Dr Remco Dijkmanhave agreed to be my reviewers Both of their work influenced my re-search significantly Matthias you have always been my favorite Thankyou for all the long valuable discussions collaborating with you hasbeen truly a nice learning experience
A special credit goes to Anne Baumgraszlig for triggering my interestin complex event processing and being a skilled mentor for the initialmonths Later I shared the major part of my research and teachingactivities with Marcin Hewelt Thanks Marcin for always answeringmy questions with a smile This brings me to express my gratitudeto all the previous BPT members who have shared some part of theiracademic stay with me and gave me a warm welcome to the group
A big applause to my current colleagues for making time to proof-read my thesis chapters Luise Stephan Kiarash Adrian Sven JanMarcin Simon ndash thanks for all the thoughtful feedback that enrichedthe content of this work You guys are amazing not only for beingsmart researchers but also for being so humorous and supportive andpatient with my random crazy stories I would like to give additionalcourtesy to my lsquoAllround Enhancement Executiversquo Stephan who hasalways been there to help be it checking a formalism or correcting anemail in German and my lsquoChief Aesthetics Counselorrsquo Jan who volun-teered to make this thesis look prettier and also designed the cover
And then there are Adriatik and Kimon coinciding the writing phasewith whom has been absolutely blissful for sharing the excitement offinally finishing the PhD and more than that for sharing the hugeamount of stress that suppresses that excitement Kimon thanks alot for all those long hours of working together for all the help withscientific and paper work and for all your unique ways of motivatingwhen I felt low
ix
The journey of completing the PhD would not have been so accom-plishing without being able to bring my parents over for the first timein Europe and witness them being proud while visiting my workplaceMy musical family including my guitarists and co-artists thanks forbeing my refuge Lastly all my wonderful friends across Germany andback in India thanks for being on board through good and bad times
x
C O N T E N T S
I introduction amp foundations 1
1 introduction 3
11 Problem Statement 4
12 Research Objectives 6
13 Contributions 8
14 Structure of Thesis 10
2 business process management 13
21 BPM Life Cycle 13
22 Business Process Model and Notation 15
221 Core Elements 15
222 Events in Business Processes 18
23 Petri Nets 20
24 BPMN to Petri Net Mapping 22
3 complex event processing 27
31 Basic Concepts 27
32 Event Distribution 29
33 Event Abstraction 31
34 Event Processing Techniques 34
4 related work 41
41 Overview 41
42 External Events in BPM 42
43 Integrated Applications 44
44 Flexible Event Subscription amp Buffering 47
45 Summary 49
II conceptual framework 51
5 integrating real-world events into business pro-cess execution 53
51 Motivation amp Overview 53
52 Requirements Analysis 54
521 R1 Separation of Concerns 55
522 R2 Representation of Event Hierarchies 56
523 R3 Implementation of Integration 57
53 System Architecture 57
531 Distribution of Logic 58
532 Use of Event Abstraction 59
533 Implementation Concepts 61
54 Summary amp Discussion 63
6 flexible event handling model 65
61 Motivation amp Overview 65
62 Event Handling Notions 69
xi
xii contents
621 Business Process View 69
622 Event Processing View 73
63 Flexible Subscription Management 74
631 Points of Subscription 75
632 Points of Unsubscription 77
633 Event Buffering 78
634 Semantic Interdependencies 80
64 Summary amp Discussion 81
7 formal execution semantics 83
71 Motivation amp Overview 83
72 Petri Net Mapping 85
721 Event Handling Notions 85
722 Points of Subscription 86
723 Points of Unsubscription 91
724 Event Buffering 93
73 Summary amp Discussion 96
III evaluation amp conclusions 99
8 application of concepts 101
81 Execution Trace Analysis 101
811 Correctness Constraints 101
812 Impact of Event Handling 105
813 Discussion 106
82 Reachability Analysis 107
821 Communication Model 108
822 Impact of Event Handling 110
823 Discussion 112
83 Summary 114
9 proof-of-concept implementation 115
91 Basic Event Interaction 115
911 Unicorn Event Processing Platform 116
912 Gryphon Case Modeler 117
913 Chimera Process Engine 119
914 Event Integration Sequence 120
92 Flexible Event Subscription with Buffering 122
921 BPMN Extension 123
922 Unicorn Extension 127
923 Camunda Extension 129
93 Summary 132
10 conclusions 133
101 Summary of Thesis 133
102 Limitations and Future Research 135
bibliography 139
L I S T O F F I G U R E S
Figure 1 Overview of research steps for the thesis 7
Figure 2 Relevance of Information Systems research [19] 8
Figure 3 Summary of research contributions 11
Figure 4 Business process management (BPM) lifecyle 14
Figure 5 State transition diagram for activity lifecycle 16
Figure 6 BPMN tasks 16
Figure 7 BPMN gateways 17
Figure 8 BPMN events as presented in BPMN 20 Posterby BPM Offensive Berlin (cf httpwwwbpmbdeindexphpBPMNPoster) 19
Figure 9 Mapping of BPMN task to Petri net modules 23
Figure 10 Mapping of BPMN gateways to Petri net mod-ules 23
Figure 11 Mapping of BPMN event constructs to Petri netmodules 24
Figure 12 Mapping of BPMN boundary event construct toPetri net module 24
Figure 13 Event processing network 28
Figure 14 Data in rest vs data in motion 29
Figure 15 Communication models for event distribution 30
Figure 16 Applications of event abstraction in context ofprocess execution 32
Figure 17 Event abstraction for order tracking in an onlineshop 33
Figure 18 Stream processing operations on events 33
Figure 19 State changes for an event query in an event pro-cessing platform 34
Figure 20 An example EPN showing the different compo-nents 35
Figure 21 Event hierarchy showing Transaction and eventsderived from it 36
Figure 22 Screenshot from Unicorn showing generation ofcomplex events following pre-defined rules 40
Figure 23 Overview of discussed research areas as relatedwork 41
Figure 24 Usecase from the logistics domain 55
xiii
xiv List of Figures
Figure 25 Proposed system architecture for event-processintegration 58
Figure 26 Event subscription and correlation within a pro-cess engine and an event platform 62
Figure 27 Collaboration diagram motivating the need forflexible subscription 66
Figure 28 Dependencies among the event handling notionsevent subscription occurrence consumption andunsubscription 69
Figure 29 Event construct classification put in example pro-cess models 71
Figure 30 Lifecycle of an event wrt requisite for a processexecution 73
Figure 31 Interaction from event processing platformrsquos per-spective 74
Figure 32 Process execution timeline 75
Figure 33 Points of (Un)-Subscription 78
Figure 34 Interdependencies among the aspects of flexibleevent handling 80
Figure 35 Event handling notions represented by Petri net 86
Figure 36 Scenarios considering the separate notions of eventoccurrence and event consumption 86
Figure 37 Petri net modules for mandatory event construct 87
Figure 38 Petri net module for boundary event construct 88
Figure 39 Petri net modules for racing event construct 90
Figure 40 Petri net modules for exclusive event construct 91
Figure 41 Petri net modules for points of unsubscription 92
Figure 42 Petri net showing event matching correlationand buffering 94
Figure 43 Petri net showing a mandatory event constructwith subscription at process instantiation and un-subscription at event consumption 102
Figure 44 Excerpt from motivating example presented in Fig-ure 27 in Chapter 6 106
Figure 45 Petri net with subscription at event enablement andunsubscription at event consumption 106
Figure 46 Petri net with subscription at process instantiationand unsubscription at event consumption 107
Figure 47 Transition diagram for a process model (M) andcorresponding environment models (E E prime) 109
Figure 48 Different subscription configurations for receiv-ing event z 110
List of Figures xv
Figure 49 Process Model M communicating with environ-ment 110
Figure 50 A chosen path in process and the set of corre-sponding paths in environment with varying sub-scription configuration 111
Figure 51 A chosen path in process and the set of corre-sponding paths in environment with varying con-sumption configuration 111
Figure 52 A chosen path in the process and the set of cor-responding paths in environment with early sub-scription for z and w 113
Figure 53 BPMN process model with boundary event andthe corresponding transition system 113
Figure 54 Detailed system architecture showing specific com-ponents and the sequence of integrating eventsinto processes 115
Figure 55 Architecture of event processing platform Uni-corn 116
Figure 56 Modeling of subscription queries with extendedfield (in right) for event annotation in Gryphon 118
Figure 57 Event data from LongDelay is written into a newlycreated data object Delay using a JSON path ex-pression 119
Figure 58 Architecture of the Chimera process engine 120
Figure 59 The sequence of communication between GryphonChimera and Unicorn for the integration of eventsinto processes 121
Figure 60 BPMN+X model showing extension of BPMN Mes-sage element 124
Figure 61 An example process with embedded subscrip-tion definition for the intermediate catching mes-sage event 126
Figure 62 Extended architecture for flexible event handling 127
Figure 63 UML Class diagram of Camunda process engineplugin 130
L I S T I N G S
Listing 1 Event type definition of Transaction 35
Listing 2 Example of Project EPA 37
Listing 3 Example of Translate EPA 37
Listing 4 Example of Enrich EPA 37
Listing 5 Example of Aggregation EPA 38
Listing 6 Event types Withdrawal and FraudAlert 38
Listing 7 Example of Compose EPA 39
Listing 8 Event type definitions for motivating example 60
Listing 9 Event abstraction pattern for LongDelay 60
Listing 10 Example of event patterns 74
Listing 11 XML interpretation of BPMN+X model 124
Listing 12 Excerpt from the XML interpretation of the BPMNprocess modeled in Fig 59 showing process struc-ture and extended elements enabling flexible sub-scription 126
xvii
A C R O N Y M S
BPM Business Process Management
CEP Complex Event Processing
IoT Internet of Things
BPEL Business Process Execution Language
BPMN Business Process Model and Notation
EPC Event-driven Process Chain
EPA Event Processing Agents
EPN Event Processing Network
EPS Event Processing Systems
DBMS Database Management Systems
SEP Simple Event Processing
ESP Event Stream Processing
PN Petri Net
SQL Structured Query Language
JMS Java Message Service
REST Representational State Transfer
CQL Continuous Query Language
IS Information Systems
CPN Coloured Petri Nets
EPP Event Processing Platform
ERP Enterprise Resource Planning
UUID Universally Unique Identifier
EIP Enterprise Integration Patterns
xix
Part I
I N T R O D U C T I O N amp F O U N D AT I O N S
1I N T R O D U C T I O N
ldquoThe event concept is simple yet powerfulrdquondash Etzion amp Niblett Event Processing in Action [46]
Medical science says every second of every day our senses bring in waytoo much data than we can possibly process in our brains1 The situationfor software systems is similar in the era of the Internet of Things(IoT) since now we have the technological advancements to translatethe physical senses into digital signals [9] Millions of sensors are pro-ducing a huge amount of events that carry data or information whichcan be interpreted to gain insight about the environmental occurrencesWe are already familiar with the concepts of ldquobig data explosionrdquo [65]and ldquodata being the new oilrdquo [124] However there is a subtle yetvery significant paradigm shift in terms of processing data Instead ofthe static data stored in large databases the last decade focused moreon the dynamic data or data in motion Rather than using the dataafterwards for analyzing what happened in the past the events give usinsight about the current situation or even predict the future so thatwe can react to the environmental occurrences in a timely manner [74]But while the amount of available information is rapidly increasing thetime window during which the information is relevant ie the self-lifeof the information is decreasing so is the reaction time [102]
Research fields such as data science data engineering and ComplexEvent Processing (CEP) explore concepts and technicalities for extract-ing insight from data The event processing platforms connect to eventsources to receive streams of events and perform range of operations tohave a meaningful interpretation of the data carried by the events [56]Often put together a few events occurred in a specific pattern higherlevel business information are derived that influence organizational pro-cesses For instance a sudden fall in stock market prices might demanda company to postpone a release of their new product Another exam-ple could be an airlines offering the passengers alternative connectionsafter there is a strike at a specific airport When it comes to organi-zational processes Business Process Management (BPM) is the field ofresearch that deals with the overall support for modeling executingmonitoring evaluating and improving them [134]
Given the situation it is highly important to get access to the rele-vant information that can influence a business process and to take thenecessary steps as soon as a certain circumstance has occurred Suchexternal influences are represented as event constructs in a business pro-cess Business Process Model and Notation (BPMN) [94] is the industry
1 httpswwwbrainyquotecomquotespeter_diamandis_488485
3
4 introduction
standard for modeling and executing business processes BPMN is ahighly expressive language and provides several event constructs tocapture the interaction possibilities between a process and its environ-ment According to the standard events can be used to instantiatea process to abort an ongoing activity in an exceptional situation totake decisions based on the information carried by the events as wellas to choose among the alternative paths for further process executionOn one hand a process can receive these events from the event sourcesdistributed in the environment On the other hand the process can alsoproduce events to send a message or a signal to the environment [27]The specifications of such interactions are termed as event handling
Despite having the provisions for integrating external informationinto processes so far there is no clear guideline for event handlingfrom a business process perspective such as how to receive a businesslevel event from the raw event sources when to start listening to anexternal occurrence and how long a particular event is relevant for pro-cess execution Research gaps for an efficient communication betweenevents and processes are outlined in detail in Section 11 This bringsthe opportunity to explain how those questions are addressed in thiswork described as the research objectives in Section 12 Next the con-tributions of this thesis are listed in Section 13 Lastly the structure ofthe thesis is sketched in Section 14
11 problem statement
Business process models incorporate environmental happenings in theform of external events These events play a significant role in processenactment mdash they can drive the process execution flow and can provideinformation for decision making Standard notations and languages formodeling and executing business processes provide event constructs tocapture the communication with environment Business Process Execu-tion Language (BPEL) [92] has been popular in the BPM community forlast two decades In BPEL events are either messages received (or sent)by activities from (to) other webservices or timers BPELrsquos ltreceivegtactivity defines an Endpoint (URL Port operation) that needs to beinvoked to receive an event ltonAlarmgt activitiy waits for a duration oftime or until a specified point in time [72]
While BPEL has a narrow range of events (message receive andtimer) the de facto standard BPMN offers a much wider understand-ing of events [130] Happenings in the world might impact a businessprocess in various ways rather than just a message sent to the processinstance or a timer based alarm To accommodate that BPMN definesevents that can be placed as a start event to instantiate a process as anintermediate event to represent communication with other process par-ticipants and as an end event to signify the completion of the processAlso several event types are specified to capture different semantics of
11 problem statement 5
the communication eg broadcasting a news to all process participantsand representing an error state These event constructs are visualizedas dedicated nodes in process models abstracting from the technicali-ties such as subscribing to the event source receiving it during processexecution and consuming the information carried by it
However BPEL and BPMN both completely ignore the details aboutthe event sources and event abstraction hierarchy that are significant forsuccessfully receiving the required information in the processes Otherlanguages such as UML Activity Diagrams [95] also neglect the aboveissues Standard process engines like Camunda [24] support BPMNevents for starting a process instance and for selecting between alter-native paths following a gateway Lack of support for
event handling inBPM
Nevertheless even in the executionlevel the engines do not care about the receiving part of the messageevent For instance Camunda has interfaces that can be connected toa Java Message Service (JMS) queue2 or a Representational State Trans-fer (REST) interface [105] but the reception of messages is not imple-mented
Event handling details the specification of how a process interactswith its environment and how the environmental occurrences impactthe process execution Considering the semantics for event handlingespecially the guidelines with respect to subscription for intermediatecatching events BPMN specification [94] states
lsquoFor Intermediate Events the handling consists of waiting for the Eventto occur Waiting starts when the Intermediate Event is reached Once theEvent occurs it is consumed Sequence Flows leaving the Event are followedas usualrsquo [BPMN 20 Sect 1342]
That is when the control-flow reaches the event construct it is en-abled and a process instance starts waiting for the event to happenOnce it happens the control-flow is passed down to next activitiesAs a consequence a process instance may not react to an event thatoccurred earlier than its control-flow reached the respective event con-struct The assumption that ldquoan event occurs only when the processis ready to consume itrdquo is severely restricting in various real businessscenarios Especially in a distributed setup or in an IoT environmentwhere the event sources are not aware of the current execution status ofthe process it might cause the process to get delayed by waiting for thenext occurrence of the event Even worse if the event is not publishedregularly then once the process misses the event occurrence the processexecution gets in a deadlock
Taking into account the fact that creation of event by the environmentis decoupled from process execution status existing event handling se-mantics raise the following research questions
bull RQ1 When to subscribe to an event sourceThis of course depends on the data availability that is needed
2 httpswwworaclecomtechnetworkarticlesjavaintrojms-1577110html
6 introduction
to create a subscription But the necessary information can beavailable at different points of time during process execution ear-lier than enablement of the event construct Also instance spe-cific data might not be needed for subscribing to certain eventsTherefore flexible yet unambiguous semantics enabling early sub-scription are needed to specify when it is feasible and when it isrecommended to start listening to a particular event occurrence
bull RQ2 For how long to keep the subscriptionAfter an event is consumed the process instance does not needit any more But there might be other points in time when theevent looses the relevance to the process instance even before it isconsumed Hence possibilities and need for an unsubscription isworth discussing in the context of early subscription
bull RQ3 How to store and retrieve the relevant events for a specific processexecutionEarly subscription calls for storing the events until the process isready to consume it But if by the time there are more than oneoccurrences of a certain event type then the following aspectshave to be decided
ndash How many events should be stored of the same typendash Which one of them is the most relevant for a specific in-
stancendash Is the event information reusable
To summarize most process specification languages share the samelimitations described above The lack of flexibility in event handlingsemantics limits the interaction scope between a process and its envi-ronment The research objectives to address these issues are describednext
12 research objectives
The goal of the thesis is to provide a formal event handling model forbusiness process enactment The event handling model shall facilitateflexible event subscription to fit the need of real-world distributed en-vironment where event sources send information to business processmanagement systems without knowing the internal process executionstatus
Essentially the event handling model defines the notions of a busi-ness process creating a subscription to start listening to an event theoccurrence of the event that is relevant for the process consumption ofthe event following the process control-flow and unsubscription to stopreceiving the event notification The subscription and unsubscriptioncan be done at several milestones along the process execution timelineThe business-level event can either directly be produced as a raw event
12 research objectives 7
by an event source or can be an aggregated one generated using eventabstraction hierarchies by an event processing platform The processcan consume the event as soon as it occurs given there is a subscrip-tion issued before or the event can be temporarily stored in a bufferuntil the process execution is ready to consume it The event handlingnotions and their interdependencies shall be defined explicitly
The aim is to come up with a platform independent formal modelthat considers the separate event handling notions instead of abstract-ing the details in an event construct This gives unambiguous and clearsemantics for correct process execution while considering event-processinteractions The concepts of early subscription and event buffering are in-tended to leverage an extended timespan of using relevant events fora process and thereby mitigating the possibility of the process gettingdelayed or getting stuck while waiting for the event occurrence Theobjective of highlighting different possible points of (un)-subscription isto enhance the flexibility of the event-process interplay
The flow of building up concepts and technicalities during the the-sis journey follows an explorative path as shown in Figure 1 Thegoal of having a detailed event handling model raised the demand tounderstand the role of complex events in business processes There-fore extensive literature study in the area of using complex event pro-cessing in business process management has been carried out Alongwith building up the knowledge base some hands on applications arealso developed For instance using complex event processing to en-able re-evaluation of decisions based on context information is exploredin [101] Integration challenges such as impact of probable latency be-tween the occurrence time of an event and detection time of that eventin the process execution engine has been discussed in [78]
Integration of external events into business processes
Importance of complex event
processing in BPM
Early event subscription and event buffering
Flexible event handling with
Petri Net mapping
Figure 1 Overview of research steps for the thesis
The investigation of state-of-the-art revealed that business processmanagement (BPM) and complex event processing (CEP) are well es-tablished fields as individual research areas however an integrationframework of the two worlds is missing This led to basic and advancedunderstanding of the challenges of integrating external events into busi-ness processes both in process design level and process execution levelThus the next research phase has been dedicated to build an end-to-end solution that integrates external events into business processes [80]While the integrated architecture met the basic requirements it wasnot enough to capture the flexibility needed by real-world scenariospresent in distributed setups In the next research phase concepts forearly event subscription and event buffering [82] are introduced to in-duce the needed flexibility to communicate with the event sources The
8 introduction
final phase flexible event handling with Petri net mapping extends theconcept of early subscription and adds formal semantics to the eventhandling notions from a business process perspective
13 contributions
In Information Systems (IS) research it is important for a contributionto be relevant According to Benbasat and Zmud [19] a research con-tent is relevant when it fulfills the following three criteria
bull Interesting whether the research address the challenges that areof concern to IS professionals
bull Current whether the research considers state-of-the-art technolo-gies and business issues and
bull Applicable whether the research is utilizable by practitionersFigure 2 summarizes the criteria for a relevant research in IS Addition-ally the research should be accessible to the IS professionals written ina well understandable and fluent style
Interesting
Current
Applicable
Relevance
Figure 2 Relevance of Information Systems research [19]
Keeping that in mind the research contributions added by this thesisare argued to be relevant while outlining the highlights in the following
bull Requirements Analysis Based on the current status of the BPMNspecification the standard process engines and with the help ofdomain experts we present the requirements for an integratedarchitecture The need for flexible event subscription points aredetailed based on a usecase The requirements elicitation is donein close collaboration with researchers as well as business pro-fessionals from the field The integration challenges have beenagreed to be of concern to all of them making the contributioninteresting
bull Integrated Framework Addressing the requirements an integratedarchitecture enabling efficient communication between externalevents and business processes are established The framework ful-fills the conceptual requirements such as separation of concernsbetween event processing logic and business process specificationexploiting event abstraction hierarchies to map raw-level eventsto higher-level business events It also considers the technicalrequirements such as subscribing to an event source receiving
13 contributions 9
events and reacting to them The generic architecture is realizedwith a process editor a process engine and an event processingplatform as a proof-of-concept implementation
bull Flexible Event Handling Model This is the main contribution of thisdissertation The work done in the course of this thesis introducesthe concepts for flexible event handling formalizes them and pro-vides implementation to show the feasibility of the concepts Con-sidering the shortcomings of current notation and process enginesmake this contribution current While the overall contribution pro-vides flexible subscription configurations for process executionthis can be further divided into the following sub-contributions
ndash The event handling notions for subscription occurrence con-sumption and unsubscription of an event are discussed sep-arately from the business process view as well as the eventprocessing view The temporal constraints between the no-tions are also explored
ndash Considering the usecase needs the constrains between theevent handling notions and the process execution timelinefour points of subscription are specified This addresses the re-search question ldquoRQ1 When to subscribe to an event sourcerdquoThe points of subscription cover the BPMN semantics of lis-tening to an event when the control-flow activates the eventconstruct and extends the possibility for an early subscriptionat process instantiation at process deployment and at en-gine initiation This enables the process to receive an eventeven when the execution flow is not ready to consume it toincrease the chance of including an early occurrence of anevent while it is still relevant for the process
ndash The concept of early subscription raises the need for storingthe events temporarily till it is consumed by the process Thisbrings us to the next contribution namely an event bufferwith buffer policies to control the lifespan for keeping anevent in the buffer to determine the most suitable event for aprocess instance when more than one occurrences have hap-pened in between the subscription and consumption and tofacilitate reuse of an event information across instances aswell as across processes These buffer policies answer thequestions discussed in the context of ldquoRQ3 How to store andretrieve the relevant events for a specific process executionrdquo
ndash Similar to the points of subscription the points of unsubscrip-tion are also specified to address ldquoRQ2 For how long to keepthe subscriptionrdquo Though unsubscription is not mandatoryit is recommended to avoid engine overhead with events thatare not relevant any more The interdependencies among the
10 introduction
chosen event handling configurations are discussed in thiscontext to guide a correct and efficient process execution
ndash Finally all the above concepts for flexible event handling aregiven formal semantics by mapping the concepts to Petri netmodules classified by the types of event constructs While stan-dard Petri nets are used for a clear semantics for the eventhandling notions and points of (un)-subscription ColouredPetri Nets (CPN) are used to formalize the buffer policiesThus this thesis provides a formally grounded flexible eventhandling model for business processes and fulfills the re-search objectives Based on the formal semantics two appli-cations demonstrating the impact of selecting event handlingconfigurations are included as well adding to the applicabilityof the contribution
Figure 3 visualizes the summary of the contributions The parts high-lighted in green are the concepts built up during the course of the thesiswhile the highlighted part in orange signifies the extension of existingmapping technique
14 structure of thesis
After the introduction to the motivation problem statement researchobjectives and contributions this section outlines the structure of thecomplete thesis This thesis consists of three main parts as describedbelow
part i introduction amp foundations This is the first partof the thesis and we are already in this part After the introductionchapter the preliminaries are given based on which the research hasbeen conducted Since the thesis is vastly emerged into the conceptsfrom both business process management and complex event process-ing fields each of them are discussed as foundations Chapter 2 startswith the BPM lifecycle Our work is based on the specifications andshortcomings of Business Process Model and Notation Therefore in-troduction to the relevant core elements of BPMN 20 are given in thischapter The role of events in BPMN is discussed in more detail As amore formal process execution notation Petri nets are introduced Theexisting mapping from BPMN to Petri net by Dijkman et al [37] is con-sidered as a foundation as well since this is later extended for mappingthe event handling configurations In Chapter 3 the basic concepts ofevent processing such as event abstraction event queries and eventpattern matching are introduced Chapter 4 concludes this part of thethesis with extensive discussion about the related work that focus onintegrated applications of CEP and BPM as well as event subscriptionand buffering concepts
14 structure of thesis 11
Com
plex
Eve
nt P
roce
ssin
g
BPM
N
Even
t Co
nstr
ucts
+Ev
ent
Han
dlin
gCo
nfig
urat
ions
Even
t Buf
fering
+
Buf
fer
Polic
ies
Poin
t of
Su
bscr
iption
Poin
t of
Uns
ubsc
ript
ion
Even
t St
ream
s
Even
t H
andl
ing
Not
ions
Petr
i Net
Map
ping
Even
t Co
nsum
ptio
nEv
ent
Subs
crip
tion
Rel
evan
tO
ccur
renc
e
Even
t Uns
ubsc
ript
ion
C e1
C e2
Oe1
Oe2
Ue1
e2
P (C
e1 y
1)
P (C
e2 y
2)
P (g C
e1)
P (g C
e2)
P (S
e1e2
Oe1e2)
S e1e2
e s
P (e
s a)
P (PD e
s)
Figu
re3
Sum
mar
yof
rese
arch
cont
ribu
tion
s
12 introduction
part ii conceptual framework This part of the thesis intro-duces the core contributions We start with the basic integrated architec-ture to use real-world events into business processes in Chapter 5 Therequirements elicitation for integration challenges are described firstNext the solution architecture fulfilling the requirements is illustratedChapter 6 goes deeper into event subscription mechanism and definesthe advanced event handling concepts The flexible subscription man-agement with different subscription and unsubscription configurationsare explored in this chapter The event buffering concept with the bufferpolicies are also discussed in this context Next in Chapter 7 formalsemantics are assigned to the event handling concepts This includesPetri net mapping for the event handling notions the points of subscrip-tion and unsubscription for each event construct and the event bufferpolicies
part iii evaluation amp conclusions The last part of the the-sis turns to evaluation of the concepts introduced so far First Chap-ter 8 demonstrates the applicability and significance of event handlingconcepts based on the formal semantics Trace analysis is used as averification method for correct process execution Based on the Petrinet mapping temporal constraints for each pair of event construct andpoint of subscription are defined for this application Further reach-ability analysis of a process path is investigated in presence of earlysubscription and reuse of events As proof-of-concept both basic andadvanced event handling implementation are discussed in Chapter 9Using a process modeler a process engine and an event processingplatform the solution architecture is implemented to enable basic event-process interactions To realize flexible event handling BPMN notationis extended to specify event handling configurations Next the eventprocessing platform is extended to incorporate buffer functionalitiesAs a complement to the event processing platform an open-source pro-cess engine is adapted to control the time of issuing a subscriptionFinally this thesis is summarized in Chapter 10 along with discussionsabout the limitations and future research directions
2B U S I N E S S P R O C E S S M A N A G E M E N T
Processes are everywhere in our everyday lives Whenever we aim to dosomething repetitively we tend to follow certain steps As soon as these steps
and the end result bear business value it becomes even more important toperform the tasks in a structured way and to consider the alternative
approaches to execute the tasks to get a better result Business processescapture these steps the order between them the decisions needed to be taken
and the information influencing the decisions The work presented in thisthesis is grounded in the vast concepts of business process management
(BPM) This chapter introduces the relevant ideas and techniques from thefield of BPM which are necessary to follow the advanced work Namely the
core concepts of modeling and enacting business processes are discussed withthe help of standard notations such as Business Process Model and Notation
and Petri Net (PN) along with the mapping from one to anotherFurthermore the use of external events in business processes are explored in
detail to understand the aspects and challenges of the integration
21 bpm life cycle
Several definitions of a business process can be found in [22 42 64 69116 134] We abide by the definition given by Weske in [134] that saysa business process is a set of activities performed in a coordinated man-ner in a business or technical context to achieve pre-defined businessgoal(s) The complete process of supporting the design administra-tion configuration enactment and analysis of business processes withvarious concepts methods and techniques is known as Business ProcessManagement (BPM) This section explains the phases of business processmanagement to understand the underlying concepts and technologiesin more detail Figure 4 represents the business process lifecycle asdiscussed in [134]
The entry point to the cycle is the Design and Analysis phase BPMis a model-driven approach [42] In this phase the business processesare extracted and represented visually in a model The processes canbe elicited using different techniques such as interviewing the knowl-edge workers observing the activities they perform or conducting aworkshop to model the process together with the domain experts [77]Instead of extracting the model from the knowledge workers they canalso be discovered from the execution logs documented by the Enter-prise Resource Planning (ERP) system or relational databases usingprocess mining techniques [124] Typically a process consists of thekey activities to achieve certain goal(s) the decision points along the
13
14 business process management
Figure 4 Business process management (BPM) lifecyle
way to reach the goal(s) and the interactions with other processes orthe environment that influence the tasks performed and the decisionstaken After extracting the process it is modeled formally using a spe-cific business process modeling notation Once modeled the processis simulated and verified to make sure it covers the complete set ofexecution possibilities and serves the modeling goal(s)
The next phase is Configuration of the process model to implementit The implementation of the process can be done with or without adedicated IT system [41] If there is a dedicated IT system such asa process engine then the modeled process is enhanced with furthertechnical details which are parsed and followed by the process engineto execute the process If there is no IT support for process executionthen certain rules and procedures are distributed among the humanresources responsible for conforming to the process while executing itmanually
In the Enactment phase the configured process is actually executedfollowing the process specification There can be several executions ofa single process Each execution is one process instance The processengine logs these execution data at runtime This information can beused to monitor the status of the process execution at anytime duringthe execution [51 120]
Next Evaluation is done to check the conformance of the process ex-ecution with the process specification The execution traces logged bythe engine is analyzed in this phase to find the bottlenecks or devia-tions from actual model [25 87 132] Evaluation can also detect per-formance metrics of a process The process is further improved basedon that eg by increasing the flexibility efficiency effectiveness anduser satisfaction Again process mining techniques are often appliedto the execution logs for conformance checking or performance evalu-ation [1 66 90] Finding the patterns of state transition events leadingto good or bad states by analyzing the execution log data is another
22 business process model and notation 15
evaluation aspect This is then used for predictive monitoring duringfuture process executions [10 43 51 52 86 107]
22 business process model and notation
As discussed above the first step for process implementation is tomodel the process visually following the behavioral specifications Laterthese specifications are executed for each process instance In additionprocess models are discovered from the execution log for checking theconformance between an intended behavior and corresponding actualbehavior [124] Thus process models lie at the heart of business processmanagement
Several languages and notations are available for process descriptionDepending on the purpose of process modeling the most suitable lan-guage can be selected For describing structured processes procedu-ral languages such as Business Process model and Notation (BPMN)1Event-driven Process Chain (EPC)2 Web Service Business Process Exe-cution Language (BPEL)3 might be used Whereas for describing moreflexible processes there are approaches such as declarative [97] artifact-centric [59] or hybrid The declarative modeling languages do not bindthe activities in a sequence rather specify some constraints that shouldbe followed while executing them However the non-procedural ap-proaches are still evolving whereas procedural languages have alreadybeen in use in business context for years [98] We followed the industrystandard BPMN 20 for our work The basic concepts of BPMN relevantto our work are described next
221 Core Elements
In essence a process model is a graph with nodes and edges [134]where nodes can be activities mdash representing a task gateways mdash rep-resenting branching in process execution and events mdash representingrelevant occurrences influencing the process A process model is usedas a blue print for a set of process instances which are the individualexecutions of this process
Each process instance consists of several activity instances Theseactivity instances traverse through different life cycle states as shownin Figure 5 Once the process is instantiated each activity is initializedThis puts the activity instances in state init As soon as the incomingflow of an activity is triggered it enables the instance and changes thestate to ready Activity life cycleWith the start of activity execution the state changes torunning Finally the activity instance is terminated once the execution iscompleted In some cases while the activity instance is yet not startedthe process execution chooses a different path This puts the activity
1 httpswwwomgorgspecBPMN20
2 httpswwwariscommunitycomevent-driven-process-chain
3 httpswwwoasis-openorgcommitteeswsbpel
16 business process management
Figure 5 State transition diagram for activity lifecycle
into the skipped state Also due to the occurrence of an exceptional sit-uation a running activity instance can switch to canceled state Duringone process instance execution an activity can be re-instantiated afterit is terminated or canceled
An activity can be a task that represents the atomic step in a processa sub-process that abstracts the lower-level process within an activity ora call activity that calls and gives the control to a global task Dependingon the nature of the task it can be classified in following categories Ser-vice task mdash performed by calling a web service or any other automatedservice Send task mdash responsible for sending a message to an externalparticipant Receive task mdash responsible for receiving message from anexternal participant User task mdash performed by a human user Manualtask mdash performed without any support of execution engine Businessrule task mdash abstracted decision logic involved in the activity [96] andScript task mdash executed by process engine Different types of BPMNtasks are visualized in Figure 6 with their standard icons
ServiceTask
SendTask
ReceiveTask
UserTask
ManualTask
Business Rule Task
ScriptTask
Figure 6 BPMN tasks
The control flow maintaining the sequence among these activities canbe optimized using gateways There are six types of gateways to specifythe branching behaviors as described below Exclusive gateways areused for alternative paths based on data-based decisionsGateways Only one ofthe outgoing branches following the exclusive gateway can be chosenfor a process instance execution The converging exclusive gatewaymerges the alternative branches On the contrary inclusive gateways can
22 business process model and notation 17
Exclusive
Inclusive
Parallel
Parallelevent-based
Complex
Event-based
Figure 7 BPMN gateways
be used to choose one or multiple paths among the alternatives Asthe name suggests the parallel gateway leads the process execution tobranches that can be executed in parallel independent of each otherHere all the branches following the gateway have to be executed inorder to move further While the exclusive or inclusive gateways arebased on data-based decisions the event-based gateway directs the pathto execute depending on the event occurrence order The first event tooccur among the events after the gateway leads the further executionin this case Parallel event-based gateway needs all the associated eventsto be triggered for process completion For more complex and specificbranching conditions (such as when three out of five branches are tobe executed) complex gateways might be used Figure 7 summarizes thedifferent types of BPMN gateways along with their notations
BPMN offers several event constructs to represent the interaction be-tween two processes as well as a process and its environment Sincethis thesis intensely deals with events in business processes an elabo-rate description of BPMN events is given later in Section 222 Basedon the above discussion we now formally define the relevant conceptsof a process model for our work in the following
Definition 21 (Process Model)A Process Model is a tuple M = (N cfB) with
bull a finite non-empty set of nodes N = NA cupNE cupNG where NANE and NG are pairwise disjoint sets of the activities the eventsand the gateways respectively
bull a control flow relation cf sube NtimesN andbull a function B that maps the activities to the associated boundary
event(s)bull NE = ES cupEI cupEE where ES EI and EE are pairwise disjoint sets
of start events intermediate events and end events respbull EI = EIC cup EIT where EIC and EIT are pairwise disjoint sets of
intermediate catching events and intermediate throwing eventsresp
bull NG = GA cupGX cupGE where GA GX and GE are pairwise disjointsets of AND gateways XOR gateways and event-based gateways
18 business process management
bull B NA rarr P(EIC) where P(EIC) is the power set of the intermedi-ate catching events
For an activity A isin NA let AbAtAc be the beginning terminationand cancellation of A respectively A start event is always a catchingevent ie the process receives the event whereas an end event is alwaysa throwing event ie the process produces the event The preset of anode n isin N is defined as bulln = x isin N | (xn) isin cf The postset of anode n isin N is defined as nbull = x isin N | (n x) isin cf
222 Events in Business Processes
Events are the happenings that are relevant to process execution It cansignify the state changes for an activity the state changes of a data ob-ject and the communication with the environment [75] The processescan consume events using the catching events and can also generateevents modeled as throwing events A process always gets instantiatedby a start event which can be a catching event received from the envi-ronment or an engine generated event Each process path should ter-minate with an end event Start events are always catching events andend events are always throwing events The intermediate events happenin between start and end of a process and they can either be throwingor catching by behavior
BPMN specifies a range of event constructs to capture different se-mantics of happenings that influence a process execution The completedescription of BPMN events are found in the standard [94] Figure 8
gives brief introduction to the events and classifies them according tostart intermediate and end events as well as their catching and throw-ing nature The event types used in this thesis are described in detailbelow
blank event This do not add any special semantics to the eventRather it just signifies the state depending on the position Blank eventscan be used as a start event throwing intermediate event and endevent
message event This is used for massage flow between process par-ticipants It can be both throwing (sending message) and catching (re-ceiving message) Message events are also used for receiving externalinformation into processes Message events might have data associationto implement the input of information to the event payload by the send-ing process and to write the information carried by the event to a dataobject to use it further in the receiving process If the message event isattached to an activity (boundary event) then it works as an exceptiontrigger and initiates an exception handling path in the process If theboundary event is interrupting then the associated activity is canceledupon firing of the event
22 business process model and notation 19
ActivitiesConversations
Events
Gateways
Conversation Diagram
None Untyped events
indicate start point state
changes or final states
Message Receiving and
sending messages
Timer Cyclic timer events
points in time time spans or
timeouts
Error Catching or throwing
named errors
Cancel Reacting to cancelled
transactions or triggering
cancellation
Compensation Handling or
triggering compensation
Conditional Reacting to
changed business conditions
or integrating business rules
Signal Signalling across differ-
ent processes A signal thrown
can be caught multiple times
Multiple Catching one out of
a set of events Throwing all
events defined
Link Off-page connectors
Two corresponding link events
equal a sequence flow
Terminate Triggering the
immediate termination of a
process
Escalation Escalating to
an higher level of
responsibility
Parallel Multiple Catching
all out of a set of parallel
events
Start EndIntermediate
Catc
hin
g
Thro
win
g
Event
Sub-P
rocess
Inte
rrupti
ng
Sta
ndard
Event
Sub-P
rocess
Non-I
nte
rrupti
ng
Boundary
Inte
rrupti
ng
Boundary
Non-
Inte
rrupti
ng
Sequence Flow
defines the execution
order of activities
Conditional Flow
has a condition
assigned that defines
whether or not the
flow is used
Default Flow
is the default branch
to be chosen if all
other conditions
evaluate to false
Task
A Task is a unit of work the job to be
performed When marked with a symbol
it indicates a Sub-Process an activity that can
be refined
Transaction
A Transaction is a set of activities that logically
belong together it might follow a specified
transaction protocol
Event
Sub-Process
An Event Sub-Process is placed into a Process or
Sub-Process It is activated when its start event
gets triggered and can interrupt the higher level
process context or run in parallel (non-
interrupting) depending on the start event
Call ActivityA Call Activity is a wrapper for a globally defined
Task or Process reused in the current Process A
call to a Process is marked with a symbol
Task TypesTypes specify the nature of
the action to be performed
Send Task
Receive Task
User Task
Manual Task
Business Rule Task
Service Task
Script Task
Markers indicate execution
behavior of activities
Activity Markers
Sub-Process Marker
Loop Marker
Parallel MI Marker
Sequential MI Marker
~ Ad Hoc Marker
Compensation Marker
A Conversation defines a set of
logically related message exchanges
When marked with a symbol it
indicates a Sub-Conversation a
compound conversation element
A Conversation Link connects
Conversations and Participants
Inclusive Gateway
When splitting one or more
branches are activated All
active incoming branches must
complete before merging
Complex Gateway
Complex merging and
branching behavior that is not
captured by other gateways
Exclusive Event-based Gateway
(instantiate)
Each occurrence of a subsequent
event starts a new process
instance
Parallel Event-based Gateway
(instantiate)
The occurrence of all subsequent
events starts a new process
instance
Multi Instance Pool
(Black Box)
Conversation
Sub-Conversation
Pool
(Black Box)
Participant B
The order of message
exchanges can be
specified by combining
message flow and
sequence flow
Pool
Pool
Pools (Participants) and Lanes
represent responsibilities for
activities in a process A pool
or a lane can be an
organization a role or a
system Lanes subdivide pools
or other lanes hierarchically
Lane
Task
Lane
Task
Pool
Message Flow symbolizes
information flow across
organizational boundaries
Message flow can be attached
to pools activities or
message events The Message
Flow can be decorated with
an envelope depicting the
content of the message
Data
Out-
put
Data Store
A Data Object represents information flowing
through the process such as business
documents e-mails or letters
A Data Store is a place where the process can
read or write data eg a database or a filing
cabinet It persists beyond the lifetime of the
process instance
A Data Input is an external input for the
entire processA kind of input parameter
A Collection Data Object represents a
collection of information eg a list of order
items
Collaboration Diagram
Pool (W
hit
e B
ox)
Lane
Lane
Choreographies
Choreography Diagram
A Choreography Task
represents an Interaction
(Message Exchange)
between two Participants
Choreography
Task
Participant A
Participant B
A Sub-Choreography contains
a refined choreography with
several Interactions
Multiple
Participants Marker
Swimlanes
BPMN 20 - Business Process Model and Notation
Collection
Ad-hoc Subprocess
Task
Task
~
Message
Start Event
Message Flow
Data Object
Collapsed
Subprocess
Event-based
Gateway
Escalation
End Event
Timer
Intermediate
Event
Receive Task
Attached
Intermediate
Timer Event
Link
Intermediate
Event
Manual Task
End
Event
Data
Store
Link
Intermediate
Event
Parallel
Multiple
Intermediate
Event
Text Annotation
Group
Multi Instance
Task (Parallel)
Message
End Event
Send Task
Parallel
Gateway
Exclusive
Gateway
Attached
Intermediate
Error Event
Signal
End
Event
Call Activity
Subprocess
Event Subprocess
Conditional
Start Event
Error End
Event
Start
Event
End
Event
Looped
Subprocess
condition
httpbpmbdeposter
Participant A
Participant C
Participant B
Choreography
Task
Participant A
Participant B
Choreography
Task
Participant A
Participant C
Initiating
Message
(decorator)
Response
Message
(decorator)
Choreography
Task
Participant B
Participant A
When splitting it routes the sequence flow to exactly
one of the outgoing branches When merging it awaits
one incoming branch to complete before triggering the
outgoing flow
Exclusive Gateway
Is always followed by catching events or receive tasks
Sequence flow is routed to the subsequent eventtask
which happens first
Event-based Gateway
When used to split the sequence flow all outgoing
branches are activated simultaneously When merging
parallel branches it waits for all incoming branches to
complete before triggering the outgoing flow
Parallel Gateway
A Call Conversation is a wrapper for a
globally defined Conversation or Sub-
Conversation A call to a Sub-conversation
is marked with a symbol
Sub-Choreography
Participant A
Participant C
Participant B
Call
Choreography
Participant A
Participant B
A Call Choreography is a
wrapper for a globally
defined Choreography Task
or Sub-Choreography A call
to a Sub-Choreography is
marked with a symbol
Input
A Data Output is data result of the entire
process A kind of output parameter
A Data Association is used to associate data
elements to Activities Processes and Global
Tasks
denotes a set of
Participants of the
same kind
Message
a decorator depicting
the content of the
message It can only
be attached to
Choreography Tasks
Pool
(Bla
ck
Box)
Pool (Black Box)
Pool
(Black Box)
copy 2011
Sta
ndard
Figure 8 BPMN events as presented in BPMN 20 Poster by BPM OffensiveBerlin (cf httpwwwbpmbdeindexphpBPMNPoster)
20 business process management
timer event This is a process (engine) generated event that getsenabled with the control flow reaching the event construct and firesonce the specified time has passed Since the firing is received as atrigger to the process it is always a catching event for the process Timerevent can be conditioned as a specific fixed date and time (2019-02-25
162514) as a time duration (50 min) and as a time cycle (every Mondayat 900 am) The timer event can be set as a start event except from thetime duration condition It can also be used as a catching intermediateevent including usage as a boundary event
23 petri nets
Petri nets are one of the most popular and standard techniques to rep-resent the behavior of concurrent systems [69] It is named after CarlAdam Petri who visioned the initial foundation for Petri nets in 1962The net is composed of places and transitions connected with directedarcs between them in a bipartite manner The transitions represent ac-tive components of a system such as activities events or gateways ina process On the other hand the places are used to model the pas-sive components eg the input place models the precondition and theoutput place models the postcondition of a transition We chose Petrinets for our mapping since it gives clearer implementation semanticsthan BPMN The Petri net semantics used here follow the definitionsproposed in [69] and [131]
A marking of a Petri net signifies the system state A marking is asnapshot of the distribution of tokens over the places of the net Thefiring of a transition can change the marking ie the state of the systemFiring of transitions are considered as atomic step The behavior ofthe system is described by all firing sequences of a net that start withan initial marking A single firing sequence is named as a trace Therelevant definitions are quoted in the following
Definition 22 (Petri Net)A Petri net is a tuple N = (P T F) with
bull a finite set P of placesbull a non-empty finite set T of transitions such that T cap P = empty andbull a flow relation F sube (Ptimes T)cup (T times P)
A marking of N is a function M P rarrN0 that maps the set of placesto the natural numbers including 0 M(p) returns the number of tokenson the place p isin P Let M be the set of all markings of N A Petri netsystem is a pair S = (NM0) where N is a Petri net and M0 isinM is theinitial marking A sequence of transitions σ = t1 t2 tnn isin N is afiring sequence iff there exist markings M0 Mn isinM such that for1 6 i 6 n transition ti changes the system from (NMiminus1) to (NMi)
23 petri nets 21
The set of traces = contains all firing sequences σ such that σ is enabledin M0
The simplest form of Petri net is a Condition Event Net where theplaces represent conditions and the transitions represent events If acondition is met then there is a single token on the place representingthat condition and it enables the firing of the succeeding event Notethat a transition is enabled only if there is no token on any output placeof the event which is not an input place as well A Place TransitionNet on the other hand allows multiple tokens in a place The numberof tokens in a place is generally unbounded Depending on the needof workflow the number of tokens in an input place (to be consumedby events) and number of tokens in an output place (to be producedby events) can be defined using a weighing function Extensions of
Petri netsThe classic Petri
nets are representations of discrete states as defined by their markingsIn real-life workflows however continuous parameters such as time isoften an important concern There exist hybrid Petri nets where time-dependency of a place transition and arc can be described Time PetriNet Timed Petri Net and Petri Net with Time Windows are such exten-sions [100]
Another aspect that is ignored in the traditional Petri nets is the dif-ferentiation of the tokens based on the data they carry Coloured PetriNets (CPN) address this shortcoming by extending Petri nets with datahandling concepts The places are typed with a colour set that deter-mine the data type of the tokens that can be kept in that place Incomplement the tokens are assigned definite colours ie values of thespecified data type The flow arcs are annotated with arc expressionsthat contain functions and variables The arc expressions specify howtokens might be consumed and produced upon firing of a transitionAdditionally the transitions are restricted with guard conditions whichare Boolean predicates that need to be true to fire the transition Thedefinition of Coloured Petri Net is given in the following based on thedefinitions provided in [63 135] An exhaustive discussion on differentkinds of Petri nets is found in [104]
Definition 23 (Coloured Petri Net)A Coloured Petri net is a tuple CN = (ΣP T ANCEG) with
bull a non-empty finite set Σ of typed colour setsbull a finite set P of placesbull a non-empty finite set T of transitions such that T cap P = emptybull a finite set A of arc identifiers such that Pcap T = PcapA = T capA = emptybull a node function N Ararr (Ptimes T)cup (T times P)bull a colour function C that associates the places with a typed colour
set such that C P rarr Σbull an arc expression function E Ararr Expr and
22 business process management
bull a guard function G T rarr BooleanExpr
The initial marking of CN follows the same semantics as that of N aspresented in Definition 22 In addition we define a list of m elementsas l = 〈x1 xm〉 to specify arc expressions and guard conditions |l| =m denotes the length of the list The i-th element of the list is referredas l(i) = xi
24 bpmn to petri net mapping
In the design and analysis phase of business process management lifecy-cle (Section 21) the processes are verified and simulated after modelingto make sure that it is sound and free from any deadlock or livelockBPMN satisfies the requirements to be an expressive and user-friendlygraphical notation to design processes efficiently However when itcomes to static analysis BPMN lacks the needed unambiguity and clearformal semantics for model checking [63] On the other hand there arepopular tools for semantic analysis that uses Petri nets as inputMotivation Map-ping BPMN process structures to Petri nets thus assigns clear semanticsto the process behavior and enables the model to have a proper analy-sis This section describes the mapping of core BPMN elements to Petrinets as formulated by Dijkman et al [37] The mapping focuses on thecontrol-flow aspects of BPMN and abstracts from the organizational as-pects such as pools and lanes Only the relevant concepts are discussedhere the readers are referred to the main paper for more details Thework in this thesis further extends this formalism with the concepts forevent handling (cf Chapter 7)
task A task in a BPMN process is mapped to a transition with thesame label in Petri net The transition has one input and one outputplace that connects it with the predecessor and successor node respec-tively For a task T x denotes the predecessor node of T y denotesthe successor node of T Places with dashed borders mean they are notunique to one module ie they can be used to connect with other mod-ules that map other BPMN artifacts Figure 9 visualizes the mapping
gateways The fork and join gateways for both XOR and AND aremapped to silent transitions that represent their routing behavior TheXOR split has one common place for all outgoing branches that is fol-lowed by separate silent transition for each branch This captures thedata-driven decision alternatives and the exclusivity of the branchesThe AND split shares the token from one place to the parallel branchesthrough a single transition The XOR join merges the transitions foreach branch to a common output place for passing the token to nextnode whereas in case of an AND join the corresponding silent transi-tion needs a token in each branch for firing For event-based gateways
24 bpmn to petri net mapping 23
BPMN Task ltPetri net Module
Figure 9 Mapping of BPMN task to Petri net modules
BPMN Gateway ltPetri net Module BPMN Gateway ltPetri net Module
BPMN Gateway ltPetri net Module
Figure 10 Mapping of BPMN gateways to Petri net modules
the silent transitions are replaced by transitions reflecting each eventafter the gateway These transitions share a common place for havingthe input token to capture the racing situation Figure 10 shows BPMNgateways and corresponding Petri net modules x x1 x2 denote thepredecessor nodes and yy1y2 denote the successor nodes of gateway
events According to the mapping techniques by Dijkman et al theintermediate events are mapped exactly in the same way as the tasksmdash a transition with the same label as the event with one input andone output place to connect to the previous and next node as shownin Figure 11 However a start event does not have any incoming edgeand is mapped to a place followed by a silent transition that signalsthe instantiation of the process Similarly an end event does not havean outgoing edge which is reflected by the silent transition in the thatleads to the end place
The boundary events are mapped to transitions with same label thatshare a common input place with the transition mapping the associatedtask as presented in the Petri Net Module in Figure 12 Boundary eventAs long as thetask is not executed the event can steal the token from the common
24 business process management
BPMN Event ltPetri net Module
Figure 11 Mapping of BPMN event constructs to Petri net modules
place and fire to initiate the exception handling path Note that themapping of boundary event according to Dijkman et al [37] assumesatomic execution of the associated task Precisely the firing of the tran-sition mapped to the associated task means the task has been executedtherefore ldquoterminatedrdquo Once the task is terminated the boundaryevent can not occur any more since the token from the shared inputplace is consumed by the task In case the boundary event occurs be-fore the task is terminated the event consumes the token instead As aresult the task can not terminate any more
BPMN Event ltPetri net Module
Revised Petri net Module
Figure 12 Mapping of BPMN boundary event construct to Petri net module
However the semantics of boundary event demands to consider theduration of the associated task explicitly since the token from the com-mon place is allowed to be stolen by the event only when the task is inthe ldquorunningrdquo state Moreover the associated task has to be cancelled ifthe boundary event occurs The Revised Petri Net Module with separatetransitions for the beginning of task T (Tb) termination of task T (Tt)and cancellation of task T (Tc) is shown in Figure 12 Here the sharedplace for the boundary event and the termination of the task receivesthe token only after the activity has begun Now the previous semantic
24 bpmn to petri net mapping 25
of a racing condition between the transitions depicting the boundaryevent e and the termination of the task Tt apply If the boundary eventdoes not occur when the activity is running the task terminates at adue time and the next node in the normal branch is activated shownby the place P(Tty1) On the contrary once the boundary event occursbefore the activity terminates a token is placed at the input place ofthe transition Tc as well as at the input place of the next node in theexceptional branch shown by the place P(ey2)
3C O M P L E X E V E N T P R O C E S S I N G
An event is a specific occurrence at a specific point in time These events formstreams of information that can be analyzed to gain insight about the series of
happenings Complex event processing (CEP) is the field of research toinvestigate the concepts and techniques for efficient processing of the large
number of events which could be related to each other by causal temporal orstructural means Event processing enables the analysis and automation of
information exchange between distributed IT systems that can be beneficial toseveral application domains such as health care logistics surveillance
agriculture production line and the Internet of Things (IoT) The currentthesis exploits complex event processing techniques to make business
processes aware of and reactive to a relevant contextual occurrence leading toincreased efficiency and flexibility This chapter introduces the basic concepts
from the CEP area followed by detailed event processing techniques used inthe course of this work
31 basic concepts
In the business process management world the term event can referto several overlapping yet distinguishable concepts The state changesduring process execution are recorded by the process engine in an eventlog These are generally known as transitional events The state changesin activity lifecycle discussed in Section 221 will generate such eventseg beginning and termination of a certain activity Process miningapplications rely on these event logs for process discovery [1] TheBPMN events described in Section 222 refer to the event nodes definedin BPMN standard to model the communication of a process with itsenvironment These nodes are mapped to the actual outer world occur-rences known as external events
In essence events are anything that has happened (eg an accident)or is supposed to have happened (eg a fraud login attempt) at a spe-cific point in time in a specific context [46] In an everyday life weare surrounded by real events such as waking up with an alarm get-ting a coffee a train getting canceled on our way to work an accidenton the highway that makes us take a detour and finally reaching ourdestination The real events are digitized to create an event object anduse the information further Event objects or events can be generatedby sensors mobile devices business processes or even human beingsThese event sources or event producers can produce events in differentformats such as XML CSV RSS feed plain text email and so on Theentities listening to such events and using the information carried by
27
28 complex event processing
Sensors
Processes
Web API
Emails
Event Producers
Phone Call
RFID Tag
Event Consumers
Event Processing
Agents
Figure 13 Event processing network
the events are called event consumers Again event consumers can be aperson as well as a system eg a BPMS
However often the raw events produced by the event producers aretoo low-level for the event consumers For example a single login at-tempt might not be interesting but five consequent wrong login at-tempts might raise a fraud alert Hence Event Processing Agents (EPA)are employed to perform a large range of operations on events from sin-gle or multiple event sources Event producers event consumers andEPAs together form an Event Processing Network (EPN) Figure 13 showsthe entities and their connections in an event processing network
Events that occur in a stateless way are called atomic events They donot take any time to occur eg the single login attempt in previousexample But to come up with the fraud alert it is necessary to observefive consequent login events for the same account Here fraud alertcan be an example of a complex event Each atomic and complex eventhas a timestamp and an unique identification Additionally the eventsmight carry data often called payload which can be used in furtherapplications
An event producer produces events of specific types The events ofthe same event type are the instances of that type Each event of thesame type has the same structure The attribute values for events arespecific to that instance Based on the description above an event canbe defined as follows
32 event distribution 29
DBMS
query result
EPS(Queries
are stored)
event stream
subscription notification
(Data is stored)
Figure 14 Data in rest vs data in motion
Definition 31 (Event)An Event is a tuple E = (et id tspl) where
bull et is the event type ie the list of attributes with assigned datatypebull id is the identification ie the unique identifier assigned to each
eventbull ts is the timestamp ie the point in time when the event occurs
andbull pl is the payload ie the key-value pairs of the attributes of the
corresponding event type et
Both Event Processing Systems (EPS) and Database Management Sys-tems (DBMS) use query languages to calculate insightful results fromthe data However event processing in its essence has a complemen-tary orientation compared to DBMS Difference in
approach betweenEPS amp DBMS
In databases the data is storedand updated periodically The queries are fired on a set of static data toreturn results matching the queries For EPS the queries are registeredinstead The queries are checked with each new event in the eventstream(s) Whenever a matching event occurs the corresponding queryis satisfied Figure 14 visualizes the different approaches towards staticdata and dynamic data
32 event distribution
In an event processing network the event producers event processingagents and event consumers communicate through their interfaces andmay follow different communication patterns The event producers andevent consumers can talk directly to each other They might also com-municate indirectly through a channel ndash such as a network of EPA(s) anevent bus or an event processing platform The communication can beeither pull-style or push-style in nature In a pull-style communicationthe initiators of the conversations send requests to fetch the informationfrom the producers and waits till the reply is received before they canstart working on the next task [46] Thus pull-style communication
30 complex event processing
Pull
RequestResponse
Anonymous RequestResponseIn
dire
ct
Push
Callback
PublishSubscribe
Dir
ect
Figure 15 Communication models for event distribution
is synchronous in nature On the contrary in push-style communica-tion the initiator invokes the communication keeps working on othertask(s) and receives the response at a point of time in future withoutwaiting idly for it making the communication asynchronous in natureBased on the above two aspects the communication models for eventdistribution can be classified as shown in Figure 15
requestresponse model Requestresponse model is followedextensively in service-oriented architectures and distributed computingHere the initiator directly sends the request for information or updatesuch as a client-server framework or a remote procedure call The serverthen sends the information or a confirmation that the update request isreceived respectively The nature of requestresponse communicationis usually synchronous
anonymous requestresponse model This is similar to re-questresponse but the provider is not specified directly [89] Insteada random provider or a set of providers receive the request For exam-ple in the shared car system Uber1 a set of nearby drivers are informedwhen the passenger sends a request
callback model Following this communication model the con-sumers subscribe for specific events directly to the producers along witha callback address After the subscription is done the consumers canfocus on other tasks since callback is asynchronous in nature Once thesubscribed event occurs the event producer pushes the notification tothe consumers who have already subscribed for the specific event sincethe producer has the callback addresses of the consumers
While callback method is popular as part of the programming lan-guage Java a non-technical example of callback model can be orderinga meal in a restaurant ndash the consumer orders a specific meal and talksto other people or works on her laptop When the meal is ready she isserved the meal at her table Thus callback is a direct but asynchronouscommunication between the producer and the consumer
1 httpsmediumcomnarengowdauber-system-design-8b2bc95e2cfe
33 event abstraction 31
publishsubscribe model Event-driven systems use publish-subscribe principle [58] intensively to access event information This issimilar to callback but the producers and consumers do not commu-nicate directly rather they are connected through a channel such as amessage queue or an event service In a subscription-based publish-subscribe model consumers register their interest in specific events byissuing a subscription Whereas in an advertisement-based publish-subscribe model the producers issue advertisements to show their in-tend to publish certain events in future Following the advertisementthe consumers subscribe for the events they want
Once a consumer subscribes to an event it can consume the eventwhenever it occurs and as many times as it occurs If the consumerissues an unsubscription for the event at a certain point no furtherconsumption of that event is possible by that specific consumer Alsothe producer might choose to unadvertise a specific event at some point
Publishsubscribe communication model has the following advan-tages over the other communication models making it the popularchoice for event-driven architectures for the last two decades [46 58 89]
bull This is a push-style distribution ie the consumer subscribesonce and until unsubscription the event notifications are pushedby the channel as soon as and as many times as it has a matchingevent to distribute The other communication model such as re-questresponse on the other hand is pull-style ie the consumerneeds to fetch the event in a regular basis to have updated noti-fication about the event occurrence The push-style makes pub-lishsubscribe more efficient in terms of processing latency andoverhead for the consumers [89]
bull Being an indirect interaction pattern the producers and consumersare connected through an intermediate channel not being awareof each other This supports loose coupling such as easy addi-tion and deletion of the consumers and reuse of events Theevent producer do not need to keep track of the consumers andthe event consumers can have multiple subscriptions to multipleevent sources since the task of event distribution is delegated tothe dedicated event service
bull Finally the asynchronous communication allows the consumersto work on other tasks rather than waiting idly for the event oc-currence
33 event abstraction
The main goal of event processing is to interpret the data representingenvironmental occurrences in a meaningful way Thereby it is impor-tant to find the connections between the events An event hierarchy rep-resents the intra- and inter-relations among events from separate event
32 complex event processing
Process Execution
Event Sources
Event Logs
Event Abstraction
legend
Other data sources
Figure 16 Applications of event abstraction in context of process execution
streams The raw events produced by the event sources are clusteredtogether using temporal or semantic information Afterwards the clus-tered events are used to derive business events for consumers Thenotion of deriving information ready to be analyzed from events thatare recorded at a lower granularity is known as event abstraction [74]
Event abstraction is used in several application domains to hide thecomplexity of event aggregation and other operations (explained laterin Section 34) done on raw event streams In process mining this isvastly used to prepare the event log for process discovery The dataelements are grouped by means of clustering [54] and supervised learn-ing techniques [119] to map to a single event representing an activitystate change More advanced techniques include exploring behaviouralstructures that reveal activity executions via identifying control flowpatterns such as concurrency loops and alternative choices [83] Natu-ral language processing enriched with contextual information [11 106]is also a popular technique for event abstraction when a process modelis available Further insight about the domain and context of processexecution leads to successful event abstraction that enables mappingsensor data to engine logged events [114] Since the context data is notalways available in a single database event abstraction on several datastores used by process execution might be efficient [16]
The areas with process execution in the center of application for eventabstraction is shown in Figure 16 where the arrows depict use of eventabstraction techniques The above mentioned works in the process min-ing area concentrate on the event hierarchy from low-level data ele-ments from several sources to higher-level events logged by the processengine and from the event log to activity execution in a process On thecontrary the focus of this work is on event abstraction applications fromthe event sources to process execution [67] Using the term abstractionin this context signifies coming up with the higher-level events required
33 event abstraction 33
Timestamp Location Status of Packet
2019‐02‐27 171932 Shipped
2019‐02‐27 145600 Warehouse Package left warehouse
2019‐02‐27 085434 Warehouse Awaiting shipment
2019‐02‐26 175555 Warehouse Awaiting packaging
2019‐02‐26 171505 Warehouse Order confirmed and Awaiting picking
2019‐02‐26 171409 Warehouse Order paid successfully
2019‐02‐26 171310 Warehouse Order submitted
Packet dispatched
Online Shop
Customer
Figure 17 Event abstraction for order tracking in an online shop
by the event consumers such as process engines from the layers of low-level events generated by the event sources such as sensors
A real-life example of such an application of event abstraction is vi-sualized in Figure 17 Upon receiving an order an online shop tracksthe status of the packet However only when the order is confirmedpicked packaged and shipped the customer gets notified about thepacket being dispatched Here the internal events are important forthe online shop to monitor that the shipment of the packet followedcorrect steps but they are too fine-granular for the customer
To realize event abstraction the EPAs operate on event streams gen-erated by the event sources An event stream consists of a set of eventsof the same event type Performing operations on events can be done indifferent multitudes depending on the event hierarchy needed to comeup with the higher-level business event from the low-level raw eventsIt can be classified in following three categories Simple Event Processing(SEP) mdash operations are done on a single event Event Stream Process-ing (ESP) mdash more than one events from the same event stream is ag-gregated and Complex Event processing (CEP) mdash multiple events frommultiple event streams are acted on The event streams with differentpossibilities of processing are shown in Figure 18
SEP ESP CEP
event stream 1
event stream 2
Figure 18 Stream processing operations on events
Often several EPA functionalities are consolidated in an Event Pro-cessing Platform (EPP) EPPs are able to connect to different eventsources perform complex event processing operations on the eventstreams and notify the BPMS about a specific happening We use the
34 complex event processing
event streams
registered unregistered1st clause satisfied matched
2nd clause satisfied
3rd clause satisfied
nth clause satisfied
partially satisfied
Figure 19 State changes for an event query in an event processing platform
terms EPP and CEP platform interchangeably in the thesis The advan-tages and underlying technicalities of integrating a CEP platform to aprocess engine are discussed further in Chapter 5
A CEP platform evaluates incoming event streams based on pre-defined rules for event abstraction known as event query The process-ing of an event query is represented as a state transition diagram in Fig-ure 19 Once the query is registered at the platform it is checked fora match on every event occurrence across the connected event streamsAn event query can have several clauses similar to Structured QueryLanguage (SQL) queries Once the first clause is satisfied the queryenters the state partially satisfied Depending on the complexity thequery stays in this state for a while although the internal state changeswith each clause being satisfied As soon as the last (n-th) clause is sat-isfied the query is considered to be matched A query can be matchedseveral times until it is unregistered from the platform visualized withthe loop sign inside the partially satisfied state The next section intro-duces the complex event processing techniques that can be applied onevent streams to build an event hierarchy by satisfying clauses of anevent query
34 event processing techniques
Event processing operations can be classified in three major categoriesnamely filtering grouping and derivation A brief introduction about theEPAs are given below All the CEP techniques described below can beimplemented in flexible order and combination Figure 20 shows anexample event processing network We have two event producers andone consumer The filter agent takes the event streams from both theproducers as input Based on the filter expression (shown as the roundcorner rectangle inside the EPA) it filters in a subset of input events andfeed to the group EPA The group EPA then clusters the filtered eventsaccording to the grouping criteria Next the derive EPA composes ahigher level event from each group and sends them to the consumer
Query languages (similar to SQL) are built for the specific purpose ofwriting queries that can process the event streams We follow the syn-
34 event processing techniques 35
Event Producer 2
Event Consumer
Group EPA
DeriveEPA
Filter EPA
Event Producer 1
Figure 20 An example EPN showing the different components
tax and semantics of ESPER Event Processing Language (EPL)2 whichis a declarative domain specific language based on SQL designed forprocessing events with time-based information As a running examplethroughout this section let us think of a bank issuing credit cards tocustomers who also have a standard account at the bank Each creditcard transaction is recorded to the bank with transaction id customername the status of the card (silvergoldplatinum) the amount cred-ited along with the purpose and the location (country) where the trans-action was initiated The event type Transaction is represented as XMLschema definition in Listing 1
Listing 1 Event type definition of Transaction
ltxml version= 10 encoding=utfminus8gtltxsschema xmlnsxs= httpwwww3 org2001XMLSchemaxmlns=Transaction xsd targetNamespace=Transaction xsdelementFormDefault= qualified gtltxselement name=Transactiongt
ltxscomplexTypegt
ltxssequencegt
ltxselement name= transactionId type= xsstring minOccurs=1 maxOccurs=1 gt
ltxselement name=customerName type= xsstring minOccurs=1 maxOccurs=1 gt
ltxselement name=cardStatus type= xsstring minOccurs=1 maxOccurs=1 gt
ltxselement name=creditAmount type=xsdoubleminOccurs=1 maxOccurs=1 gt
ltxselement name=purpose type= xsstring minOccurs=1 maxOccurs=1 gt
ltxselement name= location type= xsstring minOccurs=1 maxOccurs=1 gt
ltxssequencegt
ltxscomplexTypegt
ltxselementgt
ltxsschemagt
filtering Filtering is a stateless operation performed on a singleevent stream It is done based on the evaluation of certain filter ex-pressions on event attributes If the filter expression evaluates to true
2 httpesperespertechcomrelease-550esper-referencehtmlindexhtml
36 complex event processing
T_Filteredbull transactionIdbull customerNamebull cardStatusbull creditAmountbull purposebull location
Transactionbull transactionIdbull customerNamebull cardStatusbull creditAmountbull purposebull location
T_Aggregatedbull avgCredit
T_Projectedbull transactionIdbull creditAmountbull purpose
FraudAlertbull t1 (transactionId)bull t2 (withdrawalId)bull customerNamebull location1bull location2bull amountbull purpose
T_Enrichedbull transactionIdbull customerNamebull cardStatusbull creditAmountbull purposebull locationbull dollarAmountbull serviceCharge
Withdrawalbull withdrawalIdbull customerNamebull amountbull purposebull location
T_Translatedbull transactionIdbull customerNamebull cardStatusbull creditAmountbull purposebull locationbull dollarAmount
Figure 21 Event hierarchy showing Transaction and events derived from it
then the event is sent to the output stream otherwise it is discardedThe bank might want to know all credit card transactions done by theirplatinum customers There an event filter can be implemented withfilter expression TransactioncardStatus = lsquoPlatinumrsquo
grouping Grouping EPAs take single or multiple event streams asinput and produces clusters of events as output Grouping can be per-formed based on time number of events location and attribute valuesIn context of the credit card example fixed time window (all transac-tions during weekend) or sliding time window (transactions in eachhour) can be used as temporal grouping
Similar to the time interval events can also be used to determine theinterval boundaries In this case continuous event window or slidingevent window can be defined A customer can be charged for the trans-actions initiated each week This is an example for continuous eventwindow On the other hand to be alerted of misuse of the credit cardevery three ATM withdrawal events following an overseas withdrawalcan be monitored Sliding event window will be appropriate for track-ing the withdrawals in this case
Related to the credit card scenario location based grouping can alsobe useful eg all withdrawals outside Euro zone should be grouped tobe charged for currency conversion Last but not the least the eventscan be grouped based on a specific attribute value If the bank provid-ing credit cards wants to know how many transactions over 500 Eurotake place on average for the platinum card holders they might groupall filtered events with TransactioncreditAmount gt 500
derivation The derivation EPAs can take single events or groupsas input and modify them in several ways as shown in Figure 21 Aproject EPA takes a single event selects a subset of its attributes andproduces a corresponding event Here the number of attributes are
34 event processing techniques 37
reduced but no attribute value is changed For example the bankmight want to know how much amount is credited for which purposesuch as online shopping or travel booking Therefore they generate aprojected event from each Transaction event as presented in Listing 2
Listing 2 Example of Project EPA
INSERT INTO T_Projected
SELECT ttransactionId as transactionId
tcreditAmount as creditAmount
tpurpose as purpose
FROM PATTERN[every t=Transaction]
On the contrary an enrich EPA adds more attribute to an event addingdata from external sources A translate EPA can also add attributes bymodifying an existing attribute value rather translating an attributevalue to a corresponding value For example the amount in a creditcard transaction can be changed from Euro to Dollar using translationAfterwards service charge for conversion can be added according to thebank rate stored separately as shown in Listing 3 followed by Listing 4
Listing 3 Example of Translate EPA
INSERT INTO T_Translated
SELECT ttransactionId as transactionId
tcustomerName as customerName
tcardStatus as cardStatus
tcreditAmount as creditAmount
tpurpose as purpose
tlocation as location
(tcreditAmount)114 as dollarAmount
FROM PATTERN[every t=Transaction]
Listing 4 Example of Enrich EPA
INSERT INTO T_Enriched
SELECT trtransactionId as transactionId
trcustomerName as customerName
trcardStatus as cardStatus
trcreditAmount as creditAmount
trpurpose as purpose
trlocation as location
trdollarAmount as dollarAmount
(trdollarAmount)rate as serviceCharge
FROM PATTERN[every tr=T_Translated]
An aggregation EPA takes groups of events as input A single event isderived from one group of events aggregating them based on certain at-tribute values Calculating average credit amount for the platinum card
38 complex event processing
holders on a day can be an example of aggregation as shown in thelisting below Other operations can be to calculate the maximummini-mumtotal amount and the number of transactions
Listing 5 Example of Aggregation EPA
INSERT INTO T_Aggregated
SELECT Avg(creditAmount) as AvgCredit
FROM T_Filteredwintime(24 hour)
Compose EPA on the other hand takes input events from multipleevent streams and comes up with a composed event as output Theseevents from different streams can be joined based on common attributevalues can be used to identify a pattern based on their order of occur-rences or can be calculated to identify a certain trend among manyother possibilities [34 127] A fraud detection rule can be brought upin this context As obvious along with the credit card transactionsthe bank also records all the ATM withdrawals for its customers Nowif a withdrawal is observed within an hour of a credit card transactionwhere the location of withdrawal is a different country than the locationof initiating the transaction a misuse of the card is suspected
The event type Withdrawal and FraudAlert are defined in Listing 6whereas the rule for composing the fraud alert can be written usingEsper EPL is shown in Listing 7
Listing 6 Event types Withdrawal and FraudAlert
ltxml version= 10 encoding=utfminus8gtltxsschema xmlnsxs=httpwwww3 org2001XMLSchemaxmlns=Withdrawal xsd targetNamespace=Withdrawal xsdelementFormDefault= qualified gtltxselement name=Withdrawalgt
ltxscomplexTypegt
ltxssequencegt
ltxselement name=withdrawalId type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name=customerName type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name=amount type=xs doubleminOccurs=1 maxOccurs=1 gt
ltxselement name=purpose type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name= location type=xs string minOccurs=1 maxOccurs=1 gt
ltxssequencegt
ltxscomplexTypegt
ltxselementgt
ltxsschemagt
34 event processing techniques 39
ltxml version= 10 encoding=utfminus8gtltxsschema xmlnsxs=httpwwww3 org2001XMLSchemaxmlns=FraudAlert xsd targetNamespace=FraudAlert xsdelementFormDefault= qualified gtltxselement name=FraudAlertgt
ltxscomplexTypegt
ltxssequencegt
ltxselement name= t1 type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name= t2 type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name=customerName type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name= location1 type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name= location2 type=xs string minOccurs=1 maxOccurs=1 gt
ltxselement name=amount type=xs doubleminOccurs=1 maxOccurs=1 gt
ltxselement name=purpose type=xs string minOccurs=1 maxOccurs=1 gt
ltxssequencegt
ltxscomplexTypegt
ltxselementgt
ltxsschemagt
Listing 7 Example of Compose EPA
INSERT INTO FraudAlert
SELECT ttransactionId as t1
wwithdrawalId as t2
tcustomerName as customerName
tlocation as location1
wlocation as location2
wamount as amount
wpurpose as purpose
FROM PATTERN[every(t=Transaction-gtw=Withdrawal)]wintime(60 min)
WHERE tcustomerName=wcustomerName
AND tlocation=wlocation
To test the event processing operations all the event types and eventprocessing rules discussed above have been defined in Unicorn3 anevent processing platform that uses the Esper engine and EPL for ex-ecuting queries Upon receiving a Transaction event followed by aWithdrawal event Unicorn produces the list of events shown in Fig-ure 22
3 httpsbpt-laborgunicorn-dev
40 complex event processing
Figure2
2Screenshotfrom
Unicorn
showing
generationof
complex
eventsfollow
ingpre-defined
rules
4R E L AT E D W O R K
ldquoWhat do researchers know What do they not know What has beenresearched and what has not been researched Is the research reliable and
trustworthy Where are the gaps in the knowledge When you compile allthat together you have yourself a literature reviewrdquo
ndash Jim Ollhoff How to Write a Literature Review1
41 overview
In this chapter we outline the existing research that are closely relevantto the work presented in this thesis To begin with the literature reviewthe status of using external events in BPM is discussed in Section 42having a focus on the IoT context This is helpful for positioning thethesis with respect to the significance of the contribution and the chal-lenges associated with it As narrated in Chapter 1 this thesis builds adetailed subscription management system based on a basic frameworkintegrating external events into business processes Therefore the basicintegration work involving CEP and BPM are explored in Section 43This section highlights the use of concepts from complex event process-ing area in different phases of business process management lifecycleand the integrated applications that exploit concepts from both CEPand BPM fields Next the event subscription mechanism and eventbuffer middlewares from BPM world as well as related research fieldsare discussed in Section 44 The chapter ends with a summary of re-lated work in Section 45 The overview of the research areas coveredin this chapter is given in Figure 23
Related Work
External Events in BPM
Event Subscription amp
Buffering
IntegratedApplications
Figure 23 Overview of discussed research areas as related work
1 httpswwwgoodreadscombookshow19072895
41
42 related work
42 external events in bpm
Process executions are often supported by dedicated IT systems and thetransitional events are logged by enterprise software systems to recordthe state changes in the cases correlated to the business processes Thisresults in event streams that can be used as input for several applica-tions related to business process analytics [40] such as process discoverycompliance checking with respect to process specification violationsand finding the performance bottlenecks Ever since the IoT enabledbig data got accessible by the IT systems new business scenarios areraising that can exploit the era of digitization [53] This leads to usenot only the transitional events but also the external events as sourceof information to have better process analytics However using IoTconcepts in BPM and (vice versa) calls for a detailed understandingof the IoT field [38] shows the important building blocks for IoT busi-ness model based on an extensive survey represented with the BusinessModel Canvas2Understanding the
Internet of ThingsTo understand the actors in IoT applications and the
interactions between them detailed surveys are available that list thecommonly used technologies concepts and architectures for an IoTproject [6] More focused classification applicable in a BPM context canbe found in [82] where the authors traverse through a large number ofIoT scenarios and suggest certain usecases where BPM and IoT can ben-efit from each other For instance to employ a BPMS as the controller ofthe interacting things ie the sensors actuators and complex devicescan help to monitor the big picture of a distributed IoT application
The use of external events in business processes in an IoT contextis also being explored in multiple recent work In [112] the authorssuggest that IoT applications are data-intensive where the data needspre-processing for getting ready for analysis These data might triggerbusiness activities in real time communicated through ubiquitous com-munication means to the users To handle these features of IoT environ-ment process models need to be re-engineered mdash either with extendedmodelling elements or with rearrangement of the activities To bridgethe abstraction gap of raw data and business events in execution leveluse of context variables is suggested In a related publication realizingthe requirements [111] the authors argue that for an IoT-aware processexecution setup a BPMS must be aware of current values of IoT objectswhile the defined variable must be referenced in the executed processmodel Moreover the responsible users executing the tasks must benotified on mobile devices in real time about the context-specific knowl-edge according to the access rights of the users As an evaluation of theconcepts the authors conducted a case study in corrugation industryThe real-world objects such as the IoT devices were connected to hu-man operators using wearable devices A BPMS controlled the dataexchange via a communication middleware that includes an IoT data
2 httpswwwstrategyzercomcanvasbusiness-model-canvas
42 external events in bpm 43
server A group of operators with wearable IoT devices received statusof the ongoing activities remaining time to start the next activity anderror messages where the other group did not use any wearable device
IoT-aware processexecution
The study shows application of the IoT enhanced BPMS leads to lessmachine stops because users had context information that helped themto recognize the reactions needed to a situation in an efficient way
Events are usual representations for exceptions in business processcontext Recent studies show that exceptions are an inevitable yethighly influencing factor when it comes to performance of a process [39]The survey classifies the exception patterns that might unsettle the nor-mal control flow and evaluates the throughput time for each of thepatterns The case study presented in [129] shows similar results abouthandling unprecedented events and process performance for declara-tive process execution as well Here two groups of students (non-experts) had to execute a journey in order to meet a predefined busi-ness value keeping in mind certain constraints One group had nounexpected event whereas the other group encountered with increas-ing time of activities and traffic disruption that caused the participantsto rearrange the journey partially Business value and number of failedjourneys were calculated as evaluation parameters The results showthat the participants having to adapt to unforeseen environmental oc-currences had significantly higher difficulty to plan the journey
While the advantages of integrating IoT and BPM are already es-tablished the challenges are being investigated as well In [108] itis claimed that BPM is still not ready to utilize the huge benefits bigdata analytics can offer The authors classify data-intensive operationsin BPM into following categories event correlation process model dis-covery conformance checking runtime compliance monitoring processenhancement and predictive monitoring They propose the term pro-cess footprints that include process model transitional events logged bythe IT systems external events ie sensor data received during processexecution as well as any social media interaction or user interactionthat happens in the enactment phase All these source of informationare highly valuable since delay or non-detection of any of those canhave a harmful impact on the organizations
An exhaustive discussion on the mutual benefits and challenges ofIoT and BPM is found in [61] The list of challenges cover the completeintegration aspects such as the physical deployment of sensors in a cost-effective way visualization of both automated activities and manualtasks considering new scenarios that are sometimes unstructured anddistributed Challenges of
integrating IoT ampBPM
having loosely coupled small fragments of processes ratherthan a big predefined process coming up with specifications for theabstraction level and autonomous level Also the social role of the pro-cess participants is discussed in this context The technical challengesmention that large amount of available data demands advanced guide-
44 related work
lines for event handling online conformance checking and resourceutilization
Another significant research work by Soffer et al [117] explores thechallenges and opportunities with respect to integrating event streamsand business process models The authors detect four key quadrantsfor combining CEP and BPM according to BPM lifecycle phases Enrich-ing expressiveness of process models in design phase and using CEPconstructs for process mining in evaluation phase look at the integra-tion aspects from CEP to BPM In configuration phase deriving CEPrules from process models is proposed to determine which activitiesto monitor and which event occurrences are important to notice Fur-ther executing processes via CEP rules in execution phase is proposedThis essentially means mapping external (sensor) events to transitionalevents to automate beginning and termination of an activity withoutinvolving the user The configuration and execution phase here focuson the flow of control from BPM to CEP For all of the key quadrantschallenges and benefits are discussed with the support of existing work
Having discussed the aspects and challenges of integrating events inbusiness processes to enable the collaboration with big data IoT andCEP the rest of the section showcases specific applications where theconcepts from CEP has been used in BPM scenarios
43 integrated applications
The concept of event driven business process management (EDBPM)has been already in discussion for more than ten years [128] So farseveral approaches have been presented aiming to extend BPMN withmodeling constructs for concepts of CEP [7 13 45] Krumeich et algive a comprehensive overview of the state-of-the-art in using eventsfor event-driven architectures (EDA) or BPM in [67] While some ofthose propose conceptual enhancement some provide execution sup-port in the form of an engine For instance the work by Kunz et al [68]suggest the mapping of event processing queries to BPMN artifactsThe authors propose to map the parts of an EPL query to an event-sensitive BPMN element (BPMN service task)Modelling
extensionsThe task reads the data
objects as incoming data flow to specify FROM clause takes data objectcollections to realize the SELECT clause Once the data values match theWHERE clause of the EPL query a boundary conditional event is fired totrigger the exceptional flow Another approach in the same line is byAppel et al [7] where the authors integrate complex event processinginto process models by means of event stream processing tasks thatcan consume and produce event streams An approach from the otherdirection is presented in [132] where event queries are derived fromthe control flow of a process model deploy them to an event engineand use them to find violations of the control flow A similar derivationof event queries from the process model is done by [10]
43 integrated applications 45
The authors in [13] suggest to integrate descriptions of event patternsinto process modeling languages and consequently extend engines tohandle such patterns as they argue that both process and events areintegral aspects to be captured together They present a catalog of eventpatterns used in real-world business processes and find that most ofthose patterns are neither supported by BPEL nor BPMN For examplethey identify support for event hierarchies ie abstraction of low-levelevents into high-level business events as an important feature whichis not yet supported Similar to modelling complex events configuringprocess models to model the interactions in an internet of things contextis addressed in [118] The author proposes modelling IoT resourceswrt shareability and replicability and builds a cross-domain semanticmodel with concepts from both BPM and IoT domain validated byprototype tools
Besides design level integration several execution level applicationshave been developed to take advantage of event processing conceptsfor business processes For instance [45] propose an IT solution archi-tecture for the manufacturing domain that integrates concepts of SOAEDA business activity monitoring (BAM) and CEP Application areasThey suggest toembed event processing and KPI calculation logic directly into processmodels and execute them in an extended BPMN engine The authorssketch such an engine for executing their extended process models butrefrain from giving technical details However they suggest that someprocesses collect simple events evaluate and transform them and pro-vide high-level events for use in other process instances realizing anevent hierarchy
For processes in which some tasks are not handled by the processoriented information system (POIS) monitoring of events can be usedto determine the state of these tasks eg to detect that an user taskterminated When a process is not supported by a POIS at all moni-toring can still capture and display the state of the process by meansof events For example Herzberg et al [56] introduce Process EventMonitoring Points (PEMPs) which map external events eg a change inthe database to expected state changes in the process model eg ter-mination of a task Whenever the specified event occurs it is assumedthat the task terminated thus allowing to monitor the current state ofthe process The authors separate the process model from the eventprocessing and allow the monitored events to be complex high-levelevents The approach has been implemented however the event datais not used by and does not influence the process activities Rather theengine uses them to determine the current state of the process instanceSimilar frameworks for predictive monitoring of such continuous tasksin processes are presented in [23 127] The framework by Cabanillaset al [23] defines monitoring points and expected behavior for a taskbefore enactment Event information from multiple event streams arecaptured and aggregated to have a meaningful insight These aggre-
46 related work
gated events are then used to train the classifier and later the classifiercan analyze the event stream during execution of the task to specifywhether the task is following a safe path or not
Processes from the logistics domain contain long-running activitiesand therefore needs continuous monitoring (eg shipment by truck)In these scenarios external events eg GPS locations sent by a trackingdevice inside the truck can provide insight into when the shipment taskwill be completed Appel et al [7] integrate complex event processinginto process models by means of event stream processing tasks that canconsume and produce event streams These are used to monitor theprogress of shipments and terminate either explicitly via a signal eventor when a condition is fulfilled eg the shipment reached the target ad-dress While these tasks are active they can trigger additional flows ifthe event stream contains some specified patterns The authors providean implementation by mapping the process model to BPEL and con-necting the execution to a component called eventlet manager that takescare of event processingProcess monitoring [18] takes one step further and shows howthe event driven monitoring influences the process execution in a multi-modal transportation scenario The authors use a controller that is usedas a dashboard for controlling and monitoring the transportation pro-cesses that is connected to an event processing platform The events im-pacting the transportation are visulaized in the dashboard In the back-ground the processes are executed in Activiti3 a BPMN-based processengine In this context another publication [17] explains a methodologyfor using events in business process monitoring and execution Basedon a usecase in logistics domain requirements and lessons learned aredescribed for process design execution and required event processingHere the authors argue that event subscription information should beannotated to the process model such that the subscription queries areautomatically registered to the event platform by a process engine
Another advanced monitoring approach is proposed in the recentresearch [85] The author suggest artifact-driven business process mon-itoring that considers the changes in the state of the artifacts participat-ing in a process to detect when activities are being executed Using thistechnology smart objects can autonomously infer their own state fromsensor data This approach is helpful for exploiting IoT paradigm whilemonitoring inter-organizational processes where a monitoring platformcan not cross the border of an organization SMARTifact an artifact-driven monitoring platform has been built as a prototype
Pufahl et al in [101] present another application of complex eventprocessing used for efficient decision making in business processesThe authors here consider updated event information to re-evaluate de-cision till the point a reset is possible To receive the updated eventsthe subscription query is enriched with the decision logic behind thecurrent execution path and only interrupts the execution if the event
3 httpswwwactivitiorg
44 flexible event subscription amp buffering 47
data result in a different decision More applications regarding eventprocessing in BPM are found in [5 33 91 113 138]
While the above research shows a large sample of applications inte-grating events and processes research are being done to enhance theperformance of such applications as well Fardbastani et al looks at adifferent aspect of process monitoring in presence of events [50] Theauthors argue that distribution of CEP responsibilities are needed to en-able large scale event-based business process monitoring They suggestto either distribute parts of event abstraction rules to multiple EPAsor to cluster CEP engines on independent computational nodes Performance
optimizationA dis-
tributed architecture named dBPM is developed based on the latter ideaThis includes several BPMSs coordinators that control resource utiliza-tion by routing the events from a BPMS to assigned CEP node(s) theCEP nodes and the event consumers A case study involving processesof customs administration shows increasing the number of CEP nodesleads to almost linear increase in the throughput of process monitoring
The approach proposed by Weidlich et al [133] looks at efficient waysof event pattern matching from another perspective The authors heremap different pattern matching rules to behavioral constraints that arederived from the process models Based on the knowledge extractedfrom the process model specification the probable event occurrencesequences are written in this approach The constraints elicited frombehavioural profiles [131] are considered while writing the valid eventsequences This in turn leads to an optimized performance with re-spect to event pattern matching following execution plans that includetemporal and context information for transitional events as well as thesubscription mechanism (pushpull) used to receive an event from theevent platform
44 flexible event subscription amp buffering
This section focuses on the specific work related to event subscriptionand buffering From a business process perspective there is very lim-ited research that includes flexible event subscription semantics The ex-isting integrated applications for event-process integration [17 113 140]and distributed systems [71 125] follow the basic publish-subscribeparadigm [58] to implement subscription and notification of events Thestate-of-the-art BPMN process engines [2 24] on the other hand real-ize the BPMN semantics of listening to an event when the control flowreaches the event node and ignore the scenarios demanding increasedflexibility in event handling
However there are few significant ones that have been great inspi-ration to our work For instance the causal relationship stated byBarros et al in [13] is the one we have extended for more explicitevent handling A comparison between the dependencies suggested bythe authors in [13] and the one followed by the event handling model
48 related work
proposed in this thesis is found in Section 62 The CASU frameworkproposed by Decker and Mendling [36] is another work that has highlyinfluenced our work The framework is built to conceptually analyzehow processes are instantiated by eventsSubscription
management inbusiness processes
The name of the frameworkis an abbreviation that considers when to create new process instances(C) which control threads are activated due to this instantiation (A)which are the remaining start events that the process instance shouldstill subscribe to (S) and when should the process instance unsubscribefrom these events (U) While this essentially talks about point of (un)-subscription as well as the duration of a subscription our work givesmore detailed and formal semantics Moreover the authors in [36] re-strict themselves to the start events whereas we focus on the interme-diate catching events that bring in much more variety and complexityin semantics
While on the one hand event subscription is neglected in BPM com-munity on the other hand this has gained a lot of attention in the com-plex event processing research Event-based systems such as JEDI [31]Hermes [99] STEAM [84] and event processing engines such as Cayunga[21] and ESPER offer detailed description about the subscription mecha-nism and the event processing middlewares A formal semantics of themiddleware designs for Enterprise Integration Patterns (EIP) is givenusing coloured Petri nets in [49]
In publish-subscribe system subscriptions can follow different mod-els [12] as listed below
bull Topic-based the subscriber shows interest in a specific topic andstarts getting notified about all the events related to that topic [14]
bull Content-based the subscriber specifies filtering conditions over theavailable notifications [4 31 99]Publish-Subscribe
models bull Type-based a specific event type is subscribed to [47]bull Concept-based subscription is done on a higher abstraction level
without knowing the structure or attribute of the events [29] andbull Location-aware location-aware notifications supporting the mobile
environment [84]Advanced event based system such as PADRES [60] takes into ac-
count the event information that has happened in the past in addition tothe traditional publish-subscribe mechanism that considers only eventsthat might happen in the future This event processing network consistsof several brokers which are essentially event processing engines Theseengines can talk to the next neighbors in the network using content-based publish-subscribe model For accessing historic events the bro-kers are attached to databases The subscribers can fetch the storeddata from the databases attached to the publishers The unsubscriptionis done once the requested result set has been published
Apache Kafka4 is a large-scale distributed streaming platform thatis renowned in industries as well as for academic applications Kafka
4 httpskafkaapacheorg
45 summary 49
implements topic-based subscription where consumers can subscribeto multiple topics These topics are stored as records with uniquekey-value pair with a timestamp MiddlewareThe combination of messaging stor-ing and stream processing functionalities added with the fault-tolerantdurable exchange of records offered by Kafka makes it a popular eventstream buffer
While most of the event stream processing platforms offer bufferingSax et al [109] handles data arrival with out-of-order timestamps with-out explicit buffering The approach prioritizes low processing of onlinedata handling over traditional data buffering and reordering of recordsThe dual streaming model proposed by the authors consists tables thatcapture the updates of data arrival for a streaming operator such asan aggregation operator with specific groupingfiltering conditions Inturn a changelog stream updates the records for an operator whenevera new record with the same key is available This retains the consistencyin the logical and physical order of data The model is implemented inApache Kafka to show the feasibility of the concepts
45 summary
Transitional events ie events logged by process engines and exter-nal events ie events received from environmental sources such assensors as well as hybrid approaches including both are used exten-sively for process analytics [40] This involves plenty of applicationsfor process discovery process conformance checking and process mon-itoring [1 7 17 23 56 85 127] Concepts from CEP research fieldhas already gained popularity for modeling [7 13 45 68] and exe-cuting [10 132] these integrated applications Data stream process-ing languages such as Continuous Query Language (CQL) [8] andcomplex event processing languages such as Esper EPL [44] offer abig range of operations to aggregate the events based on timestampsand attribute values More advanced event specification language likeTESLA [32] provide rules that are formally defined and considers therequirements of larger set of application scenarios Built on publish-subscribe communication style the distributed agent based systemssuch as PADRES [60] maintains the strong influence of event processingat its core
Recently integrated applications are being developed that enable theevent sources such as sensors to talk to each other as well as to talk toa controller eg a BPMS [82 112] This has two reasons On one handthe advent of IoT era makes the event information highly accessible forthe IT systems [6 38] and on the other hand new business scenariosare emerging that involve highly intense communication between theprocess participants and execution environment [53] At the same timehandling big data efficiently in BPMS [108] load balancing of CEP oper-ations for scalability [50] and optimization of event processing [133] are
50 related work
emerging to address the challenges of integrating external events andevent processing techniques in business process management [61 117]
Since the interaction plays a pivotal role in event driven process exe-cution it also demands a more flexible event handling mechanism [81]However even if there are several applications consisting of BPMN pro-cesses that exploit the information carried by the external events lessattention is given for a standardized generic event handling model
There exist significant amount of research work for flexible processexecution such as case management [35 57 70 103 110] Also thereare approaches that propose redesigning processes to avoid unwanteddelays and deadlocks [30 78] Nevertheless only a small set of workconsiders flexibility in terms of event subscription management Onthe contrary the complex event processing field is well enriched withconcepts and technicalities for subscription-notification event stream-ing and event buffering Our work addresses these shortcoming andproposes an advanced event handling model for more flexible commu-nication between processes and events
Part II
C O N C E P T U A L F R A M E W O R K
5I N T E G R AT I N G R E A L - W O R L D E V E N T S I N T OB U S I N E S S P R O C E S S E X E C U T I O N
This chapter presents the conceptual and technical challenges to enable a basicend-to-end integration of external event information into business processes
First the requirements have been elicited This includes design levelrequirements such as separation of business process specification and complex
event processing techniques as well as implementation level requirementssuch as event subscription and correlation Later the conceptual framework
has been proposed to address those requirements A prototypicalimplementation of the proposed framework is discussed in Chapter 9 The
integrated architecture has been published in ldquoA Framework for IntegratingReal-World Events and Processes in an IoT Environmentrdquo [80]
51 motivation amp overview
Business process management (BPM) and complex event processing(CEP) are well explored fields in their own right and it has alreadybeen established that they can complement each other significantly [46]Lately the development of Internet of Things (IoT) caused the availabil-ity of an abundance of data also referred to as big data explosion Busi-ness processes can take advantage of this era of digitization of physicalproperties and react to the environment as soon as there is a certainchange that might impact the process flow In other words event in-formation enhances business processes to be more flexible robust andefficient to take reactive measures
On the other hand complex event processing techniques providemeans to filter correlate and aggregate raw events produced by thesensors to come up with a more meaningful business level event IoT enabled business
processesThe
IoT raises business scenarios that were not possible before such as re-motely controlling devices in a smart home12 facilitating thousands ofgadgets in a smart factory3 or simply tracking valuable objects4 Thesescenarios include frequent communication between the devices sensingdata interpreting it and actuating the reactions BPM concepts can bebeneficial in controlling and monitoring these interactions [82] Emerg-ing applications of predictive monitoring in an IoT environment [5 91]
1 Samsung Family Hubhttpwwwsamsungcomusexplorefamily-hub-refrigerator
2 Nest Learning Thermostat httpsstorenestcomproductthermostat3 Daimler Smart Production httpwww-05ibmcomdepmq_assetspdfIBM_SPSS_
Case_Study_Daimler_depdf
4 DHL Luxury Freight Tracking httpwwwdhlfrenlogisticsindustry_sector_solutionsluxury_expertisehtml
53
54 integrating real-world events into business process execution
often employ CEP techniques to understand and detect the patterns ofenvironmental occurrences that might lead the system to a bad stateand complement it by triggering business processes for preventing thebad state in a proactive way
The work presented in this thesis revolves around the idea of inte-grating contextual information represented in form of events duringrun-time of a business process execution Even though there is lotof research going on individually in both the areas of BPM and CEPthere has been no solid guideline or framework to integrate these twoworlds conceptually as well as technically (cf Chapter 4 for more de-tails) Hence it was required to build an integrated architecture thatencompasses the whole cycle of event-process communication startingfrom aggregating raw events into business events via detecting andextracting the event information to map it to process variables up untilreacting to the event following a business process specification
The rest of the chapter is structured as follows first we identify therequirements to build an integrated architecture The requirements aredescribed with the help of a motivating example from the logistics do-main in Section 52 Based on the requirements the integrated systemarchitecture is presented in Section 53 Finally Section 54 summarizesthe chapter
The integrated architecture presented in this Chapter includes eventprocessing platform Unicorn (see Section 911) process engine Chimera(see Section 913) and process modeler Gryphon (see Section 912)Most part of Unicorn [18] and an initial version of Chimera known asJEngine [55] was developed before the author started working at thechair of Business Process Technology5 at Hasso Plattner Institute Uni-versity of PotsdamAcknowledgements However Unicorn and Chimera did not have anyinteraction yet and Gryphon did not exist either The integration frame-work was developed in the context of an industry project with BoschSoftware Innovations GmbH [20] The work presented in this Chap-ter is jointly developed with Marcin Hewelt partly as co-supervisors ofBachelor project for consecutive two years (2015-16 and 2016-17) andhas been published in CoopIS 2017 [80]
52 requirements analysis
An extensive analysis of the aspects to consider and the challenges toovercome while integrating events and processes is the basis of the pro-posed architecture First the standard process engines are explored tolearn about the state-of-the-art To scope the work we consider the pro-cess engines that implement the semantics for usage of activities andevents in a process model according to the BPMN specification [94]The literature survey discussed in Chapter 4 gave us insight about theconceptual dimensions required for the integration framework The
5 httpsbpthpiuni-potsdamdePublic
52 requirements analysis 55
useCase
Loadgoods
Calculateshortest
routeTransportplan
received
Drive towarehouse
Drive todestination
Longdelay
Re-calculate
route
Drive alongupdated
route
Delivergoods
Figure 24 Usecase from the logistics domain
project partners and domain experts from both academia and indus-try contributed vastly to extract use cases that include communicationbetween processes and their environment
One such use case from the logistics domain is shown in Figure 24The process starts when the truck driver receives the transport planfrom the logistics company Motivating example
capturingimportance of eventintegration
Then she drives to the warehouse to loadthe goods Once the goods have been loaded the driver follows theshortest route to reach the destination While driving the driver getsinformed in case there is a long delay caused by an accident or trafficcongestion If the notification for a long delay is received the driverstops following the initial route and calculates an alternative way whichmight be faster Note that in reality a driver can recalculate the route asoften as she wants to while driving to the destination but this is implicitin the driving activity the explicit activity for recalculating the route isexecuted only when it is triggered by the long delay event Once thedestination is reached the goods are delivered and the process endsThis can be easily related to all of us driving on a highway listeningto the radio to be updated about the traffic situation taking a detour ifthere is a traffic congestion The more interesting business value hereis that the logistics companies generally control the transportation of50-200 trucks and they need to know the whereabouts of the truckscontinuously to update the estimated time of delivery Therefore au-tomating the process by using a process engine to execute and monitorthe transportations is efficient Having the above scenario as a basis therequirements for using events in processes are identified and describedin the remainder of this section
521 R1 Separation of Concerns
Using external information in business processes is essentially equiva-lent to connecting the two fields of business process management andcomplex event processing Process engines could directly connect toevent sources to get notifications This may be done by querying theirinterfaces listening to event queues or issuing subscriptions Howeverfrom a software engineering perspective this design decision woulddramatically increase the complexity of the engine Also it will violateestablished architectural principles like single responsibility and modu-larity The separation of concerns ie separation of process executionbehavior and complex event processing techniques is therefore consid-ered a major requirement
56 integrating real-world events into business process execution
Different event sources produce events in different formats (eg XMLCSV JSON plain text) and through different channels (eg REST webservice or a messaging system) In the example scenario the probableevent sources are the logistics company the GPS sensor in the vehicleand the traffic API Each of them might have their own format of pub-lished eventsSignificance of event
processing platformIf the process engine needs to directly connect with event
sources it has to be extended with adapters for each of the sources toparse the events After the event sources are connected there is alsothe need for aggregating those events to generate the business eventneeded for the process This yields yet another component in the pro-cess engine that retains the event processing techniques and operateson the event streams
From an architectural point of view to include all the event process-ing functionalities in a process engine will increase the complexity andredundancy of the engine to a great extent From a logical perspectiveprocess engines are meant for controlling the execution of process in-stances following the process specification not for dealing with eventprocessing Besides certain events can be interesting for more than oneconsumer For example the long delay event might be relevant not onlyfor the truck drivers but also for other cars following the same routeHaving a single entity responsible for both process execution logic andevent process techniques is therefore not a preferred option
522 R2 Representation of Event Hierarchies
Simple event streams generated from multiple event sources can be ag-gregated to create complex higher-level events One could propose touse BPMN parallel multiple events to represent the event hierarchy atleast to show the connection among simple and complex events How-ever using that approach one cannot express the various patterns ofevent abstraction such as sequence time period count of events or theattribute values Different patterns of event sequences are thoroughlydiscussed in [75] A structured classification for composite events canbe found in [13] Expressing event processing patterns using processartifacts would complicate the process model and defeat its purposeof giving an overview of business activities for business users and ab-stract from underlying technicalities As a user of BPM one would beinterested to see only the higher-level event that influences the processrather than the source or the structure of the event For example thedriver is only interested to know if there is a long delay that mightimpact her journey but she does not care what caused the delay
An event hierarchy essentially takes care of the flow of informa-tion from the low-level events to the higher-level events As explainedin Chapter 3 single event streams can be filtered based on certain timewindows specific numbers of event occurrences or attribute values ofthe events Also multiple events from multiple event streams can beaggregated based on predefined transformation rules to create complex
53 system architecture 57
events relevant to a process Exploiting event hierarchies the processmodel includes only the high-level business events relevant for the pro-cess and easily understandable by business users The model is notsupposed to be burdened with details of event sources and abstractiontechniques However the business event on top of the hierarchy needsto be mapped to the BPMN event modeled in the process
523 R3 Implementation of Integration
The two requirements above address the logical distribution made fromthe architectural point of view and the conceptual mapping of eventprocessing to process execution Now we define the following technicalrequirements to realize the integration of events and processes from animplementation aspect
r3 1 binding events The business events modeled in the pro-cess model need to be correlated with the higher-level event defined bythe event hierarchy in the CEP platform to make sure that the correctevent information is fed to the process For example the driver shouldbe informed only about delays on the route she is following
r3 2 receiving events The process engine should listen to spe-cific event sources to get notified once the relevant event occurs Essen-tially an event can occur at any time often independent of the processexecution status However unless the process explicitly subscribes to aspecific event the event occurrence will not be detected in the processengine In other words the driver must subscribe for the Long delay
event modeled in Figure 24 to get a notification about it
r3 3 reacting to events The consumption and further use ofevent information in later process execution should be provisionedSometimes only the event occurrence is required to trigger certainreactions such as instantiating a sequence of activities for exceptionhandling In other cases the payload or the data carried by the eventscan also be valuable for process execution For example the drivermight need to decide which alternative route is faster than the currentone The duration of the delay will be helpful for this decision makingTherefore information carried by the events should be stored for lateruse in the process
53 system architecture
This section presents the architectural framework to enable an efficientintegration of external events into business processes The conceptsare explained using the same example presented in Figure 24 Our
58 integrating real-world events into business process execution
CEPPlatform
Process Engine
Process Modeler
Client
ClWeb
Browser
ClientR
R
Event Source
Event Source
Event Source
Model Repository
Figure 25 Proposed system architecture for event-process integration
system architecture includes three components Gryphon6 the processmodeler Chimera7 the process engine and Unicorn8 the event process-ing platform [121] Exhaustive information about the components theirfeatures and interplay are found in Chapter 9
Note that even though some technical details are discussed with ex-amples based on these components the integration architecture is in-dependent of specific engines platforms technologies and interfacesThe conceptual and technical solutions to address the requirements dis-cussed above are described below They can be implemented using anyprocess modeler process engine and event processing platform com-municating with each other following the proposed framework Thegeneric components along with the connections between them are visu-alized in Figure 25
531 Distribution of Logic
To address the issues raised by R1 Separation of Concerns we propose toemploy a complex event processing platform in addition to the processengine CEP platforms are able to connect to different event sourcesand can perform further operations on event streams [56] They canreceive events parse them filter them and transform them to createnew events The event consumers can then subscribe to the event plat-form to be notified of the relevant events This solution keeps the pro-cess execution and event processing logic separate resulting in no extraoverhead to the process engine Since the CEP platform is a stand-aloneentity multiple process engines or other consumers can subscribe to acertain event facilitating the reuse of event information This separa-tion of logic is also efficient from the maintenance perspective If thereis a need to change the event source or the abstraction logic then theprocess model does not need to be altered
6 httpsgithubcombptlabgryphon
7 httpsgithubcombptlabchimera
8 httpsgithubcombptlabUnicorn
53 system architecture 59
event processing logic According to the usecase model weneed two events for the transport process a catching start event anda catching interrupting boundary event The start event sent by the lo-gistics company contains the location of the warehouse to load goodsthe destination for delivery and the deadline for delivery This is anexample of a simple event which might be sent to the truck driver viaemail or as a text message directly from the logistics company Theboundary event on the other hand is a higher-level business event thatneeds to be aggregated from the raw events This complex event iscreated in the event processing platform in our case Unicorn Since wedid not have access to real ldquotruck positionsrdquo we used the sensor unitBosch XDK developer kit9 a package with multiple integrated sensorsfor prototyping IoT applications The sensors were used to mock thelocation of the truck The unit sends measurement values over wirelessnetwork to a gateway The gateway then parses the proprietary formatof the received data and forwards it to Unicorn using the REST API Thetraffic updates were received from Tomtom Traffic Information10 Thenext section discusses how the raw events from the connected eventsources are aggregated to the business event
process execution logic In our system architecture the processengine is responsible for carrying out the deployment enactment andexecution of processes The Chimera process engine follows BPMN se-mantics for executing process specification The processes are modeledin an additional editor before the models are deployed to the engineEach occurrence of a start event triggers a process instance Followingthe process model the activities are carried out The intermediate catch-ing events are awaited once the corresponding event node is enabledUpon occurrence of a matching event the process engine gets the in-formation from the CEP platform The processes are able to send andreceive messages among themselves controlled by the process engineitself The data-based decisions are taken based on the informationgenerated during process execution optionally stored in a data objectThe event-based decision points such as an activity with a boundaryevent or an event-based gateway receive external events through theCEP platform
532 Use of Event Abstraction
To hide the complexity behind the event hierarchy the notion of eventabstraction is implemented Based on the subscription query an ab-straction rule is defined in the CEP platform The platform then keepslistening to the relevant event sources Having received each event theabstraction rule is evaluated If the event occurrence matches any partof the rule the rule is partially satisfied Once there is enough event in-
9 httpxdkbosch-connectivitycom
10 httpswwwtomtomcomen_gbsat-navtomtom-traffic
60 integrating real-world events into business process execution
formation to satisfy the complete rule the output event is generated Atthis point the CEP platform checks if there is still an existing subscriberfor this specific high-level event The subscribers are notified about theoccurrence of the high-level event accordingly Only this event is mod-eled in the business process therefore it is also called business levelevent or business event The whole event hierarchy is represented inthe event abstraction rule and thus hidden from the process modelsatisfying R2 Representation of Event Hierarchies
In our example usecase if there is a delay above a threshold aLongDelay event is produced In addition the location of the sourceof delay should be ahead of the current GPS location of the truck InUnicorn event abstraction rules are created accordingly for the eventLongDelay Since Unicorn has the Esper engine at its core we used Es-per Event Processing Language (EPL) [44] for writing event abstractionrules The event types can be defined in Unicorn as shown in Listing 8
Listing 8 Event type definitions for motivating example
CREATE schema Disruption
(latitude double longitude double
reason string delay double)
CREATE schema CurrentLocation
(latitude double longitude double
destLat double destLong double)
CREATE schema LongDelay
(reason string delay double
destLat double destLong double)
The rule for creating LongDelay is given in Listing 9 Note that thefunction distance() is not defined in EPL but has been implementedadditionally to find out if the disruption is ahead of the truck or notThe function takes the latitude and longitude of a certain location andthe destination as input parameters With those values it then calcu-lates the distance between the specified location and the destination
Listing 9 Event abstraction pattern for LongDelay
INSERT INTO LongDelay
SELECT dreason as reason ddelay as delay
ldestLat as destLat ldestLong as destLong
FROM pattern[every d=Disruption-gt l=CurrentLocation
WHERE distance(dlatitude dlongitude destLat destLong)
lt distance(llatitude llongitude destLat destLong)]
53 system architecture 61
533 Implementation Concepts
This section elaborates on how the technical challenges for the imple-mentation are handled in the integration framework The followingdiscussion proposes solutions to the requirements elicited as part of R3Implementation of Integration
event binding In Chapter 3 we mentioned events with differentproperties transitional events external events BPMN events Eventbinding is the concept of mapping these different kinds of events toeach other
To map the external events to BPMN events catching message eventconstructs are modeled in processes The catching message events canbe used as start event normal intermediate event boundary eventand in association with an event-based gateway The process needsto subscribe to the events to catch them during execution We extendthe process models by event annotations that are used as event bindingpoints To enable the subscription a subscription query is added foreach event at design time Only simple queries for subscribing to thebusiness event are added in the model Event subscription
queryMore complex event queries
to produce these high-level events are generated by abstraction rulesinside the event processing platform as per R2 For the current use-case the external event LongDelay needs to be mapped to the BPMNevent Long delay The annotation for this event is ldquoSELECT FROM
LongDelayrdquo which abstracts from the complexity of event queries dealtin CEP platform
The other event binding point needed is to map the transitional eventsie lifecycle transitions to BPMN events Since we know the location ofthe destination and we receive the regular GPS updates from the truckdriver we can match the latitude and longitude for both of them Ifthey match we can conclude that the truck has reached its destinationThis event matching specifies the binding point according to which theengine changes the state of the activity Drive to destination or Drivealong updated route from running to terminated The state transitionpoints can be used to monitor the status of the process and to auto-matically change the state of an activity instance [16] For examplethe begin and termination states of the activities Load goods or Deliver
goods can be used to track the status of the shipment Again the cancel-lation of the activity Drive to destination might trigger postponingthe estimated time of delivery due to delay This will be an exampleof mapping transitional events to external events (ie external to theldquoupdating delivery timerdquo process)
event subscription amp correlation Once the process is mod-eled it is deployed to the process engine along with the event queriesThe deployed model is then parsed and ready to be executed The eventtypes and queries are sent to the event processing platform They are
62 integrating real-world events into business process execution
Process Engine
Event Platform
POST [Subscription Query + Notification Path]
UUID
EventOccurrence
Delete Query
Event Notification
Match UUID
Figure 26 Event subscription and correlation within a process engineand an event platform
registered and stored there Once a matching event occurs the processengine gets notified about it
Process models serve as the blueprint for process instances [134]Event subscription can be done for a process model or for a specificprocess instance [79] For the basic integration the start events arealways subscribed to at the time of deployment Thus subscriptionfor Transport plan received is done at process deployment In ourcase the truck driver might register to the mailing list of the logisticscompany to receive transport plans The process gets instantiated withthe occurrence of start event(s) Subscriptions for intermediate eventsare made once the control-flow reaches the event constructs duringinstance level execution In the example process the annotation forthe event binding point of Long delay is registered for each processinstance separately once the activity Drive to destination begins
Unsubscription from an intermediate event is done once the event isconsumed or the associated activity is terminated in case of a bound-ary event Accordingly the driver stops listening to Long delay onceshe changes the route or reaches the destination The start events areunsubscribed from only when the process is undeployed Note thatthis is the subscription semantics as defined by BPMN The work inthis thesis further explores the complete subscription mechanism withother possible points in time when subscription and unsubscription canbe done Details about flexible (un)-subscription are found in later partsof the thesis (see Chapter 6 amp Chapter 7)
From a technical viewpoint we extend the execute-method of theevent nodes When the process execution flow reaches this event node
54 summary amp discussion 63
the subscription query and a notification path is sent to the event pro-cessing platform (EPP) The EPP responds with an Universally UniqueIdentifier (UUID) which is then stored in the process engine as a cor-relation key Every time an event occurs the EPP checks if there isan existing subscription for this event If a matching query is foundthen the notification is sent to the provided path along with the UUIDNow upon receiving the notification the process engine matches thisUUID to the ones stored before and correlates the event to the correctprocess instance Once the event is consumed the leave-method of theevent node performs a DELETE operation for unsubscription The abovesequence is depicted in Figure 26
event consumption In several scenarios reacting to an externalevent can only mean the occurrence of a BPMN event The process spec-ification according to BPMN semantics is simply followed to completethe reaction The occurrence of a start event will always create a newinstance of the process If the Long delay event occurs in our usecasefollowing the semantics of BPMN interrupting boundary event the as-sociated Drive to destination activity will be aborted An exceptionbranch will be triggered additionally which will lead to the activityRe-calculate route
For using the event payload in further process execution there shouldbe provisions to store the event data We suggest mapping the datacontained in the notification to the attributes of a data object Thisdata object might already exist at the time the event notification is re-ceived Otherwise it is created anew upon receiving the event Foreach attribute of the data object there exists a mapping that derives theattribute value from the event information and maps it to the outgoingdata object
There can also be a third kind of reaction to an event such as chang-ing a lifecycle state based on an external event information This hasalready been discussed as event binding point
54 summary amp discussion
Business process management and complex event processing comple-ment each other to monitor and control interacting devices especiallyin an IoT related context The work presented above assembles the nec-essary parts of integrating these two areas We gather the requirementsto build the framework with reference to a usecase from the logisticsdomain Namely we address the following major aspects
bull Separation of concerns between business process behavior andcomplex event processing techniques by enabling an event pro-cessing platform and a process engine to communicate with eachother
64 integrating real-world events into business process execution
bull Representation of event hierarchies in the event query (abstractionrule) while abstracting the complexity from the process model
bull Implementation challenges for event integration into business pro-cesses such as event binding and subscription correlation andconsumption of events
The conceptual framework and an integrated architecture are com-posed to this end which enable the basic interaction between processeswith the environment Though the technical details are described withGryphon Chimera and Unicorn the framework is independent of anyspecific platform language or technology The process specificationfollows BPMN semantics and realizes the reaction to an event accord-ing to the semantics defined in the standard Our solution architecturehandles the basic BPMN event constructs such as message or timerevents boundary events and event-based gateways The event data canbe stored in a data object to use further in decision making or execu-tion of an activity However more complex event constructs like signalerror or parallel events have not been considered in the current workand are yet to be implemented
While exploring the scenarios where event-process communicationplays a big role we stumbled upon situations where the standard se-mantics for subscription management are not enough These situationsdemand more flexibility with respect to the subscription lifetime to fitthe needs of a distributed setup The next chapter digs deeper into theneed of flexibility for event subscription and proposes a flexible eventhandling model for business processes
6F L E X I B L E E V E N T H A N D L I N G M O D E L
After an introduction to basic event handling this chapter advances to theflexible event handling model that enables early subscription to the events
Event handling notions such as subscription occurrence consumption andunsubscription are discussed individually from a process execution context
The points of subscription and unsubscription specify the possible milestoneswhen a process can start and stop listening to an event along process
execution timeline The buffer policies instruct how to store and consume therelevant events for each execution Finally the semantic interdependenciesamong the above concepts are discussed The work in this chapter has been
partly published in ldquoEvents in Business Process Implementation EarlySubscription and Event Bufferingrdquo [81] and ldquoA Flexible Event Handling
Model for Business Process Enactmentrdquo [79]
61 motivation amp overview
The previous chapters establish the definition of events event process-ing how the events influence process execution and how the processmight react to an event In this chapter we focus specifically on thesubscription management for the intermediate catching events receivedfrom the environment Previously in Chapter 5 we introduced a use-case from logistics domain Let us consider an extended version of thetransportation process shown in Figure 27 that motivates the need forflexible subscription
The logistics company here coordinates over 200 trucks each day andtherefore needs certain communication to be automated to make thebusiness more efficient In essence the logistics company employs aprocess engine to control and monitor the transportations The truckdriver is contacted via email or text message as earlier The internalprocesses as well as the message exchanges between the truck driverand the logistics company are shown using a BPMN collaboration dia-gram [94] The collaboration diagrams are used to show how two ormore process participants without a central control interact with eachother through message exchanges Each participant is captured as apool In Figure 27 the logistics company is represented as the poolnamed ldquoProcess Enginerdquo and the ldquoTruck Driverrdquo is represented in aseparate pool Additionally the process engine gets the external eventinformation through a CEP Engine The internal behavior of the CEPplatform is hidden from the logistics company but the message flow isvisible
65
66 flexible event handling model
Motivating Exam
ple - POS
Truck Driver
Truck Driver
Pick-up ReqReceived
Drive to Euro Tunnel
Check-in
Drive to FerryCheck-in
Cross Straitof D
over
Register atFerry
Transport PlanReceived
Drive to
PU Center
Pick upG
oods
Confirmation
Sent
Updated TransportPlan Received
Process Engine
Process Engine
PrepareTransport
PlanTransportPlan Sent
Significant Delay
at Euro Tunnel
Update
TransportPlan
Distribute
Orders for
Local Delivery
Ferry StatusU
pdateU
pdatedTransportPlan Sent
Ferry RegistrationReceived
ArrivalTim
e
Adapt LocalD
elivery Plan
Confirmation
ReceivedPick-up
Req Sent
TrafficU
pdateFinalize
TransportPlan
Order
Received
Complex Event Processing Engine
Figure2
7Collaboration
diagramm
otivatingthe
needfor
flexiblesubscription
61 motivation amp overview 67
The transportation in the current example is multi-modal The truckneeds to ship goods from UK to continental Europe and for that itneeds to cross the Strait of Dover Crossing Strait of Dover can be doneusing the train through Euro Tunnel which is the preferred way since itis much faster The other option is to use ferry which is preferred onlyif there is a delay at Euro Tunnel due to accident or technical failure
The whole collaboration starts when the logistics company receivesan order to deliver at Europe Once the truck driver confirms the pick-up request she drives to the pick up center (PU Center) and loadsgoods Meanwhile the logistic company starts preparing the transportplan containing the specific Euro Tunnel connection to take After theinitial plan is done the traffic update is considered to know the currentsituation of the route Motivating example
capturinginteractions betweenprocess andenvironment
Accordingly the transport plan is finalized andsent to the driver Following the plan now the truck starts driving tothe Euro Tunnel While still driving if there is a notification about along delay at the Euro Tunnel the logistic company updates the trans-port plan with a booking for the ferry and sends it to the driver Thetruck now goes to the ferry instead of Euro Tunnel Eventually us-ing Euro Tunnel or ferry the truck crosses Strait of Dover Once theroute changes to ferry the logistic company listens to the ferry statusto update estimated time of arrival and adapts the local delivery planfor continental Europe Finally based on the ferry registration the ac-tual ETA can be calculated and accordingly orders can be distributedamong the local delivery partners
The CEP platform here plays the role of environment influencingthe shipment process The process engine subscribes to the externalevents by registering a subscription query to the CEP platform whichin turn connects to the event sources such as the GPS sensor of thetruck public APIs for traffic flow information1 the Euro Tunnel RSSfeed2 and notifications from the ferry operator Operating on the eventstreams from these sources the CEP platform then notifies the processengine about current traffic situation in the route a significant delay atEuro Tunnel or the schedule of the ferry
Now letrsquos take a closer look at the intermediate message events in thecollaboration diagram since these are the events used for representingcommunication with external world The start event for the collabora-tion Order Received is sent by the customer (not shown in diagram)The exchange of pick-up request happen next which triggers the pro-cess for the truck driver After the pick-up request is received the confir-mation is passed In the process engine context the event ConfirmationReceived can not occur before the Pick-up Req Sent event since theyare causally bound However the event Traffic Update can occur any-time during the preparation of transport plan or even before that Inreality the traffic update is published at a regular interval If the pro-
1 httpwebtrishighwaysenglandcouk
2 httpwwweurotunnelfreightcomukcontact-ustravel-information
68 flexible event handling model
cess misses the last event then it has to wait for the next occurrenceMoving on the transport plan needs to be finalized before it is sentBut it does not depend on the truck driverrsquos engagement in driving tothe PU Center or loading goodsNeed for flexible
event subscriptionWe can still assume that the logistic
company is aware of the truck driverrsquos internal process and commu-nicates the transport plan in a synchronous way ie when the truckdriver is done with picking up goods This assumption does not holdfor the next catching event though Events that inform about delays atthe Euro Tunnel check-in are published by the environment at regularintervals and do not depend on the process execution status On thecontrary the shipment process waits for respective events only after thetransport plan has been sent Thus a relevant event that would haveled to route diversion may have been missed In contrast to the EuroTunnel events on the ferry status are not published at regular intervalsbut solely upon operational changes with respect to the last notificationClearly as per BPMN event handling semantics a process instance maymiss the relevant event
Letrsquos consider a transport on a very busy weekday A technical faultoccurred in the tunnel earlier that day and the train runs 3 hours be-hind schedule since then The last information on the RSS feed waspublished at 235 pm After sending the transport plan at 238 pm theprocess engine has started to listen to the delay event Meanwhile thedriver starts driving towards Euro Tunnel check-in at 240 pm as shereceives the plan already The system publishes updated informationagain at 315 pm Operations are still 230 h behind schedule which isconsidered to be a significant delay The message gets received throughthe process and updated plan is sent to the truck driver at 320 pm Thedriver eventually takes the alternative route to the ferry but only afterheading to the Eurotunnel for 40 minutes The late change of planscauses an unnecessary delay to the shipment
The presented example illustrates the complexity of using events inbusiness processes especially when all possible event occurrence timesare taken into consideration It raises the need for considering environ-mental occurrences before the process might be ready to consume itDifferences have been pointed out as to how exactly the event is placedin the process if it waits for a direct response to an earlier request or ifthe event occurrence is unrelated to the execution of that very processinstance Next in Section 62 we explore the event handling notionsfocusing on the viewpoint of business process execution However wealso show how these notions are handled in a CEP platform BPMNevent constructs with respect to their semantics are discussed alongwith their possible state transitions during runtime Based on thosein Section 63 we address the above mentioned research questions Wepropose points of subscription and unsubscription along the processexecution timeline to answer the research questions RQ1 and RQ2 re-spectively (cf Section 11) Event buffering with specific buffer policies
62 event handling notions 69
address the questions raised by RQ3 The interdependencies among theproposed concepts are discussed further to gain insight about how thebits and pieces fit together Finally Section 64 concludes the chapter
The notion event buffering was conceived during Dagstuhl Seminar2016 on ldquoIntegrating Process-Oriented and Event-Based Systemsrdquo (see57 page 57 [48]) together with Dr Jan Suumlrmeli AcknowledgementsExtending the idea theconcepts of early subscription and event buffering are explored furtherin [81] published in BPM (Forum) 2017 in collaboration with Prof DrMatthias Weidlich The specific points of subscription and correspondingPetri net mappings (cf Chapter 7) for the event constructs have beenfurther conceptualized by the author and published in EDOC 2018 [79]
62 event handling notions
BPMN models use a single node to represent a catching event At ex-ecution level the mapping to Petri net also translates this event to asingle transition However event handling from a business process per-spective consists of multiple notions which are abstracted in this singlenode or transition The four notions of event handling considered inthis work are mdash event subscription event occurrence event consump-tion and event unsubscription This section explores the underlyingdependencies among those notions and how they should be handledby a process engine as well as by an event processing platform
621 Business Process View
The notions of event handling and the dependencies among them areadopted and extended from the causality proposed by Barros et al [13]shown on the left side of Figure 28 The extended version that wepropose is portrayed on the right hand side of the figure Event sub-scription is technically sending and registering the subscription queryfor a specific event The process starts listening to the event once thesubscription is made Event occurrence can happen anytime indepen-dent of an existing subscription However only after subscription theoccurrence of an event is notified to the subscriber in our case theprocess engine Therefore the relevant occurrence can take place onlyafter a subscription has been registered
Event Matching amp Consumption
Event Subscription
Event Occurrence
Event Consumption
Event Subscription
RelevantOccurrence
Event Unsubscriptioncausal ordering
Figure 28 Dependencies among the event handling notions eventsubscription occurrence consumption and unsubscription
70 flexible event handling model
The process engine can subscribe to an event processing platform ordirectly to an event source If the subscription is directly registered atthe event source then the process engine is notified about the atomicevents produced by the source If the event streams are fed to an eventprocessing platform then the EPP can perform several operations onmultiple event streams (cf Section 34) to aggregate the raw atomicevents and come up with the higher-level business event required bythe process engine The authors in [13] combine event matching andconsumption in one step However as described in Chapter 5 the logicand control for matching an existing event subscription with the (ag-gregated) event occurrences and notifying the subscribers lie in the EPPThus event handling notions such as event abstraction and matchingare abstracted from the process engine view
Note that event occurrence and event detection are not differentiatedfurther since event occurrence in this context already signifies the de-tection of the business level most possibly complex event by the eventprocessing platform The possible delay due to the communicationchannel between the event platform and the process engine is definitelypossible [78] however this is not considered in the scope of this thesis
In the adopted version work event consumption signifies the detec-tion of the event in the process control flow and reacting to it as perprocess specification This essentially means once there is a subscrip-tion and a matching event has occurred the event information can beused by the process for different purpose such as performing a tasktaking a decision aborting an ongoing activity initiating exceptionhandling measures and choosing an execution path to follow Eventunsubscription is done to stop listening to a particular event by deletingthe subscription for itCausal dependencies
among eventhandling notions
Unsubscription is not mandatory but recom-mended since otherwise the process engine is fed with unnecessaryevents which might create overhead for the engine Usually unsub-scription is made after an event is consumed But it can also be donebefore consumption essentially anytime after an existing subscriptionif somehow the event information is not relevant for the process anymore Next sections in this chapter will elaborate more on the possi-ble points of (un)-subscription Formally the temporal dependenciescan be expressed as Se lt Oe lt Ce and Se lt Ue where Se denotes thesubscription of event e Oe denotes the occurrence of e relevant for theconsumer process Ce denotes the consumption of e and Ue denotesthe unsubscription of e
event constructs The categorization of event constructs accord-ing to their position in the process (start intermediate throwing) inter-action mode (catching throwing) and semantics (blank timer message)has been discussed in Section 222 In our work external events are al-ways represented as start or intermediate catching message event Wefocus on intermediate events since they have more variances and can ac-
62 event handling notions 71
Mandatory event
Exceptional event Racing
event
Exclusive event
Figure 29 Event construct classification put in example process models
commodate flexibility in terms of subscription and unsubscription De-pending on the necessary differences in event handling we propose thedesign time classification of the intermediate catching message eventsas described below Figure 29 visualizes the event constructs modeledin process skeletons
Definition 61 (Mandatory Event)For a process model M with the set of traces = an event e isin EIC is a
mandatory event iff forallσ = t1 t2 tn isin = exist 1 6 j 6 nn isin N suchthat tj = e Let EM sube EIC be the set of mandatory events in M
The mandatory events are those events that have to occur in order tocomplete the process execution Based thereon a mandatory event is anevent in the main process flow or an event inside a parallel branch thatis in the main process flow In either way the control flow will definitelyreach the event construct at some point for all possible executions andthe event will be awaited before the process execution can move furtherNote that a start event is always a mandatory event since a start eventneeds to occur for each execution of a process
Definition 62 (Exceptional Event)An event e isin EIC is an exceptional event iff e isin
⋃image(B) where
the function B maps the activities to its associated boundary event(s)Therefore image(B) is the set of events associated with activities LetEB sube EIC be the set of exceptional events in process model M
This is exactly the same as interrupting boundary event defined inBPMN The BPMN specification says the boundary event is alwaysattached to an activity or a subprocess Once the event occurs theassociated activity is canceled and an exceptional branch is triggeredThe relevance of the event occurrence timestamp here is very important
72 flexible event handling model
It has to be during the associated activity being in running state ie theevent must happen after the activity begins and before it terminates inorder to follow the exceptional path Since the scope of this work isonly sound processes we do not consider non-interrupting boundaryevents
Definition 63 (Racing Event)The events e1 e2 en isin EIC are racing events iff forall ei 1 lt i 6 n isin
Nexistg isin GE such that bullei = g Let ER sube EIC be the set of racingevents in process model M
BPMN event-based gateway is a special gateway where instead ofdata the decision is taken based on event occurrence The gatewayis immediately followed by several events and whichever event occursfirst the process takes the branch led by that event This is why theevents after an event-based gateway are supposedly in a race with eachother
Definition 64 (Exclusive Event)An event e isin EIC is an exclusive event iff existσ1σ2 such that σ1 =
es g1n1n2 nmg2 ee and σ2 = es g1n prime1n prime
2 n primelg2
ee where the start event es isin ES the end event ee isin EE andthe XOR gateways g1g2 isin GX such that exist i isin [1m] ni = e ANDforall j isin [1 l] n prime
j=e Let EX sube EIC be the set of exclusive events in processmodel M
According to the above definition an event e can only be in one ofthe paths between the XOR gateways g1 and g2 For a specific processinstance only one of the paths after an exclusive gateway is followedThis makes the events on the branches after an XOR split and beforean XOR join exclusive to each other ie when one of the branches ischosen the events in other branches are not required any more
runtime event lifecycle The above classification of event con-structs is done based on a static model with its process specificationsemantics We consider the design time classification since we alreadyspecify the event handling configuration as annotations to the eventsin the process model The configurations are followed by the processengine once the model is deployed However during runtime the req-uisite of an event can vary depending on the process execution statusFor example we say the mandatory events are the ones on the regularcontrol flow or inside a parallel branch This is true at both designand runtime On the contrary if we consider the runtime situation forthe exclusive events once a particular branch is chosen after the XORgateway the events on that branch become mandatory for the processinstance to complete execution Figure 30 shows the state transitions ofevent requisite from a process execution perspective
Once a process model is deployed the events are deployed to theengine too In the course of process execution the deployed events
62 event handling notions 73
Figure 30 Lifecycle of an event wrt requisite for a process execution
can transit to either of the following three states depending on theirdesirability to the process Required mdash when the event is absolutely nec-essary to the instance for a complete execution Optional mdash when theevent might occur but does not have to Obsolete mdash when the event isnot necessary for the instance any more If we try to map the event con-structs described above to the runtime lifecycle a mandatory event fora process model will be required for all instances of that model All re-quired events are executed eventually An exceptional event is optionalfrom the start of a process instance execution such that it does not haveto happen but there is a provision to execute it if it happens Once theassociated activity is terminated it goes to obsolete state Similarly theracing events are also optional and can be executed if they occur Butonly one of the racing events is executed for a single instance the restchange the state to obsolete In case of the exclusive events they are alsooptional until the branch they are situated on is chosen for the specificinstance and they become required If a different branch is chosen theybecome obsolete instead All the events are either executed or obsoleteby the time the instance completes execution Eventually the events areundeployed along with the process model
622 Event Processing View
The execution of event handling notions from an event processing plat-formrsquos perspective are shown using a transition system in Figure 31A formal definition of transition system is found later in this thesissee Definition 81 in Section 821 The basic concepts behind transi-tion system is that it abstracts from the internal behavior of a systemand only represents the interactions of the system with its environmentHere ldquordquo signifies receiving of an event whereas ldquordquo represents sendingof an event
Initially the event stream (ES) is empty and there is no registeredevent type (ET) subscription query (SQ) and event match (EM) asrepresented in state s0 Once the process is deployed the event types(E1E2) and the subscription queries (q1q2) are registered to the EPPAs a result in state s1 the ET list contains E1E2 and the SQ hasq1q2 However the ES and EM lists are still empty Letrsquos assumethe subscription query q1 listens to the occurrence of E1 where q1 issatisfied with the two consecutive occurrences of the lower-level event
74 flexible event handling model
e1 On the other hand q2 is registered to get notification about E2and needs the pattern e1 followed by e2 The event types and querieswritten in Esper EPL are given in Listing 10
ET SQ ES EM
s0ET E1 E2SQ q1 q2
ES EM
s1ET E1 E2SQ q1 q2
ES e1EM
s2
Reg (E1E2)Sub (q1q2) e1 e1
ET E1 E2SQ q1 q2ES e1e1
EM (E1q1)
s3
Occ (E1)
ET E1 E2SQ q1 q2ES e1e1
EM
s4
Unsub (q1)
ET E1 E2SQ q2
ES e1e1EM
s5
ET E1 E2SQ q2
ES e1e1e2EM (E2q2)
s6
e2Occ (E2)Unsub (q2)
ET E1 E2SQ q2
ES e1e1e2 EM
s7ET E1 E2
SQ ES e1e1e2
EM
s8
Figure 31 Interaction from event processing platformrsquos perspective
Listing 10 Example of event patterns
CREATE schema e1(id string)
CREATE schema e2(id string)
INSERT INTO E1
SELECT FROM PATTERN[e1-gte1]
INSERT INTO E2
SELECT FROM PATTERN[e1-gte2]
If the EPP receives an e1 it changes the state since the queries arepartially matched now The ES therefore has the event e1 stored butthe ET SQ and EM lists remain same for s1 and s2 As soon as thenext occurrence of e1 is received shown as ES e1 e1 the query q1gets satisfied and the event E1 is generated This is shown as the tupleE1q1 in EM list The EPP now notifies the process engine about theoccurrence of E1 Assuming the process engine unsubscribes from anevent query after consumption of the event q1 is eventually deletedfrom the SQ list At this point if e2 happens then q2 gets satisfiedand the notification is sent accordingly The event stream now containse1 e1 e2 Eventually the process engine wants to stop listening to E2and therefore unsubscribes from q2 As a result the event processingplatform ends up in state s8 with no registered query
63 flexible subscription management
Process engines are responsible for performing monitoring and con-trolling business process execution Either an integrated modeler or
63 flexible subscription management 75
EngineInitiation
ProcessDeployment
ProcessInstantiation
ProcessTermination
ProcessUndeployment
EngineTermination
t
e1
e2
Figure 32 Process execution timeline
a separate editor can be used to model the processes At some pointafter the engine is initiated the process model is deployed to the engineBPMN processes are instantiated by start event(s) Every time the startevent occurs the process model has a new running instance The pro-cess instances are executed according to the process definition Differ-ent instances can have different execution traces based on the decisionstaken or events occurred during process execution Each instance isterminated with an end event No running instance of a process modelexist once the process model is undeployed Once there is no runninginstance from any process model the engine can be terminated Themilestones of process execution starting from the engine initiation untilthe engine termination is shown in Figure 32
631 Points of Subscription
If the occurrence of an event is not dependent on the process executionthen it can happen anytime along the timeline and even beyond thatHowever we might need certain information to subscribe to an eventThese information can be specific to a process instance a process modelor across processes As soon as there is no unresolved data dependencythe process can start listening to an event it might need in future ThePoints of Subscription (POS) listed below control at which point in timea certain event can be subscribed to Since the semantics of subscrip-tion point might be different for different event constructs a formalclarification is given for each POS
pos1 at event enablement A subscription is made only whenthe event construct is enabled by the control-flow This is completelyconsistent with BPMN semantics and should be implemented whensubscription for an event can be done only after completing the previ-ous activity In the motivating example subscription should be done atevent enablement for the event Confirmation Received since it can oc-cur only after pick-up request is sent Subscription at event enablementmeans the following for the event constructs described before
bull Given e isin EIC EB and x isin NA cupNE such that xbull = esubscribe to e when x terminates
76 flexible event handling model
bull Given e isin EB and A isin NA such that Ararr esubscribe to e when A begins (Ab)
pos2 at process instantiation A subscription is made assoon as the process is instantiated ie given e isin EIC subscribe to ewhen the start event es isin ES occurs
This is required when the subscription is dependent on instance spe-cific data but the event can occur earlier than scheduled to be con-sumed in the process For example the transport plan is specific toeach transport therefore the truck driver cannot expect that before get-ting the pick-up request However once the truck gets confirmationand picks up the goods from the pick-up center the transport plan canbe ready anytime depending on how fast the logistics company worksThe truck driver can listen to the event Transport Plan Received rightafter the instantiation of the process In this case the driver does thatintuitively such as being reachable via email or phone all the time andchecking for the transport plan once done with loading goods
pos3 at process deployment According to POS3 given e isinEIC subscribe to e at process deployment (PD)
This is always done for the start events since they are needed forinstantiating the process Thus Order Received will be subscribed atthe time the transport process is deployment Additionally the sub-scription for the intermediate catching event too is created as soon asthe process model is deployed if this POS is chosen This should beimplemented when all instances of a process might need the intermedi-ate event information The Traffic Update and Significant Delay at
Euro Tunnel can be subscribed to at process deployment since all thetrucks following the same route will need to know the updates Theseupdates are not published to signify a big change rather they are up-dated in a regular interval Therefore the last update might already beuseful for the process instead of waiting for the next one
pos4 at engine initiation A subscription is made at the timewhen the engine starts running ie given e isin EIC subscribe to e atengine initiation (EI)
This is helpful in a situation where the engine already knows whichevents might be needed by the processes to be executed and subscribesto the events beforehand In such scenarios an event information isoften shared by several processes When one process starts executingit can then immediately access the event information already stored bythe engine It is very probable for the logistic company in our exampleto have other processes running than the transportation process shownhere For example they can own other transport vehicles that are notcrossing the Euro Tunnel but still driving on the same route For all ofthose transports they also need to monitor the traffic situation and sug-
63 flexible subscription management 77
gest detour in case of a congestion In this context subscribing to theevent Traffic Update is preferred to be done at engine initiation andkept accessible for all the processes that might need the information
632 Points of Unsubscription
Similar to the point when a process starts listening to an event we alsoneed to decide till which point the process keeps listening to it In casethe event occurs and the process consumes it the control flow moveson to next nodes There can also be scenarios when an event has not yetoccurred but becomes irrelevant for the process execution Dependingon different situations when a process might and should stop listeningto an event we define the following points of unsubscription
pou1 at event consumption Unsubscription is done after theevent is consumed by the process and the control flow has moved on tothe next node ie given e isin EIC and y isin NA cupNE such that ebull = yunsubscribe from e when y begins In the motivating example oncethe confirmation from the truck is received the logistic company doesnot wait for further information from the driver
pou2 at semantic resolution Unsubscription is done as soonas the event becomes irrelevant for the process This can happen in thefollowing three situations
bull When the associated activity for a boundary event terminates theboundary event is no longer relevant This is formally defined asgiven e isin EB and A isin NA such that A rarr e unsubscribe from e
when A terminates (At)bull When a specific branch is chosen after an XOR gateway the events
in other branches are no longer relevant For an exclusive eventei isin EX between an XOR split gateway g1 isin GX and an XORjoin gateway g2 isin GX where the branches after the XOR gatewaystart with the nodes d1d2 dn ie gbull = d1d2 dnunsubscribe from ei when dj begins given that i=j
bull When an event has occurred after an event-based gateway allthe events following the gateway are no longer relevant Fora racing event ei isin ER after an event-based gateway g isin GEwhere the events after the gateway are e1 e2 en ie gbull =
e1 e2 en unsubscribe from e1 e2 en when ei occurs
pou3 at process undeployment Unsubscription is done whenthe process is undeployed and there is no running instance for thatprocess According to this POU given e isin EIC unsubscribe from e
at process undeployment (PU) The event Significant Delay at Euro
Tunnel can be unsubscribed for all the instances once the process inundeployed
78 flexible event handling model
POS4Engine
Initiation
POS3Process
Deployment
POS2Process
Instantiation
POS1Event
Enablement
POU3Process
Undeployment
POU4Engine
Termination
POU2SemanticResolution
POU1Event
Consumptione1
e2
t
Figure 33 Points of (Un)-Subscription
pou4 at engine termination Unsubscription is done whenthe process engine is terminated and there is no running process anymore Therefore given e isin EIC unsubscribe from e at engine termi-nation (ET) The Traffic Update event can be unsubscribed at enginetermination since all the processes that might need it will be terminatedanyways Figure 33 combines the points of subscription and unsub-scription along the process execution timeline
633 Event Buffering
As soon as the subscription is issued the event occurrence is awaitedOnce the matching event has occurred the process engine gets notifi-cation about it However the process instance might not be ready toconsume it yet according to the motivating examples To this end anevent buffer is proposed that will store the event temporarily Laterwhen the process instance is ready to consume the event informationit checks if a matching event already exists in the buffer If the eventoccurrence has not happened yet then the process instance waits forit to occur If there exists a respective event then the process instanceretrieves it The event information is then available within the processinstance context ie the event can be consumed then
However to retrieve an event from a buffer the occurrence cardinal-ity of the events need to be accounted There can be events that occuronly once such as receiving a pick-up request In contrast there canbe events that occur continuously forming an event stream The trafficupdate or Euro Tunnel update are examples of such periodical eventsWhen the process wants to consume an event and finds multiple eventsof same event type it needs to decide which event shall be retrievedfor the specific instance To address this issue buffer policies are con-figured when subscribing to an event source The policies describedbelow define how many events are stored in the buffer which event isconsumed by a process instance and whether an event information isreused
lifespan policy The lifespan policy specifies the subset of eventsreceived from CEP platform that should be stored in the buffer Essen-tially it defines the size of the buffer It can also be interpreted as the
63 flexible subscription management 79
interval when the buffer is updated Lifespan policy can be configuredas
bull Specific Length A specific number of events can be selected to bestored in the buffer For example only last 5 traffic updates arestored to analyze the current situation in a particular route
bull Specific Time The subset of events can be selected using a temporalwindow An example can be to consider only those events thatoccurred within the last 30 minutes after an accident since theearlier events might include longer delay that is not relevant anymore
bull Keep All This configuration does not impose any restriction onevent lifespan All events received after a subscription is issuedare thereby stored in the buffer
retrieval policy This policy specifies the event to be consumedby a specific process instance The configurations include
bull Last-In-First-Out This is suitable for situations when the latestevent overwrites the required information carried by precedingevents The GPS data telling the location of a moving vehicle isan example when this configuration should be chosen
bull First-In-First-Out On the other hand there are situations whenthe first event is the most important among all In a biddingcontext the first vendor to bid a price below a certain thresholdcan be chosen as the one getting the contract
bull Attribute-based Unlike the timestamp of the event in above twocases the attribute values of the events can also be the determin-ing factor for retrieval In the bidding example the contract mightbe assigned to the vendor who quotes the cheapest offer
consumption policy Since an event can be interesting for morethan one instance or even for multiple processes the information car-ried by an event can be considered to be reused Consumption policydetermines whether an event is removed from the buffer after it hasbeen retrieved by a process instance Such consumption policies arewell-known to influence the semantics of event processing see [46] Weconsider the following configurations regarding event consumption forour buffer model
bull Consume If the consumption policy is set to this then an eventdata is deleted from the buffer as soon as it is retrieved by a pro-cess instance For example a cancellation of order is relevant onlyfor that specific order handling process instance
80 flexible event handling model
POU3Process
Undeployment
POU4Engine
Termination
POS4Engine
Initiation
POS3Process
Deployment
POS2Process
Instantiation
POS1Event
Enablement
POU2SemanticResolution
POU1Event
ConsumptionBuffer Policy
Consume
Buffer Policy(Bounded)
Reuse
Figure 34 Interdependencies among the aspects of flexible event handling
bull Reuse On the contrary choosing this consumption policy ensuresthat the event data is reused across instancesprocesses A strikein an airport most likely affect many processes that deal withflight delays and shuttle services
bull Bounded Reuse In this case a restriction is added to specify thenumber of times an event can be reused Going back to the bid-ding example offer from a certain vendor might be limited to beconsidered for a specific number of contracts to avoid bias
634 Semantic Interdependencies
The above sections describe the spectra of the event handling modelThe aspects are technically independent of each other However froma semantic perspective there are a few interdependencies that shouldbe followed while using them together For example choosing a pointof subscription for an intermediate event might have the constraint toselect a specific point of unsubscription for that event Figure 34 visual-izes these dependencies
Subscription at event enablement and process instantiation are usuallyrelevant for a specific process instance In other words these eventinformation are not used after the instance have consumed it There-fore for both of them the unsubscription can be done at event consump-tion In case the event information is obsolete even before consump-tion then unsubscription can be done at the point of semantic resolutionThe lifespan and retrieval policies are not dependent on the point of(un)-subscription anyway But the consumption policy should be set toconsume since no reuse is necessary
On the other hand subscription at process deployment is done so thatthe event can be accessed by all instances of that process Even if a spe-cific process instance does not need to listen to the event anymore afterconsumption or semantic resolution unsubscription to the event willcontradict the idea of reuse here Therefore unsubscription at processundeployment is reccommended for this scenario For the same reason
64 summary amp discussion 81
the consumption policy for the buffer should be set to reuse or boundedreuse Similarly for subscription at engine initiation the unsubscriptionshould be done only at engine termination The consumption policyshould again be either reuse or bounded reuse
64 summary amp discussion
Languages such as BPMN UML Activity diagrams or WS-BPEL donot offer flexible means for event handling Specifically the questionslike when to subscribe to an event source how long to keep the sub-scription and how to retrieve an event for a process instance are severelyignored Though the existing semantics for event subscription is ade-quate for a vast range of message exchanges they fail to capture theflexibility required for processes communicating with external eventsources in a distributed environment The BPMN assumption of anevent occurrence only after the event construct is enabled restricts the com-munication possibilities between event producers and consumers wherethe separate entities are not necessarily informed about each othersinternal status This can lead to missing out on an event which hasoccurred but still relevant Besides waiting for an already occurredevent can cause process delay even deadlock The need for advancedevent handling has further been motivated with a shipment scenariofrom the domain of logistics
To address these shortcomings a flexible event handling model isproposed with points of subscription and unsubscription along the pro-cess execution timeline The contributions presented in this chapter canbe summarized as following
bull Investigating the role and usage of handling external events inbusiness processes
bull Detecting limitations of common process specification languageswhen expressing complex event handling semantics
bull Proposing flexible subscription management system with specificpoints of (un)-subscription
bull Designing an event buffer to enable and manage early subscrip-tion efficiently
The proposed concepts are formally defined in next chapter
7F O R M A L E X E C U T I O N S E M A N T I C S
This chapter turns to the formal grounding of the event handling conceptsdiscussed in Chapter 6 The generic notions of event subscription occurrence
consumption and unsubscription are detailed using Petri nets Mappingsteps from BPMN event constructs to Petri nets are given for each point of(un)-subscription Further buffer policies are defined using Coloured Petri
Nets (CPN) The rich formalism provides unambiguous semantics anddetailed guidelines for implementing flexible event handling configurations
ldquoEvents in Business Process Implementation Early Subscription and EventBufferingrdquo [81] and ldquoA Flexible Event Handling Model for Business Process
Enactmentrdquo [79] contain part of the formalism presented in this chapter
71 motivation amp overview
The BPM lifecycle (see Section 21) instructs to come up with a fine-grained process model enriched with technical details to make it readyfor execution For using the event handling and CEP concepts for anytechnical solution a formal model is recommended to guide correct im-plementation [93] This chapter therefore gives a strong formal ground-ing to the concepts of event handling presented earlier and brings themcloser to implementation level
We chose Petri nets for our formalism since this is a popular well-established notation to model processes and it gives more technicalyet unambiguous semantics which is required for correct process exe-cution [73 122] Being a formal language there exist efficient analysistechniques and tools1 for static semantic verification of Petri nets [137]which is not the case for BPMN models Moreover Petri nets are par-ticularly suitable for capturing the communication between a processand its environment as they support the composition of models fol-lowing the principles of loose coupling and assuming asynchronouscommunication between the components
A process model represented using BPMN or WS-BPEL can be easilyand extensively transformed to a Petri net [37 72] Therefore the transi-tion of a process model from organizational level to operational level isnot an additional challenge [134] However since the standard BPMNmodels do not include the flexible event handling notions introducedin this work we define additional Petri net transformations necessaryto implement the advanced event handling semantics
1 LoLA A Low Level Petri Net Analyzer httpservice-technologyorglola
83
84 formal execution semantics
assumptions Note that we use Petri net semantics in our workto capture the behavior of a process engine with respect to executingprocesses We show the milestones such as engine initiation (EI) andprocess deployment (PD) (represented in Figure 32) as Petri net transi-tions Therefore the initial marking of the Petri net has one token in theinput place of EI In other words we use BPMN process model excerptsalong with the engine execution milestones as our representation leveland specify the corresponding Petri nets as the implementation level
We consider only sound processes that get instantiated by a startevent es isin ES and terminates with an end event ee isin EE For eachintermediate catching event the temporal order Se lt Oe lt Ce and Se lt
Ue always holds Further we do not consider any loop structure in theprocess flow
For simplicity we focus on the semantics being discussed for thespecific parts and abstract from the rest of the details For examplewe do not show the activity life cycle phases as separate transitionsunless they are needed explicitly (eg for boundary events) As ourfocus is on intermediate catching events we show only the occurrencefor start and end events In general the subscription for start eventhas to happen at process deployment since it is needed for processinstantiation Since the end event is a throwing event produced by theprocess no subscription is needed for it Note that we translate onlythe intermediate catching events not the receive tasks
We consider the interplay of the event handling notions only frombusiness process view while mapping the points of (un)-subscriptionThe event processing aspects of event handling are discussed in the con-text of event buffering Additionally we assume that for all events thetimestamp when the event source produces the event (occurrence time)coincides with the timestamp when the event notification is received bythe event processing platform (detection time)
The firing of the mapped Petri nets follow the standard semanticsie once there are tokens at all the input places of a transition it canfire immediately but does not have to The reason behind decidingon this firing behavior over immediate firing is that it supports theactivities to have certain duration which are needed to express the se-mantics of boundary events Also it will be impossible to decide on thebranch to follow after an event-based gateway since the race among theevents cannot be expressed using an immediate firing We could useGeneralized Stochastic Petri Nets (GSPN) [28] that allow to have bothtimed and immediate transitions However for the timed transitions in aGSPN a random exponentially distributed delay is assigned which isnot desired in our scenario
To avoid the unwanted delay after a transition is enabled we assumethat the transitions which can be solely carried out by the engine firesimmediately Essentially the assumption is that the engine makes sureif there is no other dependency to execute a transition it is executed im-
72 petri net mapping 85
mediately upon enablement The transitions such as issuing a subscrip-tion or an unsubscription consuming an event when the control flowreaches the event construct and there is an existing event to consumeand cancelling an activity following a boundary event consumption fallunder this category On the contrary the transitions where the engineneeds to wait on the environment such as occurrence of an externalevent and executing a user task might take time to be fired even if theyare enabled
72 petri net mapping
There are multiple layers of subscription and unsubscription in the com-plete event handling scenario such as between the process engine andthe event platform and between the event platform and the actual eventsources in the environment They are unfolded step wise in the fol-lowing First the event handling notions are transformed to Petri nettransitions in Section 721 In Section 722 each point of subscription(POS) is mapped to corresponding Petri net modules depending onthe event construct configured with the POS followed by the mappingof each point of unsubscription in Section 723 Next we switch tocoloured Petri nets since formalizing the buffer policies demand ad-vanced expressiveness Section 724 discusses the event buffer alongwith the policies expressed by functions used in the arc inscriptionsSection 73 summarizes and concludes the chapter
721 Event Handling Notions
The Petri nets representing event handling notions presented in Sec-tion 62 are given in Figure 35 The event source is captured only by itsinterface to the process flow Here event source can be interpreted aseither an individual event producer or the event processing platform
We start with the description of the process execution level Thestep of subscribing to an event e is captured by a dedicated transitionSe which is triggered when the point of subscription is reached (placeP(POS Se) This transition produces a token in the place sub that passesthe token to the event source The process execution moves on to thenext node represented by the place P(Sea) where a is the node follow-ing the point of subscription
As soon as the matching event occurs the event source sends it tothe process engine which is represented by having a token in the placee Note that this place represents the event notification that is availableonly after a subscription has been made Even if there are event oc-currences before subscription they are not yet relevant for the processexecution and therefore will not produce any token in this place
The control flow enablement of the BPMN event construct in the pro-cess execution level is mapped to the consumption of the event repre-sented by the transition Ce The predecessor and successor of Ce are x
86 formal execution semantics
Se Ce
Process Execution
Event Source
esub
Ue
unsub
P(POS Se) P(Sea) P(Ce y) P(POU Ue) P(Ue z) P(xCe)
Event Construct
Point of
SubscriptionPoint of
Unsubscription
Figure 35 Event handling notions represented by Petri net
Ce
e
P(Ce y) P(xCe)
Ce
e
P(Ce y) P(xCe)
Scenario 1 Scenario 2
Figure 36 Scenarios considering the separate notions of event occurrence andevent consumption
and y respectively Since the event handling model considers the eventoccurrence and consumption with separate transitions independent ofeach other there can be the following two scenarios
bull The control flow reaches the event construct but there is no match-ing event that has occurred yet This situation is mapped to a Petrinet with a token in the place P(xCe) and no token in the place eas shown by Scenario 1 in Figure 36
bull The matching event has already occurred but the process controlflow has not reached the event construct yet This is representedby Scenario 2 in Figure 36 as the Petri net having a token in theplace e and no token in the place P(xCe)
As soon as there are tokens in both the places P(xCe) and e the tran-sition Ce is fired producing a token in the place P(Cey) thus passingthe control flow to the next node in the process
Down the control flow another transition Ue is enabled to unsub-scribe from the event source This represents reaching the point of un-subscription along the process execution Similar to POS this transitionproduces a token in the place unsub that forwards the unsubscriptionrequest to the event source
722 Points of Subscription
In this section we tailor the event handling notions for each event con-struct and apply the points of subscription We map each pair of event
72 petri net mapping 87
Subscription at Process Deployment
Subscription at Engine Initiation
esa x y
e
hellip
Process Deployment (PD)
Engine Initiation (EI)
Mandatory Event
Subscription at Event Enablement
Ce
Se Oe
P (x Ce)
P (x Se)
P (Ce y)
Subscription at Process Instantiation
PD es Ce
Se Oe
P (x Ce)P (es a) P (Ce y)
EI
es Ce
Se Oe
P (x Ce)P (es a) P (Ce y)P (PD es)PD es Ce
Se Oe
P (x Ce)P (es a) P (Ce y)P (EI PD)
Figure 37 Petri net modules for mandatory event construct
construct and point of subscription to corresponding Petri net modulesWe take the BPMN to Petri net mapping prescribed by [37] (see Sec-tion 24) as basis and extend it to include subscription occurrence andconsumption of the events As explained by Dijkman et al x denotesthe predecessor node of event e y denotes the successor node of e andplaces with dashed borders mean they are not unique to one module Ifadditional process nodes are needed to be represented they are takenfrom the set ab z The gateways are represented by g The nodeson i-th branch following a gateway are numbered as ei xiyi wherei isinN0 Again xi and yi denote the predecessor and successor node ofevent ei resp
mapping mandatory event Following subscription at event en-ablement these are the steps to map a mandatory event construct to thecorresponding Petri net module
1 Event e is mapped to three separate transitions Se mdash subscrip-tion to e Oe mdash relevance occurrence of e detected by the processengine and Ce mdash consumption of e
2 Se has one input place to link with x the predecessor node of e3 Ce has one input place to link with x4 Ce has one output place to link with y the successor node of e5 A flow is added from Se to Oe6 A flow is added from Oe to Ce
88 formal execution semantics
For other points of subscription Step2 is replaced as indicated in thefollowing The part of process structure containing mandatory eventconstruct and resulting Petri nets are shown in Figure 37
bull Subscription at process instantiation A flow is added from the tran-sition for start event es to Se where es has an output place to linkit with a the first node after process instantiation
bull Subscription at process deployment A flow is added from the transi-tion for process deployment (PD) to Se
bull Subscription at engine initiation A flow is added from the transitionfor engine initiation (EI) to Se
mapping boundary event For a boundary interrupting eventeven if the subscription is created earlier the event occurrence is rele-vant only during the running phase of the associated activity There-fore for this event construct subscription is recommended to be regis-tered only at event enablement Figure 38 shows the boundary eventconstruct and the resulting Petri net module The steps for mappingboundary event construct with subscription at event enablement aregiven below
x y
ez
Subscription at Event EnablementBoundary Event
Ab Ce
Se Oe
At
P (x Ab)
P (At y)
P (Ce z)
Ac
Figure 38 Petri net module for boundary event construct
bull The event e is mapped to transitions Se Oe and Cebull The associated activity A is mapped to three transitions Ab de-
picting the beginning of A At depicting the termination of A andAc depicting the cancellation of A
bull Ab has one input place to link with x the predecessor node of Abull At has one output place to link with y the successor node of A
(normal flow)bull Ce has one output place to link with z the successor node of e
(exception branch)bull Ce has another output place to link it with Acbull A flow is added from Ab to Sebull Another flow is added from Ab to Cebull A flow is added from Se to Oebull A flow is added from Oe to Cebull The input place before Oe is shared with At
72 petri net mapping 89
Here the subscription is done as soon as the associated activity begins(Ab) After the subscription is done a token is put in the place sharedby the transitions At and Oe If the event occurs before the activityterminates ie the transition Oe is fired before the transition At itconsumes the token from the shared place and enables Ce Havingconsumed the event by executing Ce tokens are produced at the twooutput places ndash to pass on the control flow to the next node in theexceptional branch (P(Ce z)) and to abort the ongoing activity (inputplace for Ac) Otherwise the token from the shared place is consumedby the transition At and passed on to the normal flow of the process(P(Aty))
mapping racing event For racing events subscription at eventenablement means when the control-flow reaches the gateway all theevents following the gateway are subscribed Once one of the eventsoccur the process flow takes the branch following that event Notethat in case of early subscription (POS234) the process engine needsto check the timestamps of the events if there are more than one eventavailable in order to consume the one that happened first and followthe path leading by it The event-based gateway g with two racingevents e1 and e2 is transformed to the corresponding Petri net modulesin Figure 39 The methodology for mapping a racing event construct toPetri net following subscription at event enablement is as following
bull The event ei is mapped to two separate transitions occurrence ofei (Oei
) and consumption of ei (Cei)
bull A single transition is introduced to represent the combined sub-scription to all the racing events e1 e2 en (Se1e2en)
bull The subscription transition has one input place to link with g theevent based gateway
bull Each consumption transition Ceihas one output place to link with
yi the successor node of eibull A flow is added from subscription to each occurrence transitionOei
bull A flow is added from Oei
to Cei
For other points of subscription each consumption transition Ceiis
connected with an input place P(gCei) to link it to g the event based
gateway In contrast the subscription transition Se1e2en is not linkedwith the gateway anymore rather Step3 is replaced as indicated in thefollowing The racing event constructs following an event-based gate-way and the resulting Petri nets are shown in Figure 39
bull Subscription at process instantiation A flow is added from the tran-sition for start event es to the subscription transition
bull Subscription at process deployment A flow is added from the transi-tion for process deployment (PD) to the subscription transition
90 formal execution semantics
es
y1
y2
e1
e2
a hellip gx
Subscription at Event Enablement
Subscription at Process DeploymentSubscription at Process Instantiation
Subscription at Engine Initiation
Process Deployment (PD)
Engine Initiation (EI)
Racing Event
Ce1
Ce2
Se1e2
Oe1
Oe2
P (g Se1e2)P (Ce1 y1)
P (Ce2 y2)
Ce1
Ce2
Se1e2Oe1
Oe2
P (Ce1 y1)
P (Ce2 y2)
es
P (es a) P (g Ce1)P (g Ce2)P (PD es)
Ce1
Ce2
Se1e2Oe1
Oe2
P (Ce1 y1)
P (Ce2 y2)
es
P (es a)
PD
P (g Ce1)P (g Ce2)P (EI PD)
Ce1
Ce2
Se1e2Oe1
Oe2
P (Ce1 y1)
P (Ce2 y2)
es
P (es a)
PDEI
P (g Ce1)P (g Ce2)
Figure 39 Petri net modules for racing event construct
bull Subscription at engine initiation A flow is added from the transitionfor engine initiation (EI) to the subscription transition
mapping exclusive event As discussed in Section 62 an exclu-sive event is optional when a process is instantiated However it be-comes required once the specific branch on which the event is situatedis chosen during execution (see Figure 30) In essence an exclusiveevent behaves like a mandatory event once the associated branch isenabled by control-flow Therefore the Petri net modules mapping ex-clusive event construct coincides with the Petri net modules for manda-tory event construct for the same POS (see Figure 37) Neverthelesswe show the Petri net modules mapping an exclusive ei situated onthe i-th branch after the exclusive gateway g in Figure 40 The stepsfor mapping the exclusive event with subscription at event enablement aregiven below
1 Event ei is mapped to transitions Sei Oei
and Cei
2 Seihas one input place to link with xi the predecessor node of
the event ei3 Cei
has one input place to link with xi4 Cei
has one output place to link it to yi the successor node of ei5 A flow is added from Sei
to Oei
6 A flow is added from Oeito Cei
For the remaining points of subscription Step2 is replaced as follows
bull Subscription at process instantiation A flow is added from the tran-sition for start event es to Sei
72 petri net mapping 91
es
y1
y2
e1
e2
a hellip g
x1
x2
hellip
hellip
Subscription at Event Enablement
Subscription at Process DeploymentSubscription at Process Instantiation
Subscription at Engine Initiation
Process Deployment (PD)
Engine Initiation (EI)
ExclusiveEvent
g
es Cei
OeiSei
P (es a) P (xi Cei) P (Cei yi)P (PD es)
es Cei
OeiSei
P (es a)
PD
P (EI PD) P (Cei yi)P (xi Cei)
es Cei
OeiSei
P (es a)
PDEI
P (Cei yi)P (xi Cei)
Cei
Sei Oei
P (x Se)
P (Cei yi)P (xi Cei)
Figure 40 Petri net modules for exclusive event construct
bull Subscription at process deployment A flow is added from the transi-tion for process deployment (PD) to Sei
bull Subscription at engine initiation A flow is added from the transition
for engine initiation (EI) to Sei
723 Points of Unsubscription
This section describes the Petri net mapping for points of unsubscrip-tion (POU) as described in Section 632 The unsubscription of event eis represented as transition Ue Since unsubscription at event consump-tion (POU1) at process undeployment (POU3) and at engine termina-tion (POU4) are independent of the semantics of event construct wedescribe a universal mapping for them For unsubscription at semanticresolution (POU2) separate mappings are given for boundary eventexclusive event and racing event since these are the only three eventconstructs where it is applicable Figure 41 summarizes the Petri netmodules for all points of unsubscription
bull Unsubscription at event consumption The transition Ce depictingthe consumption of the event e is connected to the transition Ue
by an outgoing flowbull Unsubscription at process undeployment The transition PU signify-
ing process undeployment has an outgoing flow to Uebull Unsubscription at engine termination The transition ET signifying
engine termination has an outgoing flow to Ue
92 formal execution semantics
Unsubscription at
Event C
onsumption
Unsubscription at Sem
antic Resolution
Unsubscription at
Process U
ndeployment
Unsubscription at
Engine T
ermination
Ce
Ue
P (x Ce )P (O
e Ce ) P (C
e y)
PU
Ue
P (PC PU)
P (PU ET)
ET
Ue
P (PU ET)
Boundary E
ventExclusive E
ventRacing E
vent
Ce1
Ce2
Oe1
Oe2
Ue1e2
P (Ce1 y
1 )
P (Ce2 y
2 )
P (g Ce1 )
P (g Ce2 )
P (Se1e2 O
e1e2 )
Cei
P (xi C
ei )P (C
ei yi )
Uei
P (dj U
ei)P (O
ei Cei )
Ab
Ce
Se
Oe
Ue
At
P (x Ab )
P (At y)
P (Ce z)
Ac
Figure4
1Petrinetm
odulesfor
pointsof
unsubscription
72 petri net mapping 93
Semantic resolution in the context of unsubscription means the pointin time when it is clear that certain event(s) is not required for theprocess execution any more This signifies the event becoming an ob-solete one (see Section 62 Figure 30) Mandatory event constructs arerequired for each process instance hence they are named lsquomandatoryrsquoBut the other event constructs might become obsolete at specific pointsdepending on their semantics as described next
semantic resolution boundary event According to BPMNsemantics the boundary event is only relevant if it occurs in betweenthe begin and termination of the associated activity Thus once the asso-ciated activity terminates the boundary event becomes obsolete There-fore the unsubscription of a boundary event should be done eitherafter consuming the event or when the associated activity terminatesThe Petri net mapping for unsubscription of boundary event thereforecontains two incoming flows to the place before the Ue one from Ceand the other one from At
semantic resolution exclusive event If an exclusive eventis subscribed at event enablement then it is done after the particularbranch is already chosen However if subscription is done earlier thenall the events situated in different optional branches can occur beforethe control flow reaches the XOR gateway In this case as soon as thedecision is taken at the gateway and one branch is selected the events inother branches become obsolete This is shown in the Petri net modulewith the place P(djUei
) where i j isin N0 depicting the i-th and j-thbranch after the XOR gateway and i=j
semantic resolution racing event Immediately after one ofthe events following an event-based gateway occurs the process takesthe path led by that event and the other events become obsolete Thismakes not only the event occurrence but also the order of event occur-rence significant for racing events If subscription is done earlier thetemporal order of the event occurrences should be checked to makesure that the process consumes the event that occurred first In Fig-ure 41 an outgoing flow is added from each event occurrence to thetransition representing combined unsubscription for all racing events(Ue1e2en) This ensures the correct order of event consumption sincethe occurrence of an event passes the token to the input place for eventconsumption and at the same time it also enables the unsubscriptionof all other events that were in race
724 Event Buffering
This part of the chapter formalizes the concepts of event handling froman event processing platformrsquos perspective This includes registeringthe subscription query detecting a matching event putting that in the
94 formal execution semantics
xSe
reg
Ce
rem
Process Execution
Event Processing
Int
Int
id
id
id
id
id
Int x Int x Int
id
(tidp)
fretr(l)
ereqeppsub Int Int x Int x Int
id
id
put getbuffer
List(Int x Int x Int x Int)
l
lt(tid0p)l(0) hellipl(|l|)gt
l
l flife(l)
fcons(l)
srcsub
Oe
[glife(l)]
[not glife(l)](ltgt)
Ue
del
id
id
id
eppunsub
srcunsub
id
P(POS Se) P(Sea) P(Ce y) P(POU Ue) P(Ue z) P(b x)
Event Source
P(x Ce)
cep
events
Figure 42 Petri net showing event matching correlation and buffering
buffer until the process execution claims it and deleting the event querywhen an unsubscription is issued The semantics of our event model isdefined using the CPN as shown in Figure 42 The net is parameterizedby functions used in the arc inscriptions to support the buffer policiesthat will be explained later in this section In essence the net illustratesthe interplay of three levels The business process execution the eventprocessing platform (EPP) including the buffer functionality and theevent source(s) in the environment Similar to Figure 35 presented inthe beginning of this chapter the event source is captured only by itsinterface However now it communicates with the event processinglayer instead of the process execution The interaction points to theevent source are given by three places One capturing subscriptionsforwarded by EPP one modelling the events detected from the envi-ronment and one passing the unsubscription from EPP to the eventsources
The process execution layer sends the subscription to the event pro-cessing layer shown as the place epp sub The subscription query isabstracted from the model Eventually the EPP forwards the token tothe actual event source in the environment shown as the place src subThe EPP also keeps the token internally to correlate with the tokensrepresenting event notification These tokens have a product coloursetwhich represents the eventrsquos timestamp identifier and payload (tidp)We model all of them as integers (Inttimes Inttimes Int)
Once the events are received in EPP via the interface events the com-plex event processing techniques are applied represented as the transi-tion cep The events that match with a registered subscription query areaccepted as occurrence of relevant events represented by the place Oe
72 petri net mapping 95
This conforms with the causality that a subscription should exist beforean event occurrence becomes relevant for the process execution
Next transition put stores the matching events in the buffer Eventsare kept in place buffer which has a list colourset over the coloursetof stored events initially marked with a token carrying an empty list(denoted by (ltgt)) The buffer is extended with an additional integersignifying a consumption counter Once fired transition put adds thedata of the token consumed from place Oe to this list
Coming back to the process execution layer at some point the control-flow reaches the event node and the process is now ready to consumethe event stored in the buffer This is done in a two fold manner Firstthe process instance requests an event from the buffer as shown by thetoken in the place req This is done when the previous node of the event(x) is terminated Then the process actually receives the event repre-sented by a token in the place e Whereas inside the event processinglayer transition get extracts the event from the buffer when requestedThis ensures that consumption of an event is possible only when thereis a subscription as well as the event has actually occurred
When the process execution reaches the point of unsubscription eppunsub is passed to the EPP along with the id The transition del firesupon receiving the unsubscription request and consumes the tokenproduced by reg for the same id so that the event query is removedAlso the unsubscription request is forwarded to the event source asshown by the place src unsub This satisfies the interdependency be-tween subscription and unsubscription
The transition rem in the buffer model controls which events shall bekept in the buffer This transition may fire if the transition guard glife
evaluates to true Upon being fired it applies function flife to the list ofthe token in place buffer This models the lifespan policy of the bufferThe transition get is enabled as long as the transition to implement thelifespan policy is disabled The arc inscriptions fcons and fretr model theconsumption policy and the retrieval policy respectively The bufferpolicies implemented by instantiating the respective guards and func-tions are described in detail below
lifespan policy This policy is realized via the guard conditionglife and function flife The configurations can be defined as follows
bull Specific Length Assuming that at most k events shall be kept inthe buffer the guard condition for the transition to remove eventschecks for the length of the respective list ie glife is defined as|l| gt k Then function flife selects only the k most recent eventsie flife(l) 7rarr 〈l(nminus k+ 1) l(|l|)〉
bull Specific Time Assuming that there is a global variable g in theCPN model that indicates the current time and a time windowof k time units the guard glife checks whether some event fell
96 formal execution semantics
out of the window l(i) = (t idnp) with t lt g minus k for some0 6 i 6 |l| The respective events are removed ie flife(l) 7rarr l prime
where l prime(j) = l(i) = (t idnp) if t gt gminus k and for iminus j eventsl(m) = (t prime id primen primep prime) m lt i it holds that t prime lt gminus k
bull Keep All In this case the guard glife is simply set to false so thatthe function flife does not have to be defined
retrieval policy The retrieval policy is connected to the functionfretr The different configurations can be achieved as follows
bull Last-In-First-Out The last event of the list is retrieved in this casedefined as fretr(l) 7rarr l(|l|)
bull First-In-First-Out Here the head of the list of events is retrievedconsidering the function fretr(l) 7rarr l(0)
bull Attribute-based With π as a selection predicate evaluated over thepayload of events the first of events that satisfies the predicate isretrieved ie fretr(l) 7rarr (t idnp) with l(i) = (t idnp) suchthat π(p) holds true and for all l(j) = (t prime id primen primep prime) j lt i π(p prime)
is not satisfied
consumption policy Function fcons is used to implement the con-sumption policy This can be defined as
bull Consume The event retrieved from the buffer assuming its po-sition in the list of events l is i is consumed ie not writtenback to the buffer This is captured by the following definitionof the function implementing the consumption policy fcons(l) 7rarr〈l(1) l(iminus 1) l(i+ 1) l(|l|)〉
bull Reuse The event is not removed from the buffer ie fcons(l) 7rarr l
bull Bounded Reuse Assuming that an event can be consumed k-timesand with l(i) = (t idnp) being the retrieved events the functionto implement the consumption policy is defined as fcons(l) 7rarr〈l(1) l(iminus 1) l(i+ 1) l(|l|)〉 if n gt k and fcons(l) 7rarr 〈l(1) l(iminus 1) (t idn+ 1p) l(i+ 1) l(|l|)〉 otherwise
73 summary amp discussion
The thorough formalization presented above reveals the internal behav-iors of process execution and event processing when it comes to com-municating via events The Petri net mappings assign strong formalgrounding and clear execution semantics to the conceptual frameworkintroduced in Chapter 6 The Petri net modules for event constructspoints of subscription and points of unsubscription provide a complete
73 summary amp discussion 97
understanding of the event handling notions Defining each buffer pol-icy individually makes the event buffering efficient enough to suit avast range of operations
Both Petri nets and CPNs are intensely used for analyzing businessprocesses [37 137] Also there exist standard ways to transform CPNsto normal Petri nets [62] The processes enhanced with event handlingconfigurations are therefore ready and well-suited for formal analysis
The formalization opens several possibilities to explore the signifi-cance of flexible event handling Two such applications along with theimpact of event handling configurations are described in the next partof the thesis (Chapter 8)
Part III
E VA L U AT I O N amp C O N C L U S I O N S
8A P P L I C AT I O N O F C O N C E P T S
The core concepts of this thesis have been introduced and elaborated in Part IIIn this part the concepts are evaluated This chapter highlights two
applications of the flexible event handling model introduced in Chapter 6 toshow the relevance of event handling configurations in process verification
The applications are based on the formal semantics defined in Chapter 7 Onone hand execution trace analysis shows how the interdependencies among
event handling notions play a role in correct process execution Reachabilityanalysis on the other hand shows the range of allowed behaviors for a
communication model consisting of a process and its environment
81 execution trace analysis
Process execution traces are used widely for conformance and correct-ness checking of business processes [26 76 139] This part of thechapter discusses the correct process execution behavior consideringthe newly introduced event handling semantics Section 811 speci-fies the constraints for each event construct varying with precise eventhandling configurations which are needed to be true for correct execu-tion of a process The impact of choosing different configurations isexplored in Section 812 An initial version of the trace analysis con-straints has been published in ldquoA Flexible Event Handling Model forBusiness Process Enactmentrdquo [79]
811 Correctness Constraints
The correctness constraints are temporal constraints based on the for-mal semantics of event constructs points of subscription points of un-subscription and the interdependencies among them All of the tracesconform to the basic temporal order Se lt Oe lt Ce and Se lt Ue for sub-scription occurrence consumption and unsubscription In additionthe constraints according to the chosen subscription configurations arespecified The variation in the traces are highlighted whereas the pathsthat remain same are shown in gray The Petri net modules sketchedpreviously satisfy the constraints For each event construct a subset ofthe allowed behaviors defined by the corresponding Petri nets are givenbelow
traces for mandatory event The temporal constraints com-plying with correct execution behavior for a process containing a manda-tory event e are given for each POS Unsubscription is chosen to be doneat event consumption (POU1) The combined Petri net for mandatory
101
102 application of concepts
es Ce
Se Oe Ue
P (x Ce)P (es a) P (Ce y)P (PD es)
Figure 43 Petri net showing a mandatory event construct with subscription atprocess instantiation and unsubscription at event consumption
events with subscription at process instantiation and unsubscription atevent consumption is given in Figure 43 For the rest of the Petri netmodules refer to Figure 37 and Figure 41
Subscription at event enablementSubscription to event e should be done only after the previous transi-tion x is executed ie x lt Se must holdEIPD esa xSeOeCeUey ee
Subscription at process instantiationSubscription should be done immediately after the start event has oc-curred the event is consumed after x is executed ie es lt Se lt x lt Ce
must holdEIPD esSea xOeCeUey eeEIPD esSea Oe xCeUey eeEIPD esSeaOe xCeUey eeEIPD esSeOea xCeUey ee
Subscription at process deploymentHere the subscription is done after process deployment but before pro-cess instantiation Thus PD lt Se lt es lt x lt Ce must holdEIPDSeesa xOeCeUey eeEIPDSeesa Oe xCeUey eeEIPDSeesaOe xCeUey eeEIPDSeesOea xCeUey eeEIPDSeOe esa xCeUey ee
Subscription at engine initiationSubscription is done after engine initiation before process deploymentie EI lt Se lt PD lt es lt x lt Ce must holdEISePD esa xOeCeUey eeEISePD esa Oe xCeUey eeEISePD esaOe xCeUey eeEISePD esOea xCeUey eeEISePDOe esa xCeUey eeEISeOePD esa xCeUey ee
81 execution trace analysis 103
co
nf
ig
ur
at
io
nm
an
da
to
ry
ev
en
tb
ou
nd
ar
ye
ve
nt
ra
cin
ge
ve
nt
ex
cl
us
iv
ee
ve
nt
Sub
atev
ente
nabl
emen
txltSe
xltA
bltSeandO
eltA
cgltSe1
e2
en
gltSej
Sub
atpr
oces
sin
stan
tiatio
nesltSeltxltCe
ndashesltSe1
e2
enltgltCei
esltSejltgltCej
Sub
atpr
oces
sde
ploy
men
tPDltSeltes
ndashPDltSe1
e2
en
PDltSej
ltxltCe
ltesltgltCei
ltesltgltCej
Sub
aten
gine
initi
atio
nEIltSeltPD
ndashEIltSe1
e2
enltPD
EIltSejltPDltes
ltesltxltCe
ltesltgltCei
ltgltCej
Uns
ubat
even
tcon
sum
ptio
nCeltU
eCeltU
eCeiltU
e1
e2
en
CejltU
ej
Uns
ubat
sem
antic
reso
lutio
nndash
AtltU
eCeiltU
e1
e2
en
diltU
ej
Uns
ubat
proc
ess
unde
ploy
men
tPUltU
ePUltU
ePUltU
e1
e2
en
PUltU
ej
Uns
ubat
engi
nete
rmin
atio
nETltU
eETltU
eETltU
e1
e2
en
ETltU
ej
Tabl
e1
Cor
rect
ness
cons
trai
nts
for
even
tha
ndlin
gco
nfigu
rati
ons
104 application of concepts
traces for boundary event For a process containing a bound-ary event e associated with an activity A the following should holdfor a correct execution with subscription at event enablement and unsub-scription at event consumption x lt Ab lt Se and Oe lt Ac If unsub-scription at semantic resolution is chosen the constraint will rather bex lt Ab lt Se andOe lt Ac andAt lt Ue Traces below show the possible be-haviors conformant to the Petri net for the boundary event in Figure 41
EIPD esa xAbSeAtUey eeEIPD esa xAbSeOeCeAcUe z ee
traces for racing event Some example traces showing the pos-sible behavior of a net containing two racing events e1 and e2 are givenbelow The POU is chosen as unsubscription at semantic resolution asshown in Figure 41 Note that unsubscription at event consumption resultsin the same set of traces in this case since a common unsubscription isissued for all racing events as soon as one of them occurs Thereforefor POU1 and POU2 Ce lt Ue1e2en also holds
Subscription at event enablementThe traces should comply with g lt Se1e2en EIPD esa gSe1e2
Oe1Ue1e2
Ce1y1 ee
EIPD esa gSe1e2Oe2
Ue1e2Ce2
y2 ee
Subscription at process instantiationHere es lt Se1e2en lt g lt Ce must holdEIPD esSe1e2
a gOe1Ue1e2
Ce1y1 ee
EIPD esSe1e2a gOe2
Ue1e2Ce2
y2 eeEIPD esSe1e2
a Oe1Ue1e2
gCe1y1 ee
EIPD esSe1e2a Oe2
Ue1e2gCe2
y2 eeEIPD esSe1e2
Oe1Ue1e2
a gCe1y1 ee
EIPD esSe1e2a Oe2
Ue1e2 gCe2
y2 ee
Similar to mandatory events PD lt Se1e2en lt es lt g lt Ce musthold for subscription at process deployment and EI lt Se1e2en lt PD lt
es lt g lt Ce must hold for subscription at engine initiation
traces for exclusive event The following traces show a subsetof allowed behaviors of the exclusive event construct e1 and e2 shownin Figure 40 The temporal constraints for each POS are specified aswell For unsubscription at event consumption the usual condition Cei
lt
Ueiholds In case unsubscription at semantic resolution is chosen dj lt
Ueishould be true where dj signifies the first node on j-th branch
given that i=j
81 execution trace analysis 105
Subscription at event enablementThe traces for this POS should comply with g lt Sei
EIPD esa gd1 x1Se1
Oe1Ce1
Ue1y1 ee
EIPD esa gd2 x2Se2Oe2
Ce2Ue2
y2 ee
Subscription at process instantiationThe constraint for this POS is es lt Sej
lt g lt Cej In addition we
select unsubscription at semantic resolution This means once branch 1is chosen e2 is unsubscribed following semantic resolution as shownin Figure 41 However e1 is only unsubscribed once it has occurredie at consumption Therefore es lt Sej
lt g lt Cejand di lt Uej
must betrue hereEIPD esSe1e2
a gd1Ue2 x1Oe1
Ce1Ue1
y1 eeEIPD esSe1e2
a gd2Ue1 x2Oe2
Ce2Ue2
y2 eeEIPD esSe1e2
aOe1 gd1Ue2
x1Ce1Ue1
y1 eeEIPD esSe1e2
Oe1a gd2Ue1
Oe2 x2Ce2
Ue2y2 ee
For subscription at process deployment and subscription at engine initiationPD lt Sej
lt es lt g lt Cejand EI lt Sej
lt PD lt es lt g lt Cejmust hold
respectively
Table 1 summarizes the correctness constraints for each point of (un)-subscription categorized by the event constructs The event construct isdetected at design time following the definitions provided in Section 62Depending on the usecase need and data dependency for subscriptionthe event handling configurations are chosen The complete clause forcorrectness constraints is derived combining the constraints for POSand POU with a logical AND operator To this end the trace analysisis done to evaluate the process execution traces
812 Impact of Event Handling
This section turns to apply the correctness constraints defined above tothe motivating example illustrated in the motivating example presentedin Figure 27 in Chapter 6 We consider only the logistics companyrsquosprocess ie the process executed by ldquoProcess Enginerdquo We identify theintermediate catching events ldquoConfirmation Receivedrdquo and ldquoTrafficUpdaterdquo as mandatory event constructs and the other events as racingevent constructs We limit the analysis to the point until the eventldquoTraffic Updaterdquo is received as shown in Figure 44
Now we select the event handling configurations to be subscriptionat event enablement and unsubscription at event consumption for both themandatory events The resulting Petri net including transitions for en-gine initiation and process deployment is given in Figure 45 (the labelsof the process nodes are abbreviated)
106 application of concepts
Motivating Example - Traces
Truc
k D
rive
r
Truck Driver
Pick-up ReqReceived
Drive to Euro TunnelCheck-in
Drive to FerryCheck-in
Cross Straitof Dover
Register atFerry
Transport PlanReceived
Drive toPU Center
Pick upGoods
ConfirmationSent
Updated TransportPlan Received
Proc
ess
Engi
ne
Process Engine
PrepareTransport
PlanTransportPlan Sent
Significant Delayat Euro Tunnel
UpdateTransport
Plan
DistributeOrders for
Local Delivery
UpdatedTransportPlan Sent
Ferry RegistrationReceived
ArrivalTime
ConfirmationReceived
Pick-upReq Sent
TrafficUpdate
FinalizeTransport
Plan
OrderReceived
Complex Event Processing Engine
Ferry StatusUpdate
Adapt LocalDelivery Plan
Figure 44 Excerpt from motivating example presented in Figure 27 in Chap-ter 6
The correct trace with these configurations isEIPDORPRSSCROCRCCRUCRPTPSTUOTUCTUUTU FTP
Next we change the point of subscription to subscription at process in-stantiation The point of unsubscription remains the same The Petri netwith the changed event handling configurations is shown in Figure 46
The set of correct traces isEIPDORSCRTUPRSOCRCCRUCRPTPOTUCTUUTU FTPEIPDORSCRTUPRSOCRCCRUCROTUPTPCTUUTU FTPEIPDORSCRTUPRSOCRCCROTUUCRPTPCTUUTU FTPEIPDORSCRTUPRSOCROTUCCRUCRPTPCTUUTU FTPEIPDORSCRTUPRSOTUOCRCCRUCRPTPCTUUTU FTPEIPDORSCRTUOTUPRSOCRCCRUCRPTPCTUUTU FTP
OR
OCRSCR
PDEI
PRS PTP CTUCCR
UCR OTUSTU UTU
P (CTU FTP)
Figure 45 Petri net with subscription at event enablement and unsubscription atevent consumption
813 Discussion
From the traces presented above it is evident that for the intermedi-ate event construct ldquoConfirmation Receivedrdquo even if the subscription
82 reachability analysis 107
OR
OCRSCRTU
PDEI
PRS PTP CTUCCR
UCR OTU UTU
P (CTU FTP)
Figure 46 Petri net with subscription at process instantiation and unsubscriptionat event consumption
is done at different points the event CR will always take place afterthe previous node PRS is executed The reason is the process causalityexplained in Section 61 which restricts the temporal ordering of anevent occurrence based on the completion of predecessor tasks Exist-ing BPMN semantics are perfectly applicable for these scenarios
However for the intermediate event construct ldquoTraffic Updaterdquo thetraces show more variety with different event handling configurationsDepending on the time of subscription the event integration gets moreaccommodating here If the traffic update is published only when thereis a significant change in the traffic situation and that happens earlierthan the process engine is ready to consume it the information car-ried by the event can still be used In case the traffic update eventsare published periodically and there are several update events by thetime the logistics company actually needs the information to finalizethe transport plan they can either refresh the buffer to store just thelatest event or consume the last event stored in the buffer using thebuffer policies In this case the use of a flexible event handling modeldecreases the probability of the process execution getting delayed orstuck forever due to the lag between event occurrence and the processbeing ready for consumption
82 reachability analysis
Since process models are at the heart of business process management(see Section 21) techniques for workflow verification are extensivelyused for model checking [3 123] Especially soundness has been estab-lished as a general correctness criterion for process models requiringthe option to reach a final state a proper characterization of the finalstate and the absence of dead activities that cannot contribute to pro-cess execution Most of the formal verification techniques howeverfocus on control flow structure There are some works that combinedata values with control flow for soundness analysis or decision con-formance in workflow [15 115] Nevertheless none of these works
108 application of concepts
consider event handling information although events have significantinfluence on process execution
The verification problem we focus on is to analyze reachability for acertain state in a process under a certain event handling configuration
Acknowledgements This part of process verification is an ongoing work in collaborationwith Prof Dr Matthias Weidlich
To address the reachability problem we choose a path in the processmodel M leading to an intermediate event execution where the eventis equipped with specific event handling configurations As a next stepwe try to find a set of paths in the environment that will ensure theprocess reaches a desired state referred to as corresponding path(s)
The event handling concepts described in Chapter 6 constitute severalconfigurations that can be used for an event subscription For instancesubscription and unsubscription can be done at different points eventscan be buffered or not and a single event can be consumed once ormultiple times We scope the current verification with the followingtwo configurations of event handling
bull Subscription configuration by setting the point of subscriptionto subscription at event enablement (without buffering) or early sub-scription (with buffering)
bull Consumption configuration by selecting the consumption policyfor the buffer as consume or reuse
In Section 821 we introduce the formal communication model rep-resenting the interaction behavior of a process and the environmentLater in Section 822 we discuss how event handling configurationsmight extend the possible behavior of the environment to complementthe process model interaction
821 Communication Model
The communication model is built with a process model and its corre-sponding environment model The process listens to the environmentby receiving events and reacts on the environmental occurrences fol-lowing the process specification for further activities decisions andthe events generated during process execution ie the sending eventsThe internal behavior of the environment is usually unknown to theprocess and vice versa Since the current process verification considersonly the interactions between process and environment and is inde-pendent of the internal behaviors a transition system represents thecommunication model efficiently
Definition 81 (Transition System)
A Transition System is a tuple TS = (S T s0) withbull a set of states S
82 reachability analysis 109
bull a set of transitions T andbull an initial state s0 isin Sbull Let the set of events E = a z where a z are the labels of
eventsbull Let the set of interactions IE = times E cup τ where is the inter-
action mode for sending an event is the interaction mode forreceiving an event and τ is the time interval
bull The set of transitions T sube Stimes IEtimes S
A motivating example for reachability analysis including event han-dling is given in Figure 47 Using the transition diagram notation onlythe interaction points are shown and internal activities are abstractedWe model both the process and the environment with separate transi-tion systems The filled circles represent states and the arrows repre-sent the transitions responsible for the state changes Syntax of transition
systemThe initial state
is marked with an additional arrow that has no previous state Thequestion mark () signifies receiving an event whereas the exclamationmark () depicts sending of an event The transitions are labeled withthe events along with the interaction mode The transition showing the10 min interval in the process model is an example of τ
The process model interaction shows that after sending two messagesx and y the process waits for z After receiving z the process sendsw If z does not occur within those 10 min the system goes to an errorstate represented by the event e From the model alone we cannot tellhow probable it is to reach the error state
x y
z
10m
w
e
s0 s1 s2
s3 s4
s5 s6
x zy
x z y
s0 s1 s2 s3
s0 s1 s2 s3
Figure 47 Transition diagram for a process model (M) and corresponding en-vironment models (E E prime)
If we mirror the interactions of M we get E where upon receivingx followed by y z is produced Considering E as the environmentmodel we see that z will definitely be published after y is receivedIf we assume that the transitions do not take time ie z is publishedright after receiving y the system will never reach the error state andthe process remains always sound However the environment modeldoes not necessarily map to process interaction order For instance E prime
suggests another environment model where z is produced after receiv-ing x and only after that the environment expects y and z Since z isalready produced the process misses it leading to the error state for
110 application of concepts
sure This situation can be avoided by issuing an early subscription [81]For example if subscription to z is made before or immediately aftersending x the process will not miss out on the event occurrence
An early subscription in this context can be whenever the process hasenough information to subscribe to the specific event source This canbe immediately after process instantiation or anytime afterwards untilthe event node is reached According to the transition system the pointof subscription means a state in between initial state and the state that
x y
z
10m
w
e
s0 s1 s2
s3 s4
s5 s6
sub at enablement
early subscription
Figure 48 Different subscription configu-rations for receiving event z
signifies the consumption ofthe event In Figure 48 if weconsider the subscription forevent z in the process modelM subscription at event enable-ment will be represented by thestate s2 On the other handearly subscription will mean anyof the states s0 or s1 Since the
same event can be received more than once in a process the state rep-resenting point of subscription for a specific event has to be on all thepaths that lead to a transition carrying the same label as the event
822 Impact of Event Handling
Let us consider the process model M visualized in Figure 49 where the
x yM
zs0 s1
s2
s3 s4z
Figure 49 Process Model M communi-cating with environment
process is instantiated at s0Sending the event x takes theprocess into its next state s1Now two things can happenThe process might receive y andgo to state s2 Otherwise z isreceived twice in a row and theprocess goes to s4 via the inter-mediate state s3 The rest of the section describes how the set of cor-responding paths differ for the states in M depending on the differentevent handling configuration chosen for the events to be received by M
subscription configuration The reachability of the state s3is of concern for the first verification assignment The path to satisfyF(s3) in M would be the sending of x followed by the receiving of zWe select the subscription configuration as subscription at enablement(ie subscription is done at s1) and the consumption configuration asconsume to begin with For this event handling configuration we cansimply mirror the path in M and find the corresponding path in E Thecorresponding path in this case would be x followed by z as shownin Figure 50 The environment can not emit z before receiving x for thisscenario
82 reachability analysis 111
Corresponding paths in E
x z
sub at enablement
xz
x z
early subscription
x zPath in M
s0 s1 s3
Figure 50 A chosen path in process and the set of corresponding paths inenvironment with varying subscription configuration
Next we change the subscription configuration to early subscriptionThe mirrored path still belongs to the set of corresponding paths How-ever say we consider the early point of subscription as s0 and startbuffering the events With the current configuration even if the envi-ronment emits z before it receives x we can get the notification andstore z in buffer for later consumption This shows how moving thesubscription to an earlier point adds more behavior of the environmentas corresponding path resulting in more flexibility for the process com-munication
consumption configuration The verification assignment nowturns to the impact of consumption policy of the buffer Here the reach-ability of state s4 is verified ie F(s4) The path in M for this is sendingof x followed by receiving z two times consecutively We set the sub-scription configuration to be early subscription to store the events in abuffer Selecting the consumption configuration as consume will resultin deleting the event from the buffer as soon as it is used in the processTherefore the environment needs to produce two events of type z tosatisfy the corresponding path requirement The set of correspondingpaths for different consumption policies are shown in Figure 51
Corresponding paths in
x z
consume
z
x z
reusex z z
x zPath in M
zs0 s1 s3 s4
Figure 51 A chosen path in process and the set of corresponding paths inenvironment with varying consumption configuration
112 application of concepts
To compare the impact we now change the consumption configu-ration to reuse The subscription remains the same as before Sinceevent information can be used more than once it is sufficient if the en-vironment produces z only once This leads to the set of correspondingpaths containing two options rather than one Again setting the eventhandling configuration differently extends the allowed environmentalbehavior for the same process path
823 Discussion
The last section shows how different event subscription and consump-tion configurations in a process result in different sets of correspond-ing paths in the environment Having shown the influence of eventhandling configurations on workflow reachability this section turns toexploit further applications of the concepts Later the exceptions andfurther restrictions in applicability are discussed
further application ideas The workflow verification with ad-ditional event handling concepts leads to further application areas suchas synthesis If process model and event handling configuration areknown assumptions on the environment can be synthesized First thecontrollability can be evaluated by checking if there exists at least oneenvironment model that complements the process model From theabove discussion it can be answered as below
forall paths of M exist corresponding set of paths PIf exist p isin P in E then E completes the composed process model
This further leads to adapter synthesis to generate an environment thatsupports correct composition of a communication model Another areaof application can be to extend the formal properties that can be eas-ily verified once the reachability analysis has been done for a processmodel For example it can be concluded that ldquoany corresponding pathfor subscription at event enablement is also a corresponding path for earlysubscription of the same eventrdquo
limitations of the approach Though the event handling no-tions make workflow verification more precise and powerful there arecertain scenarios where a more careful application of the concepts isrequired So far we have considered the event handling configurationsonly for subscription and consumption In Figure 52 a slightly differ-ent version of M is shown where instead of two z in a row it needsz followed by w For reachability of F(s4) with early subscription andreuse for both z and w the set of corresponding paths are listed in thefigure Additionally if we include the retrieval policy then not only theevent occurrences but also the order of their occurrences will matter
Letrsquos say we select the retrieval configuration as FIFO According tothe process semantics when x is sent M will wait for z The cor-
82 reachability analysis 113
x yM
zs0 s1
s2
s3 s4w
Corresponding paths in E
x z ws0 s1 s3 s4
Path in M
x z w x w z
w x z
w z x
z x w
z w x
Figure 52 A chosen path in the process and the set of corresponding paths inenvironment with early subscription for z and w
responding paths listed on the left will fit the need as whenever theprocess is done sending x it can consume first z and then w from thebuffer Note that among the list of corresponding paths there are threeparts (listed on the right) where w occurs before z In these cases evenif z is there in the buffer it will be blocked by w The process will thusget stuck due to using the wrong event handling configuration On thecontrary selecting the retrieval configuration as LIFO should excludethe corresponding paths on the left side from correct process behavior
In addition depending on the modeling notation used to describe theworkflow there might be further restrictions on verification Figure 53
shows a process modeled with BPMN [94] After the sending task Athe control flow enables the subprocess consisting of tasks B and COnce C is completed the process executes E and reaches the end stateHowever while the subprocess is running the occurrence of the evente will abort the ongoing task and trigger the exceptional path leadingto D The corresponding transition diagram is visualized such that theoccurrence of e after s1 or s2 will change the state to s5 instead of s3
A Bs0 s1 s2
s5 s6
s3s4
C E
e eD
Figure 53 BPMN process model with boundary event and the correspondingtransition system
114 application of concepts
According to BPMN semantics for attached boundary events thesubscription is issued once the associated subprocess (or activity) isactivated Thus the state representing subscription at enablement is s1Using the flexible event handling configuration the process can startlistening to e earlier for example already at s0 But this will violate thesemantics of BPMN boundary event since the occurrence of the eventsis only valid during the running phase of the subprocess Thereforeusing event buffering in this case will add incorrect behavior to processexecution
83 summary
This chapter revisited two interesting and popular applications in pro-cess verification namely execution trace analysis to verify correctnessand reachability analysis to verify soundness The applications arebased on formal semantics of the event handling configurations intro-duced as the core concepts of the thesis Both the applications discussthe impacts of event handling concepts with the help of example pro-cesses Correctness criteria are given for each subscription and unsub-scription point that ensure correct event handling semantics during ex-ecution of a process instance Trace analysis based on those correctnesscriteria shows that choosing an early point of subscription increasesthe time window to get notifications about an event occurrence anddecreases the chance of a process missing out on a published event thatis still relevant for process execution The verification of process reach-ability is done by expressing a process as a transition system choosinga specific path with specific event handling configurations and findingthe set of corresponding paths in the environment the process is in-teracting to This enhanced reachability analysis shows that early sub-scription and reuse of event information allows for more behaviors ofthe environment to complement process execution In essence both theapplications strengthen the claim that considering the event handlingconcepts explicitly adds flexibility to event-process communication
9P R O O F - O F - C O N C E P T I M P L E M E N TAT I O N
After discussing the significance of flexible event handling in processexecution this chapter now evaluates the feasibility of event handling
concepts First we present the implementation details of the integrationframework discussed in Chapter 5 This includes individual descriptions of
the components Gryphon (process modeler) Chimera (process engine)Unicorn (event processing platform) and the communication steps betweenthem which realize the event-process integration Later we extend the basicframework with flexible event handling notions presented in Chapter 6 For
this part of the implementation we use the Camunda process engine tostrengthen the generic applicability of our approach Along with the papers
publishing the concepts the implementation work has been discussed in detailin the Master thesis ldquoFlexible Event Subscription in Business
Processesrdquo [136] Also part of the work has been showcased in the demopapers ldquoUnicorn meets Chimera Integrating External Events into Case
Managementrdquo [20] and ldquoTesting Event-driven Applications withAutomatically Generated Eventsrdquo [126]
91 basic event interaction
We presented the system architecture in Section 53 (refer to Figure 25)The generic architecture is realized with specific components and in-terfaces as shown in Figure 54 Also the sequence of integration isvisualized with five steps In the following we first discuss each of thecomponents in detail Further we outline the steps of integration in asequential manner
Unicorn Chimera
GryphonModel Repository
Cl Web Browser
Client
Cl Web Browser
Client
HTTP
HTTP
R
R
REST
SOAP REST
SOAP REST
ACTIVE MQ REST
(1) Publish Process Model
(2) Register Event Types and Event Queries
(3) Send Events(Raw Event)
(4) Notify(5) React to Events
Event Source
Event Source
Event Source
Figure 54 Detailed system architecture showing specific components and thesequence of integrating events into processes
115
116 proof-of-concept implementation
User Interface
Persistence Layer
Core Importer
Query Processor
Event Types
Events
Queries
CorrelationKeys
R
R R
R
R
UNICORN Event Processing PlatformDatabase
Web Service
R
External Data
Query Processing Engine
(ESPER)
EventGateway
R
R
R
Figure 55 Architecture of event processing platform Unicorn
911 Unicorn Event Processing Platform
Unicorn is a complex event processing platform built at the chair ofBusiness Process Technology1 at Hasso Plattner Institute University ofPotsdam The first version of Unicorn was developed in the contextof the Green European Transport (GET) Service project2 [18] funded byEuropean Union (October 2012 ndash September 2015) Since then it hasbeen extended to add more features needed for several research andstudent projects The complete Unicorn project is open-source softwarethe current version is available under the GNU General Public License20 on GitHub3
Unicorn is a web-based platform written in Java using Wicket4 as afront-end framework The event types event queries and notificationscan be managed both via a web-based UI and a REST API5 The optionsavailable to receive notifications are via email through the Java MessageService (JMS)6 by calling back registered REST endpoints or by view-ing them in the UI For event processing Unicorn is connected to theEsper engine7 Esper is a complex event processing engine developedand marketed by EsperTech and uses the expressive query languageEsper EPL8
1 httpsbpthpiuni-potsdamdePublic
2 httpgetservice-projecteu
3 httpsgithubcombptlabUnicorn
4 httpswicketapacheorg
5 httpsrestfulapinet
6 httpsdocsspringiospring-integrationdocs200M2
spring-integration-referencehtmlch19s06html
7 httpwwwespertechcomproductsesperphp
8 httpesperespertechcomrelease-710esper-referencehtmlindexhtml
91 basic event interaction 117
The internal architecture of Unicorn is modeled in Figure 55 Asseen in the Fundamental Modeling Concepts (FMC) Diagram9 there areseveral ways Unicorn can connect to event sources Event sources cansend events using Unicornrsquos REST API or publish them to a specificJMS channel which Unicorn listens to This is feasible if the code ofthe event source can be changed or an intermediary gateway is usedwhich collects events for example from sensors and forwards them toUnicorn Historic events represented as comma-separated values (csv)or spreadsheets (xls) can also be parsed and imported as event streamsusing the Unicorn UI10
Another way of getting events in Unicorn is active pulling This isdone by calling the web services or consuming RSS feeds in a periodicalmanner For active pulling adapters have to be configured separatelyfor each event source Unicorn provides a framework to extend the ex-isting adapters with low amount of effort which is found in the moduleimporter For testing event-driven applications Unicorn offers a built-in event generator that uses value ranges and distributions to generaterealistic events More details about the event generator can be foundin [126]
The core of Unicorn is responsible for triggering and managing oper-ations such as event aggregation and composition based on the Esperrules The query processor connects the core to the Esper query processingengine Additionally Unicorn maintains a database for storing eventtypes queries correlation keys and more which can be fetched by thecore component through a persistence layer The internal communica-tion of Unicorn is discussed more while describing the steps of eventintegration found later in this section
912 Gryphon Case Modeler
Gryphon is a web-based modeler that builds on a Node11 stack and usesbpmnio12 bpmnjs is an open-source BPMN modeler implemented inJavascript by Camunda13 while the other components are developedby BPT chair at HPI Camunda modeler is suitable for modeling thecore elements of BPMN such as different kinds of tasks sub-processessplit and join gateways pools and lanes and data objects Start andend events catching and throwing intermediate events like messagetimer signal link escalation conditional and compensation can alsobe modeled Gryphon extends bpmnio so as to create a data modelie the specification of data classes and attributes used in a processmodel The data classes are defined along with the states and valid statetransitions for their instances ie data objects at runtime called object
9 httpwwwfmc-modelingorg
10 httpsbpt-laborgunicorn-dev
11 httpsnodejsorg
12 httpbpmniotoolkitbpmn-js
13 httpscamundacom
118 proof-of-concept implementation
Figure 56 Modeling of subscription queries with extended field (in right) forevent annotation in Gryphon
life cycle To realize the event integration we enhanced Gryphon withthe functionality to annotate process elements with event annotationsand model event types
The data model editor in Gryphon provides the option to distinguishbetween data classes and event types Essentially both of them arenamed sets of typed attributes However if they are specified as anevent type then they are registered in Unicorn at the time of deploy-ment of the process model We decided to reuse the symbol for catch-ing message events to model external events since event notificationscan be considered as messages The catching message events can beannotated in Gryphon with event subscription queries which are regis-tered in Unicorn As Unicorn builds around Esper the event queriesare required to be written in EPL (SELECT FROM LongDelay) Theseevent annotations are used as event binding points as described inSection 533 Figure 56 is a screenshot taken of Gryphon that shows anexample of modeling event queries represented as an event annotationThe detailed description of the features can be found here14 while thesource code is published here in GitHub15
In addition for saving the event information carried by the eventswe annotate the data object in the modeler Technically this mappingis achieved by representing event notifications in the JSON notation16
and giving a path expression for each attribute of the target data objectWriting data object values from event notifications is depicted in thescreenshot of Gryphon in Figure 57 which shows the boundary eventand the property editor for the data object Here the LongDelay eventwill be stored in the data object Delay in the state created and willconsist of three attributes mdash reason duration and location
14 httpsbpthpiuni-potsdamdeGryphonGettingStarted
15 httpsgithubcombptlabGryphon
16 httpgoessnernetarticlesJsonPath
91 basic event interaction 119
Figure 57 Event data from LongDelay is written into a newly created dataobject Delay using a JSON path expression
913 Chimera Process Engine
The development of the Chimera process engine was initiated at theBPT chair at HPI during a project with Bosch Software InnovationsGmbH (2014-2018) [55] focusing on fragment-based case management(fCM) [57] Since then it has been extended and adapted vastly forspecific applications by students as well as by researchers Since fCM isa conservative extension to BPMN processes modeled using BPMN canbe executed using Chimera as with any other standard process engineThe current version of Chimera source code can be found on GitHub17The documentation and user guide can be accessed here18 The archi-tecture of the Chimera process engine is presented in Figure 58
Chimera has a frontend built in AngularJS19 that displays the de-ployed process models The dashboard lets the user start a new instanceor work on an existing instance For an ongoing instance the enabledactivities are shown which users can start and terminate When termi-nating an activity the user can add the values of data object attributesand change the state of a data object according to the data output setspecified in the model The Activity Log Data object Log and AttributeLog visualize the history of state changes for activities data objects anddata attribute values respectively The frontend communicates with theengine using a REST endpoint
The backend of the engine has several components The comparserfetches the models from the process editor deserializes the BPMN ele-ments and stores them in the database The execution of the processmodels is controlled by the core component following BPMN semantics(and the fCM specification in case it is a case model) Termination ofeach activity makes the core recompute the next set of enabled activitiesIf the next activity is a web service it is automatically executed by theengine
17 httpsgithubcombptlabchimera
18 httpsbpthpiuni-potsdamdeChimeraWebHome
19 httpsangularjsorg
120 proof-of-concept implementation
REST
Parser
AnalyticsCore
Chimera Process Engine
Chimera Frontend
Gryphon Process Modeler
R
Database HistoryR R
Engine Database
R R
R
R
R
Figure 58 Architecture of the Chimera process engine
The History module is responsible for storing the state changes ofthe activities and data objects along with the values of the data objectattributes This produces the event log that can be used for processmonitoring during the execution and process mining applications laterThe analysis algorithms and methods can be accessed using the RESTinterface from the analytics module Nevertheless the history of a pro-cess execution can also directly be accessed from the History moduleand analyzed separately The database is the access layer to the reposi-tory which is MySQL20 in our case
914 Event Integration Sequence
After having introduced the components building the system architec-ture this section turns to the interplay of them that realizes the inte-gration in five steps The steps are visualized with the architecturein Figure 54 Further the sequence of communication is recorded in thesequence diagram shown in Figure 59
(1) publish process model The process is modeled in Gryphonusing BPMN syntax and semantics The catching events are annotatedwith subscription queries Corresponding data object lifecycles (OLC)are modeled such that the state changes modeled in the process areconsistent with the state changes defined in the OLC Once the modelis completed it is deployed in Chimera using the REST API sent as aJSON file
20 httpswwwmysqlcom
91 basic event interaction 121
Gryphon Process Modeler
Chimera Process Engine
Unicorn Event Platform
Process Model
loop Event Type
loop Event Query
Start Instance
Event Query
Generate Event
Delete Query
Event Notification
ConsumeEvent
Figure 59 The sequence of communication between Gryphon Chimera andUnicorn for the integration of events into processes
(2) register event types and event queries At deploymentthe event types modeled in the process are registered in Unicorn alongwith the REST callback path of Chimera For the start event the eventquery is also registered at this point The start event remains registereduntil the process is deleted A process instance can be started eitherby receiving an event from Unicorn or manually in Chimera For theintermediate catching events the queries are registered when the con-trol flow reaches the event node during execution These queries areunregistered from Unicorn when the event is consumed or skipped Ifthe abstraction rules for events are not already defined by the eventengineer this is done at this point For each registered query Unicornsends back a unique ID to Chimera for further correlation
(3) send events Unicorn starts listening to the event sources andtransforms the raw events according to the abstraction rules The eventsources might stream the events to the REST endpoint or JMS channelof Unicorn or Unicorn can proactively pull the information from a
122 proof-of-concept implementation
Web API periodically Unicorn keeps evaluating abstraction rules uponreceiving each event to check whether any of the rules has been satisfiedcompletely or partially
(4) notify Once all the information necessary for one higher levelevent is available Unicorn generates the business event The event isthen sent to the REST callback path provided by Chimera
(5) react to events Upon receiving a start event an instance ofthe corresponding process is started For an intermediate event theassociated BPMN semantics are followed eg to consume the event toabort an ongoing activity or to decide on the further execution branchIf the event attributes are mapped to a JSON path expression duringmodeling the attribute values are stored in a data object Once con-sumed a DELETE request is sent to Unicorn that unsubscribes Chimerafrom further notification of the event In case of boundary events thatdid not occur the DELETE request is sent once the associated activ-ity terminates For start events the unsubscription is done at processundeployment
92 flexible event subscription with buffering
Having illustrated the basic integration architecture for event-processcommunication this section extends the implementation frameworkpresented above to enable flexible event handling The implementa-tion follows the concepts presented in Chapter 6 and demonstrates theproof-of-concept of flexible subscription Unicorn is again used as theevent processing platform Instead of Chimera the open-source pro-cess engine Camunda21 has been used to show that an off-the-shelfprocess engine that follows BPMN semantics can be extended withflexible event handling configurations with only minor changes Firstthe necessary extensions made to BPMN are elaborated in Section 921Next the adjustments made in Unicorn (Section 922) and Camunda(Section 923) are described
This part of the implementation has been majorly done by DennisWolf in context of his Master thesis [136] written at the chair of BusinessProcess Technology supervised by the author In the Master thesis anextended version of the BPMN+X model published in [81] has beenpresented Further the following five event occurrence scenarios (EOS)have been identifiedAcknowledgements
1 EOS1 The event occurs while the catch element is enabled2 EOS2 The event does not occur at all3 EOS3 The event occurs between process instantiation and the
enabling of the BPMN event
21 httpscamundacomproductsbpmn-engine
92 flexible event subscription with buffering 123
4 EOS4 The event occurs between process deployment and processinstantiation
5 EOS5 The event occurs before the deployment of the process inthe process engine
To accommodate all of the above scenarios Camunda has been extendedwith a Process Engine Plugin and the source code of Unicorn has beenadapted (cf Figure 62) The downloadable code for the extended archi-tecture can be found on GitHub22
921 BPMN Extension
BPMN 20 offers an extension mechanism to add new features whilestill being compliant to the standard (see BPMN 20 Section 823 [94])We formalize the extension as a BPMN+X model a UML profile [95] de-fined for using the BPMN extensibility concepts ExtensionDefinition andExtensionAttributeDefinition The extension is developed around the ad-dition of subscription-related attributes to the BPMN Message type asshown in Figure 60 using green color Based on the additional informa-tion subscription and unsubscription for message events are handledby the associated process engine Extending the Message reflects theadaptations to intermediate catching message events as well as the re-ceive tasks If a single message is used multiple times in a process thesubscription information has to be provided only once
As per the specification the Message element contains an attributename mdash the name of the message and itemRef mdash the reference to aBPMN ItemDefinition specifying the Message structure Additionallyit inherits all attributes from the BPMN RootElement (see [94] Section825) All subscription information is incorporated in a model elementSubscriptionDefinition which is added to the extensionDefinitions of theMessage element The added attributes of SubscriptionDefinition aredescribed in the following
The subscription information for an event contains the event querythe platform address and (optionally) authorization information of theCEP platform This extension assumes that only one event engine isin use with the result that access information can be configured in acentral configuration store for the current process execution environ-ment and not redundantly for each message The event query on theother hand needs to be specified for every message and is added to themodel as an extension attribute eventQuery of type String which shouldcontain the subscription query as interpretable by the CEP platform(see Figure 56) Only eventQuery is a mandatory parameter all otherswill fall back to default values if not provided Using the BPMN+Xmodel and conforming to BPMNrsquos ExtensionDefinition and ExtensionAt-tributeDefinition the following formal XSD-Schema is generated
Attribute subscriptionTime defines the points of subscription ie whenthe subscription should be registered It can take one of the following
22 httpsgithubcomdennis-wolfcamunda-explicit-early-subscription
124 proof-of-concept implementation
ltltBPMNElementgtgtReceiveTask
ltltExtensionElementgtgtSubscriptionDefinition
eventQuery StringsubscriptionTime tSubscriptionTimebufferPolicy Element
ltltExtensionElementgtgtBufferPolicy
lifespanPolicy tLifespanPolicyretrievalPolicy tRetrievalPolicyconsumptionPolicy tConsumptionPolicy
ltltBPMNElementgtgtMessage
1
01
ltltenumeration ExtensionEnumgtgt
RetrievalPolicy
‐attribute‐based‐LIFO‐FIFO
ltltenumeration ExtensionEnumgtgt
LifespanPolicy
‐specific‐length
‐specific‐time‐keep‐all
ltltenumeration ExtensionEnumgtgt
ConsumptionPolicy
‐consume‐bounded‐reuse‐reuse
ltltExtensionRelationshipgtgt
ltltBPMNElementgtgtRootElement
ltltBPMNElementgtgtMessageEventDefinition
ltltenumeration ExtensionEnumgtgt
SubscriptionTime
‐engine‐initiation‐process‐deployment‐process‐instantiation‐event‐enablement
01 01
Figure 60 BPMN+X model showing extension of BPMN Message element
values engine-initiation process-deployment process-instantiation orevent-enablement The last option is the default option representingthe standard BPMN semantics in case no other point of subscription isspecified The required time of subscription necessary for the eventsare defined at design time according to the use case The subscriptionis then executed automatically by the process engine based on the infor-mation given in the BPMN model Further information on the detailedexecution flow is provided in Section 923 SubscriptionDefinition iscomposed of another element (complex type) bufferPolicy which influ-ences the behavior of the related event buffers The XML representationof the BPMN+X model is given in Listing 11
Listing 11 XML interpretation of BPMN+X model
ltxsdelement name=SubscriptionDefinitiongt
ltxsdcomplexTypegt
ltxsdsequencegt
ltxsdelement type=xsdstring name=eventQuery
minOccurs=1 maxOccurs=1 gt
ltxsdelement type=tSubscriptionTime name=subscriptionTime
minOccurs=0 maxOccurs=1 default=event-enablementgt
ltxsdelement name=bufferPolicy
minOccurs=0 maxOccurs=1gt
ltxsdcomplexTypegt
ltxsdsequencegt
92 flexible event subscription with buffering 125
ltxsdelement type=tLifespanPolicy name=
lifespanPolicy
minOccurs=0 maxOccurs=1 default=keep-allgt
ltxsdelement type=tRetrievalPolicy name=
retrievalPolicy
minOccurs=0 maxOccurs=1 default=FIFOgt
ltxsdelement type=tConsumptionPolicy name=
consumptionPolicy
minOccurs=0 maxOccurs=1 default=reusegt
ltxsdsequencegt
ltxsdcomplexTypegt
ltxsdelementgt
ltxsdsequencegt
ltxsdcomplexTypegt
ltxsdelementgt
ltxsdsimpleType name=tSubscriptionTimegt
ltxsdrestriction base=xsdstringgt
ltxsdenumeration value=engine-initiationgt
ltxsdenumeration value=process-deploymentgt
ltxsdenumeration value=process-instantiationgt
ltxsdenumeration value=event-enablementgt
ltxsdrestrictiongt
ltxsdsimpleTypegt
ltxsdsimpleType name=tLifespanPolicygt
ltxsdrestriction base=xsdstringgt
ltxsdenumeration value=specific-length(n)gt
ltxsdenumeration value=specific-time(ISO time-span format)gt
ltxsdenumeration value=keep-allgt
ltxsdrestrictiongt
ltxsdsimpleTypegt
ltxsdsimpleType name=tRetrievalPolicygt
ltxsdrestriction base=xsdstringgt
ltxsdenumeration value=attribute-based(filter criteria)gt
ltxsdenumeration value=LIFOgt
ltxsdenumeration value=FIFOgt
ltxsdrestrictiongt
ltxsdsimpleTypegt
ltxsdsimpleType name=tConsumptionPolicygt
ltxsdrestriction base=xsdstringgt
ltxsdenumeration value=consumegt
ltxsdenumeration value=bounded-reuse(n)gt
ltxsdenumeration value=reusegt
ltxsdrestrictiongt
ltxsdsimpleTypegt
ltxsdschemagt
An example process is shown in Figure 61 where activity Do Something
is followed by an intermediate catching event TestEvent We write
126 proof-of-concept implementation
the eventQuery as select from TestEvent and choose the subscrip-tionTime as process-instantiation The XML interpretation of theSubscriptionDefinition is given in Listing 12
Figure 61 An example process with embedded subscription definition for theintermediate catching message event
Listing 12 Excerpt from the XML interpretation of the BPMN process mod-eled in Fig 59 showing process structure and extended elementsenabling flexible subscription
ltbpmnprocess id= flexsub camunda demoprojects simple SubscribeOnInstantiation name=SubscribeOnInstantiationisExecutable= truegt
process structure definition
ltbpmnstartEvent id=StartEvent_1gtltbpmnoutgoinggtSequenceFlow_0wjap3kltbpmnoutgoinggt
ltbpmnstartEventgt
ltbpmnsequenceFlow id=SequenceFlow_0wjap3ksourceRef=StartEvent_1 targetRef=Task_1um2wc3 gt
ltbpmnintermediateCatchEvent
id=IntermediateThrowEvent_16k343v name=TestEventgtltbpmnincominggtSequenceFlow_1ndzgusltbpmnincominggt
ltbpmnoutgoinggtSequenceFlow_15imq89ltbpmnoutgoinggt
ltbpmnmessageEventDefinition messageRef=Message_1gdrcmt gt
ltbpmnintermediateCatchEventgt
ltbpmnendEvent id=EndEvent_1n7dnmzgtltbpmnincominggtSequenceFlow_15imq89ltbpmnincominggt
ltbpmnendEventgt
ltbpmnsequenceFlow id=SequenceFlow_15imq89sourceRef=IntermediateThrowEvent_16k343vtargetRef=EndEvent_1n7dnmz gt
ltbpmnsequenceFlow id=SequenceFlow_1ndzgussourceRef=Task_1um2wc3targetRef=IntermediateThrowEvent_16k343v gt
ltbpmnuserTask id=Task_1um2wc3 name=Do somethinggtltbpmnincominggtSequenceFlow_0wjap3kltbpmnincominggt
ltbpmnoutgoinggtSequenceFlow_1ndzgusltbpmnoutgoinggt
ltbpmnuserTaskgt
92 flexible event subscription with buffering 127
ltbpmnprocessgt
flexible subscription extension
ltbpmnmessage id=Message_1gdrcmt name=Message_OnInstantiationgtltbpmnextensionElementsgt
ltflexsubsubscriptionDefinitiongt
ltflexsubeventQuerygtselect from TestEvent
ltflexsubeventQuerygt
ltflexsubsubscriptionTimegtprocess-instantiation
ltflexsubsubscriptionTimegt
ltflexsubsubscriptionDefinitiongt
ltbpmnextensionElementsgt
ltbpmnmessagegt
After presenting the BPMN extension the next sections describe theextensions of the CEP platform and the process engine needed for exe-cuting the information passed through the BPMN Message elements
922 Unicorn Extension
The applied architecture with extensions in both Camunda and Unicornis visualized in Figure 62 The modules colored in green are the addedcomponents whereas orange depicts modification
BPMNParser
ExecutionEngine
Camunda Process Engine
Camunda Process Modeler
R
BPMNModels
ProcessRepository
EventCorrelation
Service
BPMNParseListener
ExecutionListener
R
R
Process Engine Plugin
QueryProcessor
BufferedQuery
Listener
Core
Query Processing
Engine (Esper)
RESTAPI
Importer
R
R
R
R
R
R
R
Unicorn Event Processing Platform
Figure 62 Extended architecture for flexible event handling
For Unicorn the major extension is adding the buffering functionalityto allow delayed delivery of events to the process engine The designdecision to integrate the event buffer into the CEP platform has thefollowing reasons
bull The CEP platform registers the subscriptions and notifies aboutthe occurrences The only modification needed was to handle thetime of subscription and notification more flexibly This is con-trolled by the process engine according to the extended process
128 proof-of-concept implementation
specification Thus adding the buffer to Unicorn does not changethe responsibilities of the CEP platform and the process engineThis helps the extended architecture to stay consistent with therequirement separation of concerns
bull The CEP platform anyway receives and stores the events By im-plementing the event buffering module isolated from the processengine we reuse the storage of the CEP platform and ensure thatthe performance of the process engine is not influenced
bull Having the event buffer in the CEP platform makes it accessiblefor both Chimera and Camunda process engines as well as otherpossible event consumers
The buffering technicalities are managed by the newly added moduleBuffered Query Listener Esper offers the UpdateListener interface to en-able the callback function for a new query Unicorn implements thisas LiveQueryListener to react on new event occurrences and registersthe event query to Esper Whenever an event matches that query Live-QueryListener is notified Originally the query listener would notify allsubscribers for that query and then drop the event For implementingevent buffering a new class BufferedLiveQueryListener is created whichextends the behavior of the standard query listener
The module is built around the class EventBuffer Objects of the classare managed by the BufferManager and represent a single buffer entitycontaining events of one query The query output from Esper is storedin a list in EventBuffer The buffer behaves according to the value ofits policies which influence the items to store based on time windowor count the order in which items are retrieved from the list and howmany times an item is used The lifespan policy which requires thatevents are deleted from the buffer after a certain time is ensured by amaintenance thread that runs from the BufferManager class and iteratesover all EventBuffer objects in a specified time interval
Besides the architectural modifications the REST API of Unicorn isalso extended to make use of the buffering moduleREST API extension So far the UnicornREST API is comprised of the basic functionality such as query regis-tration query deletion and obtaining query strings by the subscriptionidentifier as described in Section 91 The additional methods intro-duced to the Unicorn Webservice for flexible event handling are de-scribed below The methods use the path ltplatformgtBufferedEventQueryREST to reach Unicorn
register query This is used by the BufferManager to create a newEventBuffer object The payload for the API call is a JSON object thatrequires an event query and optionally buffer policies A unique iden-tifier to detect the query and associated buffer is returned
92 flexible event subscription with buffering 129
Register Query
POST to BufferedEventQuery
returns queryId
Payload JSON (eventQuery[ bufferPolicies])
subscribe This method adds a new recipient to the selected queryie a new subscription is created using the queryId returned from theregister query method As a result a notification is issued based on thecurrent buffer content and whenever an event matches the query Thenotification path contains the message name that supports Camundarsquosevent correlation service to match the issued notification to the rightmessage
Subscribe
POST to BufferedEventQueryqueryId
returns subscriptionId
Payload JSON (notificationPath) with
notificationPath (notificationAddress messageName)
unsubscribe Using this method removes the specified subscrip-tion from the list of subscriptions of the selected query The specificrecipient therefore does not receive any further notification Note thatthe buffer and query instance remain intact so that other recipients canstill subscribe
Unsubscribe
DELETE to BufferedEventQueryqueryIdsubscriptionId
remove query Finally this method deletes the query and the asso-ciated buffer altogether
Remove Query
DELETE to BufferedEventQueryqueryId
923 Camunda Extension
As seen in the FMC diagram Camunda has a similar architecture asChimera The BPMN process models are created using Camunda mod-eler and deployed to the process engine The Execution Engine controlsprocess instance execution whereas the Event Correlation Service23 man-ages receiving of events and correlating them with the correct processinstance Camunda offers the concept of Process Engine Plugin (PEP)24
to intercept significant engine operations and introduce custom codeThis is a separate software module activated by adding a plugin en-try in the process engine configuration that implements the ProcessEn-ginePlugin interface of Camunda The PEPs enable adding Execution
23 httpsdocscamundaorgmanual79referencebpmn20eventsmessage-events
using-the-runtime-service-s-correlation-methods
24 httpsdocscamundaorgmanual77user-guideprocess-engine
process-engine-plugins
130 proof-of-concept implementation
Listeners25 programmatically These execution listeners trigger the ex-ecution of custom code during a process execution To customize thesemantics of the process specification we implement a BPMNParseLis-tener that is executed after a BPMN element is parsed as explained inthe GitHub project26 The BPMNParseListener interface allows to reactto the parsing of single elements based on their type by applying aseparate method for every BPMN element available
In essence the subscriptions are managed automatically by the pro-cess engine triggering the execution listeners according to the subscrip-tion configuration provided in the extended message element extractedby the BPMN parse listener An alternative way of extending Camundacould be to directly adapt the source code to integrate additional be-havior to the process elements However implementing a PEP allows aclearer more understandable approach to adapt the extension behaviorand facilitates maintainabilty and reusability of the extended code Fig-ure 63 shows the class diagram of the PEP elaborated in the following
FlexibleEventSubscriptionPEP
+ preInint(ProcessEngineConfigurationImpl)
FlexibleSubscriptionParseListener
+ parseRootElement(Element ListltProcessDefinitionEntitygt)
SubscriptionEngine
‐ SubscriptionRepository ArrayListltSubscriptionEntitygt+ registerQuery(SubscriptionDefinition String)+ subscribe(String)+ unsubscribe(String)+ removeQuery(String)
Activity ExecutionListener
RegisterQueryListener
+ notify(APICall)
RemoveQueryListener
+ notify(APICall)
SubscribeListener
+ notify(APICall)
UnsubscribeListener
+ notify(APICall)
0 0
ltextendsgt
Figure 63 UML Class diagram of Camunda process engine plugin
flexible event subscription pep The Process Engine Pluginenables executing custom Java code at predefined points during engineexecution An entry point to the modification of the execution behavioris provided through the implementation of the ProcessEnginePlugin in-terface It allows to intercept at three different points during the enginebootstrapping preInit postInit and postProcessEngineBuild We chose toprovide the custom implementation for the preInit method
25 httpsdocscamundaorgmanual77referencebpmn20custom-extensions
extension-elements
26 httpsgithubcomcamundacamunda-bpm-examplestreemaster
process-engine-pluginbpmn-parse-listener
92 flexible event subscription with buffering 131
subscription engine A new class SubscriptionEngine has been in-troduced that encapsulates the functionality needed to communicatewith the API of the event engine ie the methods for API-calls regis-terQuery subscribe unsubscribe and removeQuery The class has anotherimportant functionality namely the SubscriptionRepository that handlesthe correlation from the engine side This contains a list of all avail-able query and subscription identifiers and a mapping to the relatedprocess definitions or instances As described above active queriesand subscriptions can only be deleted using their unique identifiersUpon issuing a subscription or registering a query these identifiers arestored in the repository until the removal call is executed Based on therepository information the SubscriptionEngine matches the subscrip-tion identifiers and execute the remove and unsubscribe operations onthe event engine
execution listeners In total four execution listeners are addedone for each API-call which are attached to the process nodes (Activity)through the BPMN parse listener Execution listeners are triggered bythe internal transition events of Camunda such as terminate or begin ofan activity Each of the listeners is a separate class implementing theExecutionListener interface There is only one method notify includedin the listeners which is called by the engine when the correspondingtransition event fires Using the method each listener class issues anAPI-call as defined by the SubscriptionManager
flexible subscription parse listener The BPMNParseListen-er extracts all relevant xml elements from the deployed model based onthe element names This results in a list of intermediate and boundarymessage catch events and receive-tasks along with the messages theyreference Depending on the specified subscription time ExecutionLis-teners are added at the transitional events during process executionThese transitional events are determined according to the points of sub-scription specification as defined in Section 722 For example if thespecified subscription time is at process deployment (POS3) the pro-vided query is registered immediately using the SubscriptionManagerOn the other hand if the subscription is set at process instantiation(POS2) the following is executed
bull An instance of RegisterQueryListener is added to the start event ofthe process The subscriptionDefinition is provided to that listener
bull The SubscribeListener is attached to the start event of the xml noderepresentation of the intermediate message event
bull To the same node UnsubscribeListener and RemoveQueryListenerare attached to be triggered by the termination of the node
132 proof-of-concept implementation
93 summary
The proof-of-concept implementation shows the feasibility of both thebasic concepts of event integration into business processes and the ad-vanced event handling possibilities required for flexible subscriptionThe architecture consists of a BPMN modeler an event processing plat-form and a process engine The design decisions and implementa-tion techniques are mostly independent of a particular choice of enginecomponent or platform This is shown by using two different processengines one built for academic purposes and the other one being usedin real-world BPM solutions Nevertheless system specific adaptationsmight be required in case different components are used
The basic architecture supports separation of concerns by enablingthe CEP platform to handle the event processing logic and giving theprocess execution control to the process engine The flexible subscrip-tion follows separation of logic by splitting the buffer maintenance andsubscription handling between the CEP platform and the process en-gine respectively Throughout intermediate catching message eventsare used to represent communication received from the environmentThe BPMN extension of a Message element provides additional sub-scription definitions needed to switch between points of subscriptionand buffer policies This enables implementing flexible subscriptionmodel while being grounded in BPMN semantics
Altogether the enhanced CEP platform and business process engineenable the automatic handling of information provided through theBPMN extension for flexible event subscription The event engine ex-poses functionality for buffered event handling which is accessed throughexecution listeners during the process execution in Camunda Giventhese extended features process designers can conveniently incorporatesubscription information for external message events in their executableBPMN models
10C O N C L U S I O N S
ldquoIn literature and in life we ultimately pursue not conclusions butbeginningsrdquo ndash the wise words said by Sam Tanenhaus in his book LiteratureUnbound1 are applicable to research too With this chapter this thesis is now
coming to an end which opens the beginning for several other researchdirections The first part of the chapter Section 101 summarizes the results
of the thesis Later in Section 102 the limitations and future researchpossibilities are discussed
101 summary of thesis
The work in this thesis started with the notion of integrating the rele-vant contextual information into business processes to make the processexecution aware of environmental occurrences and enable the processto react to a situation in a timely manner To this end the concepts fromcomplex event processing area seemed to be beneficial for event abstrac-tion hierarchy that was needed to extract the right level of granularityof the information to be consumed by the processes Therefore the sys-tem architecture was set up to integrate CEP and BPM with the meansof communication between a process modeler a process engine andan event platform While applying the basic interaction framework ondifferent real life usecases the research gap of having a clear and flex-ible subscription management model was evident The research thusinvestigated the issues related to event subscription from a businessprocess execution perspective and eventually a formal event handlingmodel was developed In the following the detailed results of the thesisare listed
bull Requirements for integrating real-world events into business processesBased on literature review examples of real-world usecases andextensive disucussion sessions with domain experts from bothacademia and industry a list of requirements for integrating exter-nal events into business process execution is presented in Chap-ter 5 These requirements cover conceptual as well as technicalaspects of the integration Further the requirement for havingflexible points of subscription and unsubscription are supportedusing motivation examples from the logistics domain
bull Integrated framework enabling event-process communication The inte-grated framework satisfied the requirements and enabled a smooth
1 httpswwwgoodreadscombookshow1070640
133
134 conclusions
communication between the process engine and the event plat-form (ch Chapter 5) Assigning the responsibility for control-ling the business logic to the process engine and event processingtechniques to the CEP platform establishes separation of concernand facilitates reuse of events The event hierarchies are hiddenfrom the process view and are dealt with by the event abstractionrules The higher-level event is then mapped to the business eventneeded for the execution The process engine subscribes to thestart events at deployment and to the intermediate events at eventenablement The CEP platform connects to the event sources op-erates on the event streams according to the event query and no-tifies the process engine when a matching event is detected Theprocess engine then follows the process specification to react tothe event
bull Subscription management facilitating flexible event handling The sub-scription management is further detailed in the flexible event han-dling model presented in Chapter 6 Along the process execu-tion timeline execution states are specified when a subscriptionand an unsubscription can be issued While unsubscription isoptional subscription is mandatory to receive notification aboutan event occurrence Depending on the use of event structurein a process specific semantics are assigned to these points of(un)-subscription For instance boundary events should only besubscribed once the associated activity has started An event inthe normal flow on the contrary can be subscribed to at enable-ment at process instantiation at process deployment or at engineinitiation depending on the availability of information needed forsubscription An unsubscription can be done at event consump-tion at semantic resolution at process undeployment or at en-gine termination Semantic resolution in this context means com-ing to the point during process execution when the event becomesobsolete for that particular instance The definition of semanticresolution differs for boundary event exclusive event and rac-ing events The proof-of-concept implementation provides basictechnicalities to enable flexible subscription by extending BPMNnotation Unicorn event platform and Camunda process engine
bull Event buffer complementing early subscription Early subscriptionof events demand a temporary storage for the events to make itavailable till the process is ready to consume The concept of anevent buffer is proposed in Chapter 6 to address this The buffercomes with a set of buffer policies that offer alternative config-urations for the time and quantity based lifespan of the eventsthe most suitable event to consume in case several occurrences ofthe same event type are available and the reusability of an eventinformation In the prototype implementation discussed in Chap-
102 limitations and future research 135
ter 9 the buffering functionalities are added to the event platformwhereas the control of flexible subscription remains with the pro-cess engine
bull Formal translation of the event handling model Finally the formalmodel assigns clear semantics to the event handling concepts inChapter 7 The points of subscription and points of unsubscrip-tion are mapped to Petri net modules according to the event con-structs The buffer policies are expressed formally as colouredPetri nets This formal translation makes formal process verifi-cation methods applicable to the process execution enriched withevent handling configurations Trace analysis to verify correct pro-cess execution and reachability analysis to find allowed environ-mental behaviors are presented as examples of such applications
102 limitations and future research
We claim our work to be a significant contribution in the current contextof IoT and distributed business process execution Nevertheless thework presented in the thesis has certain limitations that need to beaddressed in future research related to this topic as discussed below
bull Roles of process designer amp event engineer First of all the wholeconcept of the thesis is based on the assumption that the processexecution is aware of the event sources and event abstraction rulesbehind the business events relevant for the processes This is pos-sible only when there is clear distribution of responsibilities in anorganization such that there are dedicated process designers andevent engineers who will decide on the configurations for eventsubscription from a business process perspective and an eventprocessing perspective respectively In practice this is often notthe case Also the thesis does not focus on the specification aboutwho is responsible for which design decision(s) In those situa-tions it might be difficult to exploit the flexibility offered by theevent handling model to the fullest However the event handlingmodel gives clear semantics for the points of (un)-subscriptionand the buffer policies Assuming the process participants haveenough domain knowledge these notions are easy to grasp andapply to a certain usecase
bull Advanced event types The integration architecture with GryphonChimera and Unicorn implements the basic use of events as pro-cess artifacts such as message and timer events boundary eventsand event-based gateways More advanced event constructs likesignal compensation parallel event types are not implementedsince that has been considered out of scope for this thesis Theexternal events are always represented as catching intermediate
136 conclusions
events (and start events) We argue that most of the business sce-narios can be captured using message events in a normal flow inan exceptional flow (boundary event) and after a decision point(event-based gateway) [88] Yet event types such as error esca-lation and signal events offer specific event handling semanticsthat are most appropriate to capture an event occurrence in cer-tain situations In future the subscription configurations shouldbe extended for all event types and their usage in a process
bull Complex process structures So far processes with loops are notconsidered in our work The loops make event correlation highlycomplicated as described in the following example For on onlinepayment procedure the customer is given the option to updatethe card details if the payment is not successful at the first placeThis is done with a simple process taking the customer details asa receiving message event If the buffer policy is set to LIFO andreuse for the event the first execution of the loop can consume thelatest card information residing in the buffer However the nextexecution of the loop happens only when the payment is failedHaving an event in buffer here leads to the consumption of thesame information though an updated card details is intendedSituations like that need to be investigated further and the eventhandling configurations might be extended to accommodate ver-satile scenarios
bull Smart Buffer Manager Let us think of a scenario where we knowthat an event is published in regular interval of 30 min The pro-cess reaches the point of consuming the event when the 30 minwindow is towards the end eg the last event has been published28 min before and the next event occurrence is expected in 2 minIn this case waiting for 2 more minutes for the updated informa-tion might make more sense than having the last event available inthe buffer A smart buffer manager reflects on the idea of havingthose context information available to the buffer and thus sug-gesting the process participant the alternative options to consumeevents
bull Further applications In Chapter 8 we documented two applica-tions based on the formal notations of the event handling modelSome possible extensions of those applications are also hinted inthe discussion sections at the end of the chapter However the ap-plication concepts are not tested with real data yet For instancebuilding up a concrete adapter based on the corresponding pathsis an interesting future work Using a set of processes to imple-ment the application ideas for the adapter synthesis and traceanalysis is in our agenda for extending the work
102 limitations and future research 137
bull User-friendly visualization Lastly the current implementation forflexible event subscription is developed to run in the backgroundand does not provide any visual cockpit yet Though the sub-scription configurations are part of the XML description of theprocesses they are not offered to the process designers in a user-friendly way An idea to address this could be to design con-figuration panels for intermediate events where drop-down listsfor point of subscription point of unsubscription and buffer poli-cies are added This approach will also be helpful to enforce thesemantic interdependencies between the event handling notionsdiscussed in Section 634
B I B L I O G R A P H Y
[1] Wil M P Aalst Process Mining Discovery Conformance and Enhancementof Business Processes volume 136 01 2011 ISBN 978-3-642-19344-6 doi101007978-3-642-19345-3 (Cited on pages 14 27 and 49)
[2] Activiti Activiti BPM Platform httpswwwactivitiorg (Cited onpage 47)
[3] Nabil R Adam Vijayalakshmi Atluri and Wei-Kuang Huang Modelingand analysis of workflows using petri nets Journal of Intelligent Informa-tion Systems 10(2)131ndash158 Mar 1998 ISSN 1573-7675 doi 101023A1008656726700 URL httpsdoiorg101023A1008656726700(Cited on page 107)
[4] Marcos K Aguilera Robert E Strom Daniel C Sturman Mark Astleyand Tushar D Chandra Matching events in a content-based subscrip-tion system In Proceedings of the Eighteenth Annual ACM Symposium onPrinciples of Distributed Computing PODC rsquo99 pages 53ndash61 New YorkNY USA 1999 ACM ISBN 1-58113-099-6 doi 101145301308301326URL httpdoiacmorg101145301308301326 (Cited on page 48)
[5] A Akbar F Carrez K Moessner and A Zoha Predicting complexevents for pro-active iot applications In 2015 IEEE 2nd World Forumon Internet of Things (WF-IoT) pages 327ndash332 Dec 2015 doi 101109WF-IoT20157389075 (Cited on pages 47 and 53)
[6] A Al-Fuqaha M Guizani M Mohammadi M Aledhari andM Ayyash Internet of things A survey on enabling technologies pro-tocols and applications IEEE Communications Surveys Tutorials 17(4)2347ndash2376 Fourthquarter 2015 ISSN 1553-877X doi 101109COMST20152444095 (Cited on pages 42 and 49)
[7] Stefan Appel Sebastian Frischbier Tobias Freudenreich and AlejandroBuchmann Event Stream Processing Units in Business Processes InBPM pages 187ndash202 Springer Berlin Heidelberg 2013 doi 101007978-3-642-40176-3_15 (Cited on pages 44 46 and 49)
[8] Arvind Arasu Shivnath Babu and Jennifer Widom The cql con-tinuous query language Semantic foundations and query execu-tion The VLDB Journal 15(2)121ndash142 June 2006 ISSN 1066-8888doi 101007s00778-004-0147-z URL httpdxdoiorg101007
s00778-004-0147-z (Cited on page 49)
[9] Kevin Ashton That lsquointernet of thingsrsquo thing 2009 URL httpwww
rfidjournalcomarticlesview4986 (Cited on page 3)
[10] Michael Backmann Anne Baumgrass Nico Herzberg Andreas Meyerand Mathias Weske Model-Driven Event Query Generation for Busi-ness Process Monitoring In Service-Oriented Computing ndash ICSOC 2013Workshops pages 406ndash418 Springer Cham December 2013 doi 101007978-3-319-06859-6_36 (Cited on pages 15 44 and 49)
139
140 bibliography
[11] Thomas Baier Claudio Di Ciccio Jan Mendling and Mathias WeskeMatching events and activities by integrating behavioral aspects andlabel analysis Software amp Systems Modeling 17(2)573ndash598 May 2018ISSN 1619-1374 doi 101007s10270-017-0603-z URL httpsdoi
org101007s10270-017-0603-z (Cited on page 32)
[12] Roberto Baldoni Leonardo Querzoni and Antonino Virgillito Dis-tributed event routing in publishsubscribe communication systems asurvey Technical report 2005 (Cited on page 48)
[13] A Barros G Decker and A Grosskopf Complex events in businessprocesses In BIS Springer 2007 (Cited on pages 44 45 47 49 56 69and 70)
[14] Reacutemi Bastide Ousmane Sy David Navarre and Philippe Palanque Aformal specification of the corba event service In Scott F Smith and Car-olyn L Talcott editors Formal Methods for Open Object-Based DistributedSystems IV pages 371ndash395 Boston MA 2000 Springer US ISBN 978-0-387-35520-7 (Cited on page 48)
[15] Kimon Batoulis Stephan Haarmann and Mathias Weske Various no-tions of soundness forAcirc decision-aware business processes In Hein-rich C Mayr Giancarlo Guizzardi Hui Ma and Oscar Pastor editorsConceptual Modeling pages 403ndash418 Cham 2017 Springer InternationalPublishing ISBN 978-3-319-69904-2 (Cited on page 107)
[16] A Baumgrass N Herzberg A Meyer and M Weske BPMN Extensionfor Business Process Monitoring In EMISA Lecture Notes in Informat-ics Gesellschaft fuer Informatik (GI) 2014 (Cited on pages 32 and 61)
[17] Anne Baumgraszlig Mirela Botezatu Claudio Di Ciccio Remco M Dijk-man Paul Grefen Marcin Hewelt Jan Mendling Andreas Meyer ShayaPourmirza and Hagen Voumllzer Towards a methodology for the engi-neering of event-driven process applications In Business Process Man-agement Workshops - BPM 2015 13th International Workshops InnsbruckAustria August 31 - September 3 2015 Revised Papers pages 501ndash5142015 doi 101007978-3-319-42887-1_40 URL httpsdoiorg10
1007978-3-319-42887-1_40 (Cited on pages 46 47 and 49)
[18] Anne Baumgrass Claudio Di Ciccio Remco M Dijkman MarcinHewelt Jan Mendling Andreas Meyer Shaya Pourmirza MathiasWeske and Tsun Yin Wong GET controller and UNICORN event-driven process execution and monitoring in logistics In Proceedings of theBPM Demo Session 2015 Co-located with the 13th International Conference onBusiness Process Management (BPM 2015) Innsbruck Austria September 22015 pages 75ndash79 2015 URL httpceur-wsorgVol-1418paper16
pdf (Cited on pages 46 54 and 116)
[19] Izak Benbasat and Robert W Zmud Empirical research in informationsystems The practice of relevance MIS Q 23(1)3ndash16 March 1999 ISSN0276-7783 doi 102307249403 URL httpdxdoiorg102307
249403 (Cited on pages xiii and 8)
[20] Jonas Beyer Patrick Kuhn Marcin Hewelt Sankalita Mandal and Math-ias Weske Unicorn meets chimera Integrating external events into case
bibliography 141
management In Proceedings of the BPM Demo Track 2016 Co-located withthe 14th International Conference on Business Process Management (BPMvolume 1789 of CEUR Workshop Proceedings pages 67ndash72 CEUR-WSorg2016 URL httpceur-wsorgVol-1789bpm-demo-2016-paper13
pdf (Cited on pages 54 and 115)
[21] L Brenna A Demers J Gehrke M Hong J Ossher B Panda M Riede-wald M Thatte and W White Cayuga a high-performance eventprocessing engine In SIGMODConf2007 pages 1100ndash1102 ACM 2007(Cited on page 48)
[22] Jan vom Brocke and Jan Mendling Frameworks for Business Process Man-agement A Taxonomy for Business Process Management Cases pages 1ndash1701 2018 ISBN 978-3-319-58306-8 doi 101007978-3-319-58307-5_1(Cited on page 13)
[23] Cristina Cabanillas Claudio Di Ciccio Jan Mendling and Anne Baum-grass Predictive Task Monitoring for Business Processes In ShaziaSadiq Pnina Soffer and Hagen Voumllzer editors BPM number 8659pages 424ndash432 Springer International Publishing September 2014 ISBN978-3-319-10171-2 978-3-319-10172-9 doi 101007978-3-319-10172-9_31(Cited on pages 45 and 49)
[24] Camunda camunda BPM Platform httpswwwcamundaorg (Citedon pages 5 and 47)
[25] Filip Caron Jan Vanthienen and Bart Baesens Comprehensive rule-based compliance checking and risk management with process min-ing Decision Support Systems 54(3)1357 ndash 1369 2013 ISSN 0167-9236 doi httpsdoiorg101016jdss201212012 URL httpwww
sciencedirectcomsciencearticlepiiS0167923612003788 (Citedon page 14)
[26] Federico Chesani Paola Mello Marco Montali Fabrizio Riguzzi Maur-izio Sebastianis and Sergio Storari Checking compliance of executiontraces to business rules In Danilo Ardagna Massimo Mecella and JianYang editors Business Process Management Workshops pages 134ndash145Berlin Heidelberg 2009 Springer Berlin Heidelberg ISBN 978-3-642-00328-8 (Cited on page 101)
[27] Michele Chinosi and Alberto Trombetta Bpmn An introduction to thestandard Computer Standards Interfaces 34(1)124 ndash 134 2012 ISSN 0920-5489 doi httpsdoiorg101016jcsi201106002 URL httpwww
sciencedirectcomsciencearticlepiiS0920548911000766 (Citedon page 4)
[28] G Chiola M A Marsan G Balbo and G Conte Generalizedstochastic petri nets a definition at the net level and its implicationsIEEE Transactions on Software Engineering 19(2)89ndash107 Feb 1993 doi10110932214828 (Cited on page 84)
[29] Mariano Cilia Alejandro Buchmann and Tu-Darmstadt K Moody Anactive functionality service for open distributed heterogeneous environ-ments 04 2019 (Cited on page 48)
142 bibliography
[30] Carlo Combi Barbara Oliboni and Francesca Zerbato Modeling andhandling duration constraints in BPMN 20 In Proceedings of the Sym-posium on Applied Computing SAC 2017 Marrakech Morocco April 3-7 2017 pages 727ndash734 2017 doi 10114530196123019618 URLhttpsdoiorg10114530196123019618 (Cited on page 50)
[31] G Cugola E Di Nitto and A Fuggetta Exploiting an event-basedinfrastructure to develop complex distributed systems In Proceedings ofthe 20th International Conference on Software Engineering pages 261ndash270April 1998 doi 101109ICSE1998671135 (Cited on page 48)
[32] Gianpaolo Cugola and Alessandro Margara TESLA a formally definedevent specification language In Proceedings of the Fourth ACM Inter-national Conference on Distributed Event-Based Systems DEBS 2010 Cam-bridge United Kingdom July 12-15 2010 pages 50ndash61 2010 doi 10114518274181827427 URL httpsdoiorg10114518274181827427(Cited on page 49)
[33] Michael Daum Manuel Goumltz and Joumlrg Domaschka Integrating cep andbpm How cep realizes functional requirements of bpm applications (in-dustry article) In DEBS pages 157ndash166 ACM 2012 (Cited on page 47)
[34] Alexandre de Castro Alves New event-processing design patterns us-ing cep In Stefanie Rinderle-Ma Shazia Sadiq and Frank Leymanneditors Business Process Management Workshops pages 359ndash368 BerlinHeidelberg 2010 Springer Berlin Heidelberg ISBN 978-3-642-12186-9(Cited on page 38)
[35] H de Man Case Management A Review of Modeling ApproachesBPTrends pages 1ndash17 January 2009 (Cited on page 50)
[36] Gero Decker and Jan Mendling Process instantiation Data KnowledgeEngineering 68(9)777ndash792 2009 doi 101016jdatak200902013 (Citedon page 48)
[37] Remco M Dijkman Marlon Dumas and Chun Ouyang Semanticsand analysis of business process models in BPMN Information andSoftware Technology 50(12)1281 ndash 1294 2008 ISSN 0950-5849 doihttpsdoiorg101016jinfsof200802006 (Cited on pages 10 22 2483 87 and 97)
[38] Remco M Dijkman B Sprenkels T Peeters and A Janssen Businessmodels for the internet of things Int J Information Management 35(6)672ndash678 2015 doi 101016jijinfomgt201507008 URL httpsdoi
org101016jijinfomgt201507008 (Cited on pages 42 and 49)
[39] Remco M Dijkman Geoffrey van IJzendoorn Oktay Tuumlretken andMeint de Vries Exceptions in business processes in relation to opera-tional performance CoRR abs170608255 2017 URL httparxiv
orgabs170608255 (Cited on page 43)
[40] Marlon Dumas and Matthias Weidlich Business Process Analytics pages1ndash8 Springer International Publishing Cham 2018 ISBN 978-3-319-63962-8 doi 101007978-3-319-63962-8_85-1 URL httpsdoiorg
101007978-3-319-63962-8_85-1 (Cited on pages 42 and 49)
bibliography 143
[41] Marlon Dumas Wil M van der Aalst and Arthur H ter Hofstede Pro-cess Aware Information Systems Bridging People and Software Through Pro-cess Technology Wiley-Interscience New York NY USA 2005 ISBN0471663069 (Cited on page 14)
[42] Marlon Dumas Marcello La Rosa Jan Mendling and Hajo A ReijersFundamentals of Business Process Management Springer 2013 ISBN 978-3-642-33142-8 doi 101007978-3-642-33143-5 URL httpdxdoiorg
101007978-3-642-33143-5 (Cited on page 13)
[43] Marius Eichenberg Event-Based Monitoring of Time Constraint ViolationsMaster thesis Hasso Plattner Institute 2016 (Cited on page 15)
[44] EsperTech Esper Event Processing Language EPL httpwww
espertechcomesperrelease-540esper-referencehtml (Citedon pages 49 and 60)
[45] Antonio Estruch and Joseacute Antonio Heredia Aacutelvaro Event-DrivenManufacturing Process Management Approach In BPM pages 120ndash133 Springer Berlin Heidelberg September 2012 doi 101007978-3-642-32885-5_9 (Cited on pages 44 45 and 49)
[46] Opher Etzion and Peter Niblett Event Processing in Action ManningPublications 2010 ISBN 9781935182214 (Cited on pages 3 27 29 3153 and 79)
[47] Patrick Th Eugster Pascal A Felber Rachid Guerraoui and Anne-MarieKermarrec The many faces of publishsubscribe ACM Comput Surv35(2)114ndash131 June 2003 ISSN 0360-0300 doi 101145857076857078URL httpdoiacmorg101145857076857078 (Cited on page 48)
[48] David Eyers Avigdor Gal Hans-Arno Jacobsen and Matthias Wei-dlich Integrating Process-Oriented and Event-Based Systems (DagstuhlSeminar 16341) Dagstuhl Reports 6(8)21ndash64 2017 ISSN 2192-5283doi 104230DagRep6821 URL httpdropsdagstuhldeopus
volltexte20176910 (Cited on page 69)
[49] Dirk Fahland and Christian Gierds Analyzing and completing middle-ware designs for enterprise integration using coloured petri nets InAdvanced Information Systems Engineering - 25th International ConferenceCAiSE 2013 Valencia Spain June 17-21 2013 Proceedings pages 400ndash4162013 doi 101007978-3-642-38709-8_26 URL httpdxdoiorg10
1007978-3-642-38709-8_26 (Cited on page 48)
[50] Mohammad Ali Fardbastani Farshad Allahdadi and Mohsen SharifiBusiness process monitoring via decentralized complex event process-ing Enterprise Information Systems 121ndash28 09 2018 doi 1010801751757520181522453 (Cited on pages 47 and 49)
[51] J Friedenstab C Janiesch M Matzner and O Muller Extendingbpmn for business activity monitoring In 2012 45th Hawaii Interna-tional Conference on System Sciences pages 4158ndash4167 Jan 2012 doi101109HICSS2012276 (Cited on pages 14 and 15)
[52] A Gal A Senderovich and M Weidlich Online temporal analysis ofcomplex systems using iot data sensing In 2018 IEEE 34th International
144 bibliography
Conference on Data Engineering (ICDE) pages 1727ndash1730 April 2018 doi101109ICDE201800224 (Cited on page 15)
[53] Samuel Greengard The internet of things MIT Press 2015 (Cited onpages 42 and 49)
[54] Christian W Guumlnther and Wil M P van der Aalst Mining activity clus-ters from low-level event logs 2006 (Cited on page 32)
[55] Stephan Haarmann Nikolai Podlesny Marcin Hewelt Andreas Meyerand Mathias Weske Production case management A prototypical pro-cess engine to execute flexible business processes In Proceedings of theBPM Demo Session 2015 Co-located with the 13th International Conferenceon Business Process Management (BPM 2015) Innsbruck Austria Septem-ber 2 2015 pages 110ndash114 2015 URL httpceur-wsorgVol-1418
paper23pdf (Cited on pages 54 and 119)
[56] N Herzberg A Meyer and M Weske An event processing platform forbusiness process management In EDOC IEEE 2013 (Cited on pages 345 49 and 58)
[57] Marcin Hewelt and Mathias Weske A hybrid approach for flexible casemodeling and execution In BPM 2016 (Cited on pages 50 and 119)
[58] Annika Hinze and Alejandro P Buchmann Principles and applications ofdistributed event-based systems Hershey PA Information Science Refer-ence 2010 (Cited on pages 31 and 47)
[59] Richard Hull Vishal S Batra Yi-Min Chen Alin Deutsch Fenno F TerryHeath III and Victor Vianu Towards a shared ledger business collabo-ration language based on data-aware processes In Quan Z Sheng EleniStroulia Samir Tata and Sami Bhiri editors Service-Oriented Computingpages 18ndash36 Cham 2016 Springer International Publishing ISBN 978-3-319-46295-0 (Cited on page 15)
[60] Hans-Arno Jacobsen Vinod Muthusamy and Guoli Li The PADRESEvent Processing Network Uniform Querying of Past and FutureEvents it - Information Technology 51(5)250ndash260 May 2009 (Cited onpages 48 and 49)
[61] Christian Janiesch Agnes Koschmider Massimo Mecella Barbara We-ber Andrea Burattin Claudio Di Ciccio Avigdor Gal Udo Kan-nengiesser Felix Mannhardt Jan Mendling Andreas Oberweis Man-fred Reichert Stefanie Rinderle-Ma WenZhan Song Jianwen Su Victo-ria Torres Matthias Weidlich Mathias Weske and Liang Zhang Theinternet-of-things meets business process management Mutual benefitsand challenges 09 2017 (Cited on pages 43 and 50)
[62] Kurt Jensen and Lars Kristensen Coloured Petri Nets Modelling and Val-idation of Concurrent Systems 01 2009 ISBN 978-3-642-00283-0 doi101007b95112 (Cited on page 97)
[63] Kurt Jensen and Lars Michael Kristensen Coloured Petri Nets - Mod-elling and Validation of Concurrent Systems Springer 2009 ISBN 978-3-642-00283-0 doi 101007b95112 URL httpdxdoiorg101007
b95112 (Cited on pages 21 and 22)
bibliography 145
[64] John Jeston and Johan Nelis Business process management Practicalguidelines to successful implementations 01 2008 (Cited on page 13)
[65] S Kaisler F Armour J A Espinosa and W Money Big data Issues andchallenges moving forward In 2013 46th Hawaii International Conferenceon System Sciences pages 995ndash1004 Jan 2013 doi 101109HICSS2013645 (Cited on page 3)
[66] Kathrin Kirchner Nico Herzberg Andreas Rogge-Solti and MathiasWeske Embedding Conformance Checking in a Process IntelligenceSystem in Hospital Environments In ProHealthKR4HC LNCS pages126ndash139 Springer 2012 (Cited on page 14)
[67] Julian Krumeich Benjamin L Weis Dirk Werth and Peter Loos Event-driven business process management where are we now A compre-hensive synthesis and analysis of literature Business Proc Manag Journal20615ndash633 2014 (Cited on pages 32 and 44)
[68] Steffen Kunz Tobias Fickinger Johannes Prescher and Klaus SpenglerManaging complex event processes with business process modeling no-tation In Jan Mendling Matthias Weidlich and Mathias Weske editorsBusiness Process Modeling Notation pages 78ndash90 Berlin Heidelberg 2010Springer Berlin Heidelberg ISBN 978-3-642-16298-5 (Cited on pages 44
and 49)
[69] Matthias Kunze and Mathias Weske Behavioural Models - From ModellingFinite Automata to Analysing Business Processes Springer 2016 ISBN978-3-319-44958-6 doi 101007978-3-319-44960-9 (Cited on pages 13
and 20)
[70] Andreas Lanz Manfred Reichert and Peter Dadam Robust and flex-ible error handling in the aristaflow bpm suite In CAiSE Forum 2010volume 72 of LNBIP pages 174ndash189 Springer 2011 (Cited on page 50)
[71] Guoli Li Vinod Muthusamy and Hans-Arno Jacobsen A distributedservice-oriented architecture for business process execution ACM Trans-actions on the Web (TWEB) 4(1)2 2010 (Cited on page 47)
[72] Niels Lohmann A feature-complete petri net semantics for WS-BPEL20 In Web Services and Formal Methods 4th International Workshop WS-FM 2007 Brisbane Australia September 28-29 2007 Proceedings pages77ndash91 2007 doi 101007978-3-540-79230-7_6 URL httpdxdoi
org101007978-3-540-79230-7_6 (Cited on pages 4 and 83)
[73] Niels Lohmann Eric Verbeek and Remco Dijkman Petri Net Trans-formations for Business Processes ndash A Survey pages 46ndash63 SpringerBerlin Heidelberg Berlin Heidelberg 2009 ISBN 978-3-642-00899-3 doi 101007978-3-642-00899-3_3 URL httpsdoiorg101007
978-3-642-00899-3_3 (Cited on page 83)
[74] David Luckham Event Processing for Business Organizing the Real-TimeEnterprise 01 2012 (Cited on pages 3 and 32)
[75] David C Luckham The Power of Events An Introduction to Complex EventProcessing in Distributed Enterprise Systems Addison-Wesley 2010 ISBN0201727897 (Cited on pages 18 and 56)
146 bibliography
[76] Linh Thao Ly Stefanie Rinderle and Peter Dadam Semantic correct-ness in adaptive process management systems In Schahram DustdarJoseacute Luiz Fiadeiro and Amit P Sheth editors Business Process Manage-ment pages 193ndash208 Berlin Heidelberg 2006 Springer Berlin Heidel-berg ISBN 978-3-540-38903-3 (Cited on page 101)
[77] Alexander Luumlbbe Tangible Business Process Modeling Dissertation Uni-versitaumlt Potsdam 2011 (Cited on page 13)
[78] Sankalita Mandal Events in BPMN the racing events dilemma In Pro-ceedings of the 9th Central European Workshop on Services and their Compo-sition (ZEUS) volume 1826 of CEUR Workshop Proceedings pages 23ndash30CEUR-WSorg 2017 URL httpceur-wsorgVol-1826paper5pdf(Cited on pages 7 50 and 70)
[79] Sankalita Mandal and Mathias Weske A flexible event handling modelfor business process enactment In 22nd IEEE International EnterpriseDistributed Object Computing Conference EDOC pages 68ndash74 IEEE Com-puter Society 2018 doi 101109EDOC201800019 URL httpsdoi
org101109EDOC201800019 (Cited on pages 62 65 69 83 and 101)
[80] Sankalita Mandal Marcin Hewelt and Mathias Weske A frameworkfor integrating real-world events and business processes in an iot en-vironment In On the Move to Meaningful Internet Systems OTM 2017Conferences - Confederated International Conferences CoopIS CampTC andODBASE Proceedings Part I volume 10573 of Lecture Notes in ComputerScience pages 194ndash212 Springer 2017 doi 101007978-3-319-69462-7_13 URL httpsdoiorg101007978-3-319-69462-7_13 (Cited onpages 7 53 and 54)
[81] Sankalita Mandal Matthias Weidlich and Mathias Weske Events inbusiness process implementation Early subscription and event buffer-ing In Business Process Management Forum - BPM Forum volume 297
of Lecture Notes in Business Information Processing pages 141ndash159 Sprin-ger 2017 doi 101007978-3-319-65015-9_9 URL httpsdoiorg
101007978-3-319-65015-9_9 (Cited on pages 50 65 69 83 110and 122)
[82] Sankalita Mandal Marcin Hewelt Maarten Oestreich and MathiasWeske A classification framework for iot scenarios In Business Pro-cess Management Workshops - BPM 2018 International Workshops vol-ume 342 of Lecture Notes in Business Information Processing pages 458ndash469 Springer 2018 doi 101007978-3-030-11641-5_36 URL https
doiorg101007978-3-030-11641-5_36 (Cited on pages 7 42 49and 53)
[83] Felix Mannhardt Massimiliano de Leoni Hajo A Reijers Wil M Pvan der Aalst and Pieter J Toussaint Guided process discovery - apattern-based approach Inf Syst 761ndash18 2018 (Cited on page 32)
[84] R Meier and V Cahill Steam event-based middleware for wireless adhoc networks In Proceedings 22nd International Conference on DistributedComputing Systems Workshops pages 639ndash644 July 2002 doi 101109ICDCSW20021030841 (Cited on page 48)
bibliography 147
[85] Giovanni Meroni Artifact-driven Business Process Monitoring PhD thesis06 2018 (Cited on pages 46 and 49)
[86] A Metzger P Leitner D Ivanovic E Schmieders R Franklin M CarroS Dustdar and K Pohl Comparing and combining predictive businessprocess monitoring techniques IEEE Transactions on Systems Man andCybernetics Systems 45(2)276ndash290 Feb 2015 ISSN 2168-2216 doi 101109TSMC20142347265 (Cited on page 15)
[87] A Meyer A Polyvyanyy and M Weske Weak Conformance of ProcessModels with respect to Data Objects In Services and their Composition(ZEUS) 2012 (Cited on page 14)
[88] M Muehlen and J Recker How Much Language is Enough Theoret-ical and Practical Use of the Business Process Modeling Notation InAdvanced Information Systems Engineering pages 465ndash479 Springer 2008(Cited on page 136)
[89] Max Muhlhauser and Iryna Gurevych Ubiquitous Computing Technologyfor Real Time Enterprises Information Science Reference - Imprint of IGIPublishing Hershey PA 2007 ISBN 1599048353 9781599048352 (Citedon pages 30 and 31)
[90] Jorge Munoz-Gama Conformance checking and diagnosis in processmining In Lecture Notes in Business Information Processing 2016 (Citedon page 14)
[91] S Nechifor A Petrescu D Damian D Puiu and B Tacircrnauca Predic-tive analytics based on cep for logistic of sensitive goods In 2014 Inter-national Conference on Optimization of Electrical and Electronic Equipment(OPTIM) pages 817ndash822 May 2014 doi 101109OPTIM20146850965(Cited on pages 47 and 53)
[92] OASIS Web Services Business Process Execution Language Version 20April 2007 (Cited on page 4)
[93] Michael Offel Han van der Aa and Matthias Weidlich Towardsnet-based formal methods for complex event processing In Proceed-ings of the Conference Lernen Wissen Daten Analysen LWDA 2018Mannheim Germany August 22-24 2018 pages 281ndash284 2018 URLhttpceur-wsorgVol-2191paper32pdf (Cited on page 83)
[94] OMG Business Process Model and Notation (BPMN) Version 20 Jan-uary 2011 (Cited on pages 3 5 18 54 65 113 and 123)
[95] OMG Unified Modeling Language (UML) Version 25 2012 (Cited onpages 5 and 123)
[96] OMG Decision Model and Notation (DMN) Version 11 June 2016(Cited on page 16)
[97] M Pesic and W M P van der Aalst A declarative approach for flexiblebusiness processes management In Johann Eder and Schahram Dustdareditors Business Process Management Workshops pages 169ndash180 BerlinHeidelberg 2006 Springer Berlin Heidelberg ISBN 978-3-540-38445-8(Cited on page 15)
148 bibliography
[98] Paul Pichler Barbara Weber Stefan Zugal Jakob Pinggera JanMendling and Hajo A Reijers Imperative versus declarative processmodeling languages An empirical investigation In Florian DanielKamel Barkaoui and Schahram Dustdar editors Business Process Man-agement Workshops pages 383ndash394 Berlin Heidelberg 2012 SpringerBerlin Heidelberg ISBN 978-3-642-28108-2 (Cited on page 15)
[99] P R Pietzuch and J M Bacon Hermes a distributed event-basedmiddleware architecture In Proceedings 22nd International Conferenceon Distributed Computing Systems Workshops pages 611ndash618 2002 doi101109ICDCSW20021030837 (Cited on page 48)
[100] Louchka Popova-Zeugmann Time and Petri Nets 11 2013 ISBN 978-3-642-41114-4 doi 101007978-3-642-41115-1 (Cited on page 21)
[101] Luise Pufahl Sankalita Mandal Kimon Batoulis and Mathias WeskeRe-evaluation of decisions based on events In Enterprise Business-Process and Information Systems Modeling - 18th International ConferenceBPMDS volume 287 of Lecture Notes in Business Information Processingpages 68ndash84 Springer 2017 doi 101007978-3-319-59466-8_5 URLhttpsdoiorg101007978-3-319-59466-8_5 (Cited on pages 7
and 46)
[102] Vivek Ranadive and Kevin Maney The Two-Second Advantage How WeSucceed by Anticipating the FuturendashJust Enough Crown Business 2011ISBN 0307887650 (Cited on page 3)
[103] Manfred Reichert Stefanie Rinderle-Ma and Peter Dadam Flexibility inprocess-aware information systems ToPNoC 5460115ndash135 2009 (Citedon page 50)
[104] Wolfgang Reisig Understanding Petri Nets - Modeling Techniques AnalysisMethods Case Studies Springer 2013 (Cited on page 21)
[105] Leonard Richardson and Sam Ruby Restful Web Services OrsquoReilly firstedition 2007 ISBN 9780596529260 (Cited on page 5)
[106] Pedro H Piccoli Richetti Fernanda Araujo Baiatildeo and Flaacutevia Maria San-toro Declarative process mining Reducing discovered models complex-ity by pre-processing event logs In Shazia Sadiq Pnina Soffer and Ha-gen Voumllzer editors Business Process Management pages 400ndash407 Cham2014 Springer International Publishing ISBN 978-3-319-10172-9 (Citedon page 32)
[107] A Rogge-Solti N Herzberg and L Pufahl Selecting Event MonitoringPoints for Optimal Prediction Quality In EMISA pages 39ndash52 2012(Cited on page 15)
[108] Sherif Sakr Zakaria Maamar Ahmed Awad Boualem Benatallah andWil M P Van Der Aalst Business process analytics and big data systemsA roadmap to bridge the gap IEEE Access PP1ndash1 11 2018 doi 101109ACCESS20182881759 (Cited on pages 43 and 49)
[109] Matthias J Sax Guozhang Wang Matthias Weidlich and Johann-Christoph Freytag Streams and tables Two sides of the same coin InProceedings of the International Workshop on Real-Time Business Intelligence
bibliography 149
and Analytics BIRTE 2018 Rio de Janeiro Brazil August 27 2018 pages11ndash110 2018 doi 10114532421533242155 URL httpsdoiorg
10114532421533242155 (Cited on page 49)
[110] Helen Schonenberg Ronny Mans Nick Russell Nataliya Mulyar andWil van der Aalst Process flexibility A survey of contemporary ap-proaches In Jan L G Dietz Antonia Albani and Joseph Barjis ed-itors Advances in Enterprise Engineering I pages 16ndash30 Berlin Heidel-berg 2008 Springer Berlin Heidelberg ISBN 978-3-540-68644-6 (Citedon page 50)
[111] Stefan Schoumlnig Lars Ackermann Stefan Jablonski and Andreas ErmerAn integrated architecture for iot-aware business process execution InJens Gulden Iris Reinhartz-Berger Rainer Schmidt Seacutergio GuerreiroWided Gueacutedria and Palash Bera editors Enterprise Business-Process andInformation Systems Modeling pages 19ndash34 Cham 2018 Springer Inter-national Publishing ISBN 978-3-319-91704-7 (Cited on page 42)
[112] Stefan Schoumlnig Ana Paula Aires Andreas Ermer and Stefan JablonskiWorkflow Support in Wearable Production Information Systems pages 235ndash243 06 2018 ISBN 978-3-319-92900-2 doi 101007978-3-319-92901-9_20 (Cited on pages 42 and 49)
[113] Ronny Seiger Christine Keller Florian Niebling and Thomas SchlegelModelling complex and flexible processes for smart cyber-physical envi-ronments Journal of Computational Science 10137 ndash 148 2015 ISSN 1877-7503 doi httpsdoiorg101016jjocs201407001 URL httpwww
sciencedirectcomsciencearticlepiiS1877750314000970 (Citedon page 47)
[114] Arik Senderovich Andreas Rogge-Solti Avigdor Gal Jan Mendlingand Avishai Mandelbaum The road from sensor data to process in-stances via interaction mining In Selmin Nurcan Pnina Soffer MarkoBajec and Johann Eder editors Advanced Information Systems Engineer-ing pages 257ndash273 Cham 2016 Springer International Publishing ISBN978-3-319-39696-5 (Cited on page 32)
[115] Natalia Sidorova Christian Stahl and Nikola Trcka Workflow sound-ness revisited Checking correctness in the presence of data while stay-ing conceptual In Barbara Pernici editor Advanced Information SystemsEngineering pages 530ndash544 Berlin Heidelberg 2010 Springer BerlinHeidelberg ISBN 978-3-642-13094-6 (Cited on page 107)
[116] H Smith and P Fingar Business Process Management The Third Wave 01
2006 (Cited on page 13)
[117] Pnina Soffer Annika Hinze Agnes Koschmider Holger Ziekow Clau-dio Di Ciccio Boris Koldehofe Oliver Kopp Arno Jacobsen Jan Suumlrmeliand Wei Song From event streams to process models and back Chal-lenges and opportunities Information Systems 01 2018 (Cited onpages 44 and 50)
[118] Kunal Suri Modeling the Internet of Things in Configurable Process ModelsPhD thesis 02 2019 (Cited on page 45)
150 bibliography
[119] Niek Tax Natalia Sidorova Reinder Haakma and Wil M P van derAalst Event abstraction for process mining using supervised learningtechniques CoRR abs160607283 2016 (Cited on page 32)
[120] Niek Tax Ilya Verenich Marcello La Rosa and Marlon Dumas Pre-dictive business process monitoring with lstm neural networks In EricDubois and Klaus Pohl editors Advanced Information Systems Engineer-ing pages 477ndash492 Cham 2017 Springer International Publishing ISBN978-3-319-59536-8 (Cited on page 14)
[121] UNICORN Complex Event Processing Platform httpsbpthpi
uni-potsdamdeUNICORNWebHome (Cited on page 58)
[122] W M P van der Aalst Verification of workflow nets In Pierre Azeacutemaand Gianfranco Balbo editors Application and Theory of Petri Nets 1997pages 407ndash426 Berlin Heidelberg 1997 Springer Berlin HeidelbergISBN 978-3-540-69187-7 (Cited on page 83)
[123] W M P van der Aalst K M van Hee A H M ter HofstedeN Sidorova H M W Verbeek M Voorhoeve and M T WynnSoundness of workflow nets classification decidability and analy-sis Formal Aspects of Computing 23(3)333ndash363 May 2011 ISSN 1433-299X doi 101007s00165-010-0161-4 URL httpsdoiorg101007
s00165-010-0161-4 (Cited on page 107)
[124] Wil van der Aalst Process Mining Data Science in Action Springer Pub-lishing Company Incorporated 2nd edition 2016 ISBN 36624985029783662498507 (Cited on pages 3 13 and 15)
[125] Wil M P van der Aalst Niels Lohmann Peter Massuthe Chris-tian Stahl and Karsten Wolf Multiparty contracts Agreeing andimplementing interorganizational processes Comput J 53(1)90ndash1062010 doi 101093comjnlbxn064 URL httpdxdoiorg101093
comjnlbxn064 (Cited on page 47)
[126] Maximilian Voumllker Sankalita Mandal and Marcin Hewelt Testing event-driven applications with automatically generated events In Proceedingsof the BPM Demo Track and BPM Dissertation Award co-located with 15th In-ternational Conference on Business Process Modeling volume 1920 of CEURWorkshop Proceedings CEUR-WSorg 2017 URL httpceur-wsorg
Vol-1920BPM_2017_paper_182pdf (Cited on pages 115 and 117)
[127] Rainer von Ammon C Silberbauer and C Wolff Domain specific refer-ence models for event patterns - for faster developing of business activitymonitoring applications 2007 (Cited on pages 38 45 and 49)
[128] Rainer von Ammon Christoph Emmersberger Torsten Greiner Flo-rian Springer and Christian Wolff Event-driven business processmanagement In Fast Abstract Second International Conference on Dis-tributed Event-Based Systems DEBS 2008 Rom Juli 2008 2008 URLhttpsepubuni-regensburgde6829 (Cited on page 44)
[129] Barbara Weber Jakob Pinggera Stefan Zugal and Werner Wild Han-dling events during business process execution An empirical test InER-POISCAiSE 2010 (Cited on page 43)
bibliography 151
[130] M Weidlich G Decker A Groszlig kopf and M Weske BPEL to BPMNThe Myth of a Straight-Forward Mapping In On the Move to MeaningfulInternet Systems pages 265ndash282 Springer 2008 (Cited on page 4)
[131] Matthias Weidlich Behavioural profiles a relational approach to behaviourconsistency PhD thesis University of Potsdam 2011 (Cited on pages 20
and 47)
[132] Matthias Weidlich Holger Ziekow Jan Mendling Oliver Guumlnther Math-ias Weske and Nirmit Desai Event-based monitoring of process exe-cution violations In BPM pages 182ndash198 Springer 2011 (Cited onpages 14 44 and 49)
[133] Matthias Weidlich Holger Ziekow Avigdor Gal Jan Mendling andMathias Weske Optimizing event pattern matching using businessprocess models IEEE Trans Knowl Data Eng 26(11)2759ndash2773 2014doi 101109TKDE20142302306 URL httpsdoiorg101109TKDE
20142302306 (Cited on pages 47 and 49)
[134] Mathias Weske Business Process Management - Concepts Languages Ar-chitectures 2nd Edition Springer 2012 ISBN 978-3-642-28615-5 doi101007978-3-642-28616-2 (Cited on pages 3 13 15 62 and 83)
[135] Mathias Weske Business Process Management - Concepts LanguagesArchitectures Third Edition Springer 2019 ISBN 978-3-662-59431-5 doi 101007978-3-662-59432-2 URL httpsdoiorg101007
978-3-662-59432-2 (Cited on page 21)
[136] Dennis Wolf Flexible event subscription in business processes DissertationUniversitaumlt Potsdam 2017 (Cited on pages 115 and 122)
[137] Karsten Wolf Petri net model checking with lola 2 In Victor Khomenkoand Olivier H Roux editors Application and Theory of Petri Nets and Con-currency pages 351ndash362 Cham 2018 Springer International PublishingISBN 978-3-319-91268-4 (Cited on pages 83 and 97)
[138] Honguk Woo Aloysius K Mok and Deji Chen Realizing the poten-tial of monitoring uncertain event streams in real-time embedded appli-cations IEEE Real-Time and Embedded Technology and Applications 2007(Cited on page 47)
[139] R Worzberger T Kurpick and T Heer Checking correctness and com-pliance of integrated process models In 2008 10th International Sympo-sium on Symbolic and Numeric Algorithms for Scientific Computing pages576ndash583 Sep 2008 doi 101109SYNASC200810 (Cited on page 101)
[140] C Zang and Y Fan Complex event processing in enterprise informa-tion systems based on rfid Enterprise Information Systems 1(1)3ndash232007 doi 10108017517570601092127 URL httpsdoiorg101080
17517570601092127 (Cited on page 47)
All links were last followed on 20092019
D E C L A R AT I O N
I hereby confirm that I have authored this thesis independently andwithout use of others than the indicated sources All passages which areliterally or in general matter taken out of publications or other sourcesare marked as such I am aware of the examination regulations and thisthesis has not been previously submitted elsewhere
Potsdam GermanyDecember 2019
Sankalita Mandal
- Title
-
- Imprint
-
- Abstract
- Zusammenfassung
- Publications
- Acknowledgments
- Contents
- List of Figures
- Listings
- Acronyms
- Introduction amp Foundations
-
- 1 Introduction
-
- 11 Problem Statement
- 12 Research Objectives
- 13 Contributions
- 14 Structure of Thesis
-
- 2 Business Process Management
-
- 21 BPM Life Cycle
- 22 Business Process Model and Notation
-
- 221 Core Elements
- 222 Events in Business Processes
-
- 23 Petri Nets
- 24 BPMN to Petri Net Mapping
-
- 3 Complex Event Processing
-
- 31 Basic Concepts
- 32 Event Distribution
- 33 Event Abstraction
- 34 Event Processing Techniques
-
- 4 Related Work
-
- 41 Overview
- 42 External Events in BPM
- 43 Integrated Applications
- 44 Flexible Event Subscription amp Buffering
- 45 Summary
-
- Conceptual Framework
-
- 5 Integrating Real-World Events into Business Process Execution
-
- 51 Motivation amp Overview
- 52 Requirements Analysis
-
- 521 R1 Separation of Concerns
- 522 R2 Representation of Event Hierarchies
- 523 R3 Implementation of Integration
-
- 53 System Architecture
-
- 531 Distribution of Logic
- 532 Use of Event Abstraction
- 533 Implementation Concepts
-
- 54 Summary amp Discussion
-
- 6 Flexible Event Handling Model
-
- 61 Motivation amp Overview
- 62 Event Handling Notions
-
- 621 Business Process View
- 622 Event Processing View
-
- 63 Flexible Subscription Management
-
- 631 Points of Subscription
- 632 Points of Unsubscription
- 633 Event Buffering
- 634 Semantic Interdependencies
-
- 64 Summary amp Discussion
-
- 7 Formal Execution Semantics
-
- 71 Motivation amp Overview
- 72 Petri Net Mapping
-
- 721 Event Handling Notions
- 722 Points of Subscription
- 723 Points of Unsubscription
- 724 Event Buffering
-
- 73 Summary amp Discussion
-
- Evaluation amp Conclusions
-
- 8 Application of Concepts
-
- 81 Execution Trace Analysis
-
- 811 Correctness Constraints
- 812 Impact of Event Handling
- 813 Discussion
-
- 82 Reachability Analysis
-
- 821 Communication Model
- 822 Impact of Event Handling
- 823 Discussion
-
- 83 Summary
-
- 9 Proof-of-Concept Implementation
-
- 91 Basic Event Interaction
-
- 911 Unicorn Event Processing Platform
- 912 Gryphon Case Modeler
- 913 Chimera Process Engine
- 914 Event Integration Sequence
-
- 92 Flexible Event Subscription with Buffering
-