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 completion. While this holds the promise of more flexible 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 more flexible processes. 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 values are not always available in the order the lifecycle process of an object requires, the lifecycle process must be able to flexibly handle these deviations. Object-aware process management provides operational semantics with flexible data acquisition built into it, instead of tasking the process modeler with pre-specifying a flexible process. At the technical level, the flexible data acquisition is accomplished with process rules.
Data-centric modeling paradigms part with the activity-centric paradigm and instead base process modeling and enactment on the acquisition and manipulation 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 must enable the flexibility of data-centric processes, while still being able to manage the increased complexity.
Object-aware process management [
The functional specifications of the operational semantics of lifecycle
processes have partially been presented in previous work [
The remainder of the paper is organized as follows. Section 2 provides the fundamentals of object-aware process management. In Section 3, the extended operational semantics are presented. The process rule framework at the core of the operational semantics implementation is discussed in Section 4. Finally, Section 5 elaborates on related work, whereas Section 6 concludes the paper with a summary and an outlook. 2
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
business process management. Object-aware process management distinguishes
designtime entities, denoted as types (formally T ), and run-time entities, denoted as
instances (formally I ). Collectively, they are referred to as entities. At run-time,
types can be instantiated to create one or more corresponding instances. For
the purpose of this paper, object instance (cf. Definition 1) and lifecycle process
instance (cf. Definition 2) definitions are required. The corresponding type
definitions can be found in [
Definition 1. An object instance !I has the form (!T ; n; I ; I ) where the following definitions hold: – !T refers to the object type from which this object instance has been generated. – n is the name of the object instance. – I is a set of attribute instances I , where I = (n; ; v ), with n as the attribute instance name, as the data type (e.g., string, bool, integer), and v as the value of the attribute instance. – I is 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. A lifecycle process instance I has the form (!I ; I ; I ; T I ; I ; E ; ) where the following definitions hold: – !I refers to the object instance to which this lifecycle process belongs. – I is a set of state instances I , with I = (n; I ; T I ; I ; ) where n is the state name.
I I is subset of steps I .
T I T I is a subset of transitions I .
I I is a subset of backwards transitions I .
is the state marking. – I is a set of step instances I , with I = ( I ; I ; TiIn; ToIut; P I ; ; ; d ) where
I 2 !I : I is an optional reference to an attribute instance I from I of object instance !I . Default is ?.
If I = ?, the step is denoted as an empty step instance.
I 2 I is the state instance to which this step instance I belongs. TiIn T I is the set of incoming transition instances iIn.
ToIut T I is the set of outgoing transition instances oIut.
P I is a set of predicate step instances I , P I may be empty, with I = ( I ; ) where
I is a step instance.
is an expression representing a decision option.
If P I 6= ;, the step instance I is called a decision step instance.
is an optional expression representing a computation.
If 6= ? , the step instance I is 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 . – T I is a set of transition instances I , with I = ( sIource ; tIarget ; ext ; p; ) where sIource 2 is the source step instance.
tIarget 2 is the target step instance. ext := sIource : I = tIarget : I is a computed property, denoting the transition as external, i.e., it connects steps in different states. p is an integer signifying the priority of the transition.
is the transition marking. – I is a set of backwards transition instances I , I may be empty, with I = ( sIource ; tIarget ; ) where sIource 2 I is the source state instance. tIarget 2 I is the target state instance, tIarget 2 Predecessors ( sIource ).
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 ! I determines a set of states from which I is reachable. The function Successors is defined analogously.
Note that for the sake of brevity the value of a step I refers 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 attributes and the
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. When executing
a process, the auto-generated forms are filled in by authorized users. The
PHILharmonicFlows authorization system and its connection to form auto-generation
has been discussed in [
DIaAtes, sdigenpiifcytiendg itnhaFtivgaulruees1f,otrhaettsrtibatuetesIInIAitmiaoliuznetdacnodntaIDinatse satreeprsequAIimreodundturainndg 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 IInitialized contains input fields for steps AImount and DIate. This means a state represents a form, whereas the steps represent form fields. The IComment field is an optional field visible to a user due to the authorization system of PHILharmonicFlows. In state DIecision, a decision step AIpproval represents the approval of the bank for the money transfer. The automatically generated form displays AIpproval as a drop-down field. End states
AIpproved and RIejected 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.
Submit
Submit Predicate Step Bank Transfer - Decision Approved
generates Decision
Approval $Approval == true $Approval == false
Approved Rejected Attributes Amount : Integer Date : Date Approval : Bool Comment : String Object Transfer Lifecycle Process
Bank Transfer - Initialized Amount Date
Comment State generates
Initialized Amount
Date Step
Transition
External Transition
Backwards Transition
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 I of the lifecycle process I , form fields are mapped to steps I . As a consequence, the operational semantics emulate the behavior of electronic and paper-based forms, following a “best of both worlds”-approach. Paper-based forms provide a great overview over the form fields, i.e., every form field may be viewed at any point in time. Furthermore, they provide a reasonable default structure, but allow filling form fields at any point in time and in any order, e.g., starting to fill in form fields in the middle of the form is possible. In turn, electronic forms usually provide less overview, i.e., viewing subsequent forms is not possible before having filled out all mandatory fields in the current form. In contrast to paper-based forms, however, electronic forms are able to only display relevant fields, especially in context of decision branching. For example, an electronic anamnesis form at a physician’s office may skip the questions related to pregnancy entirely if the patient is male. Additionally, electronic forms allow for data values to be easily changed as well as input verification, e.g., ensuring that a date has the correct format or all mandatory form fields possess a value. PHILharmonicFlows combines the advantages of both paper-based and electronic forms, providing flexibility in entering data while ensuring a correct lifecycle process execution. 3.1
Lifecycle Process Execution For realizing the combined benefits, the progress of a lifecycle process I is determined by its active state AI , i.e., marking I : = Activated . Only one state I may be active at any point in time. Per default, the form of the active state is displayed to a user when executing a lifecycle process I . However, the user may choose to display forms of other states. When processing I , the active state changes, depending on data availability and decision results. For example, in regard to Figure 1, starting the execution of the lifecycle process activates
IInitialized. If values for steps AImount and DIate are available (cf. Section 3.2),
mAIIIanpyiptriboavleiaczloe,dmeimethaaeycrtibveAeI,pmpi.raeor.v,keeddDIoreacsisRIioenj:e=ctedC=boneAccortmmiveeasdte,adca.tniDvdee.pthAeensdnbienoxgtthosnsttaatttheees vDaIarelecuieseinoodnf
states, the execution of I terminates. The active state possesses a crucial role in
the execution of I , as consequences from data acquisition or decisions are only
evaluated for the active state. For example, providing value true to AIpproval
does not trigger the decision, if IInitialized is the currently active state. This
is to avoid inconsistent processing states, e.g., because a previous decision may
make filling out a state I obsolete due to dead-path elimination [
For states Successors ( AI), data values may be entered, but processing only occurs once a state becomes active. All successor states possess marking = Waiting . If a user enters values for steps I , these values will be stored and taken into account if the corresponding state I : I becomes active. To indicate the status of the corresponding attribute value, steps possess a data marking d . When setting data value for a step hIasV alue, where the state instance I has = Waiting , the data marking of hIasV alue is set to d = Preallocated . Should I become active during process execution, d = Preallocated will indicate that a value is present and will not be required anymore (cf. Section 3.2).
States that have already been processed, i.e., P redecessors( AI), will either have = Con rmed or = Skipped . States with marking = Con rmed have previously been active, whereas skipped states have undergone a dead-path elimination. For reasons of data integrity, the values of steps in skipped or confirmed states must not be altered at any point in time. If allowed, inconsistencies and unpredictable execution behavior may occur. For example, changing values of decisions steps in an uncontrolled way might activate currently eliminated states, whereas currently active states become eliminated. However, it must be possible to correct mistakes for previously entered and accidentally confirmed data. Therefore, backwards transitions (cf. Definition 2) allow for the reactivation of confirmed states in a controlled way, where the data may be altered in a consistent and safe way and subsequent changes in decisions can be handled properly. 3.2
State Execution While PHILharmonicFlows is capable of generating forms from states and steps, these forms are static. However, there are dynamic aspects to a form, e.g., the indication which value is required next or which external transition or backwards transition may be committed. For this purpose, a lifecycle process I provides execution events E and an event storage E . Execution events are dynamically created when processing a lifecycle process I . When auto-generating a form, the static form is enriched with dynamic information from E and displayed to the user. Execution events have different subtypes, namely request events, completion events, and invalidation events. When request events are created, they are stored in E and are then used to enrich the form. Completion and invalidation events remove request events from E , when a request event are either fulfilled or no longer valid, respectively. The usage of the event storage E in conjunction with the generated static forms allows multiple users access to the same form, due to the centralized storage of the dynamic form data. Using E further allows preserving dynamic data over multiple sessions, i.e., a user may partially fill out a form, close it and do something else, and later return and continue where the user previously stopped. It is also possible that another user finishes filling out the form. In general, storing execution events E ensures consistency regardless of any user interaction with the forms.
The creation and removal of execution events is primarily determined by the respec- Bank Transfer - Initialized tive marking of states, steps, transitions, Amount* and backwards transitions. For steps with an attribute (i.e., I : I 6= ?), data mark- Date ing d is also taken into account. For example, if step AImount of Figure 1 has marking Comment
= Enabled , but AImount:d = Unassigned holds, an attribute value request event is cre- Submit ated and stored in E after some intermediate processing steps. If a user access the form for
IInitialized, form field for AImount is tagged Fig. 2. Form enriched with execuwith an asterisk, indicating that a value is tion events fmoramndfiateoldry, (tchf.e Fdiagtuarem2a)r.kAinsgsofoorn aAIsmtohuentusiesrupprdoavtieddestao vdalu=e fAorsstihgenedAI.mTouhnist indicates that a value has been successfully provided for AImount. As a consequence, the attribute value request event in E is no longer necessary. Therefore, setting d = Assigned triggers a completion event removing the attribute value request event from E . After the completion event has occurred, more markings change in a cascading fashion, until the next step DIata receives = Enabled. The data marking DIate:d = U nassigned triggers the same chain of events and marking changes as with AImount.
To illustrate the automatic handling of preallocated data values, it is assumed that another user has already provided value false for AIpproval in state
DIecision, i.e., AIpproval:d = Preallocated holds. As DIecision is not currently the active state (i.e., = Waiting ), decision step AIpproval is not evaluated. When reaching AIpproval from DIate after a state change and is marked with = Enabled , no attribute value request event is created due to d = Preallocated . Instead, the data marking is immediately changed to d = Assigned. Consequently, the completion event for providing a value is omitted. As AIpproval is a decision step, value false subsequently leads to the activation of state RIejected (cf. Figure 1), in which I terminates. Note that the end state remains active despite the termination of the lifecycle process instance. In general, the operational semantics of lifecycle processes ensure that a previously provided value requires no further user interaction by default. However, a user may still change the value afterwards should he wish to do so. Overall, the user may flexibly enter and alter data and the operational semantics ensures data integrity.
Continuing the example, where currently the lifecycle process has terminated and RIejected is the active state, a user decides he wants to revise his decision for approval and thus change the value of AIpproval from false to true. After RIejected had become active, two backwards transition instances
TI oInit and TI oDec became confirmable, i.e., their marking changed to = Con rmable. As a consequence, two backwards transition confirm request events are first created, one for each backwards transition, and then stored in E . This allows going back to state
IInitialized, using TI oInit, or go back to DIecision, using TI oDec. However, Rejected only one state may be active at once.
Therefore, only one backwards transition may be taken. To revise the To State Initialized To State Decision value of AIpproval, TI oDec must be confirmed. Confirming TI oDec causes its marking to change to = Ready .
Analogously to a step, a completion event is created, which removes the corresponding backwards transition Fig. 3. Backwards transitions confirm request event from E . Subsequently, RIejected is marked as =
W aiting and DIecision is marked as = Activated, which allows altering the value of AIpproval to true. As RIejected is no longer active, TI oInit and TI oDec become marked as = Waiting . Resetting the markings of both TI oInit, TI oDec, and RIejected to Waiting enables their reuse, e.g., if the value of AIpproval remains unchanged and the same path is taken again.
With state DIecision becoming active again, it is possible to change the value of AIpproval. However, the backwards transition confirm request event belonging to TI oInit is still stored in E , despite TI oInit having been marked with = Waiting , i.e., confirming TI oInit is no longer possible. Obviously, this constitutes an inconsistency between the forms and the lifecycle process. The form displays a button with the option that TI oInit can be confirmed, but on pressing the button the PHILharmonicFlows system produces an error and other, possibly worse, side effects. A a consequence, the operational semantics include invalidation events, with the purpose to remove invalid or obsolete execution events from event storage E . An invalidation event occurs when entities with a request event, e.g., backwards transitions, are not successfully completed, but become changed due to other circumstances, e.g., the confirmation of another backwards transition.
Request events, completion events, and invalidation events are used in many other situations than discussed above. The principles, however, are the same, and, embedded in the overall operational semantics, provide a robust, but flexible way to acquire data values for lifecycle processes. The imperative-style modeling of lifecycle processes, from which forms can be auto-generated directly, significantly reduces modeling time and efforts. The operational semantics provide the necessary flexibility to users interacting with the forms. Furthermore, the use of forms and the emulation of standard form behavior simplifies the usage of the PHILharmonicFlows system for non-expert users.
Overall, this section described the functional aspects of the operational semantics of lifecycle processes. The technical implementation of these operational semantics with the Process Rule Framework is presented in Section 4. 4
In the description of the operational semantics of lifecycle processes, at the lowest level, progress is driven by the change of markings. Marking changes elicit the creation of execution events, which, in turn, results in user actions, e.g., the provision of a data value for an attribute. This user interaction is reflected in the lifecycle process by setting new markings. This may be viewed as a chain of events, and, consequently, event-condition-action rules are used as the basis for the technical implementation of the operational semantics. In PHILharmonicFlows, a specialized variant of ECA rules, denoted as process rules, is employed. Process rules and the means to specify them constitute one part of the process rule framework. To create an execution sequence such as the one described in Section 3.2, process rules need to form process rule cascades, i.e., a rule triggers an event, which may trigger another rule, which again triggers an event. Furthermore, process rules are uniquely suited to deal with the different eventualities emerging during the execution of lifecycle processes. For example, a state I may become active in context of normal process execution progress or due to the use of a backwards transition I . Subsequently, different follow-up measures may be required, e.g., the resetting of markings for steps I 2 I : I in case the backwards transition became activated.
The basic definition of a process rule is shown in Definition 3. In order to distinguish the symbols from symbols used in the definition object instances, superscript R is used.
Definition 3. A process rule pRhas the form ( ; eT ; CR; AR) where the following definitions hold: – is an event triggering the evaluation of the rule. – e is an entity type, e.g., a step type T . – CR is a set of preconditions in regard to eT . – AR is a set of effects.
Process rules pR may be evaluated, i.e., their preconditions CR are checked and, if all are fulfilled, the effects are applied. An evaluation is triggered when the event occurs. Events are always raised by a particular entity instance eI , e.g., a step I or an transition I . eT is an entity type that provides the context for defining conditions and effects. Furthermore, it provides an implicit precondition, meaning a rule is not evaluated if the entity instance eI raising was not created from eT . Preconditions CR check different properties of an entity, e.g., whether the entity has a specific marking. Effects AR apply different effects to an entity, e.g., setting the marking of an entity. Note that preconditions and effects are not limited to properties belonging to instances of eT . They may also access or set properties of neighbor entities. For example, a rule defined for a step T may have effects that set markings for its outgoing transitions oIut 2 I :ToIut.
In the PHILharmonicFlows implementation, process rules are created in code. Figure 4 shows an example of how a process rule is represented in code. Process rules are often subject to change, as new features for PHILharmonicFlows are added or errors in lifecycle process execution are resolved. In order to be able to quickly adapt, the process rule framework uses a fluent interface for process rule specification. This allows for a high readability and maintainability.
The operational semantics introduced in Section 3 allow identifying different use cases for process rules. For example, one type of process rule raises execution events based on specific markings, while another type reacts to user input and sets appropriate markings. Consequently, process rules are subdivided based on their purpose. The type determines the general type of preconditions and effects, e.g., preconditions of marking rules check predominantly for specific markings. The different types of process rules are summarized in Table 1. Request rule, completion rule, and invalidation rule are subsumed with the term execution rule (ER).
IR
RR
The most common event that is raised during the execution of a lifecycle process instance is a marking event. An entity instance eI raises a marking events whenever its marking eI : is changed. In order to determine which process rule needs to be applied, the event is gathered by the process rule manager (PRM) of the lifecycle process. The process rule manager is a small and lightweight execution engine for process rules and constitutes the other part of the process rule framework. Figure 5 shows a schematic view of the process rule manager and its interactions with the lifecycle process and the (auto-generated) forms. Execution Event
Storage Eθ AttributeValueRequestEvent AttributeValueRequestEvent AttributeValueRequestEvent TransitionConfirmRequestEvent
Object
Data (Attribute Values, Transition Cobfirmations,..) 1
Request events 4 Completion/invalidation events State
Cascading rule application
State Step
Reaction rule application Marking rule application 3 State Step
Step
Step
Step
Starting at 1 in Figure 5, data has been entered into a form field. The data is then passed onto the lifecycle process I and the corresponding step I . As I has received a value, the step raises a user input event 2 . The event is passed on to the process rule manager, which receives all events from its corresponding User input events Marking events
2 lifecycle process I and evaluates appropriate rules, i.e., process rules pR with pR:eT = T are not evaluated if the entity creating the event has type T . The implicit precondition significantly reduces the search space for process rule application and must not be specified by a programmer. Once the PRM has identified all currently applicable rules, the effects of each rule are applied. In the example, the PRM identifies a reaction rule and applies its effects to the appropriate entities in the lifecycle process 3 .
Applying the effects from the reaction rule application raises marking events, which trigger a completion rule and a marking rule in the PRM. The completion rule raises a completion event 4 , removing the request event for the mandatory form field from event storage E of I . In parallel, the marking rule sets markings for the outgoing transitions T I of step I . This again creates marking events, resulting in a cascade of marking rules, i.e., the PRM alternates between 2 and 3 in Figure 5. The process rule cascade stops when the next step becomes marked with = Enabled. This raises a request event, which is deposited in event storage E 4 . When a user views a form, the updated event storage E and the static form data is combined into a new form 5 . When the user enters data for the next form field, the cycle starts again at 1 .
When a user fills out a form, the form is expected to tell the user immediately which form field is required next after providing data for a form field. Long processing times are prohibitive for the usability of the PHILharmonicFlows system. In order to have full control over processing times and the tight connection of process rules with lifecycle process entities, it was decided to implement the PRM as a custom, lightweight rule engine. A custom PRM implementation offers a fine-grained control over process rule application. By default, the PRM handles events in the order in which they arrive (FIFO principle). However, in several cases, the handling of specific events needed to be delayed or accelerated in order to ensure a form processing in compliance with the operational semantics. For teoxaamtpalreg,eatnsteavteent tIaergettriigs,geurnindgerthceerttariannsciitricounmsItafnrcoems, arasisoeudrcbeefsotraeteall sIsotuerpces
I 2 sIource: I have been processed. This results in errors in the application of the process rules, as the target state tIarget already received = Activated when events from I 2 sIource: I arrive at the PRM. To prevent such errors, the handling of the state transition event e must be delayed until all steps I in the source state sIource have finished processing. As a consequence, the PRM was extended with a priority queue that retains the FIFO principle, but allows assigning different priorities to events, accelerating or delaying them as needed.
Besides the advantages for the application of process rules, the lightweight
nature of the PRM also proves beneficial for the transition of
PHILharmonicFlows to a microservice-based architecture. The PRM was initially conceived
as a monolithic rule engine, i.e., all lifecycle processes use the same instance of
the PRM. Currently, PHILharmonicFlows is moving towards a hyperscale
architecture [
Fortunately, the lightweight nature of the PRM offers a satisfactory solution. By integrating an instance of the PRM into the microservice of each object instance, no message exchanges between PRM and lifecycle process are required. Furthermore, a PRM instance is only responsible for exactly one lifecycle process instance. This eliminates the delays in rule application due to the processing of other lifecycle processes. This solution offers sufficient performance for displaying dynamic forms while retaining the hyperscale property of the PHILharmonicFlows microservice-based architecture. The approach to integrate a PRM instance into a microservice will also be used with the implementation of coordination processes, where it will provide the same benefits. 5
Opus [
Case Handling [
The Guard-Stage-Milestone (GSM) meta-model [
The technical implementation of the operational semantics of object-aware process management is achieved by process rules, which govern the changing of markings and the creation of execution events. Therefore, Section 4 presents the process rule framework, which is important for two aspects. First, the process rule framework makes sure lifecycle processes execute correctly and also provides the technical basis for the operational semantics of coordination processes in PHILharmonicFlows. Coordination processes, as the name suggests, coordinate lifecycle processes of object, so that complex business processes can be realized. Its operational semantics will also be based on the process rule framework. Second, a performant, efficient and lightweight technical basis for enacting lifecycle processes and coordination processes is crucial for the transition of PHILharmonicFlows to a hyperscale architecture. The operational semantics of lifecycle processes provide a flexible acquisition of data, while modeling efforts are minimal due to an modeling style that is akin to an imperative style. The flexibility is not provided by the lifecycle process model, but by the operational semantics. The model of the lifecycle process and the operational semantics together provide the means to auto-generate dynamic forms.