=Paper=
{{Paper
|id=Vol-1612/paper2
|storemode=property
|title=On Handling Business Process Anomalies through Artifact-based Modeling
|pdfUrl=https://ceur-ws.org/Vol-1612/paper2.pdf
|volume=Vol-1612
|authors=Luciano Baresi,Giovanni Meroni,Pierluigi Plebani
|dblpUrl=https://dblp.org/rec/conf/caise/BaresiMP16a
}}
==On Handling Business Process Anomalies through Artifact-based Modeling==
https://ceur-ws.org/Vol-1612/paper2.pdf
On Handling Business Process Anomalies
through Artifact-based Modeling
Luciano Baresi, Giovanni Meroni, and Pierluigi Plebani
Politecnico di Milano — Dipartimento di Elettronica, Informazione e Bioingegneria
Piazza Leonardo da Vinci, 32 - 20133 Milano, Italy
[firstname].[lastname]@polimi.it,
Abstract. Control flow-based process modeling notations, like BPMN,
are good at defining the normal execution flow and the management of
foreseen exceptions. When unforeseen situations occur, one cannot detect
if the execution is still acceptable with respect to the process definition.
In contrast, artifact-centric process modeling notations, like the Guard-
Stage-Milestone (GSM), are better suited for this kind of scenarios: they
define a process in terms of acceptable states and do not enforce any
specific execution flow. This improves flexibility, but hampers the clarity
of the defined 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.
Keywords: Process Monitoring, Guard-Stage-Milestone, Artifact-centric
processes, Handling Process Exceptions
1 Introduction
The cooperation and communication among different organizations are usually
defined through business processes that capture the tasks performed by each or-
ganization, 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 orig-
inally, 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 artifact-
centric 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
Copyright c by the paper’s authors. Copying permitted only for private and academic
purposes.
In: S. España, M. Ivanović, M. Savić (eds.): Proceedings of the CAiSE’16 Forum at
the 28th International Conference on Advanced Information Systems Engineering,
Ljubljana, Slovenia, 13-17.6.2016, published at http://ceur-ws.org
CEUR
ceur-ws.org
Workshop ISSN 1613-0073
Proceedings
10 Luciano Baresi et al.
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.
2 E-GSM
The GSM notation is a declarative language that allows one to model artifact-
centric processes by defining conditions that determine the activation and termi-
nation 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:
– A Data Flow Guard is an Event-Condition-Action (ECA) rule. If true,
the associated Stage is declared opened. A Milestone is another ECA
rule. If true, the Stage is declared closed. A Milestone may also have an
invalidator : a boolean expression that can invalidate the Milestone and
reopen the Stage.
– A Process Flow Guard is a boolean expression that predicates on the
activation of the Data Flow Guards and Milestones used to map the
expected control flow. The expression is evaluated once one of the Data
Flow Guards of the associated Stage is triggered, and before the Stage
becomes opened. If the expression is true, the Stage complies with the ex-
pected execution, otherwise the Stage has been activated without respecting
the normal flow.
– A Fault Logger is an ECA rule. If true, the associated Stage is declared as
faulty because something went wrong during the execution of the activity.
A faulty Stage does not imply its termination, as the termination is only
determined by Milestones.
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 [5], so we write S.DFGi , S.PFGk ,
S.FLl to indicate the activation of a Data Flow Guard, Process Flow Guard, or a
Fault Logger associated with Stage S, +S.Mj (-S.Mj ) to indicate the achievement (in-
validation) of a Milestone Mj , S.Mj to indicate that Stage S is closed and a Milestone
Mj is achieved, and Active(S) to indicate that Stage S is opened.
On Handling Business Process Anomalies through Artifact-based Modeling 11
Fig. 1. Lifecycle of an E-GSM Stage S.
– The Execution outcome captures the situation of a Stage, which can be
either regular (none of its Fault Loggers has ever been triggered) or faulty
(at least one of its Fault Loggers has been triggered, A.FLl ).
– The Execution compliance captures the compliance of each Stage with the
normal flow. A Stage is declared onTime by default. It can become outO-
fOrder (according to the normal flow) when one of its Data Flow Guards
is triggered but none of its Process Flow Guards holds, or skipped if it
does not become active before the Stages that requires its activation.
Summarizing, Data Flow Guards drive the change of status. Fault Log-
gers drive the outcome, while Process Flow Guards are in charge of the com-
pliance. 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 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 – ad-
heres 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:
(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.
12 Luciano Baresi et al.
Fig. 2. BPMN to E-GSM transformation rules for basic elements.
(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 imple-
mented in ATL (ATLAS Transformation Language [6]), has been developed to
support the translation activities.2
The 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 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 ad-
dition 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 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
2
The tool is publicly available at https://bitbucket.org/polimiisgroup/
bpmn2egsm.
On Handling Business Process Anomalies through Artifact-based Modeling 13
Fig. 3. Excerpt of BPMN to E-GSM transformation rules.
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 sea-
cargo 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 per-
spectives: 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
14 Luciano Baresi et al.
Fig. 4. BPMN and E-GSM models of the example shipping process.
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
On Handling Business Process Anomalies through Artifact-based Modeling 15
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 moni-
tor 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.
5 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 mod-
els 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.
6 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
16 Luciano Baresi et al.
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.
Acknowledgments. This work has been partially funded by the Italian Project
ITS Italy 2020 under the Technological National Clusters program.
References
1. Van der Aalst, W.M.: Verification of workflow nets. In: Application and Theory of
Petri Nets 1997, pp. 407–426. Springer (1997)
2. Baresi, L., Meroni, G., Plebani, P.: A gsm-based approach for monitoring cross-
organization business processes using smart objects (2015), accepted for publica-
tion
3. Eshuis, R., Van Gorp, P.: Synthesizing data-centric models from business process
models. Computing pp. 1–29 (2015)
4. Heath III, F.T., Boaz, D., Gupta, M., Vaculı́n, R., Sun, Y., Hull, R., Limonad, L.:
Barcelona: A design and runtime environment for declarative artifact-centric bpm.
In: Service-Oriented Computing, pp. 705–709. Springer (2013)
5. Hull, R., Damaggio, E., Fournier, F., Gupta, M., Heath, Fenno(Terry), I., Hobson,
S., Linehan, M., Maradugu, S., Nigam, A., Sukaviriya, P., Vaculin, R.: Introducing
the guard-stage-milestone approach for specifying business entity lifecycles. In:
Web Services and Formal Methods, Lecture Notes in Computer Science, vol. 6551,
pp. 1–24. Springer (2011)
6. Jouault, F., Allilaire, F., Bézivin, J., Kurtev, I.: Atl: A model transformation tool.
Science of computer programming 72(1), 31–39 (2008)
7. Köpke, J., Su, J.: Towards ontology guided translation of activity-centric processes
to gsm (2015), accepted for publication
8. Kumaran, S., Liu, R., Wu, F.Y.: On the duality of information-centric and activity-
centric models of business processes. In: Advanced Information Systems Engineer-
ing. pp. 32–47. Springer (2008)
9. Meroni, G., Baresi, L., Plebani, P.: Translating BPMN to E-GSM: specifica-
tions and rules. Tech. rep., Politecnico di Milano (2016), http://hdl.handle.net/
11311/976678
10. Pichler, P., Weber, B., Zugal, S., Pinggera, J., Mendling, J., Reijers, H.A.: Impera-
tive versus declarative process modeling languages: An empirical investigation. In:
Business Process Management Workshops. pp. 383–394. Springer (2012)
11. Popova, V., Dumas, M.: From petri nets to guard-stage-milestone models. In: Busi-
ness Process Management Workshops. pp. 340–351. Springer (2013)
12. Russell, N., Hofstede, A.H.M.T., Mulyar, N.: Workflow controlflow patterns: A
revised view. Tech. Rep. BPM-06-22, BPM Center Report, BPMcenter.org (2006)