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 workﬂows. 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 workﬂow must be able to inspect the state of external workﬂows. This requires

advanced inspection interfaces and monitoring facilities. Current business process modeling languages must

thus be extended to support monitoring in the speciﬁcation, support modeling and support deployment of de-

centralized workﬂows. In this paper, correlation and monitoring extensions for BPMN are described. These

extensions to BPMN are described such that the existing speciﬁcation 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-deﬁned 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 workﬂow. Simulation activ-

ities are usually needed in the course of a business

workﬂow execution in order to validate design param-

eters early, referred as the simulation workﬂow. Fig-

ure 1 shows business and simulation workﬂows and

their relation to each other. The simulation workﬂows

are pluggable in the business workﬂow. As depicted

in ﬁgure 1, Company A has control over the business

workﬂow (including the simulation workﬂows from

Company B and C).

Figure 1: Relation of Business- and Simulation Workﬂows.

BPO results in decentralized business process

ﬂows: both inter-company ﬂows, i.e. federated busi-

ness process ﬂows that cross the borders of compa-

nies, as well as intra-company workﬂows, 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

 2015 SCITEPRESS (Science and Technology Publications, Lda.)

business ﬂows within the datacenters of one company.

The business process modeling languages constructs

offered by the current generation of workﬂow 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-

ﬂow must be able to inspect the state of the external

workﬂows, all the while hiding workﬂow implemen-

tation details. Business Process Modeling (BPM) lan-

guages must thus be extended to support modeling,

monitoring and deployment of decentralized work-

ﬂows in the speciﬁcation.

The approach described in this paper is to extend

BPMN using its extensibility such that the extensions

are backwards compatible with the existing BPMN

speciﬁcation. 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 workﬂows 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 speciﬁc

data.

The JBoss Savara

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

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-

ﬂow 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

speciﬁcation, WS-CDL, which has a very elaborate

deﬁnition 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-

ﬂows. 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 workﬂow 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 speciﬁcally 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 workﬂow 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-

http://savara.jboss.org

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 speciﬁc pro-

cess or even application is not possible yet. BPMN is

the only standardized speciﬁcation that already sup-

ports including monitoring injection points with its

monitoring and auditing element. However, except

for describing extensible placeholders, the speciﬁca-

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 deﬁni-

tion, more speciﬁcally in its Conversations. A Con-

versation is deﬁned by an array of CorrelationKeys.

The BPMN speciﬁcation claims that the Correlation-

Keys can be used to tie messages to a speciﬁc pro-

cess instance. Correlating messages to process in-

stances may be enough to support centralized work-

ﬂows, but this is insufﬁcient for decentralized work-

ﬂows. In a decentralized context, it is key to also

uniquely and formally deﬁne correlations between all

process instances of all parties involved in the decen-

tralized workﬂow. 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 deﬁnes

correlation on ChannelTypes, well-deﬁned communi-

cation endpoints of a Participant, whereas in BPMN

it is all done on the Conversations, which deﬁne 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 ﬁrst 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 speciﬁcation mentions

the actual deﬁnition of auditing/monitoring is out of

scope of the speciﬁcation. It is up to the implementers

to specify how these elements are used and extended.

Auditing and monitoring can be deﬁned 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 ﬂow. Auditing and monitoring

can also be set for a Process itself, which can be used

(for instance) to deﬁne 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 deﬁne monitoring.

Consequently, it would be more interesting to deﬁne

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 speciﬁc 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 deﬁned by the BPMN model.

process id

The unique identiﬁer for this process as set by the

participant’s system.

task id

The unique identiﬁer for this task as deﬁned 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 speciﬁc 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 speciﬁc 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 speciﬁc FlowEle-

ment. A FlowElement can be speciﬁed 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

speciﬁed by the metadata as speciﬁed in section 4.2.

In order to additionally monitor application speciﬁc

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

speciﬁc 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 ﬁrst 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 workﬂows. Correlation in de-

centralized workﬂows 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 veriﬁcation 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