Introduction

The cooperation and communication among different organizations are usually defined through business processes that capture the tasks performed by each organization, their order, and the messages exchanged. To design these processes, one usually adopts imperative modeling languages, like the Business Process Modeling Notation (BPMN). These languages ease the definition of the expected execution flow and of the exceptional flows aimed to manage anomalies foreseen at design time. However, while a process is executed, each organization has full control only on the portion of the process that is under its responsibility. This means that the overall, actual execution flow may differ from the one defined originally, and unforeseen exceptions could materialize. Moreover, one organization can know the activities executed by the others only if they properly distribute information about their initiation and termination.

To alleviate these problems, this paper proposes a solution to monitor the execution of distributed control flow-based process models based on artifactcentric ones. We start from a BPMN process, which is easy to conceive, and we transform it into an equivalent model in E-GSM, an extension to the Guard-Stage-Milestone (GSM) artifact-centric modeling notation [5]. The resulting E-GSM model can be shared by the involved parties to allow them to keep track of the order in which activities are executed and of the status of each activity. Deviations from the "original" execution flow can easily be detected at run-time during the process enactment.

The paper is structured as follows. Section 2 discusses how we extended GSM into E-GSM to enable a data-artifact driven process monitoring solution. Section 3 gives a brief overview of the rules we defined to translate BPMN to E-GSM. Section 4 shows how E-GSM can be used to monitor a real business process in the domain of logistics. After a comparison with relevant work in the literature in Section 5, Section 6 outlines possible future work.

E-GSM

The GSM notation is a declarative language that allows one to model artifactcentric processes by defining conditions that determine the activation and termination of activities, called Stages, based on events. Starting from the standard GSM notation and our preliminary work [2], we propose E-GSM, an extension where we distinguish between Data Flow Guards (that represent the original Guards in GSM) and Process Flow Guards, and we add Fault Loggers: -The Execution status captures the status of a Stage: unopened (Data Flow Guards have never been triggered), opened (one of the Data Flow Guards triggers) or closed (when opened, a Milestone is achieved).

E-GSM generation

Starting from a process modeled using BPMN -that we aim to monitor -the generation of the corresponding E-GSM -that feeds the monitoring system -adheres to a set of transformation rules. These rules are applicable to every BPMN process model that complies with a workflow net [1], that is, the process has only one start event and only one end event, and it always terminates (soundness).

Basic transformation rules are shown in Figure 2: These transformation rules allow any well-structured BPMN process model to be translated into E-GSM. A BPMN to E-GSM prototype translator implemented in ATL (ATLAS Transformation Language [6]), has been developed to support the translation activities. 2The combination of the above rules for basic elements allows one to translate well-structured business process models. In particular, we focus on five types of blocks, defined starting from the classical control flow patterns [12]: sequence block, parallel block, conditional exclusive block, conditional inclusive block, loop block. For each of these blocks a transformation rule have been defined and a graphical representation of some of them is reported in Figure 3. In [9], the complete set of these transformation rules is discussed in details.

For instance, a sequence block corresponds to a Stage Seq that includes S x inner Stages obtained by applying the transformation rules to all the elements (i.e., Activities, Events, inner blocks) that belong to the block. Moreover, in addition to the existing Process Flow Guards, each inner stage has S x .PFG1 to state that none of its Milestones is achieved, and at least one of the Milestones of the element that directly precedes it (if present) is achieved. This way, inner Stages are expected to be opened only once, and only after their direct predecessor is closed. Finally, Seq has a set Seq.DFG that includes all S x .DFG i , and a Milestone Seq.M1 that requires that, for all S x , at least one S x .M j be achieved. This way, Seq is opened when at least one of its S x is opened too, and -as achieving a Milestone is enough to close a Stage -Seq is closed when all S x are closed.

E-GSM in action

To better clarify how E-GSM models can be used to monitor the execution of complex (distributed) processes, here we concentrate on an example taken from the logistics domain. A manufacturing company M has to ship its goods to one of its customers N and, to do so, it relies on a shipping company S for rail and seacargo transportation, and on a shipping company T for truck transportation. The shipping process comprises four main phases: (i) loading goods into a shipping container; (ii) shipping such a container to an intermediate site A by truck; (iii) depending on the day of the week, shipping the goods to either site B by rail, or to site C by sea; (iv) delivering the goods to the customer's site by truck. Furthermore, if part of the goods drops during the loading phase, that activity should stop, all involved actors should be notified of such an accident, and then the loading phase redone. Figure 4 shows the BPMN definition of this process in the upper part, and the derived E-GSM process, which is produced by our translator, in the lower part.

The resulting E-GSM model definition feeds an E-GSM engine that is able to check the evolution of the lifecycle of the Stages. We assume that a smart device embeds this engine and travels along with the goods. Using on-board sensors, or via explicit messages sent by an operator, the engine is able to determine when E-GSM elements that decorate each Stage are triggered, and to log information on each Stage along with the execution status, outcome and compliance perspectives: Data Flow Guards allow the parties to realize when activities are started, Milestones when they end, Fault Loggers if they were not correctly executed, and Process Flow Guards if they are compliant with the defined control flow.

Let us suppose that the shipping process is carried out as follows: the process starts on Wednesday, when T carefully loads the goods onto their truck at M 's site (when the loading phase is complete, the operator sends a message making LoadGoods.M1 achieved) and ships them to site A on Thursday. Once the goods arrive at A, ShipToA.M1 is achieved. Before taking the goods from T , S queries the smart device to verify that the activities LoadGoods and ShipToA have been correctly performed, and then the goods are exchanged. Being Thursday, S ships the goods to site C by sea. Finally, T delivers the goods to N 's site, where N queries the smart device to have information on how the process has been enacted. In this case, since the execution flow has been respected (i.e., every time a Stage was opened, the conditions on its process flow guards have been satisfied), and no Fault Logger has been triggered, N accepts the goods.

Let us now focus on a process execution where the designed control flow is not respected. For instance, during the initial loading, part of the goods is dropped. However, T ignores that accident and the shipping process continues as planned. This cause the verification of the FaultLogger LoadGoods.FL1, that moves LoadGoods to the faulty outcome. Once N receives the goods, it discovers that some of them are damaged, and returns them to M . By querying the smart device, M immediately identifies that the goods have been dropped (i.e., the condition on LoadGoods.FL1 has been satisfied), that ShipToA started while LoadGoods was still in progress, and that the accident has not been notified (i.e., NotifyAccident has not been executed even though NotifyAccident.PFG1 was satisfied). Thank to these information, M is able to charge T a penalty for the damaged goods, and to impose it to ship the new goods to N for free.

A third example shows how the system can handle unforeseen exceptions. In this case, the shipping to site A takes longer than expected and the goods arrive there on Sunday. Nevertheless, S ships the goods by sea to site C. This causes a significant delay and a waste of resources since the goods are expected to arrive at B and, once their current location is identified, a truck must bring them from site B to C. Again, the information collected by the smart device allows N to identify that ShipToC does not comply with the model: ShipToC is executed instead of ShipToB, and ShipToC has been opened even though ShipToC.PFG1 was not satisfied. Moreover, by knowing that ShipToC is currently running, M can blame S as the responsible for this inefficiency. If the smart device is also equipped with a communication interface, it can autonomously send information to all involved parties. This allows T to figure out that ShipToC is in progress and be ready to pick up the goods at site C instead of B.

These examples demonstrate how E-GSM can be used to effectively monitor the execution of a distributed process, especially in case of processes where several actors are involved and no central orchestrator is imposed. While an E-GSM engine is not available yet, an extension of the Barcelona GSM engine [4] is currently under development.

Related Work

Modeling business processes with declarative languages is generally more difficult than with imperative ones as proved by Pichler et al. [10]. For this reason, and also because of the need for reusing excerpts of preexisting process models, there have been some attempts to develop methods and solutions to translate imperative languages into declarative ones.

Köpke et al. [7] start from a BPMN process model and produce a GSM equivalent that forces the process to behave exactly as defined in the BPMN model. While we have borrowed the Stage nesting, our rules differ significantly from the ones in [7], mainly due to the fact that the purpose of our work is completely different. In particular, we are interested in identifying control flow violations, and not in forcing the process to rigidly follow a given execution flow, which is what is pursued in this work.

Eshuis et al. [3] define a semi-automated approach to produce GSM models starting from UML Activity Diagrams, while Kumaran et al. [8] propose a language-agnostic algorithm to derive the lifecycle of artifacts based on an imperative process model. With respect to our work, which keeps control flow information in the target process model to assess compliance, [3] and [8] use such information to model the interactions among data artifacts.

Popova et al. [11] define a translator from Petri Nets to GSM to transform the outcome of process mining algorithms, which is often represented as a Petri Net, in a language easier to understand by domain experts.

Conclusions and Future Work

In this paper we proposed an extension of the Guard-Stage-Milestone (GSM) notation to embed control flow information in the process model definition to enable the translation from BPMN models into equivalent E-GSM ones. The resulting declarative process can drive the process monitoring to check anomalies during the execution of the process. Future work will concentrate on how to verify the soundness of the derived E-GSM processes and the level of equivalence with respect to the original BPMN process. As E-GSM has been studied to drive a flexible monitoring system, tools for distributing and running E-GSM-driven monitoring on smart devices will be proposed.