PRESERVING THE CONTEXT OF

INTERRUPTED BUSINESS PROCESS ACTIVITIES

Sarita Bassil

, Stefanie Rinderle

, Rudolf Keller

, Peter Kropf

, and Manfred Reichert

DIRO, University of Montreal, C.P. 6128, succ. Centre-ville, Montreal, Quebec, H3C 3J7, Canada

DBIS, Faculty of Computer Science, University of Ulm, Germany

uhlke Engineering AG, Schlieren, Switzerland

Institute of Computer Science, University of Neuchatel, Switzerland

Information Systems Group, University of Twente, The Netherlands

Keywords:

Information systems, business processes, ﬂexibility, data analysis, B2B and B2C applications.

Abstract:

The capability to safely interrupt business process activities is an important requirement for advanced process-

aware information systems. Indeed, exceptions stemming from the application environment often appear

while one or more application-related process activities are running. Safely interrupting an activity consists

of preserving its context, i.e., saving the data associated with this activity. This is important since possible

solutions for an exceptional situation are often based on the current data context of the interrupted activity.

In this paper, a data classiﬁcation scheme based on data relevance and on data update frequency is proposed

and discussed with respect to two different real-world applications. Taking into account this classiﬁcation, a

correctness criterion for interrupting running activities while preserving their context is proposed and analyzed.

1 INTRODUCTION

To stay competitive in the market, companies must

be able to rapidly react to changing situations and to

align their business processes accordingly (Reichert

et al., 2003). In particular, e–business needs a pow-

erful infrastructure to isolate process logic from ap-

plication code (Gartner Group, 1999), and to deﬁne,

control, and monitor business processes. Process–

Aware Information Systems (PAIS) offer a promising

perspective in this context (v.d. Aalst and van Hee,

2002). They aim to connect

activities

, i.e., pieces of

work to perform a task, in order to achieve a common

goal (Workﬂow Management Coalition, 1999).

However, today’s companies need to maintain a

satisfying level of agility. It appears that agile PAIS

are the ones that provide, among other things, an ap-

propriate and a competent way to cope with changing

situations and unexpected events. This, in turn, is of

particular importance for adequately supporting long-

running, distributed business processes.

From this perspective, transportation companies for

instance must adopt solutions where a close follow-up

of activities is possible such that a customer request

is well satisﬁed. An example of a transportation ac-

tivity is ”move vehicle V from origin location O to

destination location D”. A close follow-up of this ac-

tivity can be achieved using GPS (Global Positioning

System) which enables to continuously calculate and

provide the position of a vehicle in movement.

Moreover, the occurrence of unexpected problems

during transportation cannot be avoided. Indeed,

there is ample evidence that ﬂeet management at the

operational level (e.g., scheduling of transportation

activities) is highly dynamic in the sense that ongoing

transportation activity sequences require a high de-

gree of adaptation to deal with unexpected problems

(Bassil et al., 2003). As an example, technical prob-

lems of vehicles, trafﬁc jams or forced rerouting may

appear at any time while V is on the road between

O and D. This usually leads to the interruption of the

”move V from O to D” activity. In such a situation,

a dynamic adaptation of an already planned ﬂow of

activities for the satisfaction of a customer request is

needed. This adaptation should take into account the

current context of the interrupted activity. The new

transportation solution may propose to send a new ve-

hicle V’ to the current position of V or to change the

already planned route leading to D. In both cases, the

current position of V should be available such that an

appropriate new solution can be proposed.

In this paper, we focus on interrupted (business)

process activities that require context preservation. In

most cases, activity interruption is triggered by the ap-

pearance of unexpected events coming from the appli-

cation environment (i.e.,

semantic failures

). Preserv-

ing the context of an interrupted activity consists of

saving data, which are produced by or associated with

this activity. This must be done at the right time, e.g.,

as soon as the data become available or relevant.

Bassil S., Rinderle S., Keller R., Kropf P. and Reichert M. (2005).

PRESERVING THE CONTEXT OF INTERRUPTED BUSINESS PROCESS ACTIVITIES.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 38-45

DOI: 10.5220/0002513500380045

 SciTePress

At this point, it is important to have a closer look

at the granularity of work unit descriptions. Usually,

a business process consists of a set of activities each

of them dealing with a logical task (e.g., preparing

a patient for a surgery). In addition, such a process

activity can be further subdivided into atomic steps

corresponding to basic working units (e.g., measuring

weight/temperature of a patient as atomic steps of ac-

tivity ”prepare patient”) or to data provision services.

Basic working units are either directly coded within

application programs or worked on manually by peo-

ple. Distinguishing between activities and atomic

steps is useful for the following reasons: Atomic steps

are not managed within worklists like activities are.

This contributes to better system performance since

the costs for managing and updating worklists de-

crease. Furthermore, this approach offers more ﬂex-

ibility to users (if desired) since they can choose the

order in which they want to work on atomic steps. The

distinction between activities and atomic steps ﬁnally

leads to the following basic considerations.

It is very important in this context to distinguish

between a continuous and a discrete data update by

activities. The ”move V from O to D” activity intro-

duced above is an example of an activity continuously

updating the ”V current position” data element by a

GPS system. An example of an activity discretely up-

dating data is even more obvious in process-oriented

applications. We may think about the activity ”ﬁll in

a form” with many sections, each one asking for in-

formation (i.e., data) related to a speciﬁc topic. The

information becomes relevant, and therefore may be

kept in the system, only after the completion of a spe-

ciﬁc section. Filling in a section could be seen as

working on a particular atomic step.

We highlight the fact that a process activity may

apply both updating kinds: it may discretely update

a particular data element d

and continuously up-

date another data element d

. Moreover, data ele-

ments may be discretely updated by a speciﬁc activity

and be continuously updated by another activity

. As an example, activity ”monitor patient” in a

medical treatment process, may ask to measure twice

a day the ”patient temperature” and to continuously

control the ”patient heart electric signals”. On the

other hand, the ”patient temperature” may be contin-

uously controlled in case of high fever within activity

”monitor patient” while it may be measured twice a

day after operation within activity ”aftercare”.

Data continuously or discretely updated by activ-

ities may be only relevant for the speciﬁcally stud-

ied application (e.g., the vehicle ”current position” in

Fig. 3) or they may be relevant for process execution

as well; in the latter case, these data are consumed by

process activities and therefore have to be supplied by

preceding activities. At the occurence of exceptional

situations, it may appear that mandatory process rel-

evant data will not be available at the time an activ-

ity is invoked. Depending on the application context

and the kind of data, it may be possible to provide

the missing data by

data provision services

which are

to be executed before the task associated with the re-

spective activity is handled.

We distinguish between exclusive application data

and process relevant data. Note that exclusive ap-

plication data may become process relevant when a

failure occurs. In the transportation application, an

example of process relevant data would be the ”con-

tainer temperature” (continuously) measured during a

”move V from O to D” activity and relevant for a ”Re-

port to customer” activity within the same process.

Reporting on the container temperature would inform

the customer whether the transported goods (e.g.,

foods) were or were not continuously preserved un-

der the appropriate temperature. The ”V current posi-

tion” is an example of exclusive application data since

it is relevant for the application, in particular for the

optimisation module of the application (Bassil et al.,

2004), but not for the business process management

system. If, however, a road trafﬁc problem occurs, the

”current position” of V may become relevant for the

process as well; i.e., the origin location O’ of a newly

proposed activity ”move V from O’ to D” changing

the already planned route leading to D, would corre-

spond to ”current position” of V.

Figure 1 shows a data classiﬁcation scheme in the

context of business processes. This classiﬁcation puts

the frequency of updating activity data and the rele-

vance of these data into relation. Within these two

dimensions, we respectively differentiate between:

• continuously and discretely updated data, and

• exclusive application and process relevant data.

Discrete

Continuous

Data

Relevance

Data Update

Frequency

Application data

continuously

updated

Application data

written by

atomic steps

Exclusive application

Process data

continuously

updated

Process data

written by

atomic steps

Process

Figure 1: Data Classiﬁcation Scheme

Taking into account this classiﬁcation, and know-

ing that exceptions stemming from the application

environment cannot be avoided and generally appear

during activity performance, it would be a challenge

not to loose available data already produced by the ac-

tivity that will be inevitably interrupted or deleted. In

order to formally specify the correctness criterion for

PRESERVING THE CONTEXT OF INTERRUPTED BUSINESS PROCESS ACTIVITIES

interrupting running activities while preserving their

context, formal deﬁnitions of requisite foundation for

this speciﬁcation are indispensable.

The remainder of this paper is organized as follows:

In Section 2 we deﬁne such foundation; we also dis-

cuss two application processes (a medical process and

a transportation process) with respect to the provided

deﬁnitions. Then, Section 3 introduces a general cor-

rectness criterion ensuring a safe interruption of a run-

ning activity. Section 4 discusses related work and

Section 5 concludes the paper.

2 FORMAL FRAMEWORK

To be able to precisely deﬁne the different kinds of

data and update frequencies we need a formal process

meta model. In this paper, we use the established

formalism of Well–Structured Marking Nets (WSM

Nets) (Rinderle et al., 2004b) and extend it for our

purposes. Informally, a WSM Net is a serial–parallel,

attributed process graph describing control and data

ﬂow of a business process. More precisely, different

node and edge types are provided for modeling con-

trol structures like sequences, branchings, and loops.

A simple example is depicted in Fig. 2. Here, the

upper two lanes show the control and data ﬂow of a

(simpliﬁed) medical treatment process. For example,

activities ”admit patient”, ”inform patient”, and ”pre-

pare patient” are arranged in sequence whereas activ-

ities ”monitor” and ”operate” are executed in parallel.

”Weight” and ”temperature” are examples of process

relevant data elements involved in a data ﬂow between

the activities ”prepare patient” and ”operate”.

As motivated in the introduction an activity can be

subdivided into a set of atomic steps. Going back to

Fig. 2, the lower two lanes show the atomic steps

assigned to the process activities as well as the data

ﬂow between these steps. For example, the atomic

steps ”measure weight”, ”measure temperature”, and

”wash patient” are assigned to activity ”prepare pa-

tient”. ”Provide weight” is an example of a data pro-

vision service assigned to activity ”operate” as atomic

step. If an exceptional situation (e.g., failure at the

”measure weight” atomic step level) occurs this data

provision service will be invoked in order to supply

input data element ”weight” of the activity ”operate”

(and particularly of its atomic step ”anesthetize”). We

deﬁne a partial order relation on the set of atomic

steps (incl. data provision services) assigned to a cer-

tain activity. The precedence relation depicts a micro

control ﬂow between elements of this set. Note that,

by contrast, a macro control ﬂow is deﬁned between

activities. We set up this relation by assigning nu-

meric labels to atomic steps, e.g., an atomic step with

numeric label ”1” is considered as a predecessor of

all atomic steps with numeric label ”2” or greater. By

default, all atomic steps have number ”1”, i.e., they

can be worked on in parallel. In this case, the actor

which works on the respective activity is considered

as being the expert in choosing the best order. Data

provision services have number ”0” since they must

be executed before other atomic steps assigned to the

same activity, in order to properly supply these atomic

steps with the required input data.

So far WSM Nets have not considered splitting ac-

tivities into atomic steps. Therefore we extend the

formal deﬁnition from (Rinderle et al., 2004b) by in-

cluding this additional level of granularity. In the fol-

lowing, S describes a process schema.

Deﬁnition 1 (Extended WSM Net) A tuple S = (N,

D, NT, CtrlE, DataE, ST, P, Asn, Aso, DataE

extended

)

is called an extended WSM Net if the following holds:

• N is a set of activities and D is a set of process data

elements

• NT: N 7→ {StartFlow, EndFlow, Activity, AndSplit,

AndJoin, XorSplit, XorJoin, StartLoop, EndLoop}

To each activity NT assigns a respective node type.

• CtrlE ⊂ N × N is a precedence relation setting out

the order between activities.

• DataE ⊆ N × D × NAccessMode is a set of

data links between activities and data elements

(with NAccessMode = {read, write, continuous-

read, continuous-write})

• ST is the total set of atomic steps deﬁned for all

activities of the process (with P ⊆ ST describing

the set of data provision services)

• Asn: ST 7→ N assigns to each atomic step a respec-

tive activity.

• Aso: ST 7→ N assigns to each atomic step a num-

ber indicating in which order the atomic steps of a

certain activity are to be executed. By default: If

s ∈ P , Aso(s) = 0 holds; otherwise, Aso(s) = 1.

• DataE

extended

⊆ ST × D × STAccessMode is a

set of data links between atomic steps and data el-

ements (with STAccessMode = {read, write})

As can be seen in the example from Fig. 2, there

are atomic steps which produce data (e.g., ”measure

weight”) and others which do not write any data el-

ement (e.g., ”wash patient”). In order to express

this fact, we logically extend the set DataE to set

DataE

extended

which comprises all read/write data

links between atomic steps and data elements. In

particular, an intra-activity data dependency may be

deﬁned such that intermediate results of an activity

execution can be passed between subsequent atomic

steps st

and st

with Asn(st

) = Asn(st

); i.e.,

∃(st

, d, write), (st

, d, read) ∈ DataE

extended

As an example (Fig. 2), consider the intra-activity

data ﬂow from ”anesthetize” to ”operate” via data ele-

ment ”sensory perception degree”. In fact, the atomic

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

weight

temperature

electro

cardiogram

consent

Inform

Sign

Measure

weight

Measure

temp.

Wash

patient

Anesthetize

Operate

Provide

weight

Atomic

steps

Data on

macro

level

sensory perception

degree

Admit

patient

Inform

patient

Operate

Monitor

Prepare

patient

Aftercare

Control flow

AndSplit AndJoin

Process Schema S:

: Control flow

: Data flow

weight

temperature

consent

Data on

micro

level

sensory perception

degree

Figure 2: Medical Treatment Process

step ”operate” needs this data element to decide when

to begin surgery.

Based on Def. 1, process instances can be cre-

ated and executed. As discussed in (Rinderle et al.,

2004b), during runtime a process instance references

the WSM Net it was created from. Its current ex-

ecution state is reﬂected by model–inherent activity

markings. An activity which can be worked on is thus

labeled Activated. As soon as activity execution is

started the marking changes to Running. Finally, a

ﬁnished activity is marked as Completed and an ac-

tivity, which belongs to a non-selected, alternative ex-

ecution branch, is marked as Skipped.

Deﬁnition 2 (Process Instance on Extended WSM

Net) A process instance I on an extended WSM Net S

is deﬁned by a tuple (S, M

extended

, Val

) where:

• S = (N, D, NT, CtrlE, . . .) denotes the extended

WSM Net I was derived from

• M

extended

= (NS

, STS

) describes activity and

atomic step markings of I:

: N 7→ {NotActivated, Activated, Running,

Completed, Skipped}

ST S

: ST 7→ {NotActivated, Activated,

Running, Completed, Skipped}

• V al

denotes a function on D. It reﬂects for each

data element d ∈ D either its current value or the

value Undeﬁned (if d has not been written yet).

Markings of activities and atomic steps are corre-

lated. When an activity becomes activated, related

atomic steps (with lowest number) become activated

as well. The atomic steps will then be carried out ac-

cording to the deﬁned micro control ﬂow. As soon

as one of them is executed, both the state of this

atomic step and of its corresponding activity change

to Running. An activity is marked as Completed af-

ter completion of all corresponding atomic steps. Fi-

nally, if an activity is skipped during process execu-

tion, all related atomic steps will be skipped as well.

As motivated in the introduction, it is important

to distinguish between data elements only relevant in

context of application and data elements relevant for

process progress as well. We can see whether a data

element is relevant for the process if there is an activ-

ity reading this data element.

Deﬁnition 3 (Data Relevance) Let S be an extended

WSM Net, let w ∈ {write, continuous-write} and r ∈

{read, continuous-read}. Then we denote d ∈ D as

• an exclusive application data element if

∃(n, d, w) ∈ DataE =⇒ 6 ∃(m, d, r) ∈ DataE

• a process relevant data element if

∃(n, d, w) ∈ DataE =⇒

∃ m ∈ Succ

∗

(S, n) ∪ {n}: (m, d, r) ∈ DataE

Succ

∗

(S, n) denotes all direct and indirect succes-

sors of activity n.

The Data Relevance dimension captures both data

elements that are produced by the process, but are

only consumed by the application, and data elements

that are produced and consumed by the process. In

our medical treatment process (cf. Fig. 2), data ele-

ments ”weight” and ”temperature” taken during the

”prepare patient” activity are examples of process

relevant data elements. They are of utmost impor-

tance for carrying out the subsequent ”operate” ac-

tivity (e.g., to calculate the quantity of anesthesia that

has to be administered to the patient). By contrast,

”consent” is an exclusively application relevant data

element. As explained in Section 1, when a failure

occurs, an exclusive application data element may

become relevant for the process as well. A patient

who already consented upon a surgery accepts the

risks, and the ”consent” data element may thus be

used in subsequent activities dealing with respective

problems. Turning now to the container transporta-

tion process, ”current position” is an exclusive appli-

cation data element whereas ”container temperature”

is a process relevant data element (cf. Fig. 3).

PRESERVING THE CONTEXT OF INTERRUPTED BUSINESS PROCESS ACTIVITIES

Data on

macro

level

Control flow

current position

container temperature

Attach at

Move to

Load at

Move to

Unload

at D

Move to P

Report to

customer

…

Process Schema S:

: Control flow

: Data flow

Figure 3: Container Transportation Process

We now deﬁne the notion of data update frequency.

Based on this notion we will be able to deﬁne a cri-

terion for safely interrupting running activities while

preserving their context. Intuitively, for a discrete

data update by atomic steps there are certain peri-

ods of time between the single updates, whereas for

continuous data updates by activities the

time slices

between the single updates converge to 0. For deﬁn-

ing the

time slices

between data updates, we need the

function stp : ST 7→ R ∪ {U ndefined} which maps

each atomic step of ST either to a speciﬁc point in

time or to Undef ined. In detail:

stp(st) :=



if ∃(st, d, write) ∈ DataE

extended

Undef ined otherwise

whereby t



completion time of st

∞ by default

Note that the inﬁnite default value we assign to t

is updated as soon as st is completed. Hence, the real

completion time of st is assigned to t

Deﬁnition 4 (Data Update Frequency) Let S be an

extended WSM Net, let w ∈ {write, continuous-

write} ⊂ NAccessMode, and let d ∈ D, n ∈ N with

(n, d, w) ∈ DataE. Let further ST

be the set of

atomic steps associated with activity n and writing

data element d; i.e., ST

:= {st |asn(st) = n,

∃(st, d, write) ∈ DataE

extended

Then we denote (d, n) as:

• A discrete data update of d by n if

∃(n, d, write) ∈ DataE

In terms of atomic steps:

∀st ∈ ST

: stp(st) = t

6= Undeﬁned

• A continuous data update of d by n if

∃(n, d, continuous-write) ∈ DataE

In terms of atomic steps: ST

= ∅

In case an activity n continuously updates a data el-

ement d no atomic steps writing d are dissociated, i.e.,

there are no atomic steps associated with n that write

d; e.g., take the absence of atomic steps writing the

”current position”, the ”container temperature”, and

the ”electro cardiogram” in Figures 2 and 3. These

data elements are examples of data continuously up-

dated respectively by a GPS system, a thermometer,

and a cardiograph instrument.

On the other hand, the set of atomic steps discretely

writing a data element may be limited to only one

atomic step. The ”consent”, the ”weight”, and the

”temperature” are written once respectively by the

”sign”, the ”measure weight” and the ”measure tem-

perature” atomic steps (cf. Fig. 3).

Fig. 4 summarizes the classiﬁcation of the data in-

volved in the medical treatment and in the container

transportation process, taking into account the general

data classiﬁcation scheme presented in Fig. 1.

Discrete

Continuous

Data

Relevance

Data Update

Frequency

Exclusive application

- Container current

position

- Patient consent

- Patient weight

- Patient temp.

- Sensory perception

degree

- Container temp.

- Patient electro

cardiogram

Process

Figure 4: Data Classiﬁcation for the Medical Treatment /

Container Transportation Processes

3 CORRECTNESS CRITERION

In order to correctly deal with exceptional situations,

it is crucial to know those points in time when running

activities can be safely interrupted. A running activity

is safely interrupted means that the context of this ac-

tivity is kept (1) such that all input data of subsequent

activities are correctly supplied, or (2) in order to ﬁnd

possible solutions for exceptional situations. We de-

note these certain points in time as safe points of the

respective activities.

The challenging question is how to determine the

safe point of an activity. In order to adequately answer

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

this question, our distinction between continuous and

discrete data update is helpful. As the following deﬁ-

nitions show, it is possible to precisely determine the

particular safe interrupt points for discrete and con-

tinuous data updates, i.e., those points in time when

the respective data are updated such that subsequent

activities reading these data are correctly supplied.

Deﬁnition 5 (Safe Interrupt Point for a Discrete

Data Update) Let (d, n) (n ∈ N, d ∈ D) be a dis-

crete data update of d by n, and let ST

be the set

of atomic steps associated with n and writing d. Let

further B := {stp(st), st ∈ ST

| 6 ∃ p ∈ P: Asn(p) =

n and (p, d, write) ∈ DataE

extended

}. Then the safe

interrupt point t

safe

of (d, n) corresponds to the max-

imum point in time any atomic step writes d (on con-

dition that d cannot be provided by a data provision

service). Formally:

safe



max(B) : B 6= ∅

Undef ined : otherwise

Informally, the safe interrupt point for a discrete

data update by atomic steps is that maximum point in

time when the last write access to the respective data

element has taken place.

Deﬁnition 6 (Safe Interrupt Point for a Continu-

ous Data Update) Let (d, n) (n ∈ N, d ∈ D) be a

continuous data update of d by n with a start updat-

ing time t

and a ﬁnish updating time t

. The safe

interrupt point t

safe

of (d, n) (t

< t

safe

< t

)

corresponds to the time when d becomes relevant

for subsequent activities. This time is ﬁxed by the

user. If no safe interrupt point is ﬁxed by the user

safe

:= Undeﬁned holds.

Intuitively, for continuous data updates there is no

”natural” safe interrupt point. Therefore, we offer the

possibility to deﬁne a safe interrupt point by the user.

An example usage for such a user-deﬁned safe inter-

rupt point would be the ”waiting time” in order to get

the right container temperature after attaching it to

the vehicle that shall power the refrigeration system

within the container.

In order to determine the safe point of an activity,

we have to consider that there might be several safe

interrupt points. One example is the activity ”prepare

patient” which has two safe interrupt points belonging

to data elements ”weight” and ”temperature” (Fig. 2).

Deﬁnition 7 (Activity Safe Point) Let {d

, .. . , d

}

be the set of data elements (continously) written by

activity n ∈ N (i.e., ∃ (n, d

, w) ∈ DataE, i = 1,

..., k, w ∈ {write, continuous−write}). Let further

safe

, . . . , t

safe

be the related safe interrupt points.

Then we denote t

safe

= max{t

safe

, ..., t

safe

} as the

safe point of n (if t

safe

= Undeﬁned ∀ i = 1, . . .,

k, t

safe

is set to Undeﬁned as well). Thereby, t

safe

corresponds to the time when n can be safely inter-

rupted keeping its context. An activity n can be safely

interrupted if all input data of subsequent activities of

n are provided.

Using the notion of activity safe point we can state

a criterion based on which it is possible to decide

whether a running activity can be safely interrupted

or not.

Criterion 1 (Interrupting a Running Activity by

Keeping its Context) Let S be an extended WSM

Net, let I be an instance on S, and let w ∈ {write,

continuous-write} ⊂ NAccessMode. A node n ∈ N

with N S

(n) = Running and safe point t

safe

can be

safely interrupted at t

interrupt

if one of the following

conditions holds:

• 6 ∃(n, d, w) ∈ DataE

• t

safe

<= t

interrupt

or t

safe

= Undeﬁned

• ∀(n, d, w) ∈ DataE, t

interrupt

< t

safe

d is an exclusive application data element

A running activity can be safely interrupted from a

process perspective if it either writes no data or if it

solely writes exclusive application data. If a running

activity writes process relevant data it can be safely

interrupted if it has an undeﬁned safe point or its safe

point has been already transgressed. Finally, if exclu-

sive application data become process relevant (e.g., if

an exception handling process makes use of the full

context of the interrupted activity), the last condition

of Criterion 1 may not be applicable.

In order to illustrate the deﬁned correctness

criterion, we consider the container transportation

process. Based on process schema S provided in Fig.

3, instance I

in Fig. 5 has been started. Taking into

account a deﬁned transportation network, each of the

activities’ locations in I

is captured by a coordinate

(x, y). E.g., the origin and the destination locations in

activity ”move vehicle V from Montr

eal to Qu

ebec”

would respectively correspond to the coordinates

(1.5, 3.5) and (13, 8) within the transportation

network. Suppose that a road trafﬁc problem

occurs at time t

interrupt

= t

begin

+ 75minutes

(elapsed time since departure) while V is on the

road between Montr

eal and Qu

ebec. At this time,

suppose that the GPS system is indicating (7, 5.5)

for the current position of V. To avoid the trafﬁc

problem, an optimisation module may propose a new

transportation solution that consists of changing the

already planned route leading to Qu

ebec. The new

route includes a detour via another location, that is

Trois-Rivi

eres located at position (7, 7). However,

this new solution is only possible if V is close enough

to Trois-Rivi

eres, which means that the current

position of V is beyond (6, 5). This correponds

to t

”CurrentP osition”

safe

= t

begin

+ 60minutes. In

addition, suppose that the right container temperature

PRESERVING THE CONTEXT OF INTERRUPTED BUSINESS PROCESS ACTIVITIES

Montréal

(1.5,3.5)

Drummondville (6,4)

Québec (13,8)

Trois

Rivières

(7,7)

Current position of V at

interrupt

Expected position at

itionCurrentPos

safe

: Activated

: Running

√ : Completed

: Interrupted

activity

: Inserted

activity

current position

container temperature

Attach at

(6,4)

Instance I

on S

Move (6,4)

(1.5,3.5)

Load at

(1.5,3.5)

Move (1.5,

3.5) (13,8)

Unload at

(13,8)

Move (13,8)

(6,4)

Report to

customer

…

√

Attach at

(6,4)

current position

Instance I’

(modified I

)

container temperature

Move (6,4)

(1.5,3.5)

Load at

(1.5,3.5)

Move (1.5,

3.5) (13,8)

Unload at

(13,8)

Move (7,5.5)

(7,7)

Move (7,7)

(13,8)

…

√

Figure 5: Container Transportation Scenario

is reached 15minutes after ﬁnishing loading the

container and hence after the departure from the

origin location, i.e., t

”ContainerT emperature”

safe

begin

+ 15minutes. Taking into account Def.

7, the safe point of activity ”move vehicle

V from Montr

eal to Qu

ebec” corresponds to

max{t

”CurrentP osition”

safe

, t

”ContainerT emperature”

safe

}

< t

interrupt

. Hence, this activity can be safely

interrupted. The exclusive application data element

”current position” was used to generate the new

solution shown in Fig. 5. Following the road trafﬁc

problem, this data element becomes process relevant

as well: it is given as input to the inserted activity

”move vehicle V from current location to Trois-

Rivi

eres”. Note that in this speciﬁc example, the

”container temperature” data element is not relevant

for the deﬁnition of the safe point, and hence it could

be ﬁxed to Undefined.

4 DISCUSSION

In this paper a ”divide and conquer” approach is

adopted: An activity is divided into atomic steps so

that the interruption of this activity becomes possible

by preserving its context.

In (Sadiq et al., 2001; Mangan and Sadiq, 2002)

”pockets of ﬂexibility” are deﬁned. So called ”con-

tainers” comprise different activities and constraints

posed on these activities (e.g., activity B always be-

fore activity C). These containers can be inserted into

certain regions within the process. If process execu-

tion reaches such a container the assigned user can

choose the order of working on the offered activities

by obeying the imposed constraints. This idea can

be compared to our approach of subdividing activi-

ties into atomic steps and posing an order relation on

them if necessary. However, both approaches use a

different level of granularity and focus on different

aims. The approach presented by (Sadiq et al., 2001)

provides more ﬂexibility regarding process modeling

whereas our approach uses atomic steps for being able

to preserve the data context in case of unexpected

events during runtime.

The two kinds of data addressed by the Data Rel-

evance dimension of our data classiﬁcation scheme

have already been discussed within the literature

(Workﬂow Management Coalition, 1999; v.d. Aalst

and van Hee, 2002). In (Workﬂow Management

Coalition, 1999), a differentiation is made between

application data and process relevant data. It is ar-

gued that application data may become process rele-

vant if they are used by the workﬂow system to deter-

mine a state change. In this paper, we adopt the same

deﬁnitions and interpretations as provided in (Work-

ﬂow Management Coalition, 1999); furthermore, we

judiciously highlight the fact that exclusive applica-

tion data may become process relevant when a fail-

ure occurs. In (v.d. Aalst and van Hee, 2002), a

bigger variety of process data is featured: analysis

data, operational management data, historical data,

etc. It is stated that application data cannot be di-

rectly accessed by a workﬂow system but only in-

directly through instance attributes and applications

themselves. Hence, only the way of accessing appli-

cation data from a WfMS is discussed.

The inﬁnite completion time assigned as a default

ICEIS 2005 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

value to an atomic step st may be more precisely pre-

dicted using, for instance, the forward/backward cal-

culation technique based on the duration of activities

as proposed in (Eder and Pichler, 2002; Eder et al.,

2003). This would allow estimating an activity safe

point (t

safe

) as a speciﬁc point in time (instead of in-

ﬁnite) even before reaching this point.

Another interesting application of the presented re-

sults arises in the context of process schema evolution

(Rinderle et al., 2004a) i.e., process schema changes

and their propagation to running process instances.

One important challenge in this context is to ﬁnd cor-

rectness criteria in order to ensure correct process

instance migration after a process schema change.

According to the compliance criterion (Casati et al.,

1998; Rinderle et al., 2004a) it is forbidden to skip al-

ready running activities, i.e., the respective process in-

stances are considered as being non–compliant. How-

ever, if we transfer the concepts of safe interruption

of activities to the

safe deletion of activities

the num-

ber of process instances compliant with the changed

process schema can be increased.

5 SUMMARY AND OUTLOOK

We have proposed a framework to correctly ad-

dress the issue of safely interrupting running busi-

ness process activities in case of exceptional situa-

tions; i.e., interrupting running activities by preserv-

ing their data context, which is extremely important in

order to be able to provide adequate solutions in the

sequel. This work was motivated by the analysis of

data involved in the context of speciﬁc complex, yet

representative, process-oriented applications, namely

the container transportation application and the med-

ical application. Besides modeling logical work units

as process activities we have introduced another level

of granularity by deﬁning the atomic step concept.

The latter is of utmost importance to build up the ba-

sis for a two-dimensional data classiﬁcation scheme.

On the one hand, the deﬁnition of the

data relevance

dimension, distinguishing between exclusive applica-

tion data and process relevant data, is considered at its

pure level within the

safely interruption

criterion con-

ditions statement. On the other hand, we dug deeper

regarding the

data update frequency

dimension by

deﬁning safe interrupt points for each of the discrete

and the continuous data update by activities. This has

led to the formal deﬁnition of the activity safe point

considered as the backbone for the

safely interruption

criterion. Preserving this criterion, in turn, guarantees

that if an activity is safely interrupted all necessary

data is kept and can be used to ﬁgure out an adequate

solution for the respective exceptional situation.

As future work, we aim to study extended transac-

tional issues (e.g., semantic rollback) at both the mi-

cro ﬂow and the macro ﬂow level. In particular, this

must be done in a way that enables ﬂexible exception

handling procedures (incl. dynamic ﬂow changes).

Respective facilities are indispensable for realizing

adaptive enterprise applications.

REFERENCES

Bassil, S., Bourbeau, B., Keller, R., and Kropf, P. (2003).

A dynamic approach to multi-transfer container man-

agement. In Proc. Int’l Works. ODYSSEUS’03, Sicily.

Bassil, S., Keller, R., and Kropf, P. (2004). A workﬂow–

oriented system architecture for the management of

container transportation. In Proc. Int’l Conf. BPM’04,

pages 116–131, Potsdam.

Casati, F., Ceri, S., Pernici, B., and Pozzi, G. (1998). Work-

ﬂow evolution. DKE, 24(3):211–238.

Eder, J. and Pichler, H. (2002). Duration histograms for

workﬂow systems. In Proc. Conf. EISIC’02, pages

25–27, Kanazawa, Japan.

Eder, J., Pichler, H., Gruber, W., and Ninaus, M. (2003).

Personal schedules for workﬂow systems. In Proc.

Int’l Conf. BPM’03, pages 216–231, Eindhoven.

Gartner Group (1999). Why e-business craves workﬂow

technology. Technical Report T-09-4929.

Mangan, P. and Sadiq, S. (2002). A constraint speciﬁcation

approach to building ﬂexible workﬂows. Journal of

Research and Practice in Inf Tech, 35(1):21–39.

Reichert, M., Dadam, P., and Bauer, T. (2003). Dealing

with forward and backward jumps in workﬂow man-

agement systems. Int’l Journal SOSYM, 2(1):37–58.

Rinderle, S., Reichert, M., and Dadam, P. (2004a). Correct-

ness criteria for dynamic changes in workﬂow systems

– a survey. DKE, 50(1):9–34.

Rinderle, S., Reichert, M., and Dadam, P. (2004b). On deal-

ing with structural conﬂicts between process type and

instance changes. In Proc. Int’l Conf. BPM’04, pages

274–289, Potsdam.

Sadiq, S., Sadiq, W., and Orlowska, M. (2001). Pockets of

ﬂexibility in workﬂow speciﬁcations. In Proc. ER’01

Conf., pages 513–526, Yokohama.

v.d. Aalst, W. and van Hee, K. (2002). Workﬂow Manage-

ment. MIT Press.

Workﬂow Management Coalition (1999). Terminology &

glossary. Technical Report WFMC-TC-1011, WfMC.

PRESERVING THE CONTEXT OF INTERRUPTED BUSINESS PROCESS ACTIVITIES