© Springer Verlag 2003, http://www.springer.de/comp/lncs/index.html Eder J. & Saringer M. (2003). Workflow Evolution: Generation of Hybrid Flows. Proceedings of the 9th International Conference on Object-Oriented Information Systems (OOIS 2003), September 2-5, Geneva, Switzerland, LNCS 2817, pp. 279-283.
Workflow Evolution: Generation of Hybrid Flows Johann Eder1 and Michael Saringer2 1
Institute of Informatics-Systems University of Klagenfurt, Austria
[email protected] 2 Celeris AG A-9020 Klagenfurt, Austria
[email protected]
Abstract. Workflows are computational representations of business processes. When workflows are changed, a strategy for dealing with actual running workflow instances is needed, since workflows are typically longrunning processes. As the basic strategies abort and flush are rarely applicable, hybrid workflow schemas have to be defined (transitional provisions) for the continuation of these instances. In this paper we focus on workflow evolutions where merely the order and parallelism of activities are changed and present a technique for generating a manifold of hybrid workflows based on control flow and data flow analysis.
1
Introduction
Workflows [Wor95,EGL98,EG03] are computational representation of business processes. A workflow schema defines, among other things in which partial order the activities of a workflow are to be processed, either by IT systems or by human agents. Workflows are typically long running activities requiring that workflow evolution (maintaining the workflow schema) include transitional provisions to care for the correct continuation of actual running workflow instances [CCPP98,EKR95,GK99,NSWW96]. Basic strategies for dealing with the running instances are: flush: all running workflow instances are completed under the old schema (the one they were started with); abort: all running workflow instances are aborted and probably restarted; migrate: running workflow instances are analyzed and migration paths from the old schema to the new schema are defined, depending on the actual state and the history of the workflow instance. This strategy requires a series of hybrid workflows between the old and the new workflow schema. Defining such transitional provisions can be quite cumbersome, due to the great number of cases which have to be considered. It is well known from law, that amending a law might require much more text for transitional rules than for the new law itself. In analogy, the required migration rules are typically more complex than both the old and the new workflow schema. In this paper we concentrate on changes in workflows where the activities remain the same, but their order or parallelism is changed. Such changes occur
IT.I
IT.F
enterOrder (order[w])
enterOrder (order[w])
shipOrder (order[r])
produceBill (order[r],bill[w])
sendBill (bill[r])
fileOrder (order[w])
notifyCustomer (order[r])
produceBill (order[r],bill[w])
shipOrder (order[r])
sendBill (bill[r])
closeOrder (order[w])
fileOrder (order[w])
Fig. 1. initial- and final workflow instance types
in efforts for improving business processes (reengineering) and they might be part of larger changes where some sub-workflows are only changed in this way. The key idea of our approach is that the data dependency graph reveals the inherent precedence requirements of the activities, while the control flow shows how the workflow designer chose among several potentially valid process definitions.
2
Evolution of Workflow Instance Types
In this section we sketch an algorithm for dynamic workflow evolution which is based on the comparison of the dataflow between activities of workflow instances. It determines how an instance in a certain execution state of an initial workflow may be migrated to a final workflow without violating the semantics of that instance’s execution in respect to the dataflow. This is achieved by calculating hybrid workflows at build-time for every execution state an workflow instance may be in. These hybrid workflows are dataflow equivalent to the final workflow and thus describe valid migration paths for every workflow instance. Our workflow model comprises of activities with information about data access. Activities are connected by the usual control structures (sequence, concurrentand conditional execution). The information about data access (read or write) and the control flow allows to derive the data flow between activities. See Fig.1 for an example workflow. Due to conditionals not all instances of a workflow execute the same activities. We classify workflow instances into workflow instance types [EG03] according to the actual executed activities. A workflow instance
shipOrder (order[r])
DG.I
DG.F
enterOrder (order[w])
enterOrder (order[w])
produceBill (order[r],bill[w])
sendBill (bill[r])
fileOrder (order[w])
notifyCustomer (order[r])
shipOrder (order[r])
produceBill (order[r],bill[w])
closeOrder (order[w])
sendBill (bill[r])
fileOrder (order[w])
Fig. 2. dependency graphs of the initial- and final workflow instance type
type refers to (a set of) workflow instances that contain exactly the same activities, i.e., for each condition the same successor activity is chosen. A workflow instance type therefore is a valid sub-schema of a workflow schema where each conditional split has only one successor. The evolution procedure refers to single workflow instance types rather than the whole workflow to calculate hybrid workflows. The transformation algorithm compares two instance types: the initial instance type (IT.I) is part of the original schema, the final instance type (IT.F) is part of the new schema, to which instances must be migrated. In Fig. 1 an initial and a final instance type are introduced as an example. For both, IT.I and IT.F, a dependency graph in respect to the dataflow is constructed (DG.I, DG.F; see Fig. 2). For every instance (described by its execution state, i.e. the set of ready activities) of IT.I (see table 1) we reproduce its execution in DG.I and colour the executed activities (for instance (or case) C4 , the coloured DG is the same as DG.F). If the coloured DG matches with DG.F. (this is the case for instance C1 , C2 and C3 ), the instance is called compliant. So in a compliant instance the coloured DG is a partial graph of DG.F (or the same). If an instance is not compliant (as C4 ), all activities of the coloured DG which cannot be mapped to DG.F must be compensated in reverse order of their occurrence in the DG. Thus, the compensation activities themselves are organized as a graph, the so called compensation graph (CG). (We assume that a compensation activity exists, which does not mean that we are able to regain the status quo ante.) Fig. 3 shows how the coloured DG of C4 maps to DG.F. There is a problem with activity fileOrder(order[w]), because it is dependent on activity closeOrder(order[w]), which has been newly introduced to IT.F. So activity
C1 : enterOrder(order[w]) C2 : shipOrder(order[r]), produceBill(order[r],bill[w]) C3 : sendBill(bill[r]) C4 : fileOrder(order[w]) Table 1. all workflow instances of the initial workflow instance type
enterOrder (order[w])
notifyCustomer (order[r])
shipOrder (order[r])
produceBill (order[r],bill[w])
closeOrder (order[w])
sendBill (bill[r])
fileOrder (order[w])
Fig. 3. dependency graph of instance C4 mapped to DG.F
fileOrder(order[w]) must be compensated to have C4 compliant. (Compensation activities are marked with −1 ) The final step is to construct a hybrid workflow for every instance of IT.I with the information already available (ITs, DGs, CGs and state). If an instance of IT.I finishes its execution according to its hybrid workflow, the dataflow is the same as if the instance has been finished according to IF.F. In detail, a hybrid workflow for an instance consists of three parts: (1) The already executed activities in IT.I. (2) The compensation graph. (3) The missing, non-executed activities of IT.F. See Fig. 4 for all hybrid workflows of the example. The activities which describe the state are marked grey.
3
Comparison and Conclusion
Workflow evolution as opposed to flexible or dynamic workflows has gained some interest in the research community. [CCPP98] presents and discusses several different strategies for workflow evolution and introduces a workflow definition language as well as a workflow manipulation language. [LOL98] emphasizes the automatization of workflow evolution by means of rules. [GK99] proposes a very sophisticated concept for schema versioning as well as for migration of workflow instances along version trees. The approach of supporting workflow evolution presented here concentrates on the generation of hybrid workflow schemas based on data dependency graphs, such that each potential instance of the first schema can be executed according to the semantics of the second schema. This approach offers the following advantages: – – – –
For each potential instance we provide a migration path. Compliance of instances with the new schema is checked automatically. Compensation-needs to reach compliance are computed automatically. Equivalence of schemas is precisely defined.
Thus this approach appears to be helpful for situations with many workflow instances affected by evolution, albeit it also does not provide a general solution.
C1
C2
enterOrder (order[w])
C3
enterOrder (order[w])
C4
enterOrder (order[w])
notifyCustomer (order[r])
produceBill (order[r],bill[w])
shipOrder (order[r])
produceBill (order[r],bill[w])
shipOrder (order[r])
sendBill (bill[r])
notifyCustomer (order[r])
sendBill (bill[r])
shipOrder (order[r])
produceBill (order[r],bill[w])
enterOrder (order[w])
shipOrder (order[r])
produceBill (order[r],bill[w])
sendBill (bill[r])
sendBill (bill[r])
fileOrder (order[w])
closeOrder (order[w])
closeOrder (order[w])
notifyCustomer (order[r])
fileOrder (order[w])
fileOrder (order[w])
closeOrder (order[w])
fileOrder (order[w])
fileOrder (order[w])
notifyCustomer (order[r])
-1
closeOrder (order[w])
fileOrder (order[w])
Fig. 4. hybrid workflows for all instances
None of the approaches mentioned above covers all aspects. Considerable work is still needed to combine the concepts of these approaches.
References [CCPP98] F. Casati, S. Ceri, B. Pernici, and G. Pozzi. Workflow evolution. In Data and Knowledge Engineering. Elsevier Sience, January 1998. [EG03] J. Eder and W. Gruber. A meta model for structured workflows supporting workflow transformations. In Proc. ADBIS’2002, 2003. J. Eder, H. Groiss, and W. Liebhart. The workflow management system [EGL98] Panta Rhei. In A. Dogac, et al., editors, Workflow Management Systems and Interoperability. Springer, 1998. [EKR95] S. Ellis, K. Keddara, and G. Rozenberg. Dynamic change within workflow systems. In ACM Conference on Organizational Computing Systems, 1995. [GK99] A. Geppert and M. Kradolfer. Dynamic workflow schema evolution based on workflow type versioning and workflow migration. In Proc. 4rd IFCIS Intern. Conf. on Cooperative Information Systems, 1999. [LOL98] C. Liu, M. Orlowska, and H. Li. Automating handover in dynamic workflow environments. In Proc. 10th Conference on Adnvanced Information Systems Engineering (CAiSE ’98), 1998. [NSWW96] M. C. Norrie, A. Steiner, A. W¨ urgler, and M. Wunderli. A model for classification structures with evolution control. In Proceedings of the 15th International Conference on Conceptual Modeling (ER’96), 1996. [Wor95] Workflow Management Coalition. The Workflow Reference Model. document number TC00-1003, 1995.
