Flexible Data Acquisition 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 completion. While this holds the promise of more flexible processes, the addition of the data perspective results in increased com- plexity. Therefore, data-centric approaches must be able to cope with the increased complexity, while still fulfilling the promise of more flexible pro- cesses. 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 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. 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 must enable the flexibility of data-centric processes, while still being able to manage the increased complexity. Object-aware process management [11] is a data-centric approach that aims to address this challenge. In the object-aware approach, business data is held in attributes. Attributes are grouped into objects, which represent logical entities in real-world business processes, e.g., a loan application or a job offer. Each object 113 has an associated lifecycle process that describes which attribute values need to be present for successfully processing the object. Lifecycle processes adopt a modeling concept that resembles an imperative style, i.e., the model specifies the default order in which attribute values are required. Studies have indicated that imperative models posses advantages in understandability when compared to declarative models, which are known for flexibility [14]. 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 are rather rigid. However, in object-aware process management, the operational se- mantics of lifecycle processes allow for data to be entered at any point in time, while 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 [10]. This paper expands upon this work and contributes extended functionality and the technical im- plementation of the operational semantics, provided in the PHILharmonicFlows prototype. This technical implementation is based on the process rule frame- work, a lightweight, 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 allows for, i.e., correct lifecycle process execution is ensured. The process rule framework will further provide the foundation for implementing the execution semantics of semantic re- lationships and coordination processes, the object-aware concept for coordinating objects and their lifecycle processes [16]. With the transition of PHILharmon- icFlows to a hyperscale architecture [2], the process rule framework is fully com- patible with the use of microservices, enabling a highly concurrent execution of 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 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 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 busi- ness process management. Object-aware process management distinguishes design- time 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 114 the purpose 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 [11]. The “dot” notation is used to describe paths, e.g., for accessing the name of a particular object instance. ⊥ describes the undefined value. 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 gener- ated. – 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 , Tin I I , Tout , P I , λ, µγ , dγ ) where • φI ∈ ω 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 ∈ Σ I is the state instance to which this step instance γ I belongs. I • Tin ⊂ TσI is the set of incoming transition instances τin I . I I I • Tout ⊂ Tσ is the set of outgoing transition instances τout . • 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 . 115 – T I is a set of transition instances τ I , with τ I = (γsource I I , γtarget , ext, p, µτ ) where I • γsource ∈ Γ is the source step instance. I • γtarget ∈ Γ is the target step instance. I • ext := γsource .σ I = γtarget I .σ I is a computed property, denoting the tran- sition 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 = (σsource I I , σtarget , µψ ) where I I • σsource ∈ Σ is the source state instance. I • σtarget ∈ Σ I is the target state instance, σtarget I ∈ Predecessors(σsourceI ). • µψ 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 PHIL- harmonicFlows authorization system and its connection to form auto-generation has been discussed in [1]. I I As depicted in Figure 1, the state σInitialized contains steps γAmount and I I I γDate , signifying that values for attributes φAmount and φ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 I step in Figure 1. The form corresponding to σInitialized contains input fields for I I steps γAmount and γDate . 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 I to the authorization system of PHILharmonicFlows. In state σDecision , a decision I step γApproval represents the approval of the bank for the money transfer. The I automatically generated form displays γApproval as a drop-down field. End states I I σApproved and σ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. 116 Bank Transfer - Initialized Form Amount Form Field Date Bank Transfer - Decision Comment Approved Submit Submit Attributes Approved State generates Predicate Step generates Object Amount : Integer Initialized Decision Approval Date : Date Amount Date $Approval == true Transfer $Approval == false Rejected Approval : Bool Lifecycle Process Comment : String External Transition Step Backwards Transition Transition Fig. 1. Example object and lifecycle process of a transfer 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 σ 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 dis- play 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., ensur- ing 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 I determined by its active state σA , i.e., marking σ I .µσ = Activated . Only one I state σ may be active at any point in time. Per default, the form of the active 117 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 I I I σInitialized . If values for steps γAmount and γDate are available (cf. Section 3.2), I I σInitialized may be marked as µσ = Confirmed , and the next state σDecision I may become active, i.e., σDecision .µσ = Activated . Depending on the value of I I I γApproval , either σApproved or σRejected becomes active. As both states are end I states, the execution of θ terminates. The active state possesses a crucial role in the execution of θI , as consequences from data acquisition or decisions are only I evaluated for the active state. For example, providing value true to γApproval I does not trigger the decision, if σInitialized 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 [11]. I For states Successors(σA ), 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γ . I I When setting data value for a step γhasV alue , where the state instance σ has I µσ = Waiting, the data marking of γhasV 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). I States that have already been processed, i.e., P redecessors(σA ), will either have µσ = Confirmed or µσ = Skipped . States with marking µσ = Confirmed 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 con- firmed 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 reactiva- tion 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, 118 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 exam- I ple, if step γAmount of Figure 1 has marking Comment I µγ = Enabled , but γAmount .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 I I σInitialized , form field for γAmount is tagged Fig. 2. Form enriched with execu- with an asterisk, indicating that a value is tion events I mandatory (cf. Figure 2). As soon as the user provides a value for the γAmount I form field , the data marking for γAmount is updated to dγ = Assigned. This I indicates that a value has been successfully provided for γAmount . As a conse- quence, 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 I change in a cascading fashion, until the next step γData receives µγ = Enabled. I The data marking γDate .dγ = U nassigned triggers the same chain of events and I marking changes as with γAmount . To illustrate the automatic handling of preallocated data values, it is as- I sumed that another user has already provided value false for γApproval in state I I I σDecision , i.e., γApproval .dγ = Preallocated holds. As σDecision is not currently the I active state (i.e., µσ = Waiting), decision step γApproval is not evaluated. When I I reaching γApproval from γDate 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. Conse- I quently, the completion event for providing a value is omitted. As γApproval is a I decision step, value false subsequently leads to the activation of state σRejected (cf. Figure 1), in which θI terminates. Note that the end state remains active 119 despite the termination of the lifecycle process instance. In general, the oper- ational 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 termi- I nated and σRejected is the active state, a user decides he wants to revise his I decision for approval and thus change the value of γApproval from false to I true. After σRejected had become active, two backwards transition instances ψTI oInit and ψTI oDec became confirmable, i.e., their marking changed to µψ = Confirmable. 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 I σInitialized , using ψTI oInit , or go back to σDecision , using ψTI oDec . However, I Rejected only one state may be active at once. Therefore, only one backwards tran- sition may be taken. To revise the I To State Initialized To State Decision value of γApproval , ψ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θ . Subse- I quently, σRejected is marked as µσ = I W aiting and σDecision is marked as I I µσ = Activated, which allows altering the value of γApproval to true. As σRejected I I is no longer active, ψT oInit and ψT oDec become marked as µψ = Waiting. Re- setting the markings of both ψTI oInit , ψTI oDec , and σRejected I to Waiting enables I their reuse, e.g., if the value of γApproval remains unchanged and the same path is taken again. I With state σDecision becoming active again, it is possible to change the value I of σApproval . 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 120 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, signifi- cantly 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 se- mantics of lifecycle processes. The technical implementation of these operational semantics with the Process Rule Framework is presented in Section 4. 4 The Process Rule Framework In the description of the operational semantics of lifecycle processes, at the low- est 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 PHILharmon- icFlows, 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. Further- more, 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 ∈ σ 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 pR has the form (, eT , C R , 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 . – C R is a set of preconditions in regard to eT . – AR is a set of effects. 121 Process rules pR may be evaluated, i.e., their preconditions C R 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 C R 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 I τout ∈ γ I .Tout I . Fig. 4. Fluent interface definition of a marking rule in code 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). 122 Rule Abbreviation Event Preconditions Effects Marking Rule MR Marking Event Markings Markings Request Rule QR Marking Event Markings Request Event Completion Rule CR Marking Event Markings Completion Event Invalidation Rule IR Marking Event Markings Invalidation Event Reaction Rule RR User Input Event User Input Markings Table 1. Overview over the types of process rules 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. Forms 5 Static form data and execution events Data (Attribute Values, Transition Cobfirmations,..) 1 Execution Event Storage Eθ AttributeValueRequestEvent AttributeValueRequestEvent Request events AttributeValueRequestEvent 4 Process Rule Manager TransitionConfirmRequestEvent Completion/invalidation events User input events Reaction rule application Marking events Cascading rule application Marking rule application 2 3 State State State Step Step Step Step Step Object Fig. 5. Process rule manager and schematic process rule application 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 123 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 immedi- ately which form field is required next after providing data for a form field. Long processing times are prohibitive for the usability of the PHILharmonicFlows sys- tem. 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 example, an event eτ triggering the transition τ I from a source state σsource I I to a target state σtarget is, under certain circumstances, raised before all steps γ I ∈ σsource I .Γ I have been processed. This results in errors in the application I of the process rules, as the target state σtarget already received µσ = Activated I I I when events from γ ∈ σsource .Γ arrive at the PRM. To prevent such errors, the handling of the state transition event eτ must be delayed until all steps γ I I in the source state σsource 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 PHILharmon- icFlows 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 archi- tecture [2], based on a microservice framework. A microservice is a lightweight and independent service that performs single functions and interacts with other microservices in order to realize a software application. In this new hyperscale 124 architecture, an object and its lifecycle process are implemented as a single microservice. A continued use of a single PRM instance generates a significant performance overhead due to the necessary message exchanges between the PRM and the microservices. The single PRM instance is a bottleneck and puts a limit on the scalability of the microservice-based architecture, i.e., it would no longer be warranted to designate the PHILharmonicFlows system as hyperscale. Fur- thermore, the communication overhead and the delays of process rule application in the PRM, due to the high number of events simultaneously created by the object instance microservices, would negatively affect the performance of the auto-generated forms. Fortunately, the lightweight nature of the PRM offers a satisfactory solution. By integrating an instance of the PRM into the microservice of each object in- stance, 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 dis- playing dynamic forms while retaining the hyperscale property of the PHILhar- monicFlows microservice-based architecture. The approach to integrate a PRM instance into a microservice will also be used with the implementation of coor- dination processes, where it will provide the same benefits. 5 Related Work Opus [5,7] is a data-centric process management system that bases its processes on Petri nets. Petri nets are a popular and well-established formalism for model- ing business processes. Additionally, Petri nets provide several verification tech- niques, e.g., soundness checks or deadlock detection, which may also be applied to verify process model correctness. In Opus, the Petri net formalism is extended with structured data tuples, which substitute the places of a standard Petri net. The transitions of this extended Petri net provide operations on the data, e.g., operations derived from operations of relational algebra. The Opus approach does not support automatically generating forms from process models. Further- more, Petri nets are inherently more rigid in their execution and do provide the same built-in flexibility as PHILharmonicFlows and the operational semantics of lifecycle processes. However, Opus is capable to explicitly model the different execution paths to provide flexible process execution. Opus provides an imple- mented prototype [6]. Case Handling [15,17] defines a case in terms of activities and data objects. Activities are ordered in an acyclic graph in which edges represent precedence relations. To execute an activity, all precedence relations before the activity must be fulfilled. Furthermore, the execution of an activity is restricted by data bindings. A data binding represents a condition so that a data object must have a specific value at run-time. The values of the data objects are acquired by forms, which are associated with activities. While case handling possesses forms, it is unclear whether these can be auto-generated from the activities or must 125 be created manually. While both case handling and PHILharmonicFlows use an acyclic graph to represent processes, the operational semantics for lifecycle processes in PHILharmonicFlows allows for data to be acquired at any point in time. A case acquires data by activities and that activities have a precedence relation, the same flexibility in regard to data acquisition is not possible. The Guard-Stage-Milestone (GSM) meta-model [9] is a declarative notation for specifying artifact-centric processes [3,8,12]. An artifact consists of an infor- mation model, i.e., attributes and a lifecycle model. The lifecycle model is spec- ified using GSM. Its operational semantics are based on Precedent-Antecedent- Consequent rules and possess different, equivalent formulations [4]. In GSM, tasks provide the means to write attributes and acquire data. As a declarative language, guards, stages and milestones may be used in such a way that flex- ible data acquisition, within certain constraints, becomes possible. Tasks may be defined so that attributes may be written at any point in time and may be restricted, if necessary. Lifecycle processes defined in GSM are able to react to the newly acquired data and may be more flexible than lifecycle processes in PHILharmonicFlows. However, as a drawback much of this flexibility in data acquisition must be implemented by the process modeler. Furthermore, the is no auto-generation of forms from GSM-specified lifecycle models within the artifact- centric approach. 6 Summary and Outlook The technical implementation of the operational semantics of object-aware pro- cess 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. Sec- ond, a performant, efficient and lightweight technical basis for enacting lifecycle processes and coordination processes is crucial for the transition of PHILhar- monicFlows to a hyperscale architecture. The operational semantics of lifecycle processes provide a flexible acquisition of data, while modeling efforts are mini- mal 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 seman- tics. The model of the lifecycle process and the operational semantics together provide the means to auto-generate dynamic forms. References 1. Andrews, K., Steinau, S., Reichert, M.: Enabling Fine-grained Access Control in Flexible Distributed Object-aware Process Management Systems. In: 21st IEEE Int’l Conf. on Enterprise Distributed Object Computing (EDOC) (2017) 126 2. Andrews, K., Steinau, S., Reichert, M.: Towards Hyperscale Process Management. In: 8th Int’l Workshop on Enterprise Modeling and Information Systems Architec- tures (EMISA). pp. 148–152. CEUR Workshop Proceedings, CEUR-WS.org (2017) 3. Cohn, D., Hull, R.: Business Artifacts: A Data-centric Approach to Modeling Busi- ness Operations and Processes. Bulletin of the IEEE Computer Society Technical Committee on Data Engineering 32(3), 3–9 (2009) 4. Damaggio, E., Hull, R., Vaculín, R.: On the Equivalence of Incremental and Fix- point Semantics for Business Artifacts with Guard–Stage–Milestone Lifecycles. In- formation Systems 38(4), 561–584 (2013) 5. Haddar, N., Tmar, M., Gargouri, F.: A Framework for Data-Driven Workflow Man- agement: Modeling, Verification and Execution. In: 24th Int’l Conf. on Database and Expert Systems Applications (DEXA). vol. 8055, pp. 239–253. Springer (2013) 6. Haddar, N., Tmar, M., Gargouri, F.: Opus framework: A Proof-of-Concept Imple- mentation. In: IEEE/ACIS 14th Int’l Conf. on Computer and Information Science (ICIS). pp. 639–641 (2015) 7. Haddar, N., Tmar, M., Gargouri, F.: A Data-centric Approach to Manage Business Processes. Computing 98(4), 375–406 (2016) 8. Hull, R., Damaggio, E., de Masellis, R., Fournier, F., Gupta, M., Heath,III, Fenno Terry, Hobson, S., Linehan, M., Maradugu, S., Nigam, A., Sukaviriya, P.N., Vac- ulín, R.: Business Artifacts with Guard-Stage-Milestone Lifecycles: Managing Ar- tifact Interactions with Conditions and Events. In: 5th ACM Int’l Conf. on Dis- tributed Event-based System (DEBS), 2011. pp. 51–62. ACM (2011) 9. Hull, R., Damaggio, E., Fournier, F., Gupta, M., Heath,III, Fenno Terry, Hobson, S., Linehan, M., Maradugu, S., Nigam, A., Sukaviriya, P.N., Vaculín, R.: Introduc- ing the Guard-Stage-Milestone Approach for Specifying Business Entity Lifecycles. In: 7th Int’l Workshop on Web Services and Formal Methods (WS-FM) 2010. Lec- ture Notes in Computer Science, vol. 6551, pp. 1–24. Springer (2011) 10. Künzle, V., Reichert, M.: A Modeling Paradigm for Integrating Processes and Data at the Micro Level. In: 12th Int’l Working Conf. on Business Process Modeling, Development and Support (BPMDS). pp. 201–215. Lecture Notes in Business In- formation Processing, Springer (2011) 11. Künzle, V., Reichert, M.: PHILharmonicFlows: Towards a Framework for Object- aware Process Management. Journal of Software Maintenance and Evolution: Re- search and Practice 23(4), 205–244 (2011) 12. Nigam, A., Caswell, N.S.: Business Artifacts: An Approach to Operational Speci- fication. IBM Systems Journal 42(3), 428–445 (2003) 13. Pesic, M., Schonenberg, H., van der Aalst, W.M.P.: DECLARE: Full Support for Loosely-Structured Processes. In: 11th IEEE Int’l Conf. on Enterprise Distributed Object Computing (EDOC). p. 287 (2007) 14. Pichler, P., Weber, B., Zugal, S., Pinggera, J., Mendling, J., Reijers, H.A.: Imper- ative versus Declarative Process Modeling Languages: An Empirical Investigation. In: Business Process Management Workshops: BPM 2011 Int’l Workshops, Revised Selected Papers, Part I. pp. 383–394. Springer (2012) 15. Reijers, H.A., Rigter, J.H.M., van der Aalst, W.M.P.: The Case Handling Case. International Journal of Cooperative Information Systems 12(03), 365–391 (2003) 16. Steinau, S., Künzle, V., Andrews, K., Reichert, M.: Coordinating Business Pro- cesses Using Semantic Relationships. In: 19th IEEE Conf. on Business Informatics (CBI). pp. 33–43. IEEE Computer Society Press (2017) 17. van der Aalst, W.M.P., Weske, M., Grünbauer, D.: Case Handling: A New Paradigm for Business Process Support. Data & Knowledge Engineering 53(2), 129–162 (2005) 127