An environment for designing exceptions in workflows

Pergamon lnjmnatron Systems Vol. 24, No. 3, 255-273. pp 1999

0 1999 Elsevier Science Ltd. AI1 rights reserved Printed in Great Britain

PII: SO306-4379(99)00018-6 0306-4379/99 $20 00 + 0.00

AN ENVIRONMENT FOR DESIGNING EXCEPTIONS IN WORKFLOWS+

FABIO CASATI~, MARIAGRAZIA FUGIN? and ISABELLE MIRBEL~

IHewlett-Packard Laboratories, 1501 Page Mill Road, Palo Alto, CA, 94304, California, USA

‘Dipartimento di Elettronica e Informazione, Politecnico di Milano, via Ponzio 34/5, I-20133 Milano, Italy

3DQpartement Informatique, Universit de Nice - Sophia Antipolis, Part Valrose, 06108 France

(Received 16 October 1998; in final revised form 1 April 1999)

Abstract - When designing a workflow schema, the workflow designer must often explicitly deal with exceptional situations, such as abnormal process termination or suspension of task execution. This paper shows how the designer can be supported by tools allowing him to capture exceptional behavior within a workflow schema, by reusing an available set of pre-configured exceptions skeletons. Exceptions are expressed by means of triggers, to be executed on the top of an active database environment. In particular, the paper deals with the handling of typical workflow exceptional situations which are modeled as generic exception skeletons to be included in a new workflow schema by simply specializing or instantiating them. Such skeletons, called patterns, are stored in a catalog; the paper describes the catalog structure and its management tools constituting an integrated environment for pattern-based exception design and reuse. 0 1999 Elsevier Science Ltd. All rights reserved

Key words: Workflows, Exceptions, Design Patterns

1. INTRODUCTION

Workflow systems are currently becoming a widespread technology in the organizations, pro-

viding a common framework to support office and production activities. Workflow design aims at capturing the possible sequences of activities needed to reach a given business goal, and at linking the workflow to the existing Information Systems of the organization. During the design, various

aspects have to be considered in conjunction with the pure activity flow, and the designer has to provide many details in order to obtain a workflow which is executable by a Workflow Management System (WfMS) and which achieves the business goal. A workflow description requires the specification of both the normal flow and the possible variations due to exceptional situations that can be anticipated and monitored. The WIDEt Project has proposed the use of Event-Condition-Action (ECA) rules (also called triggers in the WIDE terminology and in this paper) to model exceptional situations that alter the normal activity flow. In fact, exceptions are often asynchronous

with respect to the normal flow, both in their raising (which is often not related to the start OI

completion of a specific task) and in their reaction (which often does not require the activation of a task or process). For these reasons, it is inpractical to model exceptions within the flow graph the defines the flow of control between workflow tasks. The ECA paradigm seems instead partic- ularly suited for modeling exceptional situations: WIDE triggers allow the definition of events to

be monitored, of conditions that verify whether the occurred event corresponds to an exceptional situation that must be monitored, and of actions that react to the exceptional event, that include, but are not limited to, the activation of tasks or processes. However, the applicability of WIDE triggers goes beyond the management of exceptional situations: they can also model conditions relating the starting, termination, or repetitions of workflow instances (called cases) or regarding

the periodical occurrence of operations in the workflow execution. In this paper we are concerned with the specification of exceptional situations and other aspects

of workflow applications that can be modeled by means of triggers. The following main issues are at the basis of the approach:

tRecommended by Barbara Pernici and Costantino Thanos t WIDE: Workj?ows on an Intelligent and Distributed database Environment

256 FABIO CASATI et al.

l rules (or triggers): they model exceptional situations and more in general those situations that cannot be suitably represented within the flow structure, such as reactions to events that are asynchronous with respect to the normal flow;

l patterns: they model reactive behaviors that may be used in several designs. Patterns describe triggers, or sets of related triggers, that control a given typical situation. Patterns are a way for the designer to specify the workflow schema by reusing previous design experience.

The issue of defining the different (normal and exceptional) aspects of an application has been addressed in other related fields, such as in Software Engineering and Information Systems, where

techniques and tools combining data and function modeling are adopted, in order to represent the application functionality and to describe both normal and abnormal situations and exceptions [17]. Currently, few techniques and tools exist for workflow design. Some of them [22] are based on rules and catalogs of predefined workflow portions for workflow management.

This paper focuses on the description of a tool environment for the specification of workflow

exceptions, modeled as triggers. Triggers are included in a schema by reusing (i.e., selecting and customizing) a set of pre-defined generic trigger skeletons stored in the tool catalog as patterns.

The support environment, called WERDE, consists of the pattern catalog, of tools for accessing the catalog and for reusing the suitable patterns, and of tools for managing the catalog. The set of typical patterns stored in the catalog enables the designer to deal with frequent occurrences

of similar situations in workflow design in given application domains, and with generic situations

that may occur in any application domain. The WERDE environment is presented in terms of architecture, implemented features, and interaction with the workflow execution environment of

WIDE. The paper is organized as follows. In Section 2, we frame our work in current research in

workflow management, databases, software engineering, and information systems. In Section 3, we illustrate the catalog of patterns, and describe the use of triggers in workflow design by presenting exceptions, patterns, and examples of patterns. In Section 4, we present the architecture of WERDE and its features for accessing and managing the pattern catalog; we then show the tools usage for

exception design and analysis. Finally, Section 5 concludes the paper and presents our future work.

2. RELATED WORK

The problem of managing exceptional situations in workflow execution has received increasing attention in recent years. One of the first contributions to managing workflow exceptions came from Eder and Liebhart [13]. They analyzed the different exceptions that may occur during process execution, and divided them into four classes: basic failures, that deals with failures of the WfMS or of the environment in which it executes; application failures, corresponding to failures of the applications invoked by the WfMS in order to execute a given task; expected exceptions, that are predictable deviations from the normal behavior of the workflow; finally, unexpected exceptions cor-

respond to mismatches between a business process and its workflow process definition. While basic and application failures are problems that WfMSs “inherit” from traditional information systems,

and are typically handled at the system and application level (e.g., by relying on the capability of the underlying DBMS to maintain a persistent state and support forward recovery), expected and

unexpected exceptions are peculiar of workflow management, and demand new methodologies and techniques in order to effectively managed. Unexpected exceptions, being caused by inconsistencies between workflows and the processes they describe, must be handled by modifying the workflow definition [7, 191. In this paper, we are mainly concerned with expected exceptions.

Many approaches to handling expected exceptions aim at capturing task semantic failures i.e., situations in which a task is unable to reach its business goal. These approaches share the same basic idea: every task is associated with a compensating task, that semantically undoes the effects of the forward task. As a task fails semantically, compensation is started by executing compensating tasks (usually in the reverse order of the forward execution) until a decision (split) point in the flow is reached, from which forward execution is resumed, possibly along a different path (e.g., see [3, 2, 13, 25, 261). WAMO [14] and Crew [21] extend this approach by providing

An Environment for Designing Exceptions in Workflows 257

more expressive workflow models and by allowing the workflow designer to define transactional

properties for each task, for instance by specifying if a task actually needs to be compensated (re- executed) when involved in a backward compensation (forward re-execution). TREX [28] offers more features for dealing with expected exceptions, by allowing the definition of rules of the form: task x exception -+ exceptionhandler where a specific exception handling strategy may be associated to each <task, exceptional situation> pair. For instance, a rule may specify that as a given exception occurs for a given task, the task itself is re-executed, an alternative activity is executed in its place, or the process is aborted (compensated).

The OPERA process support system [18] takes a step further, by allowing more flexibility and

by providing primitives for managing generic exceptional situations: the workflow designer may define exception handling flows (with the same formalism used for the specification of the normal

flow), activated by explicit notification from external applications or as a given predicate over process data is satisfied. OPERA offers exception handling capabilities similar to those of WIDE; however, WIDE exception handlers can be also triggered by temporal events and provides more

exception handling primitives, also including (but not limited to) the activation of an exception handling flow. Furthermore, WIDE provides a pattern-based environment that support the design and reuse of exceptions in workflows, which is the focus of this paper.

Patterns have become a common design paradigm in software development, especially in the field of object-oriented systems, to enhance component reuse by encoding design experience [16].

The abstraction mechanisms used to define patterns allow capturing static and dynamic struc-

tures and collaborations of components. As such, they are useful in solving common problems arising in designing software in different application domains, such as business data processing, telecommunications, graphical user interfaces, and distributed communication software. In [15],

a classification system is described for organizing a pattern catalog at different granularity and abstraction levels. Sample patterns identified on a number of a large-scale distributed system are presented in [27] showing the process of reusing communications architectures.

Application frameworks described in [20] also represent a kind of pattern. Patterns are viewed as a description of a problem, of a solution, and of the context in which this solution works. In [16], patterns, or more precisely, pattern languages, are related to frameworks in that patterns capture unifying aspects in software development moving reusability from the level of components up to the

higher level of large architectures [6]. Examples of patterns that were factored out by examining a number of frameworks and chosen as representative of reusable object-oriented software are

given. A single framework contains many patterns and, since patterns are not expressed in a object-oriented language, they are more abstract than frameworks.

In the database field, rule patterns have been recently proposed as an approach to designing active object-oriented database applications [24]. Rule patterns can be regarded as an extension of design patterns to the problem of specifying business policies in database design in an application- independent way. Rule patterns are abstractions of business rules endowed with pre-defined as well

as parameterized parts. A library of rule patterns is defined [23], organized as a set of dictionaries extensible by defining new patterns or by specializing the existing ones.

The pattern-based approach presented in this paper borrows concepts and solutions from both design and rule patterns to support workflow design. Existing approaches to workflow specification mainly deal with the use of rules in specific contexts serving as a mechanism for workflow enactment and evolution. Our approach is instead focused on providing abstraction mechanisms to represent in an application-independent manner the knowledge and experience associated with exceptions

and rules design in workflows. The approach is also focused on providing classification mechanisms for pattern storage and retrieval in a structured catalog of inter-related patterns and on providing

tailoring mechanisms for specializing and instantiating catalog patterns.

3. THE PATTERN CATALOG

This section describes the core component of the WERDE environment: the catalog of patterns. This component stores a set of pre-defined workflow patterns at different levels of abstraction and generality in a layered structure. The catalog is the centralized repository of WERDE, where


reusable workflow elements are available in order to support the “specification-by-example” of different elements of a workflow, at different granularity levels, such as processes, exceptions, and tasks.

We identified three main categories of patterns: built-in patterns, generic tasks, and generic application-oriented structures, as depicted in Figure 1.

Pattern catalog

Built-in patterns

Integrity patterns

Continuation patterns

_ Count patterns

Basic patterns

Interaction patterns

Starting patterns

Authorization patterns

Schema-evolution patterns

Organizational patterns

Other patterns

Generic

tasks

Generic application-oriented

stmctures

Information use

Remainder

Other patterns

Document preparation

Document revision

Reservation

Other patterns

Fig. 1: The WERDE Pattern Catalog

l Built-In Patterns. Patterns at this level deal with reaction to events and time alarms (Basic

patterns), integrity and security constraints over workflow data (Authorization, Integrity, and Count patterns), workflow management (Starting, Interaction, and Continuation pat-

terns), and with changes in the organization structure (Organization and Schema evolution patterns). They describe context-dependent and time-dependent knowledge related to basic exceptional situations independent of the semantics of all possible applications. Built-in patterns specify, for example, basic interactions between workflow elements, or situations where

a task has to be suspended or resumed, or express exception requirements related to workflow interoperability. Built-in patterns are implemented as generic rules that can be adapted to different application contexts.

Figure 2 shows the pattern classification for Built-in patterns. The rightmost column include top-level built-in pattern categories, the middle column presents second-level categories, while

the third column shows the triggers included in each category. In general, an arbitrary number of subcategories can be defined.

l Generic Tasks. Patterns at the generic tasks layer allow the description of frequently occurring activities in workflow design in the form of tasks, independent of the information items involved in their execution (e.g., a task for registering information in a document).

b Generic Application-Oriented Structures. This layer of the catalog contains workflow fragments and associated exceptions needed to model frequently occurring situations of one or more application domains. These are frequently occurring combinations of tasks (i.e., workflow fragments) generally performed together to achieve an organization goal in a given application domain (e.g., a generic structure describing the concurrent review of a document by several people). A detailed description of the pattern catalog can be found in [ll].


CATEGORY SUBCATEGORY TRIGGERS

SINGLE ENTRY PONT

STARTING

SIMULATION OF MULTIPLE

Fxl-RY P”Nr . multipleEntryPolnt

JOIN I b ~oinCOntlnuation

CONTINUATION MULTITASK w multltnskContinuatlon

WAIT , wal1CondiLlon

TERMINATION _____+ termlnntlon

couvr b taskCount

VARIABLE RANGE

creattonOutOfrange w modtficattonOutOfranRe

INTEGRITY ,

wrongA\sstgnmentAtTaskStart

WRONG VARIABLE wrongAsslgnmentAtTaskEnd

ASSIGNME~ -. wrongAssignmentAtCaseStart

wrongAsslRnmentAtCaseEnd

INVALID VALUE 1nvalldValueAtTaskStart

b invalldValueAtTaskEnd ~nvalidValueAtCa.seStart InvalidValueAtCaseEnd

prlorityChange

EVOLWION + newExternalEvent

compensatingAction

AUTHORIZATION

AUTHORlZ4TlON separatlonOfDutles

* bindtngOfDutles roleExamInatIon

OPERATION A~HORIZATION t unauthorlzaedOperatlon

INTERACTION

SYNCHRONOUS b synchronousDocumentExchange

ASYNCHRONOUS b asvnchronousDocumentExchanee

Fig. 2: Classification of Built-In Patterns


In this paper we are concerned with rule and exception design, and therefore we focus on built- in patterns. Indeed, the use of patterns to support exception design has proven to be very useful, since often similar exceptions have to be managed in different workflows. For instance, many workflows are faced with the need of managing such situations as the cancellation of an order or of a service request, or the violation of data or temporal constraints. Patterns define these behaviors in abstract forms, and may be reused for different workflow applications, thereby improving the speed and the quality of the exception design.

In order to be accessible and user friendly for the designer, the catalog associates to each pattern a Pattern Specification and a Sample Usage. The first describes the exception and includes parts allowing the designer to understand the goal of the pattern, to locate the pattern in the catalog, and to link patterns together within a workflow schema. The second contains sample instantiations of patterns in various application domains, thus guiding the designer in completing a new workflow schema. For details about the patterns contained in the various categories of the catalog, the interested reader can refer to [ll].

We now present a sample workflow schema that will be used in the following of the paper in order to introduce our approach to pattern-based exception design.

The workflow schema, depicted in Figure 3, models a hotel Room Reservation business process. As an instance of the workflow is activated, the task Get Customer data is executed. When data have been collected, the clerk checks for the availability of a room of the requested type (task Check Availability). If such a room is available, then the room isbooked. (task Book Room) and the confirmation (along with the payment request) is sent to the customer (task Send Confirmation and payment Request). If no room of the requested type is available for the selected day, then the clerk checks for room availability in a partner hotel of the same city (task Check at Associated Hotel). If a room is found, then it is booked and the confirmation and payment request are sent to the customer, otherwise a rejection answer is given (task Send Rejection Answer). The sample workflow schema includes two triggers: trigger customerCancel manages cancellation of room reservation requests, while trigger missingPayment, activated as case execution is completed, handles reservations for which the payments are not received within a specified deadline.

3.1. Exceptions

A short introduction to the exception language is now given (see [lo] for a detailed description). The Chimera-Exe exception language is based on the Chimera language for active object-oriented databases. An exception is specified by an ECA rule. Events denote the occurrence of a possibly exceptional situation; conditions determine if the occurred event actually corresponds to an exceptional situation to be managed, while the action part defines the operations to be performed in order to manage the exception. ECA rules may refer in their event, condition, or action part, to objects and classes of the WfMS database. These include static and dynamic information on workflows and tasks (stored in objects of classes case and task respectively), data relating workflow participants (objects of class agent or role), plus a workflow-specific class, bearing the name of the workflow, whose objects store process-specific variables local to each single case. For instance, variables needed for the execution of cases of a hotel roomReservat ion workflow, such as the room number or the customer name, are stored as attributes of an object of the roomReservation class.

An exception can be sensitive to different kinds of events:

data events are raised upon modification of the content of the WfMS database. Data events include the creation of a new object (create), the modification of an object’s attribute (modify), and the deletion of an object (delete). For instance, event modif y(task) is raised when an attribute of an object of the task class is modified.

Workflow events are raised when a case or task is started or completed. Workflow events include casestart, caseEnd, taskstart, and taskEnd. For instance, event taskstart (myTask) is raised when an instance of task myTask is started.

Temporal events are raised upon the occurrence of a defined temporal instant. They can be expressed as deadlines, temporal periods, or interval elapsed since a specific date or time. For


customerCancel

Legenda

Task

0 Conditional Fork

0 And-Fork, And-Join

Or-Join

.-: 7 Trigger

r

Room Reservation WF

Get Customer

Availability+&

RoomFound=“no

Book Room

I

Send Confirmation and Payment

Request

w

Send Reiection AlMVer

/-2/T 1

Fig. 3: The Room Reservation Workflow Schema


instance, event elapsed 1 day since taskStart (myTask) is raised as one day has elapsed since the start of an instance of task myTask.

l External events, qualified by their name, are notified by external applications: these may correspond to applicative situations, such as a phone call by a customer canceling a reserved room. An example of external event is raise (cancelReservation).

The condition part consists of a declarative query, expressed by a formula evaluated over the WfMS database state. The formula is expressed as a conjunction of predicates, and includes a set of variables to which bindings are associated as a result of the formula evaluation: if the result of the query is empty (i.e., if no bindings are produced), then the condition is not satisfied, and the action part is not executed. Bindings resulting from the formula evaluation are passed to the action part in order to perform the reaction over the appropriate objects. The condition includes class formulas, for declaring variables ranging over the objects of a specific class (e.g., task(T)), type formulas for declaring variables of a given type (e.g., real(R)), and formulas expressing comparisons between expressions (e.g., T. executor=” Lisa”). Objects affected by events are captured in the condition part by the occurred predicate. Thus, for instance, in an exception triggered by the casestart event, the binding with the started instance is obtained by means of the predicates case(C) , occurred(caseStart ,C>.

The action part includes data manipulation actions, updating the content of the WfMS database, and operations executed through calls to the workflow engine. The first category includes the primitives create, delete, and modify. For instance, delete (Log, L) deletes all objects of class Log to which L is bound after the condition evaluation. The second category includes primitives to start, rollback, or suspend the execution of cases and tasks, assign or delegate the execution of tasks, and send messages to agents. Examples are delegateTask(T,A), startCase(mySchema, startingparameter), and notif y(T. executor, “deadline is approaching”).

A sample trigger activated at the end of cases of the roomReservation workflow is as follows. The condition determines which is the case that has caused the triggering (predicate case(C), occurred(caseEnd,C)), retrieves the object storing the variables of the just completed case (roomReservation( R. caseId=C) and then checks if the customer has not paid (R.paymentDone=FALSE). If the condition is verified (i.e., if bindings are produced), then the action part is executed, causing the start of an instance of the cancelBooking workflow and providing the customerID as input parameter. The Chimera-Exe specification of the trigger is given below:

define trigger missingPayment events caseEnd condition case(C), occurred(caseEnd,C) , roomReservation(

R.caseId=C, R.paymentDone=FALSE act ions startcase (“cancelBooking” ,R. customerId) end

Rules can be associated to a task, to a schema, or to the whole WfMS. Task-level rules model exceptions which are related with a single task; an example is a rule reacting to the task deadline expiration. Workflow-level rules define a behavior common to every task in a schema, or model exceptions related to the whole schema; for instance, a workflow-level rule could specify that all tasks of a the workflow should be suspended at 7pm. Finally, global (WfMS-level) rules model behaviors defined for every task or case, or exceptions involving cases of different workflows. For instance, an exception stating that “tasks that were assigned to an agent who left or is on vacation must be reassigned” should be declared at the WfMS-level, since it defines a general policy valid for every task.

Rules can be ordered by absolute priority. Upon concurrent trigger, the scheduler executes first the rules with higher priority. Among rules with the same priority, the choice is non-deterministic.


3.2. Patterns for Exceptions

Since the Chimera-Exe language is quite flexible, it allows the definition of a variety of exceptional behaviors. However, experience in exceptions design has shown that, although all the language features are required, most triggers follow common, repetitive LLpatterns”. These obser- vations led to the idea of taking advantage of repetitive patterns in triggers definition, in order to

reduce the design effort and to provide guidelines for pattern reuse.

We introduce patterns as generalized descriptions of triggers and exceptional situations that can frequently arise in workflow modeling. Patterns predefine typical rules or set of rules that capture the knowledge about the occurrence of an exceptional situation and the actions that can be performed to deal with it. Patterns consist of predefined parts, parameterized parts, and optional parts. Parameterization and optionality are introduced to support pattern re-usabilit]

and adaptation in workflow design for the aspects related to exception modeling and handling. The structure of the patterns in the WERDE catalog is described below.

Patterns are described by a specification part and by a sample usage part.

1. Specification Part: The specification part is the abstract description of an exception. In

particular, the pattern specification is structured along the following fields (see [9] for a complete description of the pattern specification language):

l name, uniquely identifying the pattern in the WERDE catalog;

l intent, a textual part describing the purpose of the pattern (intended scope and known

uses) ;

l classification, according to the categories and sub-cat,egories of the catalog;

l template, containing the core specification of the pattern. The specification is given in terms of events, conditions, and actions. Unlike events and conditions, which are the

main parts of the patterns, the action part provides only suggestions. This reflects the fact that exception patterns focus on how to capture exceptions, rather than on how to fix reactions, which are application dependent: in a given application, a warning message

can be a satisfying reaction, while a cancellation of the case can be more suitable in another application of the same pattern.

The template contains parametric fields (also called generic terms in the following) to be filled in with specific values provided by the designer; mandatory and optional parts can also be specified.

l keywords, which are a set of user-selected terms that can be used to refer (select, search, etc.) to the available patterns in the catalog; this field allows one to describe more precisely the topics of the pattern, especially to distinguish the different patterns of a given category in the classification;

l related to, establishing links among patterns to combine them in different structures;

l guidelines, providing suggestions to the user about possible usage and personalization

of patterns.

2. Sample Usage Part: Since the user of the catalog is intended to be an expert of the application under design but is not required to have a detailed knowledge of the Chimera-Exe syntax, the pattern model is endowed with some user-oriented sample usage pattern. This is a set of

instantiations of patterns on specific examples. They show how patterns can be personalized in different contexts and applications by illustrating how parameters of patterns can be supplied by the designer to produce a concrete workflow. The sample usage description is a set of workflow-specific instantiations of patterns related to an application domain. In general, several examples are provided for a pattern for different domains. The sample usage is an instantiation of the variables/parameters appearing in the template field of the pattern specification according to the domain selected to construct the example.


Sample usage define trigger missingPayment events caseEnd condition case(C), occurred(caseEnd.C), roomReservation(

R.caseId=C, R.paymentDone=FALSE actions startCase(“cancelBooking”, R.customerId) end

Fig. 4: The Termination Pattern

define trigger events condition

actions end

Sample usage customerCancel raise(“customerCancel”) externalEvent( occurred(raise(“customerCancel”), E), roomReservation( R.customerId=E.intPa notify(R.responsible, “Customer has canceled the room reservation request)

Fig. 5: The externalEvent Pattern

3.3. Examples of Patterns

Figure 4 shows a sample pattern specification, that starts a new case upon termination of another one. The pattern belongs to the continuation I termination category (see Figure 2). As a case terminates, the pattern checks a predicate over workflow data and, if the predicate is verified, indicating that some exceptional situation has occurred, it activates an instance of a different workflow, in order to cope with the exception. The template part consists of a generic trigger, activated as a workflow instance terminates (event caseEnd). The condition part identifies


the completed case (case(C) ,occurred(caseEnd,C)), defines an object variable W that ranges over the workflow variables of a given (but generic) workflow schema (<wfName>(W)), and then restricts it to range over the variables of the completed case (W. caseId=C). Note that the name of

the workflow is in fact left unspecified: it is generic, and has to be defined when instantiating this pattern into a Chimera-Exe trigger.

Finally, the condition allows the definition of a predicate over the workflow data of the completed case (W. <variable>=tvalue>). If the condition holds, then the action part activates an instance of another workflow (startCase(<wfName>,<parameters>). The missingpayment trigger given in Section 3.1 is a sample usage of the termination pattern shown in Figure 4.

Figure 5 shows a pattern dealing with external event handling. The template part consists of a generic trigger, raised at the occurrence of an external event. The condition part of the pattern

template declares a variable E ranging over the occurred events of a given (but generic) type

(externalEvent( occurred(raise("<externalEvent>") , E)) and defines an object variable W that, ranges over the workflow-specific variables of a given (but generic) workflow schema (<wf Name> (W)). The pattern condition also include optional parts that matches case variables with the parameters of the external event, in order to determine which are the cases affected by

the external event,. The figure also show a sample usage trigger, which is the customerCancel

trigger defined for the roomReservation workflow.

4. SPECIFICATION OF THE EXCEPTION DESIGN ENVIRONMENT

In this section, we present the WERDE environment supporting the pattern-based approach illustrated in Section 3. We first introduce the tool architecture and the functionality, and then

we present the sample usage of the tool. We also show how the WERDE development environment is interleaved with the WIDE execution environment.

4. I. Tool Architecture

This section presents the architecture and the features provided by the WERDE tool and gives

a usage example. The architecture is depicted in Figure 6.

SCHEMA ANALYSIS ;

1 Schema Analyser Creation

Modification I Deleti0ll t

I ___________________---________________ I ____________________---_-_-___------------------

Schema Editor SCHEMA MANAGEME* I

Keyword-based search Classification-based search

Catalog Manager

Fig. 6: Architecture of the WERDE Tool


Fig. 7: Interaction between WERDE and the WIDE Engine via the Workflow Schema Repository

The definition of an exception for a workflow schema is performed through the Schema Editor module, based on reusing the available patterns. From within the Schema Editor, the designer can

interactively search the catalog for a suitable generic pattern using the Exception Retriever module. Retrieved patterns are instantiated/personalized for the workflow schema at hand, through the

Exception Writer module, which can also be used to define new patterns or exceptions from scratch, if the available ones do not fit the workflow requirements. Exceptions defined for a schema can be analyzed by exploiting the Schema Analyser module of WERDE. The Catalog Manager performs

the catalog management functions that is, insertion, modification and deletion of pa&terns.

Figure 7 shows that the interaction between WERDE and the WIDE workflow engine occurs via

the workflow and exception schema repository. WERDE stores and retrieves patterns from a local repository (the catalog), which is not accessed by the workflow engine. WERDE and the WIDE engine share instead the workflow schema repository: WERDE accesses the schema repository in order to insert, modify, and delete workflows and Chimera-Exe rules. The defined workflow schemas

are then accessed and interpreted by the WIDE engine at workflow execution time. Workflow

execution may involve modification of system and workflow relevant data, which are only accessed by the WIDE engine and not by WERDE, which is not concerned with workflow instances and workflow execution.

A Visual C++ /Windows prototype of WERDE is available, operating in a Client/Server envi-

ronment, in accordance with the design guidelines of the other WIDE tools.

,$..2. Using the Catalog

The exception design process proceeds according to a “specification-by-example” paradigm:

different elements of a workflow, at different granularity levels, are progressively inserted in the workflow schema by the designer, such as process variables, tasks, and exceptions. For exceptions,

the pattern catalog is accessed by browsing the available patterns, selecting the suitable ones, and

specializing/instantiating these patterns to fit the requirements of the specific schema. Exceptions are designed in a bottom-up way, based on reusing the patterns available in the

catalog. The tool guides the designer by providing both classification information, which facilitates

the search in the WERDE catalog, and guidelines to enter values for pattern parameters. A typical exception design session consists in retrieving a pattern by means of the Exception

Retriever module, and in instantiating the retrieved pattern by activating the Schema Editor module. The following features are provided by the tool in order to support the exception design process:

l Retrieval, to access the catalog and search for suitable patterns. Two search modalities are provided, namely, keyword-based and classifzcation-based search. The first relies on a predefined thesaurus of terms loaded at pattern specification time to characterize the pattern within the catalog. Keywords can refer either to pattern elements (e.g., names of events, actions) or can be more generic, domain-related keywords. The second modality allows for the retrieval of natterns based on two criteria.:


O-4

(4

Fig. 8: Pattern Retrieval. Selection of Retrieval Option (a), Keyword Specification for Keyword-Baaed Retrieval (b), and Presentation of the Retrieved Pattern (c)


- typology of pattern, with respect to event types (e.g., temporal, external, data);

- abstraction level of patterns in the catalog (built-in, generic, application-oriented).

Figure 8(a) show? the “Retrieve Option” screen where the various search modes are available In particular, consider that the termination pattern is being searched by keywords, x depicted in Figure 8(b). The result of the search appears in Figure 8(c).

l Insertion, to support the interactive definition of exceptions starting from a retrieved patterr or from scratch. Exceptions can be derived from retrieved pattern by instantiation. A patterr is instantiated by replacing the generic term with a value; for instance, <wfName> becomer roomReservation. If there are optional parts, the user has to decide if he/she takes the optional parts or not. If several possible actions are defined in the action part, it is alsc necessary to choose one or several of these actions. It is also allowed to add conditions 01 actions to the trigger, for example to test the value of a variable which is specific to the workflow under design.

The instantiation is performed by exploiting the syntax-driven capabilities of the Exception Writer module and the template interface facility of WERDE. This facility consists of a set of dialog windows which drives the designer in entering the patterns fields, possibly enabling the visu@ization of the guidelines and usage examples associated with the template under manipulation. The dialog facilities of the Exception ‘Writer support also the definition of neu exceptions from scratch. The instaritiation of the termination pattern retrieved through the steps depicted in Figure 8 works as shown in the sample work session of Figure 9, where the pattern is instantiated to obtain the trigger missingpayment of Section 3.1. The instantiation steps consist of activating the exception writer module, selecting the item to be instantiated (<wfName> (W) in the example of Figure 9), and overriding it with the desired Chimera-Exe condition (roomReservation(W

l Modification, to modify exceptions inside exception schemas (i.e., in the set of exceptiom defined for a given workflow).

l Deletion, to remove exceptions from exception schemas.

l Analysis, to analyze the exceptions written for the current schema, using the Schema Anal- yser module. Exceptions in workflows are typically designed individually, by identifying the

exceptional situation, selecting the appropriate pattern from the catalog, and instantiating it in order to obtain a Chimera-Exe exception. However, although an exception considered individually may be dorrectly specified, mutual interactions among exceptions may lead ta

unforeseen and undesired behaviors. For instance, a set of exceptions may trigger each other, or two exceptions might operate on the same data, with the consequence that, if they are concurrently triggered, the final result of their execution depends on their non-deterministic execution order.

Exceptions analysis aims at statically (i.e., at compile-time) verifying that such undesired interactions do not occur. In particular, it aims at verifying two significant properties for a set of exceptions: termination and confluence [l, 4, 5, 121. Termination holds if exceptions dc

not trigger each other indefinitely, so that rule processing eventually terminates. Termination analysis is typically based on building graphs depicting triggerings and activations among exceptions, and on detecting cycles in these graphs (see [4, lo] for details).

ConfEzlence requires the final effect of the rule processing (represented by direct or indirect changes to the WfMS database) to be independent on the (non-deterministic) scheduling of triggers having the same priority [9]. Sufficient conditions for confluence have been proposed in [l, 5, 91. Unfortunately, the above properties are undecidable in the general case.

A fully automated analysis of interactions between exceptions is generally difficult to achieve, since it requires to understand the semantics of conditions and actions. A simple, conservative solution consists in checking that exceptions query and operate on different classes. More


Fig. 9: Instantiation of the termination Pattern

sophisticated and less conservative techniques for rule analysis, which consider the semantics

of conditions and actions, have been proposed in [5].

In the WERDE prototype, the Schema Analyses module uses some of the techniques proposed for active database rule analysis, and adapt them in order to make them suitable for Chimera- Exe rule analysis and for the workflow domain. In particular, Chimera-Exe rules have several types of event and actions, which are not limited to data manipulation. Hence, triggering

dependencies between actions and events have to be understood and formalized. For instance, the Chimera-Exe action startcase raises event, caseStart (and all events defined as delays elapsed from the case start).

Another important difference between database rule analysis and exception analysis is that WERDE can exploit the information related to the context of rules. In our model, exceptions are always triggerable, and if two exceptions share the same triggering event, they are both

triggered as the event occurs, regardless of which part of the case is currently in execution. However, it is a good design practice to constrain the exception to be effective only when

the element for which they have to manage exceptions (e.g., a case or task) is running. This can be done by means of suitable predicates defined within the condition part, such as C. status=“running”. In this way, even if the exception is triggered regardless of its context,

the action will be executed only if the task or case it is monitoring is active. Therefore, if

this is done, exceptions become context-sensitive, and the analyzer can improve the quality of the analysis, by exploiting the additional information that only those exceptions declared for tasks or cases that, may be concurrently active can interact,.

WERDE currently performs termination analysis by detecting triggering cycles, where triggering relationships among rules are determined by performing a syntactic analysis of events and actions and by accessing the system-defined list of pairs (action, eventset), that defines which events are triggered by a given action. WERDE also provides a limited form of confluence analysis, by focusing on interactions between pairs of exceptions. In WERDE, two triggers are considered as conflicting if they are active simultaneously and contain incompatible actions; actions are incompatible if the order of their execution leads to different states of t,he workflow management database [lo]. A (predefined) table of incompatible actions is


maintained to support the analysis, which can be performed at three levels:

- task level, to check exceptions defined for a given task;

- task set level, to select a number of tasks for which the exceptions must be analyzed;

- schema level, to check all the exceptions defined in the schema.

Anomalous situations detected by the Analyser are signaled to the designer who can activate the Exception Writer for editing the involved exceptions.

4.3. Managing the Catalog

Fig. 10: Creation of the Termination Pattern in WERDE

The pattern catalog is extensible by defining new patterns and/or specializing the existing ones. To this purpose, WERDE provides maintenance functionality to manage the catalog (Catalog Manager module). Management of the pattern catalog deals mainly with the creation, modification and deletion of patterns. However, it also takes into account the management of the categories used to classify and retrieve patterns. In this section, the WERDE functionality for pattern management followed by the environment functionality dealing with management of categories are presented.

Pattern Management:

This functionality deals with the creation, modification and deletion of patterns. When creating a pattern, the pattern template is specified by invoking the Exception Writer editor. Its different parts have to be filled-in by the user: name, intent, classification, template, keywords, related- to patterns and guidelines. The pattern name must be unique. The classification conforms to the categories and sub-categories of the catalog. Patterns keywords can be selected from a tool- proposed list of keywords and belong to a thesaurus automatically updated whenever new keywords are specified for newly defined patterns. Guidelines can be textual information to be compiled off- line by the pattern designer. Links between templates (“related-to” fields) can be defined by activating an “add link” and starting a corresponding dialog window. Sample usage can also be written to facilitate pattern reuse. A pattern can be defined from scratch or by specializing an existing one. A pattern can be specialized in three different ways, that can be combined.

An Environment for Designing Exceptions in workflows 271

l The first way consists in rewriting the generic trigger using more specific generic-terms.

Consider a pattern composed of a trigger with an event part containing the generic term

<referenceEvent>. If the designer wants to write another pattern with the same structure, but focused on external events only, he/she can specialize the exception part of the pattern by replacing <referenceEvent> with the more specialized term <externalEvent>.

l The second way consists in instantiating part of the generic trigger. This is done by replacing a generic term by a non-generic one. For example, <class> in a given trigger of a pattern can be specialized into task in a specific pattern dealing only with tasks.

l The third way consists in adding conditions and (suggested) actions to a given generic trigger in order to obtain a more specialized one. These additions can be done only in the condition and actions parts. Adding events is not allowed since this would change the invocation of

the trigger.

If the specialization mechanism is used to create a new pattern, an existing pattern P can be select,ed with the Exception Rettiever component, and the designer can select the parts of P that must be modified. The pattern has to share at least one keyword of its generic pattern (the pattern from which it is derived) and has to be placed in the same category/sub-category. Links are maintained in the catalog between patterns belonging to a specialization chain.

An example of work session, dealing with the specification of the termination pattern shown

in Figure 4, is presented in Figure 10. When mod$ying patterns, new examples can be added to an existing template, by defining an

“executable example” and by selecting the template of interest from the catalog. It, is also possible to change the category and/or sub-category of a pattern. This means changing the location of the pattern in the repository, but also changing the location of the patterns linked to it through specialization or generalization, in order to maintain the catalog consistency.

Deletion of patterns is performed by selecting the pattern of interest. The tool then performs

a set of basic integrity checks:

l if another pattern uses the current one, the link is also removed;

l if the pattern is involved in an inheritance hierarchy (is inherited by at least a pattern ps, and possibly inherits also from at least pattern pl), the user has to choose (i) to delete also ~2, or (ii) to build a new inheritance link between p1 and pz.

Category Management:

As presented in Section 3, the catalog is divided in categories (built-in patterns, generic

tasks and generic application-oriented structures). Each one is divided in sub-categories: Termination, for example is a sub-category of the

built-in I continuation I termination category. Since the catalog evolves during time, it is possible to add new categories and sub-categories, and to remove some of them. Removal of categories

implies the deletion of ail sub-categories, provided that the designer has already canceled all the corresponding patterns. WERDE checks that no patterns of the catalog refer to the category or

sub-category being deleted.

5. CONCLUDING REMARKS

We have presented the WERDE environment supporting the design of exceptions in workflow schemas. The environment is based on a catalog of workflow patterns which are a generalized description of triggers that model frequently occurring exceptions that can be reused when designing a new workflow schema. Triggers model both exceptional situations and typical start/end/repetitions of operations in a workflow. We have presented the structure of the pattern catalog and the mechanisms for pattern reuse. We have also described the features of the WERDE tool for exception design and catalog management.


Currently, the catalog is populated with a set of patterns which have been constructed by

analyzing a set of real cases provided in the WIDE Project testbed. A set of primitives for pattern reuse has been fully specified in [9] and is being tested to check the quality of these patterns in terms of significance and accessibility for reuse. In particular, the sample usage of patterns stored in the catalog are proving to be an effective means for guiding the designer in selecting the appropriate patterns, in instantiating them appropriately, and in inserting the exceptions correctly in the workflow schema.

The implementation of WERDE has currently completed most of the features described in the paper. Some features, such as pattern design and schema analysis, are being extended in order to achieve a more complete and effective suite of functions. For example, for schema analysis, we plan to consider exception termination analysis and confluence analysis on rule sets, and to consider in more detail the semantics of actions and conditions. For pattern design, we plan to have features which help the catalog administrator in abstracting exception skeletons from workflow schemas in a guided way and storing new patterns in the appropriate categories with suitable links to the existing repository. In fact, the catalog is regarded as an extensible tool to be populated gradually with new categories of patterns to be defined by examining further real workflow applications. Further points of research regard the use of exceptions as a basis for managing dynamic workflow evolution and the design of patterns for authorization management in workflows [8].

Acknowledgements - This work has been partially supported by the WIDE ESPRIT Project n. 20280 and by CNR coordinated project “Ambienti di Support0 alla Progettazione di Sistemi Informativi”. The authors are thankful to the partners of the Projects for common work and ideas.

REFERENCES

PI

PI

[31

[41

[51

PI

[71

[81

PI

PO1

VI

WI P31

P41

A. Aiken, 3. Widom, and J.M. Hellerstein. Behavior of database production rules: termination, confluence, and observable determinism. In Proceedings of the ACM SIGMOD Conference on Management of Data, San Diego, CA, USA, pp. 59-68, ACM Press (1992).

G. Alonso, D. Agrawal, A. El Abbadi, M. Kamath, R. Gunthor, and C. Mohan. Advanced transaction model in workflow context. In Proceedings of the 12th International Conference on Data Engineering(ICDE’g6), New Orleans, LA, USA, 574-581, IEEE Computer Society Press (1996).

G. Alonso, M. Kamath, D. Agrawai, A. El Abbadi, R. Gunthor, and C. Mohan. Failure Handling in Large Scale Workflow Management Systems. Technical Report RJ9913, IBM Almaden Research Center (1994).

E. Baralis, S. Ceri, and S. Paraboschi. Compile-time and run-time analysis of active behaviors. IEEE Bans- actions on Knowledge and Data Engineering, 10(1):353-370 (1998).

E. Baralis and J. Widom. An algebraic approach to rule analysis in expert database systems. In Proceedings of the 20th International Conference on Very Large Data Bases (VLDB’94), Santiago, Chile, 475-486, Morgan Kaufmann (1994).

D. Brugali, G. Menga, and A. Aarsten. The framework life span. Communications of the ACM, 40(10):65-68 (1997).

F. Casati. A discussion on approaches to handling exceptions in workflows. In Proceedings of the International Conference on Computer Supported Cooperative Work, workshop on Adaptive Workjlow Systems, Seattle, WA, USA (1998).

F. Casati, S. Castano, and M.G. Fugini. Enforcing workflow authorization constraints using triggers. Journal of Computer Security, to appear (1999).

F. Casati, S. Castano, M.G. Fugini, 1. Mirbel, and B. Pernici. Using Patterns to Design Rules in Workflows. Technical Report 97.065, Dipartimento di Elettronica e Informazione, Politecnico di Milan0 (1997).

F. Casati, S. Ceri, S. Paraboschi, and G. Pozzi. Specification and Implementation of Exceptions in Workflow Management Systems. Technical Report 98.081, Dipartimento di Elettronica e Informazione, Politecnico di Milan0 (1998).

S. Castano, M.G. Fugini, I. Mirbel, and B. Pernici. Workflow Reference Models. Technical Report 3015-1, WIDE, Politecnico di Milan0 (1997).

S. Ceri and R. Ramakrishnan. Rules in database systems. ACM Computing Surveys, 28(1):109-111 (1996).

J. Eder and W. Liebhart. The Workflow Activity Model WAMO. In Proceedings of the 3nl International Conference on Cooperative Information Systems (CoopIs’95), Wien, Austria, 87-98, University of Toronto Press (1995).

J. Eder and W. Liebhart. Contributions to exception handling in workflow management. In Proceedings of the EDBT Workshop on Workjlow Management Systems, Valencia, Spain (1998).


[151 E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: abstraction and reuse of object-oriented design. In Proceedings of the 7th European Conference on Object Oriented Programming (EECOP’g3), Kaiser- slautern, Germany, pp. 406-431, Springer-Verlag, Berlin (1993).

[16] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Pattern,.? - Elements of Reusable Object-Oriented Software. Addison Wesley (1994).

[17] C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. Prentice-Hall (1991)

[18] C. Hag-en and G. Alonso. Flexible exception handling in the OPERA process support system. In Proceed- ings of the 18th International Conference on Distributed Computing Systems (lCDCS’g$), Amsterdam. The Netherlands, pp. 526-533, IEEE Computer Society Press (1998).

[19] P. Heinl. Exceptions during workflow execution. In Proceedings of the EDBT Workshop on. Wor/$olu Man- agement System.5, Valencia, Spain (1998).

[20] R.E. Johnson. Frameworks = Components + Patterns. Communications of the ACM, 40(10):39-42 (1997)

[21] M. Kamath and K. Ramamritham. Failure handling and coordinated execution of concurrent workflows. In Proceedings of the 14th International Conference on Data Engineering(ICDE’g8), Orlando, FT., USA, pp. 334-1341, IEEE Computer Society Press (1998).

[22] G. Kappel, P.Lang, S. Rausch-Schott, and W. Retschitzegger. Workflow management, based on objects, rules. and roles. IEEE Data Engineering, 18(1):11-18 (1995).

[23] G. Kappel, S. Raush-Shott, and W. Retschitzegger. From rules t,o rule patterns. In caiseg6, Cret,a. Greece, pp. 9%115, Springer-Verlag, Berlin (1996).

[24] G. Kappel, S. Raush-Shott, and W. Retschitzegger. Rule Patterns for Designing Active Object,-Oriented Database Applications. Technical Report TR 07-95, J. Kepler Universit,%t Linz (1996).

[25] F. Lrymann and D. Roller. Workflow-based applications. IBM Systems .lournal, 36(1):102-123 (1997)

[26] A. Reuter, K. Schneider, and F. Schwenkreis. Contracts revisited. In S. Jajodia and L. Kerschberg, editors, Advanced ‘l%ansaction Models and Architectures, Kluwer Academic Publishers, New York (1997).

[27] D.C. Schmidt, Using design patterns to develop reusable object-oriented communicat,ion software. Communi- cations of the ACM, 38(10):65-74 (1995).

[28] R. van Stiphout, T. Dirk Meijler, A. Aerts, D. Hammer, and R. le Comte. TREX: workflow transaction by means of exceptions. In Proceedings of the EDBT Workshop on Workflow Management Systems, Valencia,

Spain (1998).

Documents

An environment for designing exceptions in workflows