Pergamon Information Systems Vol. 24, No. 3, pp. 255{273, 1999c 1999 Elsevier Science Ltd. All rights reservedPrinted in Great Britain0306-4379/99 $20.00 + 0.00AN ENVIRONMENT FOR DESIGNING EXCEPTIONS IN WORKFLOWSyFabio Casati1, Mariagrazia Fugini2 and Isabelle Mirbel31Hewlett-Packard Laboratories, 1501 Page Mill Road, Palo Alto, CA, 94304, California, USA2Dipartimento di Elettronica e Informazione, Politecnico di Milano, via Ponzio 34/5, I-20133 Milano, Italy3Dpartement Informatique, Universit de Nice - Sophia Antipolis, Parc Valrose, 06108 France(Received 16 October 1998; in �nal revised form 1 April 1999)Abstract | When designing a work ow schema, the work ow designer must often explicitly dealwith 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 exceptionalbehavior within a work ow schema, by reusing an available set of pre-con�gured exceptions skeletons.Exceptions are expressed by means of triggers, to be executed on the top of an active database envi-ronment. In particular, the paper deals with the handling of typical work ow exceptional situationswhich are modeled as generic exception skeletons to be included in a new work ow schema by simplyspecializing or instantiating them. Such skeletons, called patterns, are stored in a catalog; the paperdescribes the catalog structure and its management tools constituting an integrated environment forpattern-based exception design and reuse. Copyright c 1999 Elsevier Science LtdKey words: Work ows, Exceptions, Design Patterns1. INTRODUCTIONWork ow systems are currently becoming a widespread technology in the organizations, pro-viding a common framework to support o�ce and production activities. Work ow design aims atcapturing the possible sequences of activities needed to reach a given business goal, and at linkingthe work ow to the existing Information Systems of the organization. During the design, variousaspects have to be considered in conjunction with the pure activity ow, and the designer has toprovide many details in order to obtain a work ow which is executable by a Work ow ManagementSystem (WfMS) and which achieves the business goal. A work ow description requires the speci�-cation of both the normal ow and the possible variations due to exceptional situations that can beanticipated and monitored. The WIDEz Project has proposed the use of Event-Condition-Action(ECA) rules (also called triggers in the WIDE terminology and in this paper) to model excep-tional situations that alter the normal activity ow. In fact, exceptions are often asynchronouswith respect to the normal ow, both in their raising (which is often not related to the start orcompletion of a speci�c task) and in their reaction (which often does not require the activation ofa task or process). For these reasons, it is inpractical to model exceptions within the ow graphthe de�nes the ow of control between work ow tasks. The ECA paradigm seems instead partic-ularly suited for modeling exceptional situations: WIDE triggers allow the de�nition of events tobe monitored, of conditions that verify whether the occurred event corresponds to an exceptionalsituation 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 WIDEtriggers goes beyond the management of exceptional situations: they can also model conditionsrelating the starting, termination, or repetitions of work ow instances (called cases) or regardingthe periodical occurrence of operations in the work ow execution.In this paper we are concerned with the speci�cation of exceptional situations and other aspectsof work ow applications that can be modeled by means of triggers. The following main issues areat the basis of the approach:yRecommended by Barbara Pernici and Costantino ThanoszWIDE: Work ows on an Intelligent and Distributed database Environment255

256 Fabio Casati et al.� rules (or triggers): they model exceptional situations and more in general those situationsthat cannot be suitably represented within the ow structure, such as reactions to eventsthat are asynchronous with respect to the normal ow;� patterns: they model reactive behaviors that may be used in several designs. Patternsdescribe triggers, or sets of related triggers, that control a given typical situation. Patterns area way for the designer to specify the work ow schema by reusing previous design experience.The issue of de�ning the di�erent (normal and exceptional) aspects of an application has beenaddressed in other related �elds, such as in Software Engineering and Information Systems, wheretechniques and tools combining data and function modeling are adopted, in order to represent theapplication functionality and to describe both normal and abnormal situations and exceptions [17].Currently, few techniques and tools exist for work ow design. Some of them [22] are based on rulesand catalogs of prede�ned work ow portions for work ow management.This paper focuses on the description of a tool environment for the speci�cation of work owexceptions, modeled as triggers. Triggers are included in a schema by reusing (i.e., selecting andcustomizing) a set of pre-de�ned generic trigger skeletons stored in the tool catalog as patterns.The support environment, called werde, consists of the pattern catalog, of tools for accessingthe catalog and for reusing the suitable patterns, and of tools for managing the catalog. The setof typical patterns stored in the catalog enables the designer to deal with frequent occurrencesof similar situations in work ow design in given application domains, and with generic situationsthat may occur in any application domain. The werde environment is presented in terms ofarchitecture, implemented features, and interaction with the work ow execution environment ofWIDE.The paper is organized as follows. In Section 2, we frame our work in current research inwork ow management, databases, software engineering, and information systems. In Section 3, weillustrate the catalog of patterns, and describe the use of triggers in work ow design by presentingexceptions, patterns, and examples of patterns. In Section 4, we present the architecture of werdeand its features for accessing and managing the pattern catalog; we then show the tools usage forexception design and analysis. Finally, Section 5 concludes the paper and presents our future work.2. RELATED WORKThe problem of managing exceptional situations in work ow execution has received increasingattention in recent years. One of the �rst contribution to managing work ow exceptions came fromEder and Liebhart [13]. They analyzed the di�erent exceptions that may occur during process ex-ecution, and divided them into four classes: basic failures, that deals with failures of the WfMSor of the environment in which it executes; application failures, corresponding to failures of theapplications invoked by the WfMS in order to execute a given task; expected exceptions, that arepredictable deviations from the normal behavior of the work ow; �nally, unexpected exceptions cor-respond to mismatches between a business process and its work ow process de�nition. While basicand 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 ofthe underlying DBMS to maintain a persistent state and support forward recovery), expected andunexpected exceptions are peculiar of work ow management, and demand new methodologies andtechniques in order to e�ectively managed. Unexpected exceptions, being caused by inconsistenciesbetween work ows and the processes they describe, must be handled by modifying the work owde�nition [7, 19]. In this paper, we are mainly concerned with expected exceptions.Many approaches to handling expected exceptions aim at capturing task semantic failuresi.e., situations in which a task is unable to reach its business goal. These approaches share thesame basic idea: every task is associated with a compensating task, that semantically undoes thee�ects of the forward task. As a task fails semantically, compensation is started by executingcompensating tasks (usually in the reverse order of the forward execution) until a decision (split)point in the ow is reached, from which forward execution is resumed, possibly along a di�erentpath (e.g., see [3, 2, 13, 25, 26]). WAMO [14] and Crew [21] extend this approach by providing

An Environment for Designing Exceptions in Work ows 257more expressive work ow models and by allowing the work ow designer to de�ne transactionalproperties 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] o�ersmore features for dealing with expected exceptions, by allowing the de�nition of rules of theform: task � exception �! exceptionhandler where a speci�c exception handling strategy maybe associated to each <task, exceptional situation> pair. For instance, a rule may specify that asa given exception occurs for a given task, the task itself is re-executed, an alternative activity isexecuted in its place, or the process is aborted (compensated).The OPERA process support systems [18] takes a step further, by allowing more exibility andby providing primitives for managing generic exceptional situations: the work ow designer mayde�ne exception handling ows (with the same formalism used for the speci�cation of the normal ow), activated by explicit noti�cation from external applications or as a given predicate overprocess data is satis�ed. OPERA o�ers exception handling capabilities similar to those of WIDE;however, WIDE exception handlers can be also triggered by temporal events and provides moreexception handling primitives, also including (but not limited to) the activation of an exceptionhandling ow. Furthermore, WIDE provides a pattern-based environment that support the designand reuse of exceptions in work ows, which is the focus of this paper.Patterns have become a common design paradigm in software development, especially in the�eld of object-oriented systems, to enhance component reuse by encoding design experience [16].The abstraction mechanisms used to de�ne patterns allow capturing static and dynamic struc-tures and collaborations of components. As such, they are useful in solving common problemsarising in designing software in di�erent application domains, such as business data processing,telecommunications, graphical user interfaces, and distributed communication software. In [15],a classi�cation system is described for organizing a pattern catalog at di�erent granularity andabstraction levels. Sample patterns identi�ed on a number of a large-scale distributed system arepresented in [27] showing the process of reusing communications architectures.Application frameworks described in [20] also represent a kind of pattern. Patterns are viewedas 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 captureunifying aspects in software development moving reusability from the level of components up to thehigher level of large architectures [6]. Examples of patterns that were factored out by examininga number of frameworks and chosen as representative of reusable object-oriented software aregiven. A single framework contains many patterns and, since patterns are not expressed in aobject-oriented language, they are more abstract than frameworks.In the database �eld, rule patterns have been recently proposed as an approach to designingactive object-oriented database applications [24]. Rule patterns can be regarded as an extension ofdesign 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-de�ned as wellas parameterized parts. A library of rule patterns is de�ned [23], organized as a set of dictionariesextensible by de�ning new patterns or by specializing the existing ones.The pattern-based approach presented in this paper borrows concepts and solutions from bothdesign and rule patterns to support work ow design. Existing approaches to work ow speci�cationmainly deal with the use of rules in speci�c contexts serving as a mechanism for work ow enactmentand evolution. Our approach is instead focused on providing abstraction mechanisms to representin an application-independent manner the knowledge and experience associated with exceptionsand rules design in work ows. The approach is also focused on providing classi�cation mechanismsfor pattern storage and retrieval in a structured catalog of inter-related patterns and on providingtailoring mechanisms for specializing and instantiating catalog patterns.3. THE PATTERN CATALOGThis section describes the core component of the werde environment: the catalog of patterns.This component stores a set of pre-de�ned work ow patterns at di�erent levels of abstractionand generality in a layered structure. The catalog is the centralized repository of werde, where

258 Fabio Casati et al.reusable work ow elements are available in order to support the \speci�cation-by-example" ofdi�erent elements of a work ow, at di�erent granularity levels, such as processes, exceptions, andtasks.We identi�ed three main categories of patterns: built-in patterns, generic tasks, and genericapplication-oriented structures, as depicted in Figure 1.Integrity patterns

Continuation patterns

Basic patterns

Interaction patterns

Starting patterns

Authorization patterns

Schema-evolution patterns

Organizational patterns

Other patterns

Information use

Document revision

Reservation

Count patterns

Other patterns

Remainder

Document preparation

Other patterns

Built-inpatterns

Genericapplication-oriented

structures

Pattern catalog

tasksGeneric

Fig. 1: The werde Pattern Catalog� Built-In Patterns. Patterns at this level deal with reaction to events and time alarms (Basicpatterns), integrity and security constraints over work ow data (Authorization, Integrity,and Count patterns), work ow management (Starting, Interaction, and Continuation pat-terns), and with changes in the organization structure (Organization and Schema evolutionpatterns). They describe context-dependent and time-dependent knowledge related to basicexceptional situations independent of the semantics of all possible applications. Built-in pat-terns specify, for example, basic interactions between work ow elements, or situations wherea task has to be suspended or resumed, or express exception requirements related to work owinteroperability. Built-in patterns are implemented as generic rules that can be adapted todi�erent application contexts.Figure 2 shows the pattern classi�cation for Built-in patterns. The rightmost column includetop-level built-in pattern categories, the middle column presents second-level categories, whilethe third column shows the triggers included in each category. In general, an arbitrary numberof subcategories can be de�ned.� Generic Tasks. Patterns at the generic tasks layer allow the description of frequently occur-ring activities in work ow design in the form of tasks, independent of the information itemsinvolved in their execution (e.g., a task for registering information in a document).� Generic Application-Oriented Structures. This layer of the catalog contains work ow frag-ments and associated exceptions needed to model frequently occurring situations of one ormore application domains. These are frequently occurring combinations of tasks (i.e., work- ow fragments) generally performed together to achieve an organization goal in a givenapplication domain (e.g., a generic structure describing the concurrent review of a documentby several people). A detailed description of the pattern catalog can be found in [11].

An Environment for Designing Exceptions in Work ows 259

BASIC

AUTHORIZATION

INTEGRITY

COUNT

STARTING

CONTINUATION

INTERACTION

SCHEMAEVOLUTION

TEMPORALDELAY

EXTERNALEVENT

SINGLE ENTRYPONT

SIMULATION OFMULTIPLE

ENTRY PONT

AGENTAUTHORIZATION

OPERATIONAUTHORIZATION

VARIABLERANGE

WRONG VARIABLEASSIGNMENT

INVALID VALUE

WAIT

temporalDelaytasktemporalDelaycaseTemporalDelaydurationExceeded

deleyAfterExternalEvent

MULTITASK

JOIN

TERMINATION

externalEventstopCase

separationOfDutiesbindingOfDutiesroleExamination

unauthorizaedOperation

SYNCHRONOUS

ASYNCHRONOUS

synchronousDocumentExchange

asynchronousDocumentExchange

priorityChangenewExternalEvent

compensatingAction

creationOutOfrangemodificationOutOfrange

wrongAssignmentAtTaskStartwrongAssignmentAtTaskEndwrongAssignmentAtCaseStartwrongAssignmentAtCaseEnd

taskCount

joinContinuation

multitaskContinuation

waitCondition

termination

singleEntryPoint

multipleEntryPoint

CATEGORY SUBCATEGORY TRIGGERS

invalidValueAtTaskStartinvalidValueAtTaskEndinvalidValueAtCaseStartinvalidValueAtCaseEnd

Fig. 2: Classi�cation of Built-In Patterns

260 Fabio Casati et al.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 di�erent work ows. For instance, manywork ows are faced with the need of managing such situations as the cancellation of an order or ofa service request, or the violation of data or temporal constraints. Patterns de�ne these behaviorsin abstract forms, and may be reused for di�erent work ow applications, thereby improving thespeed and the quality of the exception design.In order to be accessible and user friendly for the designer, the catalog associates to eachpattern a Pattern Speci�cation and a Sample Usage. The �rst describes the exception and includesparts allowing the designer to understand the goal of the pattern, to locate the pattern in thecatalog, and to link patterns together within a work ow schema. The second contains sampleinstantiations of patterns in various application domains, thus guiding the designer in completinga new work ow schema. For details about the patterns contained in the various categories of thecatalog, the interested reader can refer to [11].We now present a sample work ow schema that will be used in the following of the paper inorder to introduce our approach to pattern-based exception design.The work ow schema, depicted in Figure 3, models a hotel Room Reservation business process.As an instance of the work ow is activated, the task Get Customer data is executed. When datahave been collected, the clerk checks for the availability of a room of the requested type (task CheckAvailability). If such a room is available, then the room is booked (task Book Room) and thecon�rmation (along with the payment request) is sent to the customer (task Send Confirmationand Payment Request). If no room of the requested type is available for the selected day, then theclerk checks for room availability in a partner hotel of the same city (task Check at AssociatedHotel). If a room is found, then it is booked and the con�rmation and payment request aresent to the customer, otherwise a rejection answer is given (task Send Rejection Answer). Thesample work ow schema includes two triggers: trigger customerCancel manages cancellation ofroom reservation requests, while trigger missingPayment, activated as case execution is completed,handles reservations for which the payments are not received within a speci�ed deadline.3.1. ExceptionsA short introduction to the exception language is now given (see [10] for a detailed description).The Chimera-Exc exception language is based on the Chimera language for active object-orienteddatabases. An exception is speci�ed by an ECA rule. Events denote the occurrence of a possiblyexceptional situation; conditions determine if the occurred event actually corresponds to an ex-ceptional situation to be managed, while the action part de�nes the operations to be performedin 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 onwork ows and tasks (stored in objects of classes case and task respectively), data relating work owparticipants (objects of class agent or role), plus a work ow-speci�c class, bearing the name ofthe work ow, whose objects store process-speci�c variables local to each single case. For instance,variables needed for the execution of cases of a hotel roomReservationwork ow, such as the roomnumber or the customer name, are stored as attributes of an object of the roomReservation class.An exception can be sensitive to di�erent kinds of events:� data events are raised upon modi�cation of the content of the WfMS database. Data eventsinclude the creation of a new object (create), the modi�cation of an object's attribute (mod-ify), and the deletion of an object (delete). For instance, event modify(task) is raised whenan attribute of an object of the task class is modi�ed.� Work ow events are raised when a case or task is started or completed. Work ow events in-clude 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 de�ned temporal instant. They can beexpressed as deadlines, temporal periods, or interval elapsed since a speci�c date or time. For

An Environment for Designing Exceptions in Work ows 261

Send Confirmation and Payment

Request

Check Availability

Book Room

Get Customer data

Availability="yes"

Room Reservation WF

customerCancel

Task

Conditional Fork

And-Fork, And-Join

Or-Join

Trigger

Legenda

Availability="no"

Check at Associated

Hotels

Send Rejection Answer

RoomFound="yes"

RoomFound="no"

missingPaymentFig. 3: The Room Reservation Work ow Schema

262 Fabio Casati et al.instance, event elapsed 1 day since taskStart(myTask) is raised as one day has elapsedsince the start of an instance of task myTask.� External events, quali�ed by their name, are noti�ed by external applications: these maycorrespond to applicative situations, such as a phone call by a customer canceling a reservedroom. An example of external event is raise(cancelReservation).The condition part consists of a declarative query, expressed by a formula evaluated over theWfMS database state. The formula is expressed as a conjunction of predicates, and includes a set ofvariables to which bindings are associated as a result of the formula evaluation: if the result of thequery is empty (i.e., if no bindings are produced), then the condition is not satis�ed, and the actionpart is not executed. Bindings resulting from the formula evaluation are passed to the action part inorder to perform the reaction over the appropriate objects. The condition includes class formulas,for declaring variables ranging over the objects of a speci�c class (e.g., task(T)), type formulas fordeclaring variables of a given type (e.g., real(R)), and formulas expressing comparisons betweenexpressions (e.g., T.executor="Lisa"). Objects a�ected by events are captured in the conditionpart by the occurred predicate. Thus, for instance, in an exception triggered by the caseStartevent, 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 WfMSdatabase, and operations executed through calls to the work ow engine. The �rst category in-cludes the primitives create, delete, and modify. For instance, delete(Log,L) deletes all objects ofclass Log to which L is bound after the condition evaluation. The second category includes primi-tives to start, rollback, or suspend the execution of cases and tasks, assign or delegate the executionof tasks, and send messages to agents. Examples are delegateTask(T,A), startCase(mySchema,startingParameter), and notify(T.executor, "deadline is approaching").A sample trigger activated at the end of cases of the roomReservation work ow is as fol-lows. The condition determines which is the case that has caused the triggering (predicatecase(C), occurred(caseEnd,C)), retrieves the object storing the variables of the just com-pleted case (roomReservation(R), R.caseId=C) and then checks if the customer has not paid(R.paymentDone=FALSE). If the condition is veri�ed (i.e., if bindings are produced), then the ac-tion part is executed, causing the start of an instance of the cancelBookingwork ow and providingthe customerID as input parameter. The Chimera-Exc speci�cation of the trigger is given below:define trigger missingPaymentevents caseEndcondition case(C), occurred(caseEnd,C), roomReservation(R),R.caseId=C, R.paymentDone=FALSEactions startCase("cancelBooking",R.customerId)endRules can be associated to a task, to a schema, or to the whole WfMS. Task-level rules modelexceptions which are related with a single task; an example is a rule reacting to the task deadlineexpiration. Work ow-level rules de�ne a behavior common to every task in a schema, or modelexceptions related to the whole schema; for instance, a work ow-level rule could specify that alltasks of a the work ow should be suspended at 7pm. Finally, global (WfMS-level) rules modelbehaviors de�ned for every task or case, or exceptions involving cases of di�erent work ows. Forinstance, an exception stating that \tasks that were assigned to an agent who left or is on vacationmust be reassigned" should be declared at the WfMS-level, since it de�nes a general policy validfor every task.Rules can be ordered by absolute priority. Upon concurrent trigger, the scheduler executes �rstthe rules with higher priority. Among rules with the same priority, the choice is non-deterministic.

An Environment for Designing Exceptions in Work ows 2633.2. Patterns for ExceptionsSince the Chimera-Exc language is quite exible, it allows the de�nition of a variety of ex-ceptional behaviors. However, experience in exceptions design has shown that, although all thelanguage features are required, most triggers follow common, repetitive \patterns". These obser-vations led to the idea of taking advantage of repetitive patterns in triggers de�nition, in order toreduce the design e�ort and to provide guidelines for pattern reuse.We introduce patterns as generalized descriptions of triggers and exceptional situations thatcan frequently arise in work ow modeling. Patterns prede�ne typical rules or set of rules thatcapture the knowledge about the occurrence of an exceptional situation and the actions thatcan be performed to deal with it. Patterns consist of prede�ned parts, parameterized parts, andoptional parts. Parameterization and optionality are introduced to support pattern re-usabilityand adaptation in work ow 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 speci�cation part and by a sample usage part.1. Speci�cation Part: The speci�cation part is the abstract description of an exception. Inparticular, the pattern speci�cation is structured along the following �elds (see [9] for acomplete description of the pattern speci�cation language):� name, uniquely identifying the pattern in the werde catalog;� intent, a textual part describing the purpose of the pattern (intended scope and knownuses);� classi�cation, according to the categories and sub-categories of the catalog;� template, containing the core speci�cation of the pattern. The speci�cation is given interms of events, conditions, and actions. Unlike events and conditions, which are themain parts of the patterns, the action part provides only suggestions. This re ects thefact that exception patterns focus on how to capture exceptions, rather than on how to�x reactions, which are application dependent: in a given application, a warning messagecan be a satisfying reaction, while a cancellation of the case can be more suitable inanother application of the same pattern.The template contains parametric �elds (also called generic terms in the following) tobe �lled in with speci�c values provided by the designer; mandatory and optional partscan also be speci�ed.� 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 �eld allows one to describe moreprecisely the topics of the pattern, especially to distinguish the di�erent patterns of agiven category in the classi�cation;� related to, establishing links among patterns to combine them in di�erent structures;� guidelines, providing suggestions to the user about possible usage and personalizationof patterns.2. Sample Usage Part: Since the user of the catalog is intended to be an expert of the applicationunder design but is not required to have a detailed knowledge of the Chimera-Exc syntax,the pattern model is endowed with some user-oriented sample usage pattern. This is a set ofinstantiations of patterns on speci�c examples. They show how patterns can be personalizedin di�erent contexts and applications by illustrating how parameters of patterns can besupplied by the designer to produce a concrete work ow. The sample usage description isa set of work ow-speci�c instantiations of patterns related to an application domain. Ingeneral, several examples are provided for a pattern for di�erent domains. The sample usageis an instantiation of the variables/parameters appearing in the template �eld of the patternspeci�cation according to the domain selected to construct the example.

264 Fabio Casati et al.Name: termination

Intent: This pattern allows the definition of the initiation of a case upon termination of another case,considering its status (in terms of WF variables).Classification: Continuation pattern | TerminationTemplate:define trigger terminationevents caseEndconditions case(C), occurred(caseEnd,C), <wfName>(W), W.caseId=C,

W.<variable>=<value>actions startCase(<wfName>, “<parameters>“)endKeywords: case terminationRelated to:Guideline: The condition may contain clauses related to values of one or more variables in the terminatedcase.

Sample usagedefine trigger missingPaymentevents caseEndcondition case(C), occurred(caseEnd,C), roomReservation(R),

R.caseId=C, R.paymentDone=FALSEactions startCase(“cancelBooking” , R.customerId)end Fig. 4: The Termination PatternName: externalEvent

Intent: This pattern checks the arising of events external to the WF which can cause a variation to the WFexecution. Actions to be performed upon an external event have to be defined by the designer.Classification: Exception patterns, ExternalEventsTemplate:define trigger externalEventevents [real time] raise(“<externalEvent>“)condition externalEvent(E), occurred(raise(“<externalEvent>“),E),

<wfName>(W)[W.<variable> = E.intPar,][W.<variable> = E.stringPar1,][W.<variable> = E.stringPar2]

actions 1. <informativeAction>2. <action>

endKeywords: externalEventRelated to:Guideline: The optional parameters are used to link the WF attributes to the parameters of the externalevent.One of the parameter of the externalEvent can be the name of the workflow involved in the trigger.

Sample usagedefine trigger customerCancelevents raise(“customerCancel” )condition externalEvent(E), occurred(raise(“customerCancel” ), E), roomReservation(R),

R.customerId=E.intParactions notify(R.responsible, “Customer has canceled the room reservation request)end Fig. 5: The externalEvent Pattern3.3. Examples of PatternsFigure 4 shows a sample pattern speci�cation, that starts a new case upon termination ofanother one. The pattern belongs to the continuation|termination category (see Figure 2).As a case terminates, the pattern checks a predicate over work ow data and, if the predicateis veri�ed, indicating that some exceptional situation has occurred, it activates an instance of adi�erent work ow, in order to cope with the exception. The template part consists of a generictrigger, activated as a work ow instance terminates (event caseEnd). The condition part identi�es

An Environment for Designing Exceptions in Work ows 265the completed case (case(C),occurred(caseEnd,C)), de�nes an object variable W that rangesover the work ow variables of a given (but generic) work ow schema (<wfName>(W)), and thenrestricts it to range over the variables of the completed case (W.caseId=C). Note that the name ofthe work ow is in fact left unspeci�ed: it is generic, and has to be de�ned when instantiating thispattern into a Chimera-Exc trigger.Finally, the condition allows the de�nition of a predicate over the work ow data of the completedcase (W.<variable>=<value>). If the condition holds, then the action part activates an instanceof another work ow (startCase(<wfName>,<parameters>). The missingPayment trigger givenin 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 ofa generic trigger, raised at the occurrence of an external event. The condition part of the patterntemplate declares a variable E ranging over the occurred events of a given (but generic) type(externalEvent(E), occurred(raise("<externalEvent>"), E)) and de�nes an object variableW that ranges over the work ow-speci�c variables of a given (but generic) work ow schema(<wfName>(W)). The pattern condition also include optional parts that matches case variableswith the parameters of the external event, in order to determine which are the cases a�ected bythe external event. The �gure also show a sample usage trigger, which is the customerCanceltrigger de�ned for the roomReservation work ow.4. SPECIFICATION OF THE EXCEPTION DESIGN ENVIRONMENTIn this section, we present the werde environment supporting the pattern-based approachillustrated in Section 3. We �rst introduce the tool architecture and the functionality, and thenwe present the sample usage of the tool. We also show how the werde development environmentis interleaved with the WIDE execution environment.4.1. Tool ArchitectureThis section presents the architecture and the features provided by the werde tool and givesa usage example. The architecture is depicted in Figure 6.

Pattern catalog

ModificationCreation

Schema Editor

Deletion

Task-set levelWF level

Schema Analyser

Task-level

Classification-based searchKeyword-based search

Exception Retriever

CATALOG MANAGEMENT

SCHEMA MANAGEMENT

SCHEMA ANALYSIS

Insertion

Exception Writer

ModificationDeletion

AdditionRemoval

PatternCategory

Catalog Manager

DeletionModificationCreationFig. 6: Architecture of the werde Tool

266 Fabio Casati et al.PATTERN

CATALOG

WORKFLOW

SCHEMA

REPOSITORY

WERDE WIDE ENGINE

store/retrieve

patterns

Insert/modify/delete

workflows and exceptions

WORKFLOW

RELEVANT DATA

Execute

workflows

Fig. 7: Interaction between werde and the WIDE Engine via the Work ow Schema RepositoryThe de�nition of an exception for a work ow schema is performed through the Schema Editormodule, based on reusing the available patterns. From within the Schema Editor, the designer caninteractively search the catalog for a suitable generic pattern using the Exception Retriever module.Retrieved patterns are instantiated/personalized for the work ow schema at hand, through theException Writermodule, which can also be used to de�ne new patterns or exceptions from scratch,if the available ones do not �t the work ow requirements. Exceptions de�ned for a schema can beanalyzed by exploiting the Schema Analyser module of werde. The Catalog Manager performsthe catalog management functions that is, insertion, modi�cation and deletion of patterns.Figure 7 shows that the interaction between werde and the WIDE work ow engine occurs viathe work ow and exception schema repository. werde stores and retrieves patterns from a localrepository (the catalog), which is not accessed by the work ow engine. werde and the WIDEengine share instead the work ow schema repository: werde accesses the schema repository inorder to insert, modify, and delete work ows and Chimera-Exc rules. The de�ned work ow schemasare then accessed and interpreted by the WIDE engine at work ow execution time. Work owexecution may involve modi�cation of system and work ow relevant data, which are only accessedby the WIDE engine and not by werde, which is not concerned with work ow instances andwork ow 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.4.2. Using the CatalogThe exception design process proceeds according to a \speci�cation-by-example" paradigm:di�erent elements of a work ow, at di�erent granularity levels, are progressively inserted in thework ow 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, andspecializing/instantiating these patterns to �t the requirements of the speci�c schema.Exceptions are designed in a bottom-up way, based on reusing the patterns available in thecatalog. The tool guides the designer by providing both classi�cation information, which facilitatesthe 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 ExceptionRetriever module, and in instantiating the retrieved pattern by activating the Schema Editormodule. The following features are provided by the tool in order to support the exception designprocess:� Retrieval, to access the catalog and search for suitable patterns. Two search modalities areprovided, namely, keyword-based and classi�cation-based search. The �rst relies on a pre-de�ned thesaurus of terms loaded at pattern speci�cation time to characterize the patternwithin 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 forthe retrieval of patterns based on two criteria:

An Environment for Designing Exceptions in Work ows 267

(a) (b)

(c)Fig. 8: Pattern Retrieval. Selection of Retrieval Option (a), Keyword Speci�cation for Keyword-Based Retrieval(b), and Presentation of the Retrieved Pattern (c)

268 Fabio Casati et al.{ 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) shows the \Retrieve Option" screen where the various search modes are available.In particular, consider that the termination pattern is being searched by keywords, asdepicted in Figure 8(b). The result of the search appears in Figure 8(c).� Insertion, to support the interactive de�nition of exceptions starting from a retrieved patternor from scratch. Exceptions can be derived from retrieved pattern by instantiation. A patternis instantiated by replacing the generic term with a value; for instance, <wfName> becomesroomReservation. If there are optional parts, the user has to decide if he/she takes theoptional parts or not. If several possible actions are de�ned in the action part, it is alsonecessary to choose one or several of these actions. It is also allowed to add conditions oractions to the trigger, for example to test the value of a variable which is speci�c to thework ow under design.The instantiation is performed by exploiting the syntax-driven capabilities of the ExceptionWriter module and the template interface facility of werde. This facility consists of a setof dialog windows which drives the designer in entering the patterns �elds, possibly enablingthe visualization of the guidelines and usage examples associated with the template undermanipulation. The dialog facilities of the Exception Writer support also the de�nition of newexceptions from scratch. The instantiation of the termination pattern retrieved through thesteps depicted in Figure 8 works as shown in the sample work session of Figure 9, where thepattern is instantiated to obtain the trigger missingPayment of Section 3.1. The instantiationsteps 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-Exccondition (roomReservation(W)).� Modi�cation, to modify exceptions inside exception schemas (i.e., in the set of exceptionsde�ned for a given work ow).� Deletion, to remove exceptions from exception schemas.� Analysis, to analyze the exceptions written for the current schema, using the Schema Anal-yser module. Exceptions in work ows are typically designed individually, by identifying theexceptional situation, selecting the appropriate pattern from the catalog, and instantiatingit in order to obtain a Chimera-Exc exception. However, although an exception consideredindividually may be correctly speci�ed, mutual interactions among exceptions may lead tounforeseen 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 areconcurrently triggered, the �nal result of their execution depends on their non-deterministicexecution order.Exceptions analysis aims at statically (i.e., at compile-time) verifying that such undesiredinteractions do not occur. In particular, it aims at verifying two signi�cant properties for aset of exceptions: termination and con uence [1, 4, 5, 12]. Termination holds if exceptions donot trigger each other inde�nitely, so that rule processing eventually terminates. Terminationanalysis is typically based on building graphs depicting triggerings and activations amongexceptions, and on detecting cycles in these graphs (see [4, 10] for details).Con uence requires the �nal e�ect of the rule processing (represented by direct or indirectchanges to the WfMS database) to be independent on the (non-deterministic) scheduling oftriggers having the same priority [9]. Su�cient conditions for con uence have been proposedin [1, 5, 9]. Unfortunately, the above properties are undecidable in the general case.A fully automated analysis of interactions between exceptions is generally di�cult to achieve,since it requires to understand the semantics of conditions and actions. A simple, conservativesolution consists in checking that exceptions query and operate on di�erent classes. More

An Environment for Designing Exceptions in Work ows 269

Fig. 9: Instantiation of the termination Patternsophisticated and less conservative techniques for rule analysis, which consider the semanticsof conditions and actions, have been proposed in [5].In the werde prototype, the Schema Analyser module uses some of the techniques proposedfor active database rule analysis, and adapt them in order to make them suitable for Chimera-Exc rule analysis and for the work ow domain. In particular, Chimera-Exc rules have severaltypes of event and actions, which are not limited to data manipulation. Hence, triggeringdependencies between actions and events have to be understood and formalized. For instance,the Chimera-Exc action startCase raises event caseStart (and all events de�ned as delayselapsed from the case start).Another important di�erence between database rule analysis and exception analysis is thatwerde can exploit the information related to the context of rules. In our model, exceptionsare always triggerable, and if two exceptions share the same triggering event, they are bothtriggered 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 e�ective only whenthe 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 de�ned within the condition part, such asC.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, ifthis is done, exceptions become context-sensitive, and the analyzer can improve the qualityof the analysis, by exploiting the additional information that only those exceptions declaredfor tasks or cases that may be concurrently active can interact.werde currently performs termination analysis by detecting triggering cycles, where trig-gering relationships among rules are determined by performing a syntactic analysis of eventsand actions and by accessing the system-de�ned list of pairs haction; eventSeti, that de�neswhich events are triggered by a given action. werde also provides a limited form of con- uence analysis, by focusing on interactions between pairs of exceptions. In werde, twotriggers are considered as con icting if they are active simultaneously and contain incompat-ible actions; actions are incompatible if the order of their execution leads to di�erent statesof the work ow management database [10]. A (prede�ned) table of incompatible actions is

270 Fabio Casati et al.maintained to support the analysis, which can be performed at three levels:{ task level, to check exceptions de�ned 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 de�ned in the schema.Anomalous situations detected by the Analyser are signaled to the designer who can activatethe Exception Writer for editing the involved exceptions.4.3. Managing the Catalog

Fig. 10: Creation of the Termination Pattern in werdeThe pattern catalog is extensible by de�ning new patterns and/or specializing the existingones. To this purpose, werde provides maintenance functionality to manage the catalog (CatalogManager module). Management of the pattern catalog deals mainly with the creation, modi�cationand deletion of patterns. However, it also takes into account the management of the categories usedto classify and retrieve patterns. In this section, the werde functionality for pattern managementfollowed by the environment functionality dealing with management of categories are presented.Pattern Management:This functionality deals with the creation, modi�cation and deletion of patterns. When creatinga pattern, the pattern template is speci�ed by invoking the Exception Writer editor. Its di�erentparts have to be �lled-in by the user: name, intent, classi�cation, template, keywords, related-to patterns and guidelines. The pattern name must be unique. The classi�cation conforms tothe 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 keywordsare speci�ed for newly de�ned patterns. Guidelines can be textual information to be compiled o�-line by the pattern designer. Links between templates (\related-to" �elds) can be de�ned byactivating an \add link" and starting a corresponding dialog window. Sample usage can also bewritten to facilitate pattern reuse. A pattern can be de�ned from scratch or by specializing anexisting one. A pattern can be specialized in three di�erent ways, that can be combined.

An Environment for Designing Exceptions in Work ows 271� The �rst way consists in rewriting the generic trigger using more speci�c 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 patternby replacing <referenceEvent> with the more specialized term <externalEvent>.� The second way consists in instantiating part of the generic trigger. This is done by replacinga generic term by a non-generic one. For example, <class> in a given trigger of a patterncan be specialized into task in a speci�c pattern dealing only with tasks.� The third way consists in adding conditions and (suggested) actions to a given generic triggerin order to obtain a more specialized one. These additions can be done only in the conditionand actions parts. Adding events is not allowed since this would change the invocation ofthe trigger.If the specialization mechanism is used to create a new pattern, an existing pattern P canbe selected with the Exception Retriever component, and the designer can select the parts of Pthat must be modi�ed. The pattern has to share at least one keyword of its generic pattern (thepattern from which it is derived) and has to be placed in the same category/sub-category. Linksare maintained in the catalog between patterns belonging to a specialization chain.An example of work session, dealing with the speci�cation of the termination pattern shownin Figure 4, is presented in Figure 10.When modifying patterns, new examples can be added to an existing template, by de�ning an\executable example" and by selecting the template of interest from the catalog. It is also possibleto change the category and/or sub-category of a pattern. This means changing the location ofthe pattern in the repository, but also changing the location of the patterns linked to it throughspecialization or generalization, in order to maintain the catalog consistency.Deletion of patterns is performed by selecting the pattern of interest. The tool then performsa set of basic integrity checks:� if another pattern uses the current one, the link is also removed;� if the pattern is involved in an inheritance hierarchy (is inherited by at least a pattern p2,and possibly inherits also from at least pattern p1), the user has to choose (i) to delete alsop2, or (ii) to build a new inheritance link between p1 and p2.Category Management:As presented in Section 3, the catalog is divided in categories (built-in patterns, generictasks and generic application-oriented structures).Each one is divided in sub-categories: Termination, for example is a sub-category of thebuilt-in|continuation|termination category. Since the catalog evolves during time, it is pos-sible to add new categories and sub-categories, and to remove some of them. Removal of categoriesimplies the deletion of all sub-categories, provided that the designer has already canceled all thecorresponding patterns. werde checks that no patterns of the catalog refer to the category orsub-category being deleted. 5. CONCLUDING REMARKSWe have presented the werde environment supporting the design of exceptions in work owschemas. The environment is based on a catalog of work ow patterns which are a generalized de-scription of triggers that model frequently occurring exceptions that can be reused when designing anew work ow schema. Triggers model both exceptional situations and typical start/end/repetitionsof operations in a work ow. We have presented the structure of the pattern catalog and the mech-anisms for pattern reuse. We have also described the features of the werde tool for exceptiondesign and catalog management.

272 Fabio Casati et al.Currently, the catalog is populated with a set of patterns which have been constructed byanalyzing a set of real cases provided in the WIDE Project testbed. A set of primitives for patternreuse has been fully speci�ed in [9] and is being tested to check the quality of these patternsin terms of signi�cance and accessibility for reuse. In particular, the sample usage of patternsstored in the catalog are proving to be an e�ective means for guiding the designer in selecting theappropriate patterns, in instantiating them appropriately, and in inserting the exceptions correctlyin the work ow schema.The implementation of werde has currently completed most of the features described in thepaper. Some features, such as pattern design and schema analysis, are being extended in order toachieve a more complete and e�ective suite of functions. For example, for schema analysis, we planto consider exception termination analysis and con uence analysis on rule sets, and to consider inmore detail the semantics of actions and conditions. For pattern design, we plan to have featureswhich help the catalog administrator in abstracting exception skeletons from work ow schemasin a guided way and storing new patterns in the appropriate categories with suitable links to theexisting repository. In fact, the catalog is regarded as an extensible tool to be populated graduallywith new categories of patterns to be de�ned by examining further real work ow applications.Further points of research regard the use of exceptions as a basis for managing dynamic work owevolution and the design of patterns for authorization management in work ows [8].Acknowledgements | This work has been partially supported by the WIDE ESPRIT Project n. 20280 and by CNRcoordinated project \Ambienti di Supporto alla Progettazione di Sistemi Informativi". The authors are thankful tothe partners of the Projects for common work and ideas.REFERENCES[1] A. Aiken, J. Widom, and J.M. Hellerstein. Behavior of database production rules: termination, con uence,and observable determinism. In Proceedings of the ACM SIGMOD Conference on Management of Data, SanDiego, CA, USA, pp. 59{68, ACM Press (1992).[2] G. Alonso, D. Agrawal, A. El Abbadi, M. Kamath, R. Gunthor, and C. Mohan. Advanced transaction model inwork ow context. In Proceedings of the 12th International Conference on Data Engineering(ICDE'96), NewOrleans, LA, USA, 574-581, IEEE Computer Society Press (1996).[3] G. Alonso, M. Kamath, D. Agrawal, A. El Abbadi, R. Gunthor, and C. Mohan. Failure Handling in LargeScale Work ow Management Systems. Technical Report RJ9913, IBM Almaden Research Center (1994).[4] E. Baralis, S. Ceri, and S. Paraboschi. Compile-time and run-time analysis of active behaviors. IEEE Trans-actions on Knowledge and Data Engineering, 10(1):353{370 (1998).[5] E. Baralis and J. Widom. An algebraic approach to rule analysis in expert database systems. In Proceedings ofthe 20th International Conference on Very Large Data Bases (VLDB'94), Santiago, Chile, 475-486, MorganKaufmann (1994).[6] D. Brugali, G. Menga, and A. Aarsten. The framework life span. Communications of the ACM, 40(10):65{68(1997).[7] F. Casati. A discussion on approaches to handling exceptions in work ows. In Proceedings of the InternationalConference on Computer Supported Cooperative Work, workshop on Adaptive Work ow Systems, Seattle, WA,USA (1998).[8] F. Casati, S. Castano, and M.G. Fugini. Enforcing work ow authorization constraints using triggers. Journalof Computer Security, to appear (1999).[9] F. Casati, S. Castano, M.G. Fugini, I. Mirbel, and B. Pernici. Using Patterns to Design Rules in Work ows.Technical Report 97.065, Dipartimento di Elettronica e Informazione, Politecnico di Milano (1997).[10] F. Casati, S. Ceri, S. Paraboschi, and G. Pozzi. Speci�cation and Implementation of Exceptions in Work owManagement Systems. Technical Report 98.081, Dipartimento di Elettronica e Informazione, Politecnico diMilano (1998).[11] S. Castano, M.G. Fugini, I. Mirbel, and B. Pernici. Work ow Reference Models. Technical Report 3015-1,WIDE, Politecnico di Milano (1997).[12] S. Ceri and R. Ramakrishnan. Rules in database systems. ACM Computing Surveys, 28(1):109{111 (1996).[13] J. Eder and W. Liebhart. The Work ow Activity Model WAMO. In Proceedings of the 3rd InternationalConference on Cooperative Information Systems (CoopIs'95), Wien, Austria, 87-98, University of TorontoPress (1995).[14] J. Eder and W. Liebhart. Contributions to exception handling in work ow management. In Proceedings of theEDBT Workshop on Work ow Management Systems, Valencia, Spain (1998).

An Environment for Designing Exceptions in Work ows 273[15] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: abstraction and reuse of object-orienteddesign. In Proceedings of the 7th European Conference on Object Oriented Programming (EECOP'93), Kaiser-slautern, Germany, pp. 406-431, Springer-Verlag, Berlin (1993).[16] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns - Elements of Reusable Object-OrientedSoftware. Addison Wesley (1994).[17] C. Ghezzi, M. Jazayeri, and D. Mandrioli. Fundamentals of Software Engineering. Prentice-Hall (1991).[18] C. Hagen and G. Alonso. Flexible exception handling in the OPERA process support system. In Proceed-ings of the 18th International Conference on Distributed Computing Systems (ICDCS'98), Amsterdam, TheNetherlands, pp. 526-533, IEEE Computer Society Press (1998).[19] P. Heinl. Exceptions during work ow execution. In Proceedings of the EDBT Workshop on Work ow Man-agement Systems, 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 work ows. InProceedings of the 14th International Conference on Data Engineering(ICDE'98), Orlando, FL, USA, pp.334-341, IEEE Computer Society Press (1998).[22] G. Kappel, P.Lang, S. Rausch-Schott, and W. Retschitzegger. Work ow 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 to rule patterns. In caise96, Creta, Greece, pp.99-115, Springer-Verlag, Berlin (1996).[24] G. Kappel, S. Raush-Shott, and W. Retschitzegger. Rule Patterns for Designing Active Object-OrientedDatabase Applications. Technical Report TR 07-95, J. Kepler Universit�at Linz (1996).[25] F. Leymann and D. Roller. Work ow-based applications. IBM Systems Journal, 36(1):102{123 (1997).[26] A. Reuter, K. Schneider, and F. Schwenkreis. Contracts revisited. In S. Jajodia and L. Kerschberg, editors,Advanced Transaction Models and Architectures, Kluwer Academic Publishers, New York (1997).[27] D.C. Schmidt. Using design patterns to develop reusable object-oriented communication 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: work ow transaction bymeans of exceptions. In Proceedings of the EDBT Workshop on Work ow Management Systems, Valencia,Spain (1998).