Executing Lifecycle Processes
in Object-aware Process Management
Sebastian Steinau, Kevin Andrews, and Manfred Reichert
Institute of Databases and Information Systems, Ulm University, Germany
{sebastian.steinau,kevin.andrews,manfred.reichert}@uni-ulm.de
Abstract. Data-centric approaches to business process management, in
general, no longer require specific activities to be executed in a certain
order, but instead data values must be present in business objects for a
successful process completion. While this holds the promise of more flex-
ible processes, the addition of the data perspective results in increased
complexity. Therefore, data-centric approaches must be able to cope with
the increased complexity, while still fulfilling the promise of high process
flexibility. Object-aware process management specifies business processes
in terms of objects as well as their lifecycle processes. Lifecycle processes
determine how an object acquires all necessary data values. As data val-
ues are not always available in the order the lifecycle process of an object
requires, the lifecycle process must be able to flexibly handle these devia-
tions. Object-aware process management provides operational semantics
with built-in flexible data acquisition, instead of tasking the process mod-
eler with pre-specifying all execution variants. At the technical level, the
flexible data acquisition is accomplished with process rules, which effi-
ciently realize the operational semantics.
Keywords: lifecycle execution, data-centric processes, flexible data ac-
quisition, process rules
1 Introduction
Data-centric modeling paradigms part with the activity-centric paradigm, and
instead base process modeling and enactment on the acquisition and manip-
ulation of business data. In general, a data-centric process no longer requires
certain activities to be executed in a specific order for successful completion.
Instead certain data values must be present, regardless of the order in which
they are acquired. Activities and decisions consequently rely on data conditions
for enactment, e.g., an activity becomes executable once required data values
are present. While this holds the promise of vastly more flexible processes in
theory, it is no sure-fire success. The increased complexity from considering the
data perspective in addition to the control-flow perspective requires a thoughtful
design of any approach for modeling and enacting data-centric processes. This
design should enable the flexibility of data-centric processes, while still being
able to manage the increased complexity.
2 Sebastian Steinau, Kevin Andrews, and Manfred Reichert
Object-aware process management [16] is a data-centric approach to busi-
ness process support that aims to address this challenge. In the object-aware
approach, business data is held in attributes. Attributes are grouped into ob-
jects, which represent logical entities in real-world business processes, e.g., a
loan application or a job offer. Each object has an associated lifecycle process
that describes which attribute values need to be present for successfully process-
ing the object. Lifecycle processes adopt a modeling concept that resembles an
imperative style, i.e., the model specifies the default order in which attribute val-
ues are required. Studies have indicated that imperative models show advantages
concerning understandability compared to declarative models, which are known
for flexibility [11, 20]. While the imperative style allows for an easy modeling
of lifecycle processes, it seemingly subverts the flexibility promises of the data-
centric paradigms, as imperative models tend to be rather rigid [25]. However,
in object-aware process management, the operational semantics of lifecycle pro-
cesses allow data to be entered at any point in time, while still ensuring correct
process execution. The imperative model provides only the basic structure. This
has the advantage that modelers need not concern themselves with modeling
flexible processes, instead the flexibility is built into the operational semantics
of lifecycle processes.
The functional specifications of the operational semantics of lifecycle pro-
cesses have partially been presented in previous work [15]. This paper expands
upon this work and contributes extended functionality and the technical im-
plementation of the operational semantics, provided in the PHILharmonicFlows
prototype. In particular, the logic involving execution events has been completely
redesigned to include completion and invalidation events. These event types be-
came necessary as otherwise the consistency of the lifecycle process was not
guaranteed. Further, decision making in lifecycle processes has been improved
by redesigning the data-driven operational semantics of decisions.
The technical implementation is based on the process rule framework, a light-
weight, custom process rule engine. The framework is based on event-condition-
action (ECA) rules, which enable reacting to every contingency the functional
specification of the operational semantics permit, i.e., correct lifecycle process
execution is ensured. The process rule framework will further provide the founda-
tion for implementing the operational semantics of semantic relationships and
coordination processes, the object-aware concept for coordinating objects and
their lifecycle processes [23]. Such a coordination is necessary, as objects inter-
act and thereby form large process structures, constituting an overall business
process [22]. As such, coordination processes enable collaborations of concur-
rently running lifecycle processes, having the advantage of separating lifecycle
process logic and coordination logic. With the transition of PHILharmonicFlows
to a hyperscale architecture [2], the process rule framework is fully compatible
with the use of microservices, enabling a highly concurrent execution of multiple
lifecycle processes with large numbers of user interactions.
The remainder of the paper is organized as follows: Section 2 provides the
fundamentals of object-aware process management. In Section 3, the extended
Executing Lifecycle Processes in Object-aware Process Management 3
operational semantics are presented. The process rule framework at the core
of the operational semantics implementation is described in Section 4. Finally,
Section 5 discusses related work, whereas Section 6 concludes the paper with a
summary and an outlook.
2 Fundamentals
Object-aware process management organizes business data in form of objects,
which comprise attributes and a lifecycle process describing object behavior.
PHILharmonicFlows is the implementation of the object-aware concept to pro-
cess management. Object-aware process management distinguishes design-time
entities, denoted as types (formally T), and run-time entities, denoted as in-
stances (formally I). Collectively, they are referred to as entities. At run-time,
types may be instantiated to create one or more corresponding instances. For
the purposes of this paper, object instance (cf. Definition 1) and lifecycle process
instance (cf. Definition 2) definitions are required. The corresponding type defi-
nitions can be found in [16]. The “dot” notation is used to describe paths, e.g.,
for accessing the name of an object instance. ⊥describes the undefined value.
Definition 1. (Object Instance)
An object instance ωIhas the form (ωT, n, ΦI, θI)where
–ωTrefers to the object type from which this object instance has been gener-
ated.
–nis the name of the object instance.
–ΦIis a set of attribute instances φI, where φI= (n, κ, vκ), with nas the
attribute instance name, κas the data type (e.g., String, Boolean, Integer),
and vκas the typed value of the attribute instance.
–θIis the lifecycle process (cf. Definition 2) describing object behavior.
An object’s lifecycle process (cf. Definition 2) is responsible for acquiring
data values for the attributes of the object.
Definition 2. (Lifecycle Process Instance)
Alifecycle process instance θIhas the form (ωI, ΣI, Γ I, TI, ΨI, Eθ, µθ)
where
–ωIrefers to the object instance to which this lifecycle process belongs.
–ΣIis a set of state instances σI, with σI= (n, Γ I
σ, TI
σ, ΨI
σ, µσ)where
•nis the state name.
•ΓI
σ⊂ΓIis subset of steps γI.
•TI
σ⊂TIis a subset of transitions τI.
•ΨI
σ⊂ΨIis a subset of backwards transitions ψI.
•µσis the state marking.
–ΓIis a set of step instances γI, with γI= (φI, σI, T I
in, T I
out, P I, λ, µγ, dγ)
where
4 Sebastian Steinau, Kevin Andrews, and Manfred Reichert
•φI∈ωI.ΦIis an optional reference to an attribute instance φIfrom ΦI
of object instance ωI. Default is ⊥.
If φI=⊥, the step is denoted as an empty step instance.
•σI∈ΣIis the state instance to which this step instance γIbelongs.
•TI
in ⊂TI
σis the set of incoming transition instances τI
in.
•TI
out ⊂TI
σis the set of outgoing transition instances τI
out.
•PIis a set of predicate step instances ρI,PImay be empty, with
ρI= (γI, λ)where
∗γIis a step instance.
∗λis an expression representing a decision option.
If PI6=∅, the step instance γIis called a decision step instance.
•λis an optional expression representing a computation.
If λ6=⊥, the step instance γIis called a computation step instance.
•µγis the step marking, indicating the execution status of γI.
•dγis the step data marking, indicating the status of φI.
–TIis a set of transition instances τI, with τI= (γI
source , γI
target ,ext, p, µτ)
where
•γI
source ∈Γis the source step instance.
•γI
target ∈Γis the target step instance.
•ext := γI
source .σI=γI
target .σIis a computed property, denoting the tran-
sition as external, i.e., it connects steps in different states.
•pis an integer signifying the priority of the transition.
•µτis the transition marking.
–ΨIis a set of backwards transition instances ψI,ΨImay be empty, with
ψI= (σI
source , σI
target , µψ)where
•σI
source ∈ΣIis the source state instance.
•σI
target ∈ΣIis the target state instance, σI
target ∈Predecessors(σI
source ).
•µψis the backwards transition marking.
–Eθis the event storage for θI, storing execution events E.
–µθis the lifecycle process marking.
All sets are finite and must not be empty unless specified otherwise. The function
Predecessors:σI→ΣIdetermines a set of states from which σIis reachable.
The function Successors is defined analogously.
Note that for the sake of brevity the value of a step γIrefers to the value of
the corresponding attribute γI.φI. Furthermore, correctness criteria have been
omitted from Definitions 1 and 2. For the sake of clarity, a lifecycle process
is described by a directed acyclic graph with one start state and at least one
end state. Figure 1 shows object instance Bank Transfer with its attributes and
lifecycle process. The object instance represents a simplified transfer of money
from one account to another.For this purpose, the states and the steps of a
lifecycle process can be used to automatically generate forms. This is unique for
process management systems, as in other systems, forms must still be designed
manually, leading to a huge difference regarding productivity [25]. Additionally,
when executing a process, the auto-generated forms are filled in by authorized
users. The PHILharmonicFlows authorization system and its connection to form
Executing Lifecycle Processes in Object-aware Process Management 5
auto-generation has been discussed in [1]. In essence, forms may be personalized
automatically based on the user’s permissions, no different form designs showing
different form fields are necessary.
Bank Transfer - Decision
Bank Transfer - Initialized
RejectedRejected
ApprovedApproved
DecisionDecisionInitializedInitialized
Amount : IntegerAmount : IntegerAmount : Integer
Date : DateDate : DateDate : Date
Approval : BoolApproval : BoolApproval : Bool
Comment : StringComment : StringComment : String
ObjectObject
AttributesAttributes
Lifecycle
Process
Lifecycle
Process
StateState
StepStep
Predicate StepPredicate Step
Backwards TransitionBackwards Transition
TransitionTransition
Amount
Date
Submit
Comment Approved
generates generates
Submit
FormForm Form FieldForm Field
External TransitionExternal Transition
TransferTransfer AmountAmount DateDate
Approval
[Approval] == true[Approval] == true
[Approval] == false[Approval] == false
Approval
[Approval] == true
[Approval] == false
Fig. 1. Example object and lifecycle process of a Transfer
As depicted in Figure 1, the state σI
Initialized contains steps γI
Amount and
γI
Date, signifying that values for attributes φI
Amount and φI
Date are required during
process execution. For the sake of brevity, the properties of an entity (e.g., the
name of a step γ) may be written as a subscript, e.g., γAmount for the first
step in Figure 1. The form corresponding to σI
Initialized contains input fields for
steps γI
Amount and γI
Date. This means a state represents a form, whereas the steps
represent form fields. The φI
Comment field is an optional field visible to a user due
to the authorization system of PHILharmonicFlows. In state σI
Decision, a decision
step γI
Approval represents the approval of the bank for the money transfer. The
automatically generated form displays γI
Approval as a drop-down field. End states
σI
Approved and σI
Rejected display an empty form, as the contained steps are empty
(cf. Definition 2). Transitions determine at run-time which attribute value is
required next, an external transition also determines the next state. Backwards
transitions allow returning to a previous state, e.g., to correct a data value.
3 Lifecycle Process Operational Semantics
Data acquisition in PHILharmonicFlows is achieved through forms, which can
be auto-generated from lifecycle process models θI. A form itself is mapped to a
state σIof the lifecycle process θI; form fields are mapped to steps γI. In conse-
quence, the operational semantics of lifecycle processes emulate the behavior of
electronic and paper-based forms, following a “best of both worlds” approach.
Loading more pages...