the authors receive author kits through emails, with necessary documents as attachments. The process ... The author does not send the paper at all, or after the deadline. The process ..... (1994) Specification and Execution of Transactional.
On Capturing Exceptions in Workflow Process Models Shazia W. Sadiq
Maria E. Orlowska
Department of Computer Science and Electrical Engineering The University of Queensland QLD 4072 Australia Email: {shazia,maria}@csee.uq.edu.au
Abstract-Exceptions have always been a major source of complexity and limitation in business process automation. In this paper we review exception handling from the perspective of large business processes that involve several, possibly heterogeneous and distributed information systems. The aim is to capture behavior which represents deviations from the normal process, but still can be anticipated, and handled accordingly. These exceptions are useful and a key to effective and flexible processes. Using workflow techniques as instruments of business process modeling, we provide methodological guidelines for analyzing exceptional behavior and designing special constructs within the process model that support useful exceptions.
1
Introduction
A business process model is a description of an organization’s activities in terms of tasks, agents, rules and procedures. It is engineered to fulfill a business goal [GHS95]. In the dynamic and competitive business environments of recent times, process models are subject to frequent and unavoidable change [Dav93]. Process models thus evolve over time. It is necessary for the technology supporting business process automation to allow the process models to adapt to the changing requirements [SMO99]. Process evolution is generally a carefully planned strategic decision. It comprises several phases of propose, define/clarify, review, analyze, revise, distribute, enact and evaluate. However, a process model may be unable to fulfill the business goal because of reasons other than changed circumstances. Consequently, reengineering or process evolution is not always the right solution. In fact, limitation of process models is most frequently felt in their inability to cater for rare or unanticipated cases [SW95]. These deviations from the prescribed process logic are exceptions. Exceptions may or may not trigger a re-definition of the process model. A large majority of exceptions, however, can be anticipated. Thus they are not exceptions in the real sense, but they still represent deviations from the normal process. Recognition and design of these deviant processes promotes the flexible aspect of the business process. As such, an exception can be perceived as [SM95]: • •
Useful, that is, a 'key to effective and flexible' processes, and thus should be handled. Unanticipated, that is, the result of an 'unexpected, infrequent and non-repetitive' event.
In general, exception handling is expensive. Business processes that are (partially) automated through process enactment systems such as group ware and workflow systems are liable to suffer substantially from a lack of exception handling support since it essentially causes 'system work arounds'. For processes that span organizational boundaries, or extend beyond organizations into virtual enterprises, the consequences of these work arounds cannot be easily established. As a result exceptional handling may come in conflict with process goals, and this conflict may go undetected until a critical point, and which time a cascade of further exceptions may be triggered [KD98]. This is obviously not desirable. In this paper, we primarily deal with exceptions that are deemed useful. The aim is to enhance the process model, so that these exceptions can be handled without system work arounds, and in conformance with process goals. We thus view a business process as a composition of the core process and a collection of exception processes.
1
In the following sections we investigate viable approaches for the modeling of such processes using workflow techniques. In section 2, we provide a brief introduction to workflow technology and related concepts. We will also introduce a workflow modeling language, which is used in the subsequent discussion. Section 3 gives a description of various classes of exceptions from a modeling perspective. We illustrate the taxonomy with an example scenario of a workflow that represents a typical international conference. Finally, in section 4 and 5, we present methodological guidelines for incorporating useful exceptions into the process model. We will also briefly discuss the extensibility of the proposed methods for supporting unanticipated exceptions.
2
Business Process Automation
Workflow technology has emerged as an appropriate platform for consolidating the distributed information resources of an enterprise, promoting interoperability in cross-platform systems and for providing a global view and understanding of business process models. A workflow is defined as the automation of a business process, in whole or part, during which documents, information or tasks are passed from one participant to another for action, according to a set of procedural rules [WFMC95]. Workflow management is a means by which the ordering, coordination and allocation of tasks can be defined and controlled in accordance with usually a given set of rules and procedures. A Workflow has two main components: The process model, or workflow model is a definition of the tasks, ordering, data, resources, and other aspects of the process. This represents the workflow schema or type. Most, if not all, workflow models are defined as graphs which depict the flow or ordering of the tasks involved in the process, together with a description of other task properties. For example, we can define an admission workflow that handles student admission applications in a university. The process instance is a particular occurrence of the process, for example, a particular application for admission represents an instance of the admission workflow. Different instances of the same workflow may perform a different subset of workflow tasks, i.e. they may have different execution paths in the workflow graph. An instance class is a set of instances that can be represented by the same (execution) sub-graph We briefly introduce the workflow modeling language first [SO97]. This conforms closely to the Workflow Management Coalition standards [WFMC98]. Figure 1 gives example graph notations.
Figure 1. Process Graph Notations
A Workflow is a Directed Acyclic Graph (DAG) W = such that N: Finite Set of Nodes, F: Flow Relation F ⊆ NΧN. Nodes can be tasks (rectangles) or coordinators (circles). Each task in the workflow is described by a set of properties. These relate to the data, time, underlying applications, resources, clients, compensation and other properties [JB96]. We do not elaborate on task properties in this paper. However, the task is a complex object with rich semantics, and cannot be considered as a mere node in the workflow graph. Each node n ∈ N in the Workflow W also has an execution structure consisting of a set of visible states and a set of transitions between these states [RS94]. The execution of nodes is modeled by the Finite State Machine in Figure 2. Nodes can take the following states:
2
• • • • •
Scheduled: Scheduled for execution, but not yet allocated to any workflow client Active: Chosen by its client, and being performed Suspended: Temporarily put on hold Complete: Successfully completed Terminated: Result of aborting an active task or recalling a scheduled task Suspended
Scheduled
Active Allocate
Recal
Completed Complete
Abort Terminated
Figure 2. Finite State Machine for a Node Let INS be the set of instances for W nodestate: N X INS → {Scheduled, Active, Complete, Terminated, Suspended}, nodestate(n, i) : State of Node n for instance i where n ∈ N, i ∈ INS. Assuming that time lapse between the completion of a node and the scheduling of its ‘chosen’ successors is negligible, we define the following states for an instance: • • •
Ready: An instance i is in Ready State when nodestate (n0, i) = Scheduled Current: An instance i is in Current State when ∃ n ∈ N, s.t. nodestate (n, i) = Active ∨ (∃ n ∈ N, s.t. nodestate (n, i) = Scheduled ∧ ∃ m ∈ N, s.t. nodestate (m, i) = Completed) Complete: An instance i is in Complete State when nodestate (nf, i) = Completed Where n0 is the Initial Task and nf is the Final Task of W
The above concepts are typical to most workflow process and execution models. We will use these concepts in the subsequent sections to illustrate the examples and modeling methodology.
3
Classes of Exceptions
Several classifications of exceptions can be found in related literature. One of the earliest contributions came from [SM95] in the area of information systems. They provide five different perspectives on exceptions, namely random-event, error, political system, total quality management, and human computer system perspective. In the context of business processes and workflow systems, notable work on exception classes can be found in [EL95], [HS98], [CP99]. [EL95] were the first to present a classification of workflow exceptions. They divide exceptions that may occur during workflow execution into basic failures, which are failures at the system level, application failures, expected exceptions and unexpected exceptions. In [HS98], the authors provide a taxonomy based on the level of abstraction. This includes adaptation to a changing business context, which is the domain level. Process level adaptation, which is adaptation of workflow schemas and tasks including model evolution as well as ad-hoc changes. Resource level adaptation, which deals with adaptation of organization and data structures. And finally, infrastructure level adaptation, which is adapting to technical advances and changed system configurations. [CP99] classify exceptions on the basis of time of occurring. Thus exceptions can occur synchronously with the flow of the process, or asynchronously. They further divide synchronicity into localized and sparse.
3
We approach the problem from a modeling perspective, thus classifying exceptions on the basis of when and how useful exceptions can be included in the process model. The underlying assumption is that these exceptional cases in the business process are well recognized and understood, and the procedures for handling them have been determined. The main characteristic that distinguishes these exceptions from 'normal' business process logic is infrequency. Exceptions in the process are driven by events. These events could be of a variety of forms, including predicates over process data, temporal events, resource violations, and external notification. A typical process may have a significant number of exception conditions that require special proceduress, which are not part of the normal process. Useful exceptions (UE) for a given process can be described through UE: (W, F) E where W is the Workflow Process, F is the Failure Condition and E is the Exception Handling (sub) Process. Several F may trigger the same E, so E is not necessarily unique to a given F.
Call for Papers
Review
Accepted N Rejection Notification
Y Acceptance Notification
Publication
Presentation
Close
Figure 3. A Conference Workflow To illustrate our classification, we introduce an example scenario. Consider a workflow process that models a typical international conference management process (Figure 3). Some of these activities are blocks, consisting of several workflow tasks. There are several clients for this workflow, including the conference organizers, the program committee, authors, publishers and sponsors. This example does not represent the design of any particular conference, nor does it aim at providing a comprehensive process model for this application area. This process model has been designed to the best of our knowledge using commonly accepted procedures. We now introduce the classification of exceptions, which groups exceptions on the basis of when and how they can be integrated with the process model.
3.1
Embedded
The simplest approach to model exceptional behavior is to embed exception logic into process logic. Consider the workflow representing the Publication block. This primarily involves the publishers and the authors. Normal processes can be modeled as in Figure 4. The publishers for the conference receive the data from the conference organizers regarding papers and authors. They, then communicate to the authors necessary pre-requisites for printing. Assuming that electronic media is the main form of communication, the authors receive author kits through emails, with necessary documents as attachments. The process represented in Figure 4 is an iterative process, however, iterative structures have been omitted for simplicity. Several exceptions can arise in this scenario, for example:
4
1. 2. 3.
Authors are unable to view the author kit attachments The author sends the paper but does not fully comply with the formatting guidelines The author does not send the paper at all, or after the deadline
The process model depicted in Figure 4 is unable to handle any of these exceptions. In order to embed the exception logic into the process model, first the exception handling procedure has to be defined. Recieve Publication Request Recieve Author Kit Post Author Kits Reformat Paper
Prepare Copyright Statement
Prepare Abstract
Recieve Papers Send Documents Send to Print
Publisher
Author
Figure 4. Publication Workflow Suppose the following business rules are defined for the above exceptions. 1. 2. 3.
Authors unable to view author kit attachments, can download the documents from the publisher's web site. Papers received by the publishers which fail to comply with prescribe formatting standards will be charged to the authors at a given rate Papers not received within the deadline will not be published Recieve Publication Request Recieve Author Kit Post Author Kits
View Attachements Yes
No Download
NULL
Reformat Paper Recieve Papers
Status
Prepare Copyright Statement
Prepare Abstract
Send Documents Not Okay
Reformat
Okay Charge Customer
Send to Print
Figure 5. Extended Publication Workflow
5
In Figure 5, the Publication sub process is extended to include the exception logic. This demonstrates an obvious improvement over the previous process model. Failure conditions F, are implemented as control flow conditions, and the exception handlers E, are implemented as workflow task(s). However, this approach may not work for all types of exceptions. We can consider paper withdrawal by authors as another exception. Authors choosing to withdraw must send a statement signed by all co-authors. Consequently their paper would be stricken from the conference publications. This exception may occur after submission, during or after the review process, after notification of acceptance, an even during the publication process. Embedding exception logic translates to the insertion of Choice/Merge (OR-Split/OR-Join) structures in the process graph. Modeling of exceptions such as paper withdraw, will cause repeated use of the same structure. This obscures the normal process from the modeling point of view. Excessive use of choice constructs designed solely for exception handling, even when used as in Figure 5, introduces a complexity in the process model which is not always desirable. The decision to embed certain exception handling procedures within the process model will be a domain specific decision, dependent upon the semantic criticality, and frequency of the exception. Furthermore, once such procedures are embedded into the normal process logic, it is debatable whether the term 'exception', is appropriate for these procedures.
3.2
Separated
Separating failure semantics is not a new concept. It has been widely used and accepted in programming languages. The primary motivation is the design of readable code. This is a table versus shelf scenario, where only the requisite material is put on the table. All reference material is shelfed, and brought to the table only when required, thus keeping the table material under control. The same reasoning can be applied to process enactment systems [HA98]. Recieve request for withdrawal
Authorization Not Okay Reject
Under Publication
Paper Status Under Review Inform Reviewers
Review Pending
Inform Printer
Notification Pending Accepted
Printing
Y Now N
Pending Reject
Remove Paper Remove Paper
Notify Authors
Figure 6. Paper Withdraw Exception Exception rules One approach is to implement exceptions through an explicit exception rule base of the form (W,F) E. Upon F, control flow is transferred from the affected instance to the (workflow management) system, which invokes the appropriate exception handler E. Upon completion of E, control may or may not return to the instance. We will discuss this issue in more detail in the next section.
6
The identification of E is dependent on the failure condition F. It is vital that the correct F is delivered to the system. Workflow tasks are responsible for generating the correct F. Determining F for certain workflow tasks may not always be possible, which may result in a system work around, even when the exception handling procedure has been specified. Exception workflows Alternatively, exceptions can be modelled as workflow processes themselves. This is different from the rule base approach because the initiation of E is not dependent on workflow tasks to return the correct F. Instead E is initiated as an instance of another workflow process. An instance of the exception workflow will impact on the process data and subsequent execution path of the exception raising instance. The instantiation of the exception workflow will (temporarily) suspend the corresponding workflow of the exception raising instance, the execution of which may, or may not resume later. Consider the exception of paper withdrawal in the conference workflow. Handling of this exception can be captured as a workflow process (Figure 6). Creating an instance of this workflow would cause the conference workflow instance for that paper to be terminated.
3.3
Unanticipated
These are exceptions which cannot be predicted in advance, and hence cannot be included in the process model, at least until their first occurrence. For example not enough papers are submitted, because of which the conference is cancelled, or a sponsor withdraws financial support, because of which the publication of the proceedings cannot be accomplished as advertised. Unanticipated exception may result in a failure of the workflow system to meet the process goal. It would be pertinent to note at this point that 'failure' is often meant to denote system failure. Recovery from system failure such as power cut, program abort, server down etc. is generally handled by the workflow activity which relies on the recovery capabilities of underlying (database management) systems. The workflow may be temporarily suspended, but resumes execution when the local system recovers. Semantic failure occurs when an instance is unable to proceed according to the given workflow model. This may happen at the application (task) or process (workflow) level. Thus the workflow system is unable to cater for the special circumstances. Process model changes may be initiated as a result of semantic failure. The challenge here is the management of active instances that are affected by a given change. The dynamic schema change problem has been extensively addressed in literature [Sad00], [CCP+96], [RD97], [EKR96]. The notion of workflow history management is also of importance in this issue. Workflow histories can be used to find exception precedents, which can provide guidelines for handling the current situation. An unanticipated exception may eventually be implemented as a useful exception, if it recurs, and is found significantly important. Figure 7 presents a view of the exception classes introduced above. In summary, we make the following observations for the three exception classes: Embedded: Exceptions which are embedded within the process model become part of the core process and generally are not even considered as exceptions. Separated: Exceptions which are implemented through exception rules and/or exception workflows constitute the set of useful exceptions for the process. Unanticipated: The business process can not be completely captured through its core and exception processes because of the existence of unanticipated exceptions. The (known) business process model is thus composed of the core process and a given set of exception processes, that is BP = {CP, P1, P2, P3, … Pk}. The challenging question at this point becomes the modeling and enactment of the useful exceptions, so as to effectively provide system support for these exceptions. We address this question in the next section.
7
Figure 7. Modeling Perspective on Exception Classes
4
Exception Handling Methodology
Modeling exceptions in business processes is not confined to designing exception handling processes. In fact, detecting and diagnosing an exception is an equally complex problem for large workflows. Accordingly, we divide exception handling into three typical phases: detection, diagnosis and resolution. In this section, we provide guidelines for capturing the exception logic in each of these phases.
4.1
Detection
Exceptions are clearly event driven. The aim is to recognize the occurrence of an event as a given exception. The design of failure modes (the F in (W,F) E) is the key factor. Failure conditions can be designed at three levels: Task Level: Failures that can occur for particular tasks. For example, papers received by publishers which are not formatted correctly, is a failure condition of the 'Receive Papers' task. Block level: Failures that can occur for a group of tasks within the workflow. An example block can be the group of tasks that relate to 'Review', which include receiving paper submissions, finding the appropriate reviewers, and dispatching the papers. An example failure for this block is a decline by a reviewer to review a particular paper. Process Level: Failures that can occur anytime within the entire process. For example paper withdraw' is a process level failure condition. Thus the W in (W,F) E can represent the workflow, a block in the workflow, or a single task. It is important that the triggering object, (or the tasks executed prior to it) provide sufficient data for the evaluation of F.
4.2
Diagnosis
Once the failure condition has been established, diagnosing the exception is the next step, which is determining the appropriate exception handler (the in (W,F) E). Exception diagnosis can be implemented through: Control Flow: The flow conditions of the process model diagnose the exception (Figure 5). Control flow can be used for only those exceptions that occur at the completed state of a given task, and is thus limited to the implementation of task level failure conditions. The exception handling process may be modeled as single task, a block of tasks or a nested process.
8
Exception Rules: Using exception rules is typical of programming environments. Exception rules can be defined for task, block and process level failures. Workflow tasks usually end in a completed state (Figure 2), after which normal flow continues. Workflow tasks that end in terminated state indicate semantic failure, after which the (workflow management) system evaluates the given failure conditions for that task (block or process) and diagnoses the exception handler if possible. The underlying assumption in this approach is that the relevant data for the evaluation of the failure condition will be generated by the preceding workflow task(s). External Triggers: When the workflow process cannot completely provide the data necessary for evaluating the failure condition of a particular exception, an exception workflow may be triggered through external notification. In contrast with rule based diagnosis, the initiation of the exception sub-process is replaced by the instantiation of the exception workflow, which is controlled by humans. The failure condition is identified through an external notification, and thus does not require system evaluation.
4.3
Resolution
Resolving exceptions effectively, lies in appropriately designed exception handlers (the E (W,F) E). Since the design of the exception handling process is a domain dependent semantic issue, we do not discuss that further. However, the issue of resuming execution after completing the exception handling process is of importance here. Except when embedded in the process model through control flow, exceptions are resolved by invoking the exception handling processes and (temporarily) suspending the execution of the exception raising instance. This invocation is irrespective of the diagnosis strategy, which could be through wait tasks, rule base or exception workflows. Suppose that for a current instance i of workflow W, a given failure condition f ∈ F evaluates to true. The corresponding e ∈ E is diagnosed. Since instance i is in current state, at the time when f is evaluated, there will exist at least one n ∈ N, such that nodestate (n, i) = Active or nodestate (n, i) = Scheduled (See definition in Section 2). The invocation of e is preceded by a suspension of i. This means that n will be put into Suspended state if it was previously Active, or it would be recalled and put into Terminated state if it was previously Scheduled. On completion of e, execution of i may or may not resume. Depending upon the state of n when f was evaluated, a number of options may exist for the resumption of execution of i after executing e. Case
Table 1. Resuming Execution after Exception Handling nodestate (n, i) = Active nodestate (n, i) = Scheduled
A
n is aborted and control never returns to i
Control never returns to i
B
Control returns to i and n is (re)activated
Control returns to i and n is (re)scheduled
C
Control returns to i, but execution is resumed
Control returns to i, but execution is resumed
at a different point
at a different point
D
Control is not diverted from n, and n executes in parallel with e
Resuming at the point of suspension (Case B), or aborting the instance (Case A) may not work in all cases. Case C, where control returns to i but execution is resumed at a different point causes several complexities, which we shall discuss further in the next section. A special case in the above scenario is where i need not be suspended (Case D). For example the authors of a given paper wish to change the authorship and/or affiliation on the paper. Business rules state that this can be allowed only if the paper has not yet been sent to the printer. Thus, the paper may be in the submitted state, it may be under review, or pending notification. Raising of this exception will require triggering of exception handling tasks, however, it will not require suspension of the exception raising instance. That is, nodestate (n, i) remains unchanged after f. Note that the execution of (the final task in) e will be constrained to reach complete state before the first task in the 'Publication' block is scheduled. This identifies a temporal property of e. As stated above, the tasks in the process model are complex objects with rich semantics, that capture various properties of the business activities represented by these workflow tasks. This is equally true for tasks in the exception processes.
9
5
Modeling and Enactment of Exception Processes
We have proposed a modeling approach under which the business process is given as BP = {CP, P1, P2, P3, … Pk}. We do not elaborate on the modeling of the core process (CP), and instead refer the reader to several articles in the literature which focus on business process modeling, in particular on workflow modeling languages [WFMC98, SO97, Jab94]. However, as noted before, the core process may also contain exception handling logic, which is generally implemented through choice constructs in the workflow model.
5.1
Modeling exception processes
The Pi's (i: 1, 2, … k) constitute the exception handling component of the business process. We represent each Pi by the tuple (n, t, f, e, p) where n: Name of the exception t: Set of triggering objects, which could be tasks, blocks, the entire process, or external entities f: Failure condition(s) e: Exception handling process p: Type of the exception (Corresponding to the cases given in Table I) The Pi processes (e) are modeled as sub processes of the exception raising instance, when they are of the type A, B or D. The Pi's can also be views of the business process that depict a given exception. The view approach is applicable to case C, where the impact on the exception raising instance cannot be determined.
5.2
Enacting exception processes
The enactment of the core process and any exception handling tasks embedded in the core process, is handled by the workflow engine. The enactment of the exception processes however, may require some additional or extended components in the workflow management system (WFMS). In this section, we identify the actions that are required for the enactment of the exception processes, and thereby provide a foundation for an analysis of the generic architecture [WfMC95] of the workflow management system and its limitations. The foremost requirement is for the system evaluation of a failure condition (when exceptions are diagnosed through exception rules) or the external notification of a failure condition (when exceptions are diagnosed through exception workflows). Thus a mechanism is required to manage the signaling between the triggering objects and the WFMS. The workflow management system then has to search for the given failure condition in the Pi tuples, and find the corresponding exception handling process. The invocation of exception handling process will depend upon the type of Pi. Sub process: The exception handling process (e) is modeled as a sub process, when the type of Pi is A, B or D. The WFMS must include components that can transfer the control to e where required, change the node states of the tasks in the exception raising instance, and finally resume the execution of this instance in accordance with its type. View: The exception handling process (e) is modeled as a view of the business process, when the type of Pi is C, since for these type of exceptions, the impact on the exception raising instance is dependent on the current state of the instance. Type C exceptions are more likely to occur when the triggering object is the process or an external entity. A mechanism is required that dynamically charts out the subsequent execution path for the exception raising instance. This is analogous to the ‘migration’ of an instance to a workflow of another type. In other words, the exception raising process migrates to the exception process. Th migrate approach is usually addressed in the context of workflow processes that evolve in the presence of active instances [SO99]. However, to handle type C exceptions, a similar framework is required.
5.3
Handling unanticipated exceptions
A failure condition, for which no match is found, will identify a special case of Pi which represents unanticipated exceptions. This Pi is given by the tuple (Unknown, [W], NULL, empty-process, C) where n: Name of the exception: Unknown
10
t: Set of triggering objects: The entire process W f: Failure condition(s): NULL e: Exception handling process: empty-process, that is unknown process p: Type of the exception: C When an unanticipated exception is raised, the first issue is that of resolving the exception from a business point of view, that is what activities have to be performed for the exception raising instance, such that it meets with the process goals. Here, the history management component of the WFMS becomes important. Previously completed instances with unknown exceptions are searched for precedents. The stage of the instance and process data is used to find close matches. How the previous exception raising instances were handled provides guidelines for handling the current situation. Documenting unanticipated exceptions as special Pi tuples extended to include identification of the exception raising instance(s) is necessary to provide the support for precedent search. These precedents can also be the basis for process refinement or redesign after a period of observation. An unanticipated exception may eventually be implemented as a useful exception, if it recurs, and is found significantly important. After having determined the exception handling process for the unanticipated exception, the next step is to invoke the newly defined exception process. The view approach is proposed since the impact on the exception raising instance is unknown. Again, a mechanism is required to dynamically chart out the subsequent execution path for the exception raising instance. An approach to dynamic instance adaptation is given in [Sad00], which proposes the concept of 'compliance graphs' for unanticipated exceptions. The compliance graph provides a bridge between the exception raising instance and the newly defined exception process, including any rollback/compensation that may be required.
6
Contributions
Exception handling is a well-recognized, however difficult area of business process automation. Exceptions can be broadly classified as unanticipated and useful. In this paper, we have investigated the modeling of useful exceptions, so that they can be handled by the system, thus reducing or ideally eliminating the need for system workarounds, where it is difficult to establish the outcomes. Our approach is to model a business process as a composition of the core process and a set of exception processes. We have provided guidelines for specifying exceptional behavior in the three phases of exception handling, that is detection, diagnosis and resolution. Furthermore, we have presented a modeling methodology to capture the exception processes. We plan to investigate further the feasibility of this methodology and its demands in terms of WFMS components and functionality.
7
References
CCP+96
CP99
Dav93 EKR96
EL95
GHS95
F. Casati, S Ceri, B. Pernici, G. Pozzi. (1996) Workflow Evolution. Proceedings of the 15th ER'96 international Conference, Oct 7-10, Cottbus, Germany, Springer Verlag Lecture Notes in Computer Science, 1996. Fabio Casati, Giuseppe Pozzi (1999) Modeling Exception Behaviors in Commercial Workflow Management Systems. Proceedings of the Fourth IFCIS International Conference on Cooperative Information Systems (CoopIS99). Edinburgh, Scotland. Sep 2-4, 1999. Davenport Thomas (1993) Process Innovation – Reengineering work through Information Technology. Harvard Business School Press. S. Ellis, K. Keddara, G. Rozenberg. (1996) Dynamic Changes within Workflow Systems. Proceedings of ACM Conference on Organizational Computing Systems (COOCS 95), Milpitas, CA. USA, Nov 1995. J Eder, W. Liebhart (1995) The workflow activity model WAMO. Proceedings of the 3rd international conference on Cooperative Information Systems (CoopIs), Vienna, Austria, May 1995. Dimitrios Georgakopoulos , Mark Hornick, Amit Sheth. (1995) An Overview of Workflow Management: From Process Modelling to Workflow Automation Infrastructure. Distributed and Parallel Databases, 3, 119-153, 1995.
11
HA98
Claus Hagen, Gustave Alonso (1998) Flexible Exception Handling in the OPERA Process Support System. IEEE 18th International Conference on Distributed Computing Systems HS98 Yanbo Han, Amit Sheth (1998) A Taxonomy of Adaptive Workflow Management. Towards Adaptive Workflow Systems, Workshop in Conference on Computer Supported Cooperative Work, Seattle, USA, Nov 1998 Jab94 Stefan Jablonski (1994) MOBILE: A Modular Workflow Model and Architecture. Proceedings of 4th International Conference on Dynamic Modeling and Information Systems, Netherlands, 1994. JB96 Stefan Jablonski, Christoph Bussler (1996) Workflow Management - Modeling Concepts, Architectures and Implementation. International Thompson Computer Press. 1996. KD98 Mark Klein, Chrysanthos Dellarocas (1998) A Knowledge-based Approach to Handling Exceptions in Workflow Systems. Workshop on Adpative Workflow Systems. Conference on Computer Supported Cooperative Work (CSCW), Seattle, USA. November 1998. RD97 Manfred Reichert, Peter Dadam (1997) ADEPTflex - Supporting Dynamic Changes of Workflow without loosing control. Journal of Intelligent Information Systems (JIIS), Special Issue on Workflow and Process Management RS94 Marek Rusinkiewicz, Amit Sheth. (1994) Specification and Execution of Transactional Workflows. Modern Database Systems: the object Model, Interoperability, and beyond, Kim Won (ed.), Addison-Wesley, 1994. Sad00 Shazia Sadiq (2000) Handling Dynamic Schema Change in Process Models. (To Appear) Australian Database Conference, Canberra, Australia. Jan 27 - Feb 02, 2000. SM95 Diane M. Strong, Steven M. Miller (1995) Exceptions and Exception Handling in Computerized Information Processes. ACM Transactions on Information Systems, Vol 13, No 2, Pages 206-233, April 1995. SMO99 Shazia Sadiq, Olivera Marjanovic, Maria E. Orlowska (1999) Managing Change and Time in Dynamic Workflow Processes. (To Appear) International Journal of Cooperative Information Systems. SO97 Sadiq Wasim, Orlowska Maria E. (1997) On Correctness Issues in Conceptual Modeling of Workflows. In Proceedings of the 5th European Conference on Information Systems (ECIS ‘97), Cork, Ireland, June 19-21, 1997. SO99 Shazia Sadiq, Maria Orlowska (1999) Architectural Considerations in Systems Supporting Dynamic Workflow Modification. Proceedings of the workshop on Software Architectures for Business Process Management at CAiSE*99, The 11th Conference on Advanced Information Systems Engineering, Heidelberg, Germany. June14-18, 1999. SW95 Heikki Saastomoinen, George M. White (1995) On Handling Exceptions. Proceedings of ACM Conference on Organizational Computing Systems (COOCS 95), Milpitas, CA. USA, Nov 1995. WFMC95 Workflow Management Coalition (1995) The Workflow Reference Model, Document Number TC00-1003, Issue 1.1, 19-Jan-95. WFMC98 Workflow Management Coalition. (1998) The Workflow Management Coalition Interface 1: Process Definition. Interchange Process Model. Document No WFMC-TC-1016-P. Issue 7.05 beta. Aug 1998.
12
