Enabling Compliance Monitoring for Process Execution Engines Marwa Hussein Zaki , Ahmed Awad , and Osman Hegazy Information Systems Department, Faculty of Computers and Information, Cairo University, Giza 12613, Egypt m.hussein, a.gaafar, o.hegazy@fci-cu.edu.eg Abstract. Most of organizations try to ensure that their business processes are compliant with regulations and laws, so runtime monitoring of process compli- ance is considered to be of crucial importance. In this regard, there are several frameworks that enable the monitoring based on variants of event processing technologies. Most of these frameworks presume a rich activity lifecycle model for the execution of tasks. However, most of process execution engines support simpler lifecycle models. Thus, these frameworks fall short in monitoring com- pliance for such engines due to missing needed input events. The goal of this paper is to enable compliance monitoring for different process execution engines. First we propose a middleware layer that maps different exe- cution engines’ lifecycles states to a reference lifecycle model. Also, unmatched states will be derived from execution’s engine states. Additionally, we implement compliance anti patterns to prove the feasibility of our approach. Keywords: Business Process Management; web services; compliance; runtime monitoring; lifecycle mapping 1 Introduction Most of the organizations try to ensure the compliance of their business processes against regulations and laws to avoid non-compliance penalties [21]. As a result, differ- ent approaches were developed to check the compliance of a business processes through different phases of a business process lifecycle [13,21] e.g., at design time [21], at the process execution (runtime) [3] or at the evaluation phase [18]. Compliance monitoring at process execution time is considered of utmost impor- tance because not every possibility of violation can be checked at design time. Several approaches have been developed to enable the monitoring of running processes compli- ance, e.g. [14,3]. Most of the monitoring frameworks presume a rich activity lifecycle model, cf. [3,10] compared to the simple task lifecycle models supported by business process execution engines. So, many of the expected execution events by the moni- toring frameworks will be missing. This introduces the threat of having violations go undetected. To make use of those frameworks, the gap between what is provided by execution engines and what is expected by monitoring frameworks has to be filled. In this paper, we propose a mapping approach that fills the gap between the activ- ity lifecycle models supported by different process execution engines and the reference 2 Enabling Marwa Compliance Hussein Zaki, Monitoring Ahmed Awad for Process and Osman Hegazy Execution Engines 31 lifecycle model proposed by Russell et al. [19] and supported by the BP-MaaS moni- toring framework [3], as an example monitoring framework, and two process execution engines: Activiti [17] and jBPM [6]. For each, we have studied the supported task life- cycle models of the engines, compared them to the reference lifecycle and identified the mapping. To achieve the compliance monitoring, we implemented the compliance patterns presented in [3]. The rest of the paper is organized as follows: Section 2 presents our proposed model, Section 3 discusses related work and Section 4 concludes the paper with an outlook on future work. The needed preliminaries, some of the background techniques and a simple running example are provided in an extended version of this paper [9]. 2 Enabling Monitoring Lifecycle Mapping Logic Reference Engine Raw Event Mapping Lifecycle Events Stream Reference Events Compliance Monitoring Violation Rules System Events Fig. 1: Proposed monitoring system framework Our contribution can be seen as a middleware which consists of: a) An engine- specific mapping to the reference task lifecycle b) Implementation of the compliance monitoring anti patterns in [3]. Fig. 1 depicts the architecture of the middleware. The Lifecycle Mapping Logic is a set of rules used to perform the mapping from Engine’s raw events to the reference events. Currently, these rules are manually derived and pro- grammed into an executable language. For the case of jBPM, the mapping rules are encoded as Drools rules. For Activiti, rules are encoded as extensions to the engine and written in EPL syntax, more details are given later in this section. The mapping logic is done offline and once per process execution engine. It only needs to be revisited in case either the engine lifecycle or the reference lifecycle is changed. At runtime, the moni- toring system detects and throws violation events, if any, based on the input compliance rules and the events coming from the reference events stream. 2.1 Reference Task Lifecycle The lifecycle in Fig. 2 illustrates the state transitions of tasks as follows: a work item (a task) is created by the system. It is either directly started or allocated to a resource. A 32 Enabling Compliance Monitoring for Process Execution Engines Lifecycle Mapping 3 task can be delegated to another resource either by the system (escalate), or the respon- sible resource (delegate). After assigning a resource, the task will be started. However, the resource can skip it to be completed directly. Moreover, a resource can suspend a task to be suspended and resume it again (resume) to be started and finally completed or (redo) it after completion. If the resource fails to execute the task failed, it can try to (restart) it again or (reallocate) to another resource . More details about this lifecycle could be found in the extended version of this paper [9]. Fig. 2: Reference task lifecycle model adapted from [19] 2.2 Lifecycle Mapping The lifecycle mapping part has two inputs: (1) Engine Raw Events Stream and (2) Life- cycle Mapping Logic which contains a list of rules used to obtain the corresponding reference event. The output of this part is the Reference Event Stream which contains the mapped and the derived missing reference events. There are four different possibilities for mapping an engine-specific event/state to the reference state. The first possibility is that there is a direct correspondence. Both the engine activity state and the reference state carry the same name and meaning. The sec- ond possibility is that there is a naming mismatch but a conceptual match. For instance, the engine defines activity state assigned which is matched with the reference state allocated. The third possibility is that the reference state can be derived via observing a pattern over one or more of the engine’s states. As an example, the reference state tran- sition resumed can be derived by detecting a sequence of suspended and started events of the same task instance and the same performer. The last possibility is that there is no mapping possible, this means that the engine does not support this state. We investigated different execution engines’ lifecycles for different languages such as BPMN, BEPL and workflow systems (YAWL). A survey about these engines and their lifecycles could be found on the extended version of this paper [9] We report im- plementation on jBPM [6] and Activiti [17] as Camunda 1 and Activiti almost have the same API functions. We investigated the YAWL workflow engine’s lifecycle [20] with- out a specific implementation as this workflow system is more scientific and complex for regular user; rather than BPMN execution engines which are easier to understand and use. Table 1 summarizes the mapping between the different states of these engines’s lifecycle to the reference lifecycle. 1 https://camunda.com/ 4 Enabling Marwa Compliance Hussein Zaki, Monitoring Ahmed Awad for Process and Osman Hegazy Execution Engines 33 Table 1: Mapping the lifecycle of different engines to the reference lifecycle Reference states Engine States Activiti jBM Camunda YAWL Created create created new Enabled Allocated assignment reserved assigned Enabled 2 Started Rule 1 in progress Rule 1 Fired Suspended Rule 2 suspended Rule 2 Suspended Failed no mapping failed no mapping Failed Completed complete completed completed Complete The direct mapping and the naming mismatch are straightforward. In the latter case, when the engine generates an event with the mis-named state, our approach generates another event copying all the data of the original event except for the state where the conceptually equivalent state is substituted. In the third case, the approach can derive the reference state by observing the occurrence of one or more of the engine’s events. This process happens by adding engine extension to throw a new event when the engine performs an operation on the task that is not supported by its lifecycle. The following rules are specific for each engine. For Activiti and Camunda engines: – Rule 1: (Start on Create) action can be inferred when task t is created with per- former ri and the system directly starts this task. If the start event is not supported by the engine, we consider that the task is immediately started after creation and a new start on create event is thrown and mapped to started reference event. – Rule 2: (Suspended) event can be inferred when the whole process instance is sus- pended as the engine doesn’t support the suspended state on the task level. When the engine reports a wait state for the process instance, we can detect that a sus- pended event occurred and is thrown to the stream. After the investigation of the Activiti and Camunda engines, we found that the failed state is not supported and there is no way of mapping this state. 2.3 Compliance Monitoring Implementation This subsection provides the implementation details of compliance monitoring within Activiti and jBPM engines. We use complex event processing (CEP) with the help of Esper within Activiti which consists of four parts: (1) Business Process Model where we define task listeners in the XML file defining the process, (2) Task Listeners that detect any change in the task’s state through the process execution and generate a predefined event to be analyzed later, (3) Esper Engine that is responsible for generating streams and populating them with events coming from different sources, initiating listeners to detect events from the engine, throwing new events in case of any changes after pro- cessing and communicating with our middleware (4) Stream; that contains all kinds of 2 Enabled state with more information about the resource 34 Enabling Compliance Monitoring for Process Execution Engines Lifecycle Mapping 5 events either raw, mapped or complex events thrown from our middleware. All the logic for mapping events or implementation of compliance anti patterns is implemented using Event Processing Language (EPL) and Drools Rule Language (DRL). The following lists present a sample EPL query of the implementation of the map- ping cases. Listing 1.1: EPL statements for naming mismatch for the allocated state 1 insert into referenceeventsstream ( taskInstanceId , receiveTime , 2 eventType , performer ) select taskInstanceId , receiveTime , 3 'allocated ',performer from engineraweventsstream where 4 eventType = ? " jBPM supports the CEP technology through the integration with Drools [2]. The mapping approach on jBPM starts by defining an active session to register the streams which contains the raw events generated from the process instances execution. After that Drools rules match the incoming events with the defined mapping logic and fires when a mapping match is found. The following list introduces a sample of the Drools rule used in the naming mis- match case in jBPM for the inprogress state. Listing 1.2: inprogress detection drools rule 1 rule " inprogress Rule" 2 when 3 $mevent : events ( tasktype ==" InProgress ") from 4 entry -point engineStream then 5 $mevent . seteventType (" started "); 6 update ( $mevent ); The second part of our approach is the implementation of the compliance rules us- ing the anti patterns technique presented in [3]. We implemented most of the patterns, e.g. exist,absence, response, one to one response, next, sequence and separation of duty using the rule semantics logic of the Drools engine [2]. The framework uses the refer- ence events stream and the compliance patterns as input and matches each pattern with its corresponding anti-pattern rule to detect any possible violation as depicted in Fig. 1. We implement this part using the Drools fusion component which contains complex event processing features. The anti patterns queries are written using the Drools rule language (DRL) and are stored in the production memory of the Drools engine. The compliance rules which present one of the inputs for the compliance monitoring part is stored in the working memory of the engine as ”facts” to be compared later with the stored Drools rules. The streams containing events in Drools engine are called entry points. Based on the compliance rules and the events from the entry points, Drools rules fire and throw a violation event whenever a violation occurs. The following list introduces sample of the rules used to implement the compliance rules anti-patterns. Listing 1.3: Exist anti pattern rule 1 2 Exist anti pattern 3 when Event ( $task : task , $ts : tistamp , $type : type , 6 Enabling Marwa Compliance Hussein Zaki, Monitoring Ahmed Awad for Process and Osman Hegazy Execution Engines 35 4 $pi : processinstance ) from entry -point Stream 5 $comprules : Comprules ( pattern == " exist", scopestart == $type , 6 $mul: multiplicity ) 7 $total : Number ( intValue > $mul ) 8 from accumulate ( Event ( task == $comprules .antecedent , 9 tistamp > $ts , type == $comprules .scopeend , processinstance == $pi , 10 $ant: task ) from entry -point Stream ,count($ant )) 11 then System .out. println ("Exist pattern VIOLATION --> 12 the antecedent count 13 is GREATER THAN multiplicity , Evaluate Loan request delegation 14 happened more than once "); The full set of implemented rules and mapping part implementation on Activiti and jBPM engines could be found here: https://github.com/MarwaHusseinZaki/Lifecycle- Mapping.git. Also more details about the evaluation and results of our approach could be found in this extended version of the paper [9]. 3 Related Work Regarding runtime monitoring frameworks, [1] combines BPM with CEP for monitor- ing business process execution. They used the activity lifecycle from [23], the refined process structure tree (RPST) [16] to analyze process models, CEP queries and pro- cess event monitoring points (PEMPs) to monitor business process execution based on events in semi-automated environments. [8] introduces a framework that addresses the gap between events occurring during process execution and the correlation of these events to the corresponding process using PEMPs. In [4] the authors present a frame- work for monitoring the progress of task execution and predicting problems during runtime, using Support Vector Machines (SVMs) machine learning. The authors in [3] present a runtime business process compliance monitoring framework, BP-MaaS. Their work is based on compliance patterns for the specification of runtime constraints and anti-pattern queries notation to detect runtime compliance violations using CEP. In [11,12], authors presented a framework for monitoring business process com- pliance by introducing the extended Compliance Rule Graph (eCRG) for monitoring compliance rules visually with respect to all relevant process perspective. This frame- work supports the activity lifecycle by capturing the activity states and implements a correlation mechanism between events. [10] presented a generic framework to monitor process instances from different process perspectives. They are using the lifecycle from [19] and defines the events as a points to be tracked by their monitoring system which carry information from different perspectives. Our work could complement their work as they are not focusing on the resource perspective in their implementation. [5] fo- cused on realizing a monitoring component for the YAWL system using sensors, which monitors conditions that can be achieved through cases. All the previous work focused on monitoring business process over runtime envi- ronment based on events with different task or activity lifecycles. Our work aims at trying to help them by developing a mapping approach that will unify the states of events produced from process execution with their supported lifecycle to remove any inconsistency. 36 Enabling Compliance Monitoring for Process Execution Engines Lifecycle Mapping 7 With respect to task lifecycle used in monitoring systems, [7] discuss increasing the number of observed events by capturing data state transition events in non automated environment. They focus on the object lifecycle states generated from data objects. [15] addresses the problem of modeling processes with complex data dependencies and their enactment from process models. They focus on the process data level and data objects. Meanwhile, [22] presents an approach that captures the whole process life cycle and all kinds of changes in an integrated way. They are focusing mainly on control-flow changes. The changes of the resource perspective or data perspective are out of the scope of that paper. As discussed above, most of the monitoring frameworks use different task lifecycle models. Also, most of researches which address lifecycle models focus on either the data perspective or the lifecycle states extracted from the non automated environments, not generated from execution engine. For those approches that support automated pro- cess execution, we position our work as complementary to their work when it comes to actual implementations on available open source process execution engines. 4 Conclusion and Future Work In this paper, we proposed an approach that maps different execution engines’ lifecy- cles states to a reference lifecycle model. Also, the approach infers missing events that the execution engine does not support. The proposed approach serves as a middleware between process enactment and third party monitoring systems. To prove the validity of our middleware, we implemented most of the compliance patterns presented by the BP- Maas framework to enable compliance monitoring over jBPM engine. We implemented our approach using Activiti and jBPM open source execution engine and we use CEP technology with Esper, Java and EPL language and CEP with Drools Rule Language (DRL). Our approach focus on the compliance monitoring as one of the many cases of business process monitoring over runtime, but the mapping part can be used by any framework to support any kind of process monitoring. As a future work, we intend to apply our mapping approach on more execution engines to prove its feasibility. Also we will try to expand our monitoring framework by building a dashboard to enable users enter the compliance patterns and determine the events stream to let the framework detect possible violations. References 1. Michael Backmann, Anne Baumgrass, Nico Herzberg, Andreas Meyer, and Mathias Weske. Model-driven event query generation for business process monitoring. In ICSOC Workshops, volume 8377 of LNCS, pages 406–418. Springer, 2013. 2. Michal Bali. Drools JBoss Rules 5.0 Developer’s Guide. Packt Publishing, 2009. 3. Ahmed Barnawi, Ahmed Awad, Amal Elgammal, Radwa Elshawi, Abduallah Almalaise, and Sherif Sakr. An anti-pattern-based runtime business process compliance monitoring framework. INTERNATIONAL JOURNAL OF ADVANCED COMPUTER SCIENCE AND APPLICATIONS, 7(2), 2016. 4. Cristina Cabanillas, Claudio Di Ciccio, Jan Mendling, and Anne Baumgrass. Predictive task monitoring for business processes. In BPM, volume 8659 of LNCS, pages 424–432. Springer, 2014. 8 Enabling Marwa Compliance Hussein Zaki, Monitoring Ahmed Awad for Process and Osman Hegazy Execution Engines 37 5. Raffaele Conforti, Marcello La Rosa, and Giancarlo Fortino. Process monitoring using sen- sors in YAWL. In Proceedings of the First YAWL Symposium, volume 982 of CEUR Work- shop Proceedings, pages 49–55. CEUR-WS.org, 2013. 6. Simone Fiorini and Arun V Gopalakrishnan. Mastering jBPM6. Packt Publishing, 2015. 7. Nico Herzberg and Andreas Meyer. Improving process monitoring and progress prediction with data state transition events. volume 1029, pages 20–23, 2013. 8. Nico Herzberg, Andreas Meyer, and Mathias Weske. An Event Processing Platform for Business Process Management. In EDOC, pages 107–116. IEEE Computer Society, 2013. 9. Marwa Hussein, Ahmed Awad, and Osman Hegazy. Enabling compliance monitoring for process execution engines. technical report, Faculty of Computers and Information, Cairo University, 2017. http://scholar.cu.edu.eg/?q=marwa_hussein/files/paper. pdf. 10. Amin Jalali and Paul Johannesson. Multi-perspective business process monitoring. In BP- MDS, volume 147 of LNBIP, pages 199–213. Springer, 2013. 11. David Knuplesch, Manfred Reichert, and Akhil Kumar. Visually monitoring multiple per- spectives of business process compliance. In BPM, volume 9253 of LNCS, pages 263–279. Springer, 2015. 12. David Knuplesch, Manfred Reichert, and Akhil Kumar. A framework for visually monitoring business process compliance. Inf. Syst., 64:381–409, 2017. 13. Linh Thao Ly, Stefanie Rinderle-Ma, Kevin Göser, and Peter Dadam. On enabling inte- grated process compliance with semantic constraints in process management systems - re- quirements, challenges, solutions. Information Systems Frontiers, 14(2):195–219, 2012. 14. Fabrizio Maria Maggi, Marco Montali, Michael Westergaard, and Wil M. P. van der Aalst. Monitoring business constraints with linear temporal logic: An approach based on colored automata. In BPM, volume 6896 of LNCS, pages 132–147. Springer, 2011. 15. Andreas Meyer, Luise Pufahl, Dirk Fahland, and Mathias Weske. Modeling and enacting complex data dependencies in business processes. In BPM, volume 8094 of LNCS, pages 171–186. Springer, 2013. 16. Artem Polyvyanyy, Jussi Vanhatalo, and Hagen Völzer. Simplified computation and gener- alization of the refined process structure tree. In WS-FM Workshop, volume 6551 of LNCS, pages 25–41. Springer, 2010. 17. Tijs Rademakers. Activiti in Action. Manning Publications, 2012. 18. Elham Ramezani, Dirk Fahland, and Wil M. P. van der Aalst. Where did I misbehave? diagnostic information in compliance checking. In BPM, volume 7481 of LNCS, pages 262– 278. Springer, 2012. 19. Nick Russell, Wil M. P. van der Aalst, Arthur H. M. ter Hofstede, and David Edmond. Work- flow resource patterns: Identification, representation and tool support. In Advanced Informa- tion Systems Engineering, volume 3520 of LNCS, pages 216–232. Springer, 2005. 20. Arthur H. M. ter Hofstede, Wil M. P. van der Aalst, Michael Adams, and Nick Russell, edi- tors. Modern Business Process Automation - YAWL and its Support Environment. Springer, 2010. 21. Oktay Türetken, Amal Elgammal, Willem-Jan van den Heuvel, and Mike P. Papazoglou. Enforcing compliance on business processes through the use of patterns. In ECIS, page 5, 2011. 22. Barbara Weber, Manfred Reichert, Stefanie Rinderle-Ma, and Werner Wild. Providing Inte- grated Life Cycle Support in Process-Aware Information Systems. International Journal of Cooperative Information Systems, 18(01):115–165, 2009. 23. Mathias Weske. Business Process Management: Concepts, Languages, Architectures. Springer, 2007.