Changes to the Workflow Schema

Businesses must react quickly on changing market conditions. This means that they have to change their business processes to meet changing business requirements.

Changing business processes must be reflected in the underlying workflow systems.

New activities may be added, old activities may be removed, the control flow (i.e., order and conditions) of the activities may change, and the data dependencies be-tween the activities due to changing input and output of activities may change. In summary, this means changing the workflow structure or, in other words, changing the workflow schema.

Changing the workflow schema requires operations for inserting and deleting activities as well as control/data dependencies between them [31]. The characteristic of completeness refers to the provision of such operations to transform a workflow schema into another one without restricting the user to specify the required changes [7, 31]. It is the goal to provide completeness by a minimal set of operations.

Once a workflow schema is changed it must be guaranteed that the changes do not result in compile-time and run-time errors. The correctness of changes concerns both the workflow schema and the workflow instances. According to these two lev-els, Casati et al. [7] distinguish between structural consistency and behavioral con-sistency. Structural consistency refers to the schema level changes. It implies that after modifications to a schema the resulting schema is valid. Behavioral consis-tency refers to the instance level changes. This addresses the problem of changing a schema at a point in time when instances of that schema are still running. Behavioral consistency implies that applying a set of operations to a running instance of the old schema results in a valid execution of this instance under the new schema. This means the instance evolves without causing run-time errors. Different approaches to reach behavioral consistency have been developed that sometimes differ signifi-cantly in their principal approach and solution. A survey of the different approaches towards consistency of workflow evolutions ensuring its correctness is provided by Rinderle et al. [31].

If a change to the workflow schema of an orchestration O happens resulting in the new workflow schema O’ the following principle approaches may be taken.

• All running instances of O are aborted, and all new instances are started following the schema O’.

• All running instances of O have to terminate following the schema O. No new instances are started until all the running instances of O are completed. Once they are completed, new instances are able to start following the schema O’.

• Running instances of O will complete following the schema O, new instances will start immediately following the schema O’. This requires that both schema versions O and O’ must be supported by the workflow engine at the same time.

• Running instances of the workflow O are transformed according to correctness criteria to become valid instances of O’ and continue running following schema O’.

In the above mentioned case 4, an instance I of schema O must correctly be transformed into an instance I of schema O’. An instance of schema O is also a valid instance of O’ if its resulting state could also have been produced by following schema O’. This is always the case when the running instance of O is still in a phase that was not affected by the change to O’. In other words, the running instance has only passed activities where O and O’ are identical. In case that the running instance has already passed the position of the change, it is necessary to check the execution history of the running instance. If the execution history describes a flow that is a valid flow instance of schema O’, then the instance is compliant and is migrated.

In [30] Rinderle et al. this approach is described—also using a reduced execution history—in more detail.

The previously described situation—where a running instance I of schema O is also a valid instance of O’—is preferred, but not always given. If the instance of I is not a valid instance of O’, the running instance must not be migrated in its current state to the new schema O’. The running instance must first undergo some modifications that guarantee that the instance is compliant to schema O’ [7, 33].

In general, it is necessary to undo some activities that have already been executed by the instance I. The undo may or may not require compensation. Following the reverse execution history one activity is undone after the other until the instance is compliant to schema O’. In the worst case scenario all activities must be undone and the instance starts from the beginning following schema O’.

In order to demonstrate the dynamic schema evolution we assume the following change to the order management example: Given the fact that the seller experiences the fact that some of the buyers get bankrupt, the seller decides to perform a credibil-ity check with a financial institution (F) for purchase orders that exceed an amount of 10,000 Euro. Figure 4.6 displays the change in the order management process.

In the seller’s orchestration a change is made aftercheck against offer. A decision checks whether the amount of the purchase order is above 10,000 by an XPath ex-pression on the variable purchase order (which was instantiated by the previous received call of order product). If so, the sequence of invokingcheck credibility and receivingget credit check is executed. If not, no new activities are executed.

After merging the two alternative paths again, the orchestration continues like in the old schema with the parallel execution ofreserve stockandreserve production line.

In the following we are going to exemplify the different cases of running in-stances of the purchase order management process at the seller:

• All running instances that are in a state up tocheck against offer and have not started reserve stock or reserve production line are transformed into the new

Order Product Seller Buyer

Order Product

S_s S_s

Check against Offer S_A

F F

[else] […/Amount > 10000] Financial Institution

Check credibility

Get Credit Check S_s

Check credibility

Get Credit Check S_s

Reserve Stock Reserve Production Line

S_P S_P

Calculate Delivery Date

Reserve Transport S_P

C

Reserve Transport C Carrier

Confirm Transport

Response To Order Response To Order

S_s

B B

Confirm Transport S_s

Response To Order

Get Status p

Get Status

S_s S_s

Inform on Status Inform on Status

B

B

Fig. 4.6 Changing the order management process

process schema. Since they are in a state before the schema change is effective, they are compliant to the new schema.

• Running instances that have already startedreserve stock orreserve production line passed the area of change. If a process instance handles a purchase order up to an amount of 10,000 Euro, the change does effect the instance. In other words, the flow of activities in the old schema and in the new schema are equiv-alent. No matter in which state the running instance is at the time of the change, the instance is compliant with the new schema and may execute following the new schema. Even if this is trivial in our case, because the remaining steps are identical for the old and the new schema.

• More complicated is the case where a process instance handling an order above 10,000 Euro has already passed the area of change. Assume that a running in-stance has already passed the parallel execution of reserve stock and reserve production line as well as thecalculate delivery dateoperation. In this case it is necessary to undo the mentioned operations. The undo ofcalculate delivery date does not require any measures to be taken—the new delivery date will be cal-culated anyway when the instances executes this operation again. However, the undo ofreserve stock andreserve production linerequires compensation. Thus, compensation handlers must be defined to execute the operations clear resources and deallocate production line, respectively. Note, both compensating operations have already been introduced in Section 4.2 as part of the regular flow. Due to space limitations we do not depict the compensation handlers in Figure 4.6. Hav-ing performed the undo of the three operations, the instance is compliant with the new schema. It now continues following the new schema by the invocation ofcheck credibility.

So far we concentrated on changes to the orchestration of a process. In Sec-tion 4.2 we already introduced the inter-dependencies between orchestraSec-tions and choreographies. Some of the activities within an orchestration may also be part of one or more choreographies involving interactions with business partners. In the discussion up to now we focused on changes that affect only the owner of an orches-tration. However, not all changes may be kept local to the owner of an orchesorches-tration.

Some changes in an orchestration may also affect the interactions with partners in a choreography. This is usually the result of adding, removing, or changing the flow of activities that are provided on the partner’s port which is part of a partner link in a choreography. The evolution of process choreographies is discussed in [32]. The paper provides an approach to calculate the consistency of two local choreographies once one of them is changed. In case of inconsistency the second local choreography must be changed as well. Since business partners interacting in a choreography must be considered as autonomous, an automatic adaptation of the second local choreog-raphy is not envisioned. Nevertheless, the adaptation may be assisted by suggesting respective adaptations—but this is not detailed in the paper.

Furthermore, we see problems in the case of undoing operations in an orches-tration that are part of a choreography. Undoing such operations may require com-pensations that are not part of the agreed choreography with a business partner. In the schema evolution example of our order management process we have stated that

all running instances for purchase orders above 10,000 Euro must be undone to get to an state ofcheck against offerto be able to continue withcheck credibility. As-sume that a running instance has already past theresponse to orderoperation. From a business point of view, this means that the order has been accepted and that a contract has been established. Also a transport for delivering the order has already been reserved. In this case an undo is rather problematic, it requires interactions with the buyer and the carrier. However, these interactions have not been defined in the choreography with the buyer nor with the carrier. Accordingly, there is no cancellation of an order possible from the seller’s side once the order is accepted by response to order. Only the buyer may cancel the order. Also the cancellation of a transport reservation is not detailed with the carrier.

Unless the choreography agreement with the buyer and the carrier, respectively, is changed, the instances of the seller’s orchestration must not undo the theresponse to orderandreserve transportoperation. Otherwise the changes to running instances will violate contracts with business partners. So far there does not exist any work that elaborates on the undos of orchestrations and its effects on choreographies. In order to avoid contractual conflicts, we propose to mark those operations which result in contractual obligations and must not be undone without changing the choreography as well. We have developed the UN/CEFACT modeling methodology (UMM) [13]

that uses six business transaction patterns classifying the basic interactions between business partners. Among these the one-waynotificationpattern, and the two-way patternscommercial business transactionandrequest/confirmhave contractual con-sequences. Following the definition of the three mentioned patters, undo operations must never cross the boundaries of these business transactions.