Control ow-based process modeling notations, like BPMN, are good at de ning the normal execution ow and the management of foreseen exceptions. When unforeseen situations occur, one cannot detect if the execution is still acceptable with respect to the process de nition. In contrast, artifact-centric process modeling notations, like the GuardStage-Milestone (GSM), are better suited for this kind of scenarios: they de ne a process in terms of acceptable states and do not enforce any speci c execution ow. This improves exibility, but hampers the clarity of the de ned models. The goal of this paper is to show how an extension of GSM, i.e., E-GSM, can be used to detect deviations from the execution path as modeled in BPMN, while keeping the process execution alive.
The cooperation and communication among di erent organizations are usually de ned 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 de nition of the expected execution ow and of the exceptional ows 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 ow may di er from the one de ned 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 ow-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
GuardStage-Milestone (GSM) artifact-centric modeling notation [
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 de ned 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. 2
E-GSM
The GSM notation is a declarative language that allows one to model
artifactcentric processes by de ning conditions that determine the activation and
termination of activities, called Stages, based on events. Starting from the standard
GSM notation and our preliminary work [
Figure 1 sketches the lifecycle of an E-GSM Stage organized around three
main orthogonal execution perspectives: status, outcome, and compliance1:
{ 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).
1 In this paper we use the the notation introduced in [
Summarizing, Data Flow Guards drive the change of status. Fault Loggers drive the outcome, while Process Flow Guards are in charge of the compliance. With respect to Standard GSM, E-GSM interprets reopening a closed Stage as a new iteration of that process portion. Therefore, once a parent Stage is reopened, the lifecycle of all its child Stages will restart from scratch. 3
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 work ow net [
Basic transformation rules are shown in Figure 2: (a) BPMN Activities are translated into E-GSM Stages. (b) BPMN Start, End or Intermediate Events are translated into E-GSM Stages where their Data Flow Guards and the Milestones are associated to the occurrence of the event. (c) BPMN Activities with a non-interrupting Boundary Event attached to them are translated into E-GSM Stages as in case (a), with a Fault Logger having the occurrence of the event as condition. (d) BPMN Activities A with an interrupting Boundary Event attached to them are translated into E-GSM Stages as in case (a), with an additional Milestone and Fault Logger having the occurrence of the event as condition.
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 [
The combination of the above rules for basic elements allows one to translate
well-structured business process models. In particular, we focus on ve types of
blocks, de ned starting from the classical control ow patterns [
For instance, a sequence block corresponds to a Stage Seq that includes Sx 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 Sx.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 Sx.DFGi, and a Milestone Seq.M1 that requires that, for all Sx, at least one Sx.Mj be achieved. This way, Seq is opened when at least one of its Sx is opened too, and { as achieving a Milestone is enough to close a Stage { Seq is closed when all Sx are closed. 4
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 2 The tool is publicly available at https://bitbucket.org/polimiisgroup/ bpmn2egsm. 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 noti ed of such an accident, and then the loading phase redone. Figure 4 shows the BPMN de nition 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 de nition 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 de ned control ow.
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 ow has been respected (i.e., every time a Stage was opened, the conditions on its process ow guards have been satis ed), and no Fault Logger has been triggered, N accepts the goods.
Let us now focus on a process execution where the designed control ow 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 veri cation 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 identi es that the goods have been dropped (i.e., the condition on LoadGoods.FL1 has been satis ed), that ShipToA started while LoadGoods was still in progress, and that the accident has not been noti ed (i.e., NotifyAccident has not been executed even though NotifyAccident.PFG1 was satis ed). 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 signi cant delay and a waste of resources since the goods are expected to arrive at B and, once their current location is identi ed, 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 satis ed. Moreover, by knowing that ShipToC is currently running, M can blame S as the responsible for this ine ciency. If the smart device is also equipped with a communication interface, it can autonomously send information to all involved parties. This allows T to gure 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 e ectively
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
EGSM engine is not available yet, an extension of the Barcelona GSM engine [
Modeling business processes with declarative languages is generally more di cult
than with imperative ones as proved by Pichler et al. [
Kopke et al. [
Eshuis et al. [
Popova et al. [
In this paper we proposed an extension of the Guard-Stage-Milestone (GSM) notation to embed control ow information in the process model de nition 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 exible monitoring system, tools for distributing and running E-GSM-driven monitoring on smart devices will be proposed.
Acknowledgments. This work has been partially funded by the Italian Project ITS Italy 2020 under the Technological National Clusters program.