On Business Process Monitoring Using Cross-Flow

On Business Process Monitoring Using Cross-Flow Coordination Zakaria Maamar1 , Noura Faci2 , Mohamed Sellami3 , Khouloud Boukadi4 , Fadwa Yahya4 , Ahmed Barnawi5 , and Sherif Sakr6 1

Zayed University, Dubai, U.A.E Universit´e Lyon 1, Lyon, France 3 ISEP Paris, Paris, France 4 University of Sfax, Sfax, Tunisia 5 King Abdulaziz University, Jeddah, Saudi Arabia 6 University of New South Wales, Sydney, Australia King Saud bin Abdulaziz University for Health Sciences, Riyadh, Saudi Arabia 2

Abstract. This paper presents an approach for monitoring the execution progress of business processes. The monitoring focuses on the exceptions that could arise during this execution and hence, could make the processes fail if not handled properly and timely. The approach relies on three flows known as control, communication, and navigation. The control flow connects tasks together with respect to a certain business logic. The communication flow captures the messages exchanged between persons/machines when they perform tasks of processes. Finally, the navigation flow captures the interactions between specialized networks that offer solutions to exceptions. These networks are built upon relations between tasks, between persons, and between machines. The coordination of control, communication, and navigation flows focuses on both the actions that are taken and the messages that are exchanged when handling exceptions. A system demonstrating flow development and coordination is, also, presented in the paper. Keywords: business process, coordination, exception, flow, monitoring.

1

Introduction

Simply put, a Business Process (BP) consists of tasks connected to each other with respect to a certain business logic (e.g., processing car-loan application). This logic specifies what to do in response to specific internal or external events and who does what, when, and where. At run time, tasks are assigned to persons and/or machines (aka executors) so they perform them. In an early work, we discuss the benefits of injecting social elements into the design of BPs so that relations (with a social “flavor”) between tasks, between persons, and between machines are identified. We use these relations to develop networks of tasks, networks of persons, and networks of machines [1]. Examples of relations include interchange between tasks, backup between machines, and peering between persons. Practically speaking, the execution of BPs requires resources (logical such

as data and/or physical such as equipment) that are sometimes limited, nonshareable, and/or non-renewable. These properties restrict the availabilities of resources when they are required. For instance, a non-shareable resource will delay some processes if it is not released on time. To address certain resource restrictions, we use the networks of tasks, persons, and/or machines [2]. According to Haget et al. [3], “Whilst 95% of IT investments are today still focused on the automation of business processes from the point of view of cutting costs, a good part of employees’ working time is not spent on the process, but on the exception to the process” (as cited in [4]). Monitoring is critical to the success of any BP execution and thus, a global view over this execution is a must. This should help decision makers adjust resource availabilities, channel messages to appropriate recipients, and keep track of what is pending, for example. To achieve this monitoring, some works (e.g., [5] and [6]) develop flows (e.g., process/control and message/communication). Unfortunately, these flows are developed independently from each other (i.e., silos), which means they provide a restrictive view over the status of a BP. To deal with this restrictive-view limitation, we support our monitoring with three specialized flows referred to as control, communication, and navigation, and coordinate their development so that a global view over a BP is produced. In particular, the control flow connects tasks together with respect to the business logic of the process. The communication flow connects the process’s executors (machines and/or persons) together when they receive these process’s tasks for execution. Last but not least, the navigation flow connects the networks of tasks, machines, and persons together when this process’s tasks are subject to exceptions that could fail this process if they are not handled. The development of control, communication, and navigation flows is dependent on tracking the messages that are exchanged between tasks, between executors (persons/machines), and between networks. To support these messages, we define communication performatives like those used in agent communication languages [7]. Our contributions include: (i ) definition of control, communication, and navigation flows; (ii ) an architecture for supporting flow development and coordination; and (iii ) a system that implements the architecture. The rest of this paper is organized as follows. Section 2 includes a running scenario, some related work, and a brief overview of our work on BP social-design. Section 3 discusses the cross-flow coordination approach to monitor BPs. Section 4 presents the system implementing the monitoring approach. Finally, Section 5 concludes the paper.

2

Background

This section consists of three parts: running scenario, related work on BP monitoring, and our work on BP social-design. 2.1

Running scenario

Our scenario is based on OMG’s shipping BP example [8]. Fig. 1 shows its partial representation in Business Process Model and Notation (BPMN, [9]). Different

persons (e.g., clerk, warehouse worker, and logistic manager) and/or machines (e.g., equipment for packaging and loading goods) take part in the execution of the process. When this BP is triggered, the following happens (sometimes in a concurrent way) where ta stands for task:

Fig. 1. BPMN representation of shipping BP

1. A clerk decides on the best shipping option by either carrier or postal (ta1 ). (a) Carrier option: quotes are requested from different carriers (ta2 ). When the quotes are received, the clerk selects a carrier and then, finalizes the necessary paperwork (ta3 ). (b) Postal option: the clerk checks if the shipment is valuable (ta4 ). If yes, he requests from the logistic manager to apply for an extra insurance1 (ta5 ) while he prepares a postal sticker for the shipment (ta6 ). The sticker is sent to the warehouse worker upon the extra insurance confirmation. 2. A packaging equipment assists the warehouse worker package the shipment (ta7 ). Following the postal sticker’s receipt, the warehouse worker finalizes the pending paperwork while the operator uses a crane to move the shipment to the pick-up area (ta8 ). Like any other BP, the shipping process could be subject to different exceptions. Persons might be unavailable when they need to intervene (e.g., logistic manager needs to attend an unplanned meeting), performed tasks might be inappropriate (e.g., clerk requests an extra insurance for an invaluable shipment), and some equipment might break down suddenly (e.g., due to poor maintenance). 1

We suppose that regular insurance is included in any shipping.

2.2

Related work on BP monitoring

Our literature review on BP monitoring permitted to identify some key concepts like contract, event, compliance, prediction, and abnormal. We present some works around these concepts and conclude with a paragraph highlighting how different our work is from those reported hereafter. Comuzzi et al. [5] target cross-organizational processes whose execution requires the collaboration of several partners. The monitoring collects details on BPs during or after execution. Cases that do not comply with the established contracts are detected so that corrective actions are taken. The monitoring is not limited to the status of a process, but, also, includes consumers’ requirements reported in contracts’ clauses. Comuzzi et al., also, consider business-network evolution in terms of new/previous contracts that are introduced/updated or dropped, or new/old partners that join/leave the network. Requirement monitoring spans over multiple interrelated contracts between partners. Contracts that establish collaboration between partners might not be sufficient to track the processes since the contracts are established prior to execution. As a result, a proactive monitoring approach is required at run time. Kang et al. [6] propose a real-time BP monitoring so that abnormal terminations of under-execution process instances are predicted. Two phases ensure the success of monitoring: off-line pre-processing and run-time. The former analyzes a training set of historical process instances and uses a detection technique to compute a cluster of normal instances. The latter detects the existence of any abnormal instance execution based on how “far” it is from the cluster. Instances are observed through a set of observable process- or task-relevant attributes (e.g., start and completion times of each task and input/output data). This set generates plausible process instances based on the current process state and consists of observed attributes and unknown attributes that are inferred from the next potential states. Potential states are predicted over entire monitoring periods based on the current performance of the observed process. By observing a process execution, an abnormal termination of an instance can be proactively predicted before it happens. Last but not least, Thullner et al. [10] propose an event-based monitoring framework. Events are state changes in a process or business environment, and usually mark a significant point in time such as start and/or end of a task in a process. The authors model BPs as flows of events connected through connectors (e.g., “has to occur after”). For monitoring purposes, compliance checkpoints are added to the event flows in order to identify events and event flow segments of a process that are relevant for compliance check (e.g., a customer’s invoice must not to be sent before product delivery). Thullner et al. define two types of compliance checkpoints: time and flow. Time-checkpoint monitors if the execution of a task in a process has occurred within a time frame. And flow-checkpoint checks if the execution order of tasks is compliant with the predefined order of tasks in the process. Using both checkpoints, monitoring rules are defined to detect compliance violations and automatically trigger the required corrective actions. Along with BP monitoring, we discuss below three initiatives related synchronizing models. Weidmann et al. [11] look into the best ways of managing

changes in business processes. They advocate for process model synchronization that should happen at different abstraction levels. The levels are numbered in order of detail with zero being the highest-level process model. Synchronization ensures alignment of business with IT since continuous changes could impact this alignment. Changes are logged in a queue that is bound to a specific abstraction level and their propagations could be either top-down, bottom-up, or meet-in-the-middle. Grossmann et al. [12] propose an approach for propagating changes on-the-fly in BPs during design-time from one BP view (i.e., BP model at some abstraction level) to its reference BP model and any other views that contain elements that a change could affect. This approach relies on Model Driven Engineering (MDE) to make different BP views/models synchronize more efficiently in case of changes. It checks consistency rules on the structure of different BP models and keep relationships between elements in those models. Finally, Polyvyanyy et al. [13] argue that maintaining several models of one BP at various abstraction levels requires a lot of synchronization effort when the BP is changed and is also prone to errors. To address this issue the authors propose a BP model abstraction approach to derive on-demand coarse grained process models from the existing detailed models. This approach learns process model elements which are insignificant and abstracting from those elements. It, thus, provides a user control over the model abstraction. Compared to the aforementioned works, we provide a complete view over the execution progress of BPs. This view spans over three levels process level showing at-risk tasks due to exceptions, execution level showing interactions between executors of tasks, and network level showing the ongoing development of possible solutions for these exceptions. These levels are associated with control, communication, and navigation flows, respectively. Other works, for instance [5,6,10], develop independent flows that do interact with each other and do not capitalize on previous experiences between a BP’s components to handle exceptions. Our networks of tasks/persons/machines capture these experiences, which permits developing efficient solutions to exceptions.

2.3

Business process social-design

As part of our research agenda on enterprise 2.0 [1] (aka social enterprise), we examine BP from a social perspective. In fact, we define the BP’s three components namely task (ta), person (pe), and machine (ma). A task (e.g., submit extra-insurance request) is a work unit that forms with other tasks (e.g., pay extra insurance) a BP and that a person (e.g., clerk) and/or machine (e.g., truck) perform. Performance is either manual (e.g, apply for extra insurance; ta5 in Fig. 1), automatic (e.g., post good receipt), or both (e.g., package goods; ta7 in Fig. 1). We also associate a task with requirements (e.g., task should be executed on a secure platform), a person with capacities (e.g., person with experience in operating crane), and a machine with capacities (e.g., crane lifts up to 15 tonnes) as well. Requirements help identify those who will execute tasks in terms of person’s necessary expertise level, machine’s minimum reliability level, etc. Tasks,

persons, and machines connect to other peers (ta2ta, pe2pe, and ma2ma), respectively, through execution and social relations that we thoroughly discuss in [1] and listed below: – Execution relations between tasks include prerequisite (preReq), parallel (par ), parallel-prerequisite (parPre), and completion (comp). And, social relations between tasks include coupling and interchange. – Execution relations between persons include enablement and inhibition. And, social relations between persons include substitution, delegation, and peering. – Execution relations between machines include enablement and inhibition. And, social relations between machines include backup, cooperation, and partnership. The social relations allow the development of configuration network of tasks (specialized into interchange and coupling), social network of persons (specialized into substitution, delegation, and peering), and support network of machines (specialized into backup, cooperation, and partnership).

3

Cross flow coordination-based monitoring

This section presents the different flows that underpin our monitoring approach and then, how these flows are defined and coordinated. 3.1

Foundations

Fig. 2 illustrates the flows that constitute the basis of monitoring the progress of BPs spanning over three levels: process, execution, and network. The process level is linked to the control flow, the execution level is linked to the communication flow, and the network level is linked to the navigation flow. Fig 2 also bind bind illustrates two bindings: (person/machine −→ task) and (person/machine −→ bind

social/support network). (task −→ configuration network) binding is not shown in the figure to avoid cross-cutting lines that would make the figure unnecessarily complex. Binding is either of type execution or of type membership. Let T a, M a, and P e be three finite sets of tasks (taj ∈ T a), machines (mal ∈ M a), and persons (pek ∈ P e), respectively. Let also N T a, N M a, and N P e be three finite sets of N etworks of T asks, N etworks of M achines, and N etworks of P ersons, respectively. As per Section 2.3, N T a is specialized into {N T acoupling , N T ainterchange }, N P e is specialized into {N P esubstitution , N P edelegation , N P epeering }, and N M a is specialized into {N M abackup , N M acooperation , N M apartnership }. For the sake of simplicity, we drop the specialized networks and restrict the discussion to N T a, N M a, and N P e, only, when referring to networks. As a result, taj , pek , and mal correspond to ntaj ∈ N T a, npek ∈ N P e, and nmal ∈ N M a, respectively, i.e., a task/person/machine is a node in a network of tasks/persons/machines. To define flows, we use statecharts [14] although the use of other notations is possible with no impact on our monitoring approach.

ta1

ta2

pe1

pe2

pe4

ma2

Communication flow

npe 1

Network level

ta3

nta 1

npe 3

npe 2

Social network of persons (NPe)

nma 2

nta 3

nta 2

Configuration network of tasks (NTa)

nma 6

Interaction-based coordination

Execution level

Process level

Control flow

nma 3

Support network of machines (NMa)

Navigation flow Legend : Flow ta

: task

: Execution binding pe

: person

: Membership binding

ma : machine

NT : network

Fig. 2. Flow/level coupling in the monitoring approach

Definition 1. Flow is a 5-tuple Flow = < S, L, T , s0 , F > where: S is a finite set of state names; L is a set of labels; T ⊆ S × L × S is the transition relation; each transition t = (ssr , l, stg ) consists of a source state ssr ∈ S, a target state stg ∈ S, and a transition label l ∈ L; s0 ∈ S is the initial state; and F ⊆ S is a set of final states.  A control flow represents the business logic of a BP with respect to a certain application domain (e.g., shipping) and certain requirements (e.g., maximum delivery time and minimum deposit). Definition 2. Control flow is an instance of Flow (Definition 1) denoted by Flowc =< S c , Lc , T c , sc0 , F c > where: S c consists of all tasks (taj ∈ T a) in a BP. A state in Flowc is a task (i.e., sci corresponds to taj ).  Example 1. Let Flowic =< Sic , Lci , Tic , sc0i , Fic > be the control flow of the running scenario where: - Sic = {ta1 , ta2 , . . . , ta8 }, e.g., ta1 : decide on the best shipping way and ta2 : request quotes from different carriers; - Lci = {[postal shipment], . . . , [extra insurance conf irmation]}; - Tic = {(ta1 , [postal shipment], ta4 ), (ta2 , [], ta3 ), . . .}; - sc0i = ta1 ⊕ ta7 ; and

- Fic = {ta8 }.

A communication flow captures the interactions between persons and/or machines when they execute a BP’s tasks. Execution is either manual, automatic, or semi-manual (or semi-automatic). Definition 3. Communication flow is an instance of Flow (Definition 1) denoted by Flowo =< S o , Lo , T o , so0 , F o > where: S o consists of persons (pek ∈ P e) and/or machines (mal ∈ M a) taking part in the execution of a BP. A state in Flowo is either a machine in the case of automatic execution of task (i.e., soi corresponds to mal ), a person in the case of manual execution of task (i.e., soi corresponds to pek ), or both machine and person in the case of semi-automatic (-manual) execution of task (i.e., soi corresponds to pek and mal ).  A navigation flow captures the interactions between the networks of tasks and networks of persons/machines when these networks are used for handling exceptions like machine sudden-breakdown and person unexpected-unavailability. Definition 4. Navigation flow is an instance of Flow (Definition 1) denoted by Flown =< S n , Ln , T n , sn0 , F n > where: S n consists of certain2 tasks (ntaj ) in the network of tasks (N T a), certain3 persons (npek ) in the network of persons (N P e), and certain machines (nmal ) in the network of machines (N M a). All these networks’ constituents contribute towards handling exceptions. A state in Flown refers to a node in a network (i.e., sni corresponds to either ntaj , npek , or nmal ).  Since the communication and navigation flows are developed on-the-fly (contrarily to the control flow that is known in advance), examples of these two flows are given later. It is worth noting that the connection between states in the aforementioned definitions, enables the development of intra-flow sequences and inter-flow sequences. In this paper, we focus on inter-flow sequences; they support flow coordination using specialized messages (Table 3).

3.2

Architecture of the monitoring approach

Our BP monitoring is dependent on first, persons/machines who bind tasks for execution needs (Fig. 2) and second, changes in the states of tasks, persons, and machines (as per Section 3.4 (Fig 4), suspended state for task and busy state for person/machine) when this binding becomes effective. The architecture consists of four components (Fig. 3): mapper, control-flow manager, communication-flow builder, and navigation-flow builder. 2 3

Not all tasks are subject to exceptions. Not all persons/machines raise exceptions.

1

Design-time BP models ta2

Mapper

ta1

1.1

ta4 ta3

1.2

Control flow

Runtime

2

Control flow manager

2.1

2.2

ta2

ta1

ta2

ta1

BP instances (execution in progress)

ta3

….

2.5

2.3

Communication flow (under construction)

2.2’

2.3’

Communication flow builder

2.4

Networks of tasks/machines/persons ma 1

ta 1

ma3

ta5 ta7

ma4

pe1

pe2

pe4

ma2

Navigation flow (under construction)

pe1

nta 1

pe2 pe3

Navigation flow builder

pe3

2.4’

pek nta j

nta 6

Interchange network

pe1 Delegation network

Fig. 3. Cross-flow monitoring architecture

• At design time, the mapper takes the business model of a BP as an input (1.1) in order to produce a control flow as an output (1.2). The mapper transforms the transitions4 in a BP’s business model into relations between tasks. This transformation is detailed in Section 3.3. • At run time, the control-flow manager tracks the under-execution BP instances (2.1) so that the execution bindings are known. The control-flow manager informs the communication-flow builder of these bindings (2.2). Using both inputs, i.e., the bindings and the control flow (2.3), as inputs, the communication-flow builder puts in place the communication flow (2.4) that connects the executors (i.e., persons and/or machines) together. The development of the communication flow is detailed in Section 3.4. Parallel to monitoring the under-execution BP instances (2.1), the controlflow manager checks the states of both tasks and executors with emphasis on certain states like suspended for task and on-hold for person/machine. These states could “hint” towards some potential exceptions. If this is the case, the control-flow manager interacts with the networks of tasks/machines/persons in order to handle these exceptions (2.2’) and updates the control flow, eventually (2.5). The control-flow manager sends the navigation-flow builder details about these interactions (2.3’). The builder uses these details to develop the navigation flow (2.4’) as per Section 3.5. Both the communication-flow builder and the navigation-flow builder carry out their duties in a concurrent manner. 4

BP models like in Fig. 1 are converted into statecharts in compliance with our definitions.

To wrap-up this section, we recall that the development of control flow is discussed in Section 3.3, the development of communication flow is discussed in Section 3.4, and the development of navigation flow is discussed in Section 3.5. 3.3

Control-flow development

To ensure that our BP monitoring is independent from any BPM platform, we convert BP models (e.g., Fig. 1) into statecharts in compliance with Definition 1. In statecharts [14], a state is either simple or composite. The latter consists of several states (which we call substates) and is either sequential or parallel. The different types of states are: (i ) simple state (s) that is a task in a BP; (ii ) sequential composite state (sseqComp ) that consists of an initial state to trigger when sseqComp is activated, a set of final states, and a set of sequential states; and (iii ) parallel composite state (sparComp ) that consists of a set of concurrent states that include sequential composite and/or parallel composite states. When sparComp is active, all corresponding states are concurrently active. Varro [15] categorizes transition into external, choice, internal, completion, parallel, external with history, external with exit point, or synchronized parallel. We map Varro’s transitions onto specific execution relations between tasks. These relations are the basis of control flows and are of three types: prerequisite, parallel, and parallel-prerequisite. As per Definition 2, we consider a state as a task (i.e., sc corresponds to ta) for mapping needs and use incoming/outgoing, when necessary, to indicate the direction of a transition. In Table 1, we provide the necessary mapping rules (Rulemi ) (used by the mapper; Step (1.1) in Fig. 3) for some transition types. 1. Rulem1 maps an external transition text = (tasr , l, tatg ) onto a prerequisite execution-relation in Flowc between tasr and tatg where: tatg ’s preconditions and/or conditions correspond to l. As per Section 2.1, an example of Rulem1 is text1 = (ta2 , quotes received, ta3 ) onto preReq(ta2 , ta3 ). 2. Rulem2 maps a choice transition tchoice = (tasr , l, {tatg1 , tatg2 }) onto two prerequisite execution relations in Flowc between tasr and tatg1 and between tasr and tatg2 where: tatg1 (resp. tatg2 )’s pre-conditions and/or conditions correspond to l (resp. not l). As per Section 2.1, an example of Rulem2 is tchoice1 = (ta1 , delivery mode = regular, {ta4 , ta2 }) onto preReq(ta1 , ta4 )⊕ preReq(ta1 , ta2 ). 3. Rulem3 assumes that an internal transition tint =(tai , l′ , taj ) exists when tai and taj are enclosed in a sequential composite state ({tak }). tint executes without exiting {tak }. Rulem3 maps an internal transition tint given an external transition text =(tak ,l,tatg ) onto a nested prerequisite execution relation. As per Section 2.1, an example of Rulem3 is tint1 =(t31 , carrier assigned, t32 ) onto preReq(preReq(ta31 , ta32 ), ta8 ) where (t31 ,t32 ) are enclosed in t3 and correspond to assign carrier and prepare paperwork, respectively.

Table 1. Some mapping rules underlying control-flow development Transition in a BP model

preReq(tasr , tatg )

Rulem2 (tasr , l, {tatg1 , tatg2 })

preReq(tasr , tatg1 ) ⊕ preReq(tasr , tatg2 )

′

Rulem3 (tai , l , taj ) |({tak }, l, tatg )&tai , taj ∈ {tak }

3.4

Execution relation in a F lowc

Rulem1 (tasr , l, tatg )

preReq(preReq(tai , taj ), tatg )

Communication-flow development

To establish the communication flow that connects task executors together, we define its structure (using the relations between tasks (Section 3.3)) and then, its operationalization (using the messages exchanged with the control flow). Structure. To define the structure of a communication flow, we examined Song et al.’s relations namely transfer of work, subcontracting, and cooperation [16]. These relations are proposed for organizational mining purposes in a BP management context. The objective is to examine how to convert our execution relations between tasks in a control flow into (some of) Song et al.’s relations so that relations between executors in a communication flow are defined. We use Event-Condition-Action (E[C]A) format to specify the necessary conversion rules (used by the communication-flow builder; Step (2.4) in Fig. 3). Events refer to methods that the control-flow manager executes upon the request of the communication-flow builder. These methods are: change(ei ) detects changes in an executor’s state, monitor(taj ) tracks a task’s execution progress (e.g., meeting points), and report(taj /ei ) returns a task’s/executor’s current-state. Conditions refer to the following statement: “is the BP component in a certain state?”. States are represented in Fig. 4: state ∈ {activated, done, suspended, failed} for task and state ∈ {idle, on-hold, busy} for person/machine. A task takes on activated state when adequate executors are found for the task (task’s requirements versus executors’ capacities). When the task takes on activated state, it could transition to either done state when the task execution succeeds or suspended state so that the task is put on hold. In suspended state, the task can take on either activated state (i.e., resumed) or failed state (i.e., aborted). In the suspended state, the different networks of tasks/persons/machines are used to handle exceptions. Table 2 describes the conversion rules that connect executors together and thus, permits to develop the communication flow while the control flow is underexecution. 1. Rulec1 converts prerequisite relation (preReq(tai , taj )) into work-transfer relation between executors (workT rans(ei , ej )) where ei/j execute tai/j . 2. Rulec2 converts parallel prerequisite relation (parP re(tai , taj )) into parallelwork-transfer relation between executors (parW orkT rans(ei , ej )) where ei sends ej certain details (e.g., intermediate data) at a given point of the execution, called 1st -meeting-point of tai and taj .

(a) Task.

(b) Person/Machine.

Fig. 4. Statecharts of a business process’s components

3. Rulec3 converts parallel relation (par(tai , taj )) into parallel-work-exchange relation between executors (parW orkExch(ei , ej ) = parW orkT rans(ei , ej ) ∪ parW orkT rans(ej , ei )) where ei sends ej certain details (e.g., intermediate data) at a 1st -meeting-point and vice versa but at a 2nd -meetingpoint of tai and taj . The rule calls parW orkT rans(ei , ej ) and then parW orkT rans(ej , ei ). Note that 1st - and 2nd -meeting-points can be the same. 4. Rulec4 converts completion relation (comp(tai , taj )) into work-facilitation relation (aka Song et al.’s cooperation relation) between executors (workF ac(ek , ej )) where ek is an executor of tak that is added to the control flow as per the request of ej . tak processes tai ’s outputs for the benefit of taj .

Table 2. Conversion rules underlying communication-flow development Event

Condition

Conversion action ∧ preReq(tai , taj ) workT rans(ei , ej )

→

Rulec1

change(ei ): from busy to idle report(tai )=done report(ej )=idle

Rulec2

monitor(tai ): point

meeting report(tai )=activated ∧ report(ej )=idle

parP re(tai , taj ) → parW orkT rans(ei , ej )

Rulec3

monitor(tai ) ∧ monitor(taj ): report(tai )=activated ∧ 1st meeting point report(taj )=activated /suspended

par(tai , taj ) → parW orkT rans(ei , ej )

1st

later (optional in case both meeting points are the same)

∪

monitor(tai ) ∧ monitor(taj ): report(tai )=activated parW orkT rans(ej , ei ) /suspended ∧ 2nd meeting point report(taj )=activated Rulec4

change(ej ): from busy to on- report(tai )=done ∧ comp(tai , taj ) hold report(taj )=activated workF ac(ek , ej )

→

Operationalization. During the development of the communication flow, the communication-flow builder constantly interacts with the control-flow manager so that the process level binds to the execution level (Step (2.2) in Fig. 3). To support these interactions, we draw some analogy with network protocols (e.g., [17]) to define the necessary messages. The result of this analogy is a list of seven messages (Table 3): open, sync, success, fail, ping, ack, and close. Table 3. Messages between the control-flow manager (F lowc -M) and communicationflow builder (F lowo -B) Type

Sender

Receiver

Description

Impact

open

F lowc -M

F lowo -B

Establishes a communication Identification of a conversion channel to initiate the execution rule (Table 2) as per the exeof a certain task cution relation between the task and previous tasks

sync

F lowo -B

F lowc -M

Requests a potential executor for Identification of a potential exa certain task ecutor for the task

success F lowc -M

F lowo -B

Coupled with sync; confirms the Changes in respective states of availability of an executor for a task and executor certain task

fail

F lowc -M

F lowo -B

Coupled with sync; confirms the Search for a replacement task unavailability of an executor for to execute using interchange neta certain task work (Section 3.5)

ping

F lowo -B

F lowc -M

Checks liveness/audit of a task Collection of performance details executor (periodically) on the executor

ack

F lowc -M

F lowo -B

Coupled with ping; confirms or Non-liveness: Search for a not the liveness of a task execu- replacement executor using tor backup/substitution networks and withdrawal of the executor o from F low (Section 3.5)

close

F lowc -M

F lowo -B

Coupled with open; finalizes a No impact communication channel

In Table 3, fail and ack refer to abnormal execution cases that could for instance, result in looking for a task and/or executor replacement. These cases trigger the development of a navigation flow that captures how the different networks contribute towards identifying solutions for these cases. This is discussed in the next section. 3.5

Navigation-flow development

We discuss the interactions between the control-flow manager and networks of tasks/persons/machines while the control flow is under execution. We associate networks’ nodes with BP components (either ta, pe, or ma) and associate networks’ edges with relations between these components. In addition, we identify a network authority (Nauth , [18]) that connects new tasks/persons/machines to nodes in a network, assesses the weights of edges in a network, etc. Messages that support network interactions are either vertical (v, between the

control flow and network authorities) or horizontal (h, between independent network authorities) and are of two types: query and reply. The syntax of a message is: [Message-type: sender(namei ), receiver(namej ), content(string), reply-with/in-reply(string)] where: content refers to the method call (in case of query) and return value (in case of reply), and reply-with/in-reply refers to a message’s identifier. The navigation-flow builder uses query and reply messages to develop the navigation flow (Step (2.4’) in Fig 3). This development is case-driven (i.e., varies from one case to another). We identify two cases, task replacement and task delay, and discuss the first case, only. Assigning tasks to potential executors (persons and/or machines) might turn out unsuccessful. This happens when the capacities of executors do not satisfy tasks’ requirements (Section 2.3). We use the networks of tasks/persons/machines to first, replace these tasks and second, look for new executors for the replacement tasks, as well. Let us assume ta1 , ta2 , and ta3 in the control flow of shipping BP and that ta2 ’s requirements are not satisfied (Fig. 5). First, ta2 will be replaced with a similar task like ta9 using the interchange network of tasks. The control-flow manager (Flowc -M) sends this network’s authority (Nauth(interchange) ) a v-message requesting a replacement for ta2 : [v-query: sender(Flowc -M), receiver(Nauth(interchange)/N T a2 ), content(f indReplacement(ta2 ), reply-with(query1 )].

Control flow

X

ta1 rep

ta2

tai

lac

em

en

t

ta9

vertical (v)

interactions

Navigation flow (built upon h-interactions) Authority

Authority

nta 2

nta 3 horizontal (h) interactions

nta 9

…

Coupling network of tasks (NTa)

nta 9

…

Interchange network of tasks (NTa)

Fig. 5. Control flow/Networks of tasks in interactions

After screening the interchange network of tasks, the Nauth(interchange) selects ta9 , for example. Prior to confirming ta9 , the Nauth(interchange) requests the Nauth(coupling) the coupling level between ta9 and ta3 ([h-query: sender(Nauth(interchange) /N T a2 ), receiver(Nauth(coupling) /N T a2 ),

content(couplingLevel(ta9 , ta3 ))]). The Nauth(interchange) informs the coupling level to the control-flow manager based on the response it receives from the Nauth(interchange) . Then, the control-flow manager compares the coupling level to a threshold set earlier by the BP engineer: [v-reply: sender(Nauth(interchange) /N T a2 ), receiver(Flowc -M), content(couplingLevel(ta9 , ta3 )), in-reply(query1 )]. Let us assume that pe9 will execute ta9 . However, there is a concern over the availability level of pe9 . As a result, the control-flow manager sends the substitution network’s authority (Nauth(substitution) ) a v-message asking to find a substitute for pe9 with respect to a certain availability threshold (Trel ). This ′ message along with its response showing that pe9 is the new executor for ta9 are: [v-query: sender(Flowc -M), receiver(Nauth(substitution) /N P e9 ), content(f indSubstitute(pe9 ,Trel )), reply-with(query2 )], and [v-reply: sender(Nauth(substitution) /N P e9 ), receiver(Flowc -M), ′ content(substitute(pe9 :pe9 )), in-reply(query2 )].

4

Implementation

This section discusses the development of the cross-flow coordination approach in terms of deployment architecture, implementation technologies, and chronology of operations. Fig. 6 represents the deployment architecture as a UML component diagram [14]. This diagram includes components (protruding rectangle) wired together using two types of connectors: circle and semi-circle representing output(s) and input(s), respectively. The deployment architecture consists of four blocks: model transformation, flow development, cross-flow coordination, and BP execution simulation-platform. Each block includes components whose roles are described in the following. 1. The model-transformation block converts models from one format into another at design time. To this end, the block relies on two components, transformer and mapper, that are developed in compliance with MDE principles [19]. The transformer converts BP models represented in BPMN into UML statecharts as per Fig 7 . And, the mapper implements the rules that convert a UML statechart’s transitions into execution relations in Flowc (Section 3.3). Fig 7 shows the resulted Control flow. Both statecharts and Flowc are stored in XML and are displayed using JGraph visualization library. 2. The flow-development block contains three components, Flowc -M, Flowo B, and Flown -B, that manage the control, communication, and navigation flows, respectively. All these components are developed as transformation rules using MDE and implemented as Java classes. They take certain elements (e.g., tasks and execution relations between tasks) as inputs and transform them into other elements (e.g., executors and relations between these execuand . tors) as outputs that will form flows as per Fig 7

Design-time Transformer (MDE)

BP model (BPMN)

d1

BP UML statechart

d2

Mapper (MDE)

d3

Model transformation

c Flow (XML+JGraph)

Runtime

Config files

BP instances

(XML) r1

r8

BP execution simulation-platform

r2 r3

BP tracker

c Flow -M r4

Networks of tasks/machines/persons

r7

ma1

ta1

ma3

ta5 ta7

ma4

pe1 pe2 pe3

r6

Checker

r5

Exception detector

r9

Cross-flow coordination

o Flow -B

Flowo (XML+JGraph)

Flown-B

n Flow (XML+JGraph)

Flow development

Legend:

Aspect component

Java component

Output

Input

Input/Output flow

Fig. 6. Deployment architecture of the monitoring approach

3. The cross-flow coordination block ensures run-time communication between Flowc -M and Flowo -B and between Flowc -M and Flown -B. To this end, the block relies on three components, BP tracker, checker, and exception detector. All these components are developed as aspects using AspectJ [20]. Aspects help modularize design concerns like system-wide error-handling and context-sensitive behavior. The BP tracker collects details on the execution traces of BP instances as per Fig 7 . These details could be executors’ identifiers and their respective states for each task they execute. The checker captures events reported in Table 3 and assesses if the corresponding conditions are satisfied. Last but not least, the exception detector collects details on exception (e.g., failed task, person leave, and machine breakdown) along with interactions between the Flowc -M and networks’ authorities while handling exceptions. 4. The BP execution simulation-platform is an integrated suite of software components that allow BP engineers to simulate BP execution and trigger exceptions. BP instances are the result of instantiating Java classes that implement BP models along with some configuration files (e.g., task binding and executors’ states during BP execution). The chronology of operations in the deployment architecture is discussed as follows where di /ri denotes operation at design time/run time. Note that a complete video of this chronology is available at youtu.be/Nzi-_gNKV4A. Prior to initiating the shipping-BP execution, the BP engineer uploads the BP model in BPMN onto the model-transformation block (d1 ). The transformer generates the corresponding UML statechart (d2 ) of this BP model. While the mapper generates the Flowc (d3 ) using the UML statechart as an input, the configuration files are also uploaded. They contain a set of possible executors per task and their respective states like idle, busy, and on-hold. Then, the BP engineer triggers the BP execution via the BP execution simulation-platform that performs task/executor binding based on the configuration files and hence, creates BP instances (r1 ). During BP execution, the BP tracker tracks the BP instance progresses (e.g., ongoing and completed task(s)) by intercepting details on this binding, the current task/executor states, and the exceptions raised as well (r2 ). The BP tracker informs the Flowc -M of these details (r3 ). Then, the checker captures all task/executor state changes (r4 ) and communicates them to the Flowo B (r5 ). The Flowo -B and Flowc -M keep each other informed about for instance, the conversion rule (Table 2) to trigger for building the Flowo and the exceptions that raised like executor unavailability as per Table 3 (r6 ). When an exception raises, the Flowc -M interacts with the appropriate network authorities in order to handle the exception (r7 ). This might require updating the Flowc by the Flowc -M. The exception detector catches details about this interaction like what network authority is involved and its outcomes (e.g., who replaces who) (r8 ). Finally, the exception detector informs the Flown -B of these details that are necessary for building the Flown (r9 ).

Fig. 7. Mixed graph visualization of the different flows

5

Conclusion

We presented a cross-flow coordination approach for monitoring the execution progress of business processes. Different exceptions could undermine this progress and thus, make the business processes fail. The approach relies on three flows control, communication, and navigation- that track the actions taken in order to handle these exceptions as well as the messages exchanged between a business process’s components -task, person, and machine- when handling these exceptions. The approach also relies on different networks that connect tasks together, persons together, and machines together using specific social relations. The control flow consists of tasks that form a BP. The communication flow describes the collaboration between persons/machines when they perform tasks. Last but not least, the navigation flow represents the interactions between the various networks when tasks cannot be performed. All these flows along with their coordination have been illustrated with a shipping running scenario. Different tasks, persons, and machines contribute to the completion of this scenario and could, also, be the sources of exceptions like person calling-in-sick and machine suddenbreakdown. The cross-flow coordination approach has been implemented using four blocks -model transformation, flow development, cross-flow coordination, and BP execution simulation-platform-. These blocks have been designed in compliance with model-driven engineering principles and programmed in Java and AspectJ. In term of future work, we would like to look into the soundness and completeness properties of flows as well as the use of special repositories (aka logs) for mining purposes [21]. Acknowledgments This work was partially supported by King Abdulaziz City for Science and Technology (KACST) Project AD-35-20.

References 1. E. Kajan, N. Faci, Z. Maamar, A. Loo, A. Pljaskovic, and Q. Z. Sheng, “The Network-based Business Process,” IEEE Internet Computing, vol. 18(2), March/April 2014. 2. Z. Maamar, N. Faci, S. Sakr, M. Boukhebouze, and A. Barnawi, “Network-based Social Coordination of Business Processes,” Information Systems, Elsevier, vol. 58, 2016. 3. J. Hagel, J. Seely Brown, and L. Davison, The Power of Pull: How Small Moves, Smartly Made, Can Set Big Things in Motion. Basic Civitas Books, 2010. 4. OpenKnowledge. Social Business Process Reengineering (Social Business Manifesto). [Online]. Available: http://socialbusinessmanifesto.com/ social-business-process-reengineering/ 5. M. Comuzzi, J. Vonk, and P. W. P. J. Grefen, “Measures and Mechanisms for Process Monitoring in Evolving Business Networks,” Data Knowledge Engineering, vol. 71(1), 2012.

6. B. Kang, D. Kim, and S.-H. Kang, “Periodic Performance Prediction for Realtime Business Process Monitoring,” Industrial Management and Data Systems, vol. 112(1), 2011. 7. Y. Labrou and T. W. Finin, “Semantics and Conversations for an Agent Communication Language,” in Proceedings of the Fifteenth International Joint Conference on Artificial Intelligence (IJCAI’1997), Nagoya, Japan,, 1997. 8. O. M. G. (OMG), “Business Process Model and Notation by Example,” Object Management Group, Tech. Rep., 2010, http://www.bpmn.org. 9. ——, “Business Process Model and Notation Version 2.0,” Object Management Group, Tech. Rep., 2011, http://www.omg.org/spec/BPMN/2.0. 10. R. Thullner, S. Rozsnyai, J. Schiefer, H. Obweger, and M. Suntinger, “Proactive Business Process Compliance Monitoring with Event-Based Systems,” in Proceedings of the Workshops of the 15th IEEE International Enterprise Distributed Object Computing Conference (EDOCW’2011), Helsinki, Finland, 2011. 11. M. Weidmann, M. Alvi, F. Koetter, F. Leymann, T. Renner, and D. Schumm, “Business Process Change Management Based on Process Model Synchronization of Multiple Abstraction Levels,” in Proceedings of the 2011 IEEE International Conference on Service-Oriented Computing and Applications (SOCA’2011), Washington, DC, USA, 2011. 12. G. Grossmann, S. Mafazi, W. Mayer, M. Schrefl, and M. Stumptner, “Change Propagation and Conflict Resolution for the Co-evolution of Business Processes,” International Journal of Cooperative Information Systems, vol. 24, no. 1, 2015. 13. A. Polyvyanyy, S. Smirnov, and M. Weske, “Business Process Model Abstraction,” in Handbook on Business Process Management 1, Introduction, Methods, and Information Systems, 2nd Ed., 2015. 14. R. Miles and K. Hamilton, Learning UML 2.0. O’Reilly Media, Inc., 2006. 15. D. Varro, “A Formal Semantics of UML Statecharts by Model Transition Systems,” in Proceedings of the 1st International Conference on Graph Transformation (ICGT’2002), Barcelona, Spain, 2002. 16. M. Song, “Organizational Mining in Business Process Management,” Ph.D. dissertation, Pohang University of Science and Technology, Pohang, South Korea, 2006. 17. G. Wondracek, P. M. Comparetti, C. Kruegel, and E. Kirda, “Automatic Network Protocol Analysis,” in Proceedings of the 15th Annual Network and Distributed System Security Symposium (NDSS’2008), San Diego, CA, USA, 2008. 18. Z. Maamar, N. Faci, M. Luck, and S. Hachimi, “Specifying and Implementing Social Web Services Operation Using Commitments,” in The Proceedings of the 27th Annual ACM Symposium on Applied Computing (SAC’2012), Riva del Garda, Trento, Italy, 2012. 19. O. Top¸cu, U. Durak, H. O˘ guzt¨ uz¨ un, and L. Yilmaz, “Model Driven Engineering,” in Distributed Simulation. Springer, 2016. 20. R. Laddad, AspectJ in Action: Enterprise AOP with Spring Applications. Manning Publications Co., 2009. 21. W. van der Aalst, “Process Mining: Overview and Opportunities,” ACM Transactions on Management Information Systems, vol. 3, no. 2, 2012.