Adaptive Process Management with ADEPT2
Manfred Reichert
University of Twente, IS Group
7500 AE Enschede, The Netherlands
Stefanie Rinderle, Ulrich Kreher, Peter Dadam
University of Ulm, DBIS Group
89069 Ulm, Germany
{rinderle,kreher, dadam}@informatik.uni-ulm.de
1. Introduction
In the ADEPT project we have been working on the de-
sign and implementation of a next generation process man-
agement software for several years [1, 2]. Based on a con-
ceptual framework for dynamic process changes, on novel
process support functions, and on advanced implementation
concepts, the developed system enables the realization of
adaptive, process-aware information systems (PAIS).
Basically, process changes can take place at the type
as well as the instance level: Changes of single process
instances may have to be carried out in an ad-hoc man-
ner (e.g., to deal with an exceptional situation) and must
not affect system robustness and consistency. Process type
changes, in turn, must be quickly accomplished in order to
adapt the PAIS to business process changes. This may re-
quire the concomitant migration of thousands of instances
to the new process schema (if desired). Important require-
ments are to perform respective migrations on-the-fly, to
preserve correctness, and to avoid performance penalties.
2. Change Features of ADEPT2
ADEPT2 offers powerful concepts for modeling, analyz-
ing, and verifying process schemes. Particularly, it ensures
schema correctness, like the absence of deadlock-causing
cycles or erroneous data flows. This, in turn, constitutes an
important prerequisite for dynamic process changes as well.
In detail, ADEPT2 supports both ad-hoc changes of sin-
gle process instances and the progagation of process type
changes to running instances:
Ad-hoc changes of single instances: We support differ-
ent kinds of ad-hoc deviations from the pre-modeled pro-
cess template (e.g., to insert, delete, or shift activities). Such
ad-hoc changes do not lead to an unstable system behavior,
i.e., none of the guarantees achieved by formal checks at
buildtime are violated due to the dynamic change. ADEPT2
offers a complete set of operations for defining changes at
a high semantic level and ensures correctness by introduc-
ing pre-/post-conditions for these operations. All complex-
ity associated with the adaptation of instance states, the re-
mapping of activity parameters, or the problem of missing
data (e.g., due to activity deletions) is hidden from users.
Process type changes and change propagation:Inor-
der to deal with business process changes we enable quick
and efficient schema adaptations at the process type level
(schema evolution). In particular, it is possible to
propagate
type changes to running instances (of this type) as well. We
provide a comprehensive correctness criterion for deciding
on the compliance of process instances with a modified type
schema. This criterion is independent of the used process
meta model and is based on a relaxed notion of trace equiv-
alence [2]. It considers control as well as data flow changes,
and it works correctly in connection with loop backs. In or-
der to enable efficient compliance checks, for each change
operation we provide precise and easy to implement compli-
ance conditions (cf. Fig. 1). Finally, efficient procedures ex-
ist for adapting the states of instance when migrating them
to the new schema (cf. Instance I1in Fig. 1).
Process Schema S: S’
Instance I1(on S):
'
T= addActivity(S, send questions, compose order, pack goods),
insertSyncEdge(S, send questions, confirm order))
Instance I2(ad-hoc modified):
Instance I3(on S):
get order
collect data
confirm
order
compose
order
pack goods
deliver goods collect data
confirm
order
compose
order
pack goods
delivergoods
send
questions
get order
ET=Sync
Instance I1(on S’):
ET=Sync
send brochure
Not compliant due to structural conflicts!
Not compliant due to state-related conflicts!
com
p
leted activated TRUE Si
g
naledrunnin
g
Change Operation
… and related compliance condition:
addActivity(S, act,
n
Preds: NS(n) = Disabled]
Preds, Succs) [
n
Succs:
(NS(n) {NotActivated, Activated})
(NS(n) = Disabled
m
succ(S,n):
NS(m)
{NotActivated,Activated,Disabled})]
Figure 1.
Migration Process (Example)
The correct interplay between concurrent type and in-
stance changes is indispensable to provide real benefit for
Proceedings of the 21st International Conference on Data Engineering (ICDE 2005)
1084-4627/05 $20.00 © 2005 IEEE
D
E
F
A
B
C
unchanged ("unbiased") instances
(and their marking on S)
I4
I3
I1
D
X E
I6
I2
changed ("biased") instances
(and their marking on S + )
A
C
D
I5
original schema S
substitution block of I5
(representing deletion of B)
substitution block of I2
(representing insertion of X)
Figure 2.
Managing Schema and Instance Data
practical applications. Therefore, we have also dealt with
the question how to propagate type changes to running in-
stances that may be in different states and may have under-
gone preceding ad-hoc modifications. For such ”biased” in-
stances, the current execution schema differs from the orig-
inal one. We apply a comprehensive correctness principle in
this context, which excludes state-related, structural, and se-
mantical conflicts. Fig. 1 shows an example: Instance I2has
been individually modified such that type change ∆Tcan-
not be applied to it; otherwise the resulting instance schema
would contain a deadlock-causing cycle.
ADEPT2 comprises a number of buildtime and runtime
components. They support the correct modeling of process
schemes, enable (distributed) process control, prove the fea-
sibility of dynamic process changes (also in case of dis-
tributed process control), indicate which interfaces are re-
quired, and show how the different concepts work in con-
junction with each other.
The implementation of ADEPT2 has raised many chal-
lenges, e.g., with respect to storage representation of
schema and instance data: Unchanged instances are stored
in a redundant-free manner by referencing their origi-
nal schema and by capturing instance-specific data (e.g.,
activity states). As an example, consider instances I1,
I3,I4, and I6from Fig. 2. For changed (”biased”) in-
stances, this approach is not applicable. One alternative
would be to maintain a complete schema for each biased in-
stance, another to materialize instance-specific schemes on
the fly. We follow a hybrid approach: For each biased in-
stance we maintain a minimal substitution block that cap-
tures all changes applied to it so far. This block is then
used to overlay parts of the original schema when access-
ing the instance (I2and I5in Fig. 2).
3. Demo Description
In our prototype the effects of ad-hoc instance modifi-
cations can be visualized by a special monitoring compo-
nent. The same applies for process type changes (cf. Fig.
3). Users define a new process type by introducing a re-
spective process template. Based on such a template new in-
stances can be created and new schema versions be derived;
Fig. 3 shows version V2of an online ordering process. Af-
ter committing the change, the system automatically checks
compliance conditions and reports migration results to the
user (cf. Fig. 3). This report summarizes which instances are
compliant with the new schema version. For non-compliant
instances the report indicates state-related (I3in Fig. 3) or
structural conflicts (I2in Fig. 3).
Fig. 3 also illustrates the interplay between type and in-
stance changes: I2has been individually modified. Due to a
structural conflict, it cannot be migrated to the new schema
version and therefore remains running on the old one.
online order, version V2
I1 running on version V2
I2 running on version V1
I3 running on version V1
conflict info
efficient migration
(ad-hoc modified)
Figure 3.
ADEPT Prototype: Migration Process
ADEPT2 is one of the few available research prototypes
for adaptive, high-performance process management. In or-
der to gain usability experience we have deployed this sys-
tem to different research groups [3, 4]. They have used it
as platform for realizing advanced PAIS in domains like e-
health and e-business. The experiences made have helped us
to refine our conceptual framework and to develop new sys-
tem components with advanced programming interfaces.
References
[1] M. Reichert, P. Dadam:
ADEPT
flex
– Supporting Dynamic
Changes of Workflows Without Losing Control.
JIIS 10(2):
93–120 (1998).
[2] S. Rinderle, M. Reichert, P. Dadam:
Flexible Support Of
Team Processes By Adaptive Workflow Systems.
Distributed
and Parallel Databases, 16(1):91–116 (2004).
[3] S. Bassil, R. Keller, P. Kropf:
A Workflow-oriented System
Architecture for the Management of Container Transporta-
tion.
Proc. BPM’04, Potsdam, June 2004, pp. 116–131.
[4] R. M¨
uller, U. Greiner, E. Rahm:
AgentWork: A Workflow
System Supporting Rule-based Workflow Adaptation.
Data
& Knowledge Engineering, 51(2): 223–256.
Proceedings of the 21st International Conference on Data Engineering (ICDE 2005)
1084-4627/05 $20.00 © 2005 IEEE
