Temporal Exception Prediction for Loops in Resource Constrained Concurrent Workflows

Transcription

1 emporal Exception Prediction for Loops in Resource Constrained Concurrent Workflows Iok-Fai Leong, Yain-Whar Si Faculty of Science and echnology, University of Macau {henryifl, Abstract Workflow management systems WfMS) are widely used for improving business processes and providing better quality of services. However, rapid changes in business environment can cause exceptions in WfMS leading to deadline violation and other consequences. In these circumstances, one of the crucial tasks for a workflow administrator is to detect any potential exceptions as early as possible so that corrective measures can be taken. However such detections can be extremely complex since a workflow process may consist of various control flow pattern and each pattern has its own way of influencing temporal properties of a task. In this paper, we describe a novel approach for predicting temporal exceptions for loops in concurrent workflows which are required to share limited identical resources. Our approach is divided into two phases; preparation phase and prediction phase. In the preparation phase, temporal and resource constraints are calculated for each task within the workflow schema. In the prediction phase, an algorithm is used to predict potential deadline violations by taking into account constraints calculated from the preparation phase. 1. Introduction Workflow Management Systems WfMS) enable the automation of business operations by allocating and dispatching work to users according to executable process models [8]. A workflow schema is the description of the business flow [1]. Workflow schemas are defined to support business s goals. A workflow instance, however, is an execution of the workflow schema. While executing a workflow instance, some events that are not defined in the workflow schema may occur. hese events are typically considered as exceptions in workflow management systems. Exceptions in a workflow management system can be classified into different categories. Fabio Casati [2] defines two types of exceptions; expected exceptions which are the results of predictable deviations from the normal behavior of a process and unexpected exceptions which are the outcomes of inconsistencies between the business process in the real world and its corresponding workflow description. Most of the researches mainly focus on detecting and handling of expected exceptions. Although unexpected exceptions are difficult to be handled, they usually occur during execution of a workflow. In general, an organization may need to execute different workflows simultaneously for different segments of the business and these concurrent workflows can be interdependent. For example, two concurrent workflows representing a purchase process and an inventory management process may share the same resources. Conflicts occur when a limited number of resources are available during a given interval. Recent work by Li et al. [8] addressed the problem of predicting unexpected exceptions in concurrent workflows by verifying temporal constraints. However, the approach described in [8] only considers single unique resources. In this paper, we address this issue by taking into account identical resources which are shared by one or more concurrent workflows. A loop refers to a recursive execution of one or more tasks within a workflow. Although loops are extensively used in workflow schemas, less attention has been devoted to understanding their impact on temporal exceptions. Indeed, looping of tasks within workflows can greatly increase the difficulty in exception prediction since rapid changes in the number of iterations can cause deadline violations as well as conflicts in resource usage. In [1], Jin Hyun Son et al. propose a method for identifying the critical path for a given workflow schema based on queuing theory. he critical path is then used for the assignment of deadlines for the activities in the workflow. In their approach, loops are transformed into a sequence control construct. However, to the best of authors knowledge, no work has been reported on predicting exception in concurrent workflows which contain loops. In this paper, we further extend the temporal checking algorithm from [8] to allow prediction of unexpected temporal exceptions in concurrent workflows which not only share identical resources but also contain one or more loops. Our approach can be basically divided into

2 two phases; preparation phase and prediction phase. In the preparation phase, temporal and resource constraints are calculated for each task within the workflow schema. In the prediction phase, an algorithm is used to predict potential deadline violations by taking into account constraints calculated from the preparation phase. his paper is organized into 6 sections. A brief introduction to resource and temporal constraints in a workflow is given in Section 2. We describe our proposed solution in Section 3 and 4. In Section 5, we briefly review recent work. In section 6, we summarize our ideas and future work. 2. Resource and temporal constraints Workflows within an organization can be designed to execute in parallel. In addition, they may share the same resources e.g., human resources, financial resources, etc.). Conflicts usually occur when tasks from instances of different workflows compete for limited resources. Figure 1a) shows an example of conflict involving tasks from two concurrent workflows when four units of identical resources are only available for sharing. In this example, resource conflicts occur at tasks 22, 23, 24 and 25. Furthermore, these resource conflicts are linked to the underlying temporal constraints of a task within the workflow. We denote the duration of a task by a boundary [d ),D )], where d ) and D ) are the minimum and maximum durations of a task respectively. In addition, we can define 4 temporal constraints for a task: a) Earliest Start ime ES), b) Latest Start ime LS), c) Earliest End ime EE), and d) Latest End ime LE) see figure 1b)). hese values are assumed to be defined in the workflow specification during design time by the workflow designers a) ime 0 ES LS D ask d b) EE LE ime Figure 1. a) Resource conflict in workflows b) emporal constraints of task hese constraints are crucial in determining the deadline of a workflow. For example, LE of a task can be used to determine the hard deadline of a workflow. Basically, temporal constraints of a task are related to its predecessor and successor tasks. For instance, if a task is scheduled to execute right after another task, its ES value can be set to the EE value of its predecessor task. However, depending on the control flow [7] within the workflow, derivation of these constraints can be different. A workflow may also have loops. A loop is a repeated execution of one or more tasks within a workflow. Such repetition has significant impact on temporal constraints of a task which may belong to one or more loops. Since tasks within a loop can be repeated a number of times, calculating temporal constraints of a task also needs to take into account possible repetition of its ancestors and descendants as well. Such calculation can be even more problematic when a task belongs to one or more nested loops. In the following sections, we describe how ES and LE values of a task can be calculated for simple control flow patterns and loops. 3. Calculating temporal constraints 3.1. Deriving ES and LE for simple control flow patterns Similar to [8], our approach predicts temporal exceptions in a workflow by creating a conflict free execution trace based on the workflow specification. he resulted execution trace defines the order of task execution with respect to the temporal and resource constraints and is free from any conflict. o do so, we first need to calculate the earliest start time ES) and latest end time LE) of every task in the workflow. hese values define the upper and lower boundaries of a time window in which a task may execute. According to this time frame, a task must not be executed before its ES value and after its LE value. Such underpinning is crucial in determining the hard deadline of the entire workflow and also in predicting whether or not a given workflow instance will violate the deadline. In our proposed algorithm, we assume that a task is predefined with a minimum duration d ), a maximum duration D ), and a resource usage R ). asks are linked by different types of flows. Different combinations of task-flow pairs within the workflow are defined as control patterns [7]. Our aim is to calculate ES and LE values for those control patterns which are commonly used in business process modeling. Figure 2 shows various types of control patterns and corresponding formulas for deriving ES and LE values.

3 Sequence ES )=ES )+d ) LE )=LE )+D ) XOR-Join ES )=Max{ES )+d ), ES k )+d k )} LE )=Max{LE ),LE )}+D ) XOR-Split ES )=ES )+d );ES )=ES )+d ) LE )=LE )+D );LE )=LE )+D ) OR-Join ES )=Min{ES )+d ), ES )+d )} LE )=Min{LE ),LE )}+D ) OR-Split ES )=ES )+d );ES )=ES )+d ) LE )=LE )+D );LE )=LE )+D ) AND-Split ES )=ES )+d );ES )=ES )+d ) LE )=LE )+D );LE )=LE )+D ) AND-Join ES )=Max{ES )+d ), ES k )+d k )} LE )=Max{LE ),LE )}+D ) Figure 2. Deriving ES and LEn simple control flow patterns [8] 3.2. Deriving LE values for tasks within loops Based on the definition from [7], loops can be classified as structured loops, and arbitrary loops. In this paper, we further divide arbitrary loops into nested loops and crossing loops. In a nested loop, all tasks within a loop appear in another loop. In a crossing loop, only a certain number of tasks within a loop appear in another loop. In this section, we show how LE values for the tasks in these three types of loops can be derived. Let I N be the maximum number of iterations that a loop N within a workflow wf can be executed and let S N be the set of tasks in loop N in wf. We assume that I N > 0 and S N {} i.e., loop N should contain at least one task), and that the maximum number of iteration I N ) of a loop N will be reset once the execution flow leaves N e.g., when the flow leaves the last task in a loop). We also assume that each task within a workflow is atomic, i.e., a task must be executed entirely until it is completed and cannot be interleaved with other tasks. In the following sections, we show how LE value can be derived for three different types of loop Structured Loop. he simplest form of a loop is the Structured Loop [7]. An example of a structured loop is shown in Figure 3. Definition 1: Structured Loop. A loop N in a workflow wf is a Structured Loop if for all tasks n S N, does not exist in any other loop in wf. In Figure 3, if loop N can iterate for at most I N times, then each of the tasks in S N can be executed for at most I N +1 times. he calculation of ES for tasks in a loop is done according to their control patterns as shown in Figure 2. However, in calculating LE values, we need to consider the worst case since the loop can iterates for at most I N times. Let Φ N be the total maximum duration for executing all tasks within loop N for one iteration. Φ N = k = i D 1) We calculate the latest ending time LE) of the first task in loop N as follows: LE ) = LE ) + I Φ + D ) 2) ) i 0 N N i Since other tasks within the loop N inherit the LE values of, their LE values can be calculated as: LE ) = LE ) + D ) if i 3) Nested Loop. In a nested loop, all tasks within a loop are also members of another loop. Such loops are also classified as Arbitrary Loops [7]. For instance, in Figure 4, a loop N is nested within another loop M. Figure 3. Structured Loop Figure 4. Nested Loop

4 Definition 2: Nested loop: A loop M in a workflow wf is a nested loop if there exists another loop N such that all the tasks in N are also members of M and both M and N do not share the same initial task 1. When we calculate the ES and LE values of the tasks in loop M, we also need to take into account the time required to execute loop N. From Figure 4, we can define the latest ending time LE )) of the first task of loop M as follows: LE i ) = LE 0 ) + I MΦM + I M I NΦN + D i ) 4) his formula applies to the first task of an outermost loop M in Figure 4. Since remaining tasks in loop M inherit the LE values of, their LE values can be calculated as: LE ) = LE 1) + D ) if 5) i, S, M S N Since loop N in this case is a Structured Loop and there is no other nested loop inside N, LE values of tasks in S N can be calculated by using equation 3) Crossing loop. Crossing loops are also classified as Arbitrary Loops [7]. In Figure 5, an example of crossing loop is depicted with two loops N and M crossing each other at a and. Figure 5. Crossing Loop Definition 3: Crossing loop. Loop N and M in a workflow wf are crossing loops if 1) both N and M share at least one task and 2) there exists at least one task in wf which is a member of only either one of the loops 2. We calculate the LE values of the tasks in crossing loops by considering the worst case scenario, i.e., when loop N iterates for I N times and loop M iterates for I M times. Let be the first task in loop N in Figure 4 and loop N is crossing with another loop M. We derive the latest ending time of the first task of loop N as follows: LE ) = LE ) + I I + 1) Φ + I Φ + D ) 6) i 0 N M N M M i For the remaining tasks that are within loop N or loop M except a ), their LE values can be calculated as follows: 1 If M and N share the same initial task, we consider M as a crossing loop. 2 Both loops may begin at the same task, i.e. both flows from and b may point back to either or a in Figure 5. In this case, the loop whose last task ends earlier is considered as loop N. LE ) = LE ) + D ) if 1 SN SM, i, a Since a is the first task of the structured loop M, its LE value will be calculated by using equation 2) as follows: LE ) = LE ) + I Φ + D ) 8) a a 1 M M a Loops are defined in the workflow specification during design time. o identify the loop type in a workflow, we check whether tasks in a loop are contained in other loops or not. Figure 6 shows the algorithm for identifying the type of loop N. For each task t in loop N If t exists in other loop N then If all tasks in N exists in N then N is a Nested Loop Else N is a Crossing Lop End If Else N is a Structured Loop End If End Figure 6. Psudocode for identifying loop type In Figure 7, we describe the algorithm for calculating ES and LE values of tasks in an arbitrary workflow wf. Calculate the ES values of each task in wf, according to the control patterns defined in Section 3.1 For each task n wf If s the first task in a loop N then /* calculate LE) recursively */ Calculate LE) as calrecur N) + D) Else Calculate LE) according to the equations defined in Figure 2 Function calrecur N) Begin If N is a structure loop then return I N * Φ N.//eq.3) Else if N is a nested loop which contains another loop M then return I N*calRecurM)+I N* Φ N.//eq.4) Else if N is a crossing loop with loop M then return calrecurm)+i N*I M+1)* Φ N //eq.6) End Figure 7. Psudocode for calculating ES and LE value of a workflow which contains loops In this algorithm, we first calculate the ES values for every task. Next we check whether a task is within in a loop. If it is within a loop, we identify the type of loop for applying the appropriate equation in 7)

5 calculating the LE values accordingly. his algorithm also supports cases where loops are nested/crossed in more than two levels. 4. Predicting temporal exceptions he proposed prediction algorithm is separated into two steps as shown in Figure 8. In the conflict detection and resolution step, we extend the algorithm from [8] to re-enact a conflict free execution trace based on the pre-defined workflow specification during design time. In the prediction step, we use the generated execution trace from previous step to check possible deadline violations in run time for the two workflow instances which are executing in parallel. 4. Generate an execution trace by taking into account revised LE values and allowing each task to execute in maximum duration. An execution trace will be created in step I, where tasks are only permitted to use the maximum allowable resources. he execution trace guarantees that the concurrent workflows will not exceed the resource usage during execution. he latest end time of the resulted conflict-free execution trace is said to be the hard deadline HD) of the workflow. Step II Prediction 5. Pick a time point current time for workflow instances wi1 and wi2, which are instantiated from the workflow specification wf1 and wf2 respectively during run time. 6. Calculate the total minimum execution time required for all tasks including those which are currently being executed at current time and tasks which are planning to be executed after current time. 7. If current time + the total minimum execution time > HD), we can conclude that an exception is predicted, otherwise exception cannot be determined. 5. Related work Figure 8. Steps for predicting temporal exceptions Step I Conflict Detection and Resolution 1. Calculate the ES and LE values for each tasks in wf1 and wf2 according to the types of control patterns. 2. For each task in wf1 and wf2, we calculate dep ), which is a list of tasks which has resource conflicts with. A task t in wf1 and wf2 where t ) is a member of dep ) if i) resource usage of + resource usage of t > maximum number of available resources and ii) and t have overlapping execution time, i.e., μ, ES i ) μ LE i ), ES t') μ LE t' ) 3. If dep ) is not empty, then do the followings: i) For each task t in dep ), if execution time of and t overlap, modify [ESt ), LEt )] as [MAX{ESt ), ES )+d )}, MAX{LEt ), LE )+D )}]. ii) Modify the LE values for subsequent tasks of t using the new LEt ) value. In the area of programming languages, exceptions may interrupt the normal flow of a program, leading to unexpected abortion of a program. Exceptions in workflow management system are also similar to that of programming languages. Klein et al. [5] describe a knowledge-based approach that allows workflow designer to determine when a workflow may fail. In their approach, rules are created for detecting exceptions during workflow definition stage. he approach proposed in [5] mainly focuses on prediction of exceptions at the workflow definition. his kind of approach is static and not flexible enough to deal with changes in a workflow. However, in our approach, in addition to the workflow definition, we also make use of the audit trail information of the workflow instance to dynamically generate the execution trace, thus result in a prediction model that reflects the real situation more accurately. An alternative approach is proposed by Kammer et al. [3] for detecting exceptions during workflow execution. heir approach is implemented in Endeavors workflow support system by comparing its historical information with current workflow status and feedback data captured during the execution of a workflow. he system then uses the result for detecting exceptions.

6 Similar to [3], our approach extends XML Schema of YAWL [9] for modeling different kinds of loop. A prototype prediction system was also developed based on YAWL workflow management system. Exceptions can occur due to the modeling errors in workflow schemas. Shiyong Lu et al. [6] develop an algorithm for checking the validity of a workflow model represented in the form of a graph. By identifying the precondition and post-condition of a workflow, the algorithm checks if the input and output edges of the workflow follows a valid pattern or not. Our approach does not validate the correctness of the workflow specification. Instead, the proposed algorithms take into account several commonly used control patterns and loops for prediction. In [4], Grigori et al. propose an approach for exception prediction based on data warehousing and mining techniques. In their approach, WfMS log is extracted and stored in a relational database, which is then used in generating rules and decision trees for exception prediction in future workflow instances. he main difference between our approach and the approach proposed by [4] is that, our approach allows predicting of exceptions in concurrent workflows which are required to share identical resources. In the context of predicting temporal exceptions in concurrent workflows, our approach extends the algorithm given in [8] by taking into account different kinds of loops which are identified in [7]. he recursive algorithm outlined in our approach allows calculation of LE values for nested loops with arbitrary depth. In resource sharing, our approach allows sharing of identical resources whereas the approach proposed in [8] only considers sharing of single unique resources by concurrent workflows. 6. Conclusion In this paper, we describe a novel approach for predicting temporal exceptions for loops in resource constrained concurrent workflows. In our approach, we create a conflict free execution trace for concurrent workflows to resolve both time and resource constraints. We then use the generated execution trace to predict exceptions in workflow instances which are in the progress of executing. Our approach also takes into account identical resources and different types of loops that may exist within a workflow. A prototype exception prediction system was developed in JAVA and integrated with YAWL system [10]. We have also extended the definition of YAWL workflow schema for defining different types of loop. We are currently in the process of extending our algorithm to take into account other complex workflow patterns proposed in [7]. 7. Acknowledgment his research is funded by the University of Macau under grant RG056/06-07S/SYW/FS Audit rail Data Management, Intelligent Deadline Escalation, and Exception Prediction in Workflows. 8. References [1] J.H. Son, J.S. Kim and M.H. Kim, Extracting the workflow critical path from the extended well-formed workflow schema, Journal of Computer and System Sciences, 701), pp , [2] F. Casati, Models, semantics, and formal methods for the design of workflows and their exceptions, PhD hesis, [3] P.J. Kammer, G.A. Bolcer, R.N. aylor, A.S. Hitomi and M. Bergman, echniques for supporting dynamic and adaptive workflow, Computer Supported Cooperative Work, 93-4), pp , [4] D. Grigori, F. Casati, U. Dayal and M.C. Shan, Improving business process quality through exception understanding, predication, and prevention, In Proceedings of the 27th International Conference on Very Large Data Bases, San Francisco, CA, USA, pp , [5] M. Klein and C. Dellarocas, A knowledge-based approach to handling exceptions in workflow systems, Journal of Computer Supported Collaborative Work, 93-4), pp , [6] S. Lua, A. Bernsteinb, and P. Lewis, Automatic workflow verification and generation, heoretical Computer Science, ), pp , 14, [7] W.M.P. van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros, Workflow Patterns, Distributed and Parallel Databases, 143), pp. 5-51, [8] H. Li and Y. Yang, Dynamic Checking of emporal Constraints for Concurrent Workflows, Electronic Commerce Research and Applications, 42005), pp , [9] W.M.P. van der Aalst and A.H.M. ter Hofstede, YAWL: Yet Another Workflow Language, Information Systems, 304), pp , [10] YAWL,