BPMN Extensions for Decentralized Execution and Monitoring of
Business Processes
Jonas Anseeuw, Gregory Van Seghbroeck, Bruno Volckaert and Filip De Turck
Department of Information Technology, Ghent University, B-9050 Ghent, Belgium
Keywords:
Cloud Computing, Business Process Management, Monitoring, Business Process as a Service.
Abstract:
Software-as-a-service (SaaS) providers are further expanding their offering by growing into the space of busi-
ness process outsourcing (BPO). Therefore, the SaaS provider wants to administer and manage the business
process steps according to a service level agreement. Outsourcing of business processes results in decen-
tralized business workflows. However, current business process modeling languages, e.g. Business Process
Execution Language (BPEL), Business Process Model and Notation (BPMN), are based highly on a central-
ized execution model and current BPMN engines offer limited constructs for federation and decentralized
execution. To guarantee execution of business processes according to a service level agreement, different par-
ties involved in a federated workflow must be able to inspect the state of external workflows. This requires
advanced inspection interfaces and monitoring facilities. Current business process modeling languages must
thus be extended to support monitoring in the specification, support modeling and support deployment of de-
centralized workflows. In this paper, correlation and monitoring extensions for BPMN are described. These
extensions to BPMN are described such that the existing specification can still be used as is in a backwards
compatible way.
1 INTRODUCTION
Software-as-a-service oriented software companies
want to add value to their offering by providing sys-
tematic and controlled delegation of many of the steps
of a company’s business process, also known as busi-
ness process outsourcing (BPO). The companies thus
administer and manage the business process steps ac-
cording to a service level agreement. SLA can be
an agreement on QoS parameters, but this is also an
agreement on the different interfaces between part-
ners.
For example, the process of designing a product
needs both business activities and simulation activi-
ties (often in an interleaved sequence). Business ac-
tivities represent mainly data in and output (e.g. con-
straints, design parameters, etc.) tasks. Simulation
activities take models and parameters as input, and
analyze usually characteristics that are mentioned in
the user-defined constraints and that must be met.
Business activities form a high-level view on the pro-
cess with branches, loops and concurrent activities,
referred as the business workflow. Simulation activ-
ities are usually needed in the course of a business
workflow execution in order to validate design param-
eters early, referred as the simulation workflow. Fig-
ure 1 shows business and simulation workflows and
their relation to each other. The simulation workflows
are pluggable in the business workflow. As depicted
in figure 1, Company A has control over the business
workflow (including the simulation workflows from
Company B and C).
Figure 1: Relation of Business- and Simulation Workflows.
BPO results in decentralized business process
flows: both inter-company flows, i.e. federated busi-
ness process flows that cross the borders of compa-
nies, as well as intra-company workflows, distributed
304
Anseeuw J., Van Seghbroeck G., Volckaert B. and De Turck F..
BPMN Extensions for Decentralized Execution and Monitoring of Business Processes.
DOI: 10.5220/0005492303040309
In Proceedings of the 5th International Conference on Cloud Computing and Services Science (CLOSER-2015), pages 304-309
ISBN: 978-989-758-104-5
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
business flows within the datacenters of one company.
The business process modeling languages constructs
offered by the current generation of workflow lan-
guages, e.g. Business Process Execution Language
(BPEL) (OASIS, 2007) or Business Process Model
and Notation (BPMN) ((OMG), 2011), are based
highly on a centralized execution model and current
BPMN engines offer no constructs for federation and
decentralized execution.
The different parties involved in a federated work-
flow must be able to inspect the state of the external
workflows, all the while hiding workflow implemen-
tation details. Business Process Modeling (BPM) lan-
guages must thus be extended to support modeling,
monitoring and deployment of decentralized work-
flows in the specification.
The approach described in this paper is to extend
BPMN using its extensibility such that the extensions
are backwards compatible with the existing BPMN
specification. The remainder of this paper is struc-
tured as follows. In Section 2, relevant related work
is discussed. Sections 3 and 4 handle advanced cor-
relation and monitoring extensions in BPMN respec-
tively. Finally, our conclusions are drawn and future
work is discussed in Section 5.
2 RELATED WORK
Previous research (Van Seghbroeck et al., 2007)(Ste-
fanescu et al., 2014)(Barros, 2015)(Dumas and
Kohlborn, 2015) has come to the same result with re-
gard to the different steps in the development cycle of
decentralized workflows or choreographies depicted
in Figure 2. First, a top-down approach describes the
service choreography, which can be validated. When
the choreography is described, and after validation,
all the different participants’ stubs are extracted. As
a result of the stub extraction and the different im-
plementations, it is possible to use common process
engines to execute a choreography.
Figure 2: The complete development cycle for service
choreographies.
The European Project CHOReOS (Large Scale
Choreographies for the Future Internet) (Autili et al.,
2014), which ended in 2013, resulted in a very
interesting implementation of this development cy-
cle. CHOReOS focusses only on BPMN, to de-
scribe its choreography, and to describe and execute
the different participants parts of the choreography.
CHOReOS, unfortunately, only monitors system level
KPIs. In the monitoring model described in this pa-
per, it is also possible to monitor application specific
data.
The JBoss Savara
1
project can be used to cre-
ate service choreographies. It uses Web Ser-
vice Choreography Description Language (WS-CDL)
(Kavantzas et al., 2005) to describe the choreography,
but only some basic tools to monitor and validate the
choreography are available. The Eclipse BPMN Mod-
eler
2
can only be used to design choreographies, it
does not have an execution environment incorporated,
nor are there monitoring tools.
Correlating messages in choreographies comes
with another level of complexity, not only do mes-
sages have to be correlated to each participant’s work-
flow instance, but they also have to correlate these in-
dividual participants to the overall choreography in-
stance. To the authors’ knowledge, there is only one
specification, WS-CDL, which has a very elaborate
definition of and view on correlation. Since BPMN
does not offer this, extensions to BPMN are needed.
Since there are no clear choreography execution
environments yet, there are no ready-to-use moni-
toring environments to monitor choreography work-
flows. Monitoring, using the current tools and frame-
works, would entail consolidating and aggregating the
monitoring info from all the different choreography
participants. It is clear that this is a fairly impos-
sible task since every workflow engine has its own
way to store the monitored data and has their own
APIs to reference this information. The lack of a
standardized monitoring API is a real problem here.
Research has dealt with monitoring choreographies
(Wetzstein et al., 2010; Lazovik et al., 2004; Roder
et al., 2011), but very little research has been per-
formed aimed specifically at BPMN. Another way to
monitor a distributed environment is having a central-
ized system in place (e.g. Business Activity Mon-
itoring) that gathers all necessary information from
the individual partner’s workflow engines, either via
a pull or push method, or via monitoring agents. An-
other problem with regards to monitoring is that most
of the current engines only provide monitoring infor-
mation about system-wide aspects (e.g. number of re-
1
http://savara.jboss.org
2
http://eclipse.org/bpmn2-modeler
BPMNExtensionsforDecentralizedExecutionandMonitoringofBusinessProcesses
305
quests) or about aspects related to particular processes
or particular process instances (e.g. execution time,
a log trace for the different activities of a process).
Adding monitoring points as part of a specific pro-
cess or even application is not possible yet. BPMN is
the only standardized specification that already sup-
ports including monitoring injection points with its
monitoring and auditing element. However, except
for describing extensible placeholders, the specifica-
tion claims details are out of scope and are left to the
implementing BPMN engines.
3 CORRELATION EXTENSIONS
As mentioned in related work, BPMN doesn’t provide
enough functionality to correlate messages in chore-
ographies. BPMN already has some notion of cor-
relation. This is done in the Collaboration defini-
tion, more specifically in its Conversations. A Con-
versation is defined by an array of CorrelationKeys.
The BPMN specification claims that the Correlation-
Keys can be used to tie messages to a specific pro-
cess instance. Correlating messages to process in-
stances may be enough to support centralized work-
flows, but this is insufficient for decentralized work-
flows. In a decentralized context, it is key to also
uniquely and formally define correlations between all
process instances of all parties involved in the decen-
tralized workflow. This requires thorough knowledge
on how all instances are created and on how those in-
stances can be correlated via the messages communi-
cated between them. Such a complex model is pos-
sible in WS-CDL, by means of its Identity types, but
not in BPMN. There is another big difference between
correlation in BPMN and WS-CDL, WS-CDL defines
correlation on ChannelTypes, well-defined communi-
cation endpoints of a Participant, whereas in BPMN
it is all done on the Conversations, which define the
communication potential between two or more Partic-
ipants. There are two possible approaches to improve
correlation in BPMN:
1. Extend the BPMN Correlation mechanism to hold
similar information as the WS-CDL mechanism.
2. Aid the users by improving how correlation is per-
ceived in BPMN, i.e. add semantical meaning to
particular constructs and combinations of conver-
sations.
3.1 Extending BPMN
The first option results in less conversations and most
resembles the usage of ChannelTypes and Identities in
WS-CDL. A BPMN Conversation can be interpreted
as a WS-CDL ChannelType. WS-CDL has four dis-
tinct correlation types: primary, alternate, derived and
association. With these four identity types, it is possi-
ble to create complex correlation relations. BPMN’s
extension mechanism can be used to add an attribute
to the CorrelationKey element. For example the at-
tribute type, which can have the following values: pri-
mary, alternate, derived, or association. This way, we
can mimic WS-CDL correlation types in BPMN.
3.2 Semantical Meaning
In the second option, the user interface will visual-
ize correlation between messages or between con-
versations different. The user only has to be aware
whether CorrelationKeys are used to correlate mes-
sages or conversations. Message CorrelationKeys in
BPMN resemble the Primary and Alternate identities
from WS-CDL. They are used to correlate messages
belonging to the same Conversation. Conversation
CorrelationKeys on the other hand are used to corre-
late conversations. Derived and Association identities
take up this role in WS-CDL.
4 MONITORING EXTENSIONS
BPMN already has two placeholders available, audit-
ing and monitoring, but as the specification mentions
the actual definition of auditing/monitoring is out of
scope of the specification. It is up to the implementers
to specify how these elements are used and extended.
Auditing and monitoring can be defined for all Flow-
Elements (e.g. Activities, Gateways, Events, Data Ob-
jects, Data Associations and Sequence Flows), with
the only limitation, that these FlowElements have to
be part of a Process flow. Auditing and monitoring
can also be set for a Process itself, which can be used
(for instance) to define process-wide actions.
Setting the audit and monitoring tags for each
FlowElement would be too time-consuming and
prone to mistakes. Besides that, in many cases generic
monitoring statements (e.g. log servicetime between
TaskA and TaskB) can be used to define monitoring.
Consequently, it would be more interesting to define
the monitoring in a separate declarative model (as an
extension on BPMN). References to elements in this
new model can be used to connect the FlowElements
and the Process to specific monitoring points. These
monitoring points are described in declarative rules.
The following subsections describe in more de-
tails the declarative monitoring model, monitoring in-
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
306
formation, declaration, visualization and implementa-
tion of monitoring.
4.1 Monitoring Model
Several options are available for the Monitoring
Model. Either a procedural model or a declarative
model. Using a declarative model allows to describe
the behaviour of the monitoring framework. Instead
of describing in detail when to place a monitoring
point, the model can describe under which conditions
the framework should place a monitoring point. It is
with a declarative model also possible to have sim-
ple rules that can result in multiple monitoring points.
Some examples:
after each Activity, log the name of the Activity
servicetime between TaskB and TaskG
delay between PartnerA and PartnerB
4.2 Monitoring Information
Metadata
The monitoring metadata describes which data can be
captured from the FlowElements.
local
time
The timestamp as set by the participants system.
In the assumption that all servers involved in the
execution of one particular participant’s process
are in sync.
correlation keys
An array of all the instances of the correlation
keys as defined by the BPMN model.
process id
The unique identifier for this process as set by the
participant’s system.
task id
The unique identifier for this task as defined in the
BPMN model.
data context [optional ]
An optional array of all data currently used in this
process’ instance. This is used to monitor appli-
cation specific data and is realised by using Data
Objects.
4.3 Describing Monitoring Declarations
There are different types of monitoring points: single
monitoring points, monitoring ranges and monitoring
aggregates. Single monitoring points are associated
with a specific or all FlowElements. This can be a
single Activity (e.g. Task, Sub-Process, Call Activ-
ity), Events, etc. Monitoring ranges are used to mon-
itor data that involves multiple FlowElements (e.g.
monitoring the service time between two FlowEle-
ments). A monitoring range implies that multiple sin-
gle monitoring points are set. Monitoring aggregates
are similar to monitoring ranges, but they aggregate
data within a certain scope (e.g. over all process in-
stances).
Single Monitoring Points
Single monitoring points can be set before, after or
during either all FlowElements or a specific FlowEle-
ment. A FlowElement can be specified by a BPMN
attribute (e.g. id). The second function parameter ω
determines where the monitoring point should be set.
Setting monitoring points results in capturing all data
specified by the metadata as specified in section 4.2.
In order to additionally monitor application specific
data, Data Objects can be associated with monitoring
points.
log(FlowElement[: id], ω)
{
local time, ..., data context
}
(1)
Monitoring points can be placed depending on the
outcome of a function. For example, function e can
be <, >, =, and, or, not, etc. x and y can be FlowEle-
ments.
e(x, y, ω) log(FlowElement, ω) (2)
Monitoring Ranges
Monitoring ranges are associated with multiple Flow-
Elements. Therefore an ordered list of FlowElements
is passed to function f .
f(FlowElement, . . . ) (3)
An example is monitoring the servicetime between
two FlowElements. The function servicetime implies
that a single monitoring point must be placed after
FlowElementA and before FlowElementB.
servicetime(FlowElementA, FlowElementB)
log(FlowElementA, a f ter) as x
log(FlowElementB,be f ore) as y
y.localtime x.localtime
Monitoring Aggregates
Monitoring aggregates are similar to ranges, but they
aggregate all monitoring data within a scope (e.g. av-
erage, sum, count, etc.). Parameter α can be function
(1),(2) or (3).
BPMNExtensionsforDecentralizedExecutionandMonitoringofBusinessProcesses
307
g(α, scope) (4)
The monitoring scope can be:
process instance, e.g. count of all tasks within a
specific process instance.
process: range of process instances, e.g. count of
all tasks over a range of process instances.
system: range of processes, e.g. when you want
to know the service time of a particular participant
over different processes.
4.4 Visualization
In order to allow non-developers (business users) to
specify where to place monitoring points, a more vi-
sual representation of monitoring points is discussed
in the next subsections.
Single Monitoring Points
Figure 3 corresponds to the first rule (1). A monitor-
ing point can contain a Data Object for application
data to be logged.
Figure 3: Placement of a single monitoring point.
Figure 4 corresponds to the second rule (2). For ex-
ample a monitoring point will be placed if a Data Ob-
ject and a particular Message Event have occurred.
Figure 4: Placement of a conditional single monitoring
point.
Monitoring Ranges
Figure 5 corresponds to the third rule (3).
Figure 5: Placement of a monitoring range.
4.5 Implementation
Since BPMN is persisted in XML, the declarative
rules should also have an XML counterpart, e.g.
RuleML (a markup language for rules). Implementa-
tion of monitoring in BPMN can then be achieved by
intercepting messages between tasks or by adding a
wrapper around tasks. Automatically adding a wrap-
per around the monitoring tasks allows for more ad-
vanced monitoring capabilities. Figure 6 shows this
wrapper.
Figure 6: Wrapper around tasks to enable monitoring.
All of the supported monitoring operations must be
included in the process. Whether or not they are active
depends on the decisions in the process.
5 CONCLUSIONS
In this paper a number of backwards compatible ex-
tensions to the BPMN business process modeling lan-
guage are presented to support correlation and moni-
toring in decentralized workflows. Correlation in de-
centralized workflows is achieved by using BPMN’s
extensibility. The BPMN correlation mechanism can
than hold similar information as the WS-CDL mech-
anism. Another option is to aid the user by improv-
ing how correlation is perceived in BPMN. BPMN
already has two placeholders available, auditing and
CLOSER2015-5thInternationalConferenceonCloudComputingandServicesScience
308
monitoring, but it is up to the implementers of the
BPMN engine to specify how these elements are used
and extended. Therefore, a declarative monitoring
model as an extension on BPMN is described. This
model results in declarative rules. Since BPMN is
persisted in XML, the declarative rules also have an
XML counterpart, e.g. RuleML. These rules have
also a notation model. Finally, implementation of the
monitoring model can be achieved by adding a wrap-
per around tasks.
Further research will show which correlation ex-
tension option is the more favorable. In future work
tooling will be developed allowing non-developers
(business users) to design and deploy decentralized
business processes. A monitoring API will be de-
signed to monitor these decentralized business pro-
cesses.
ACKNOWLEDGEMENTS
The iMinds D-BASE project is co funded by iMinds
(Interdisciplinary Institute for Technology), a re-
search institute founded by the Flemish Government
with project support of the IWT.
REFERENCES
Autili, M., Inverardi, P., and Tivoli, M. (2014). Choreos:
Large scale choreographies for the future internet. In
Software Maintenance, Reengineering and Reverse
Engineering (CSMR-WCRE), 2014 Software Evolu-
tion Week - IEEE Conference on, pages 391–394.
Barros, A. (2015). Process choreography modelling. In
vom Brocke, J. and Rosemann, M., editors, Handbook
on Business Process Management 1, International
Handbooks on Information Systems, pages 279–300.
Springer Berlin Heidelberg.
Dumas, M. and Kohlborn, T. (2015). From business pro-
cess models to service interfaces. In vom Brocke, J.
and Rosemann, M., editors, Handbook on Business
Process Management 1, International Handbooks on
Information Systems, pages 557–578. Springer Berlin
Heidelberg.
Kavantzas, N., Fletcher, T., Burdett, D., Lafon, Y., Barreto,
C., and Ritzinger, G. (2005). Web services chore-
ography description language version 1.0. Candidate
recommendation, W3C. http://www.w3.org/TR/2005/
CR-ws-cdl-10-20051109/.
Lazovik, A., Aiello, M., and Papazoglou, M. (2004). As-
sociating assertions with business processes and mon-
itoring their execution. In Proceedings of the 2Nd In-
ternational Conference on Service Oriented Comput-
ing, ICSOC ’04, pages 94–104, New York, NY, USA.
ACM.
OASIS (2007). OASIS Web Services Business Process Ex-
ecution Language. http://docs.oasis-open.org/wsbpel/
2.0/OS/wsbpel-v2.0-OS.html.
(OMG), O. M. G. (2011). Business process model and no-
tation (bpmn) version 2.0. Technical report.
Roder, A., Lehmann, M., and Kabitzsch, K. (2011). Moni-
toring service choreographies. In Industrial Informat-
ics (INDIN), 2011 9th IEEE International Conference
on, pages 142–147.
Stefanescu, A., Wieczorek, S., and Schur, M. (2014). Mes-
sage choreography modeling. Software & Systems
Modeling, 13(1):9–33.
Van Seghbroeck, G., De Turck, F., Dhoedt, B., and De-
meester, P. (2007). Web service choreography con-
formance verification in m2m systems through the
pix-model. In Pervasive Services, IEEE International
Conference on, pages 385–390.
Wetzstein, B., Karastoyanova, D., Kopp, O., Leymann, F.,
and Zwink, D. (2010). Cross-organizational process
monitoring based on service choreographies. In Pro-
ceedings of the 2010 ACM Symposium on Applied
Computing, SAC ’10, pages 2485–2490, New York,
NY, USA. ACM.
BPMNExtensionsforDecentralizedExecutionandMonitoringofBusinessProcesses
309