Deriving Active Rules for Work ow Enactment - CiteSeerX

8 downloads 10882 Views 266KB Size Report
Mar 25, 1996 - information exchange among tasks does not require an external communication service, such as e-mail monitor or OLE drivers; transaction ...
Deriving Active Rules for Work ow Enactment F. Casati, S. Ceri, B. Pernici, G. Pozzi Dipartimento di Elettronica e Informazione Politecnico di Milano Piazza L. Da Vinci, 32 - I20133 Milano, Italy ceri/casati/pernici/[email protected] tel. +39-2-2399.3526, fax. +39-2-2399.3411 March 25, 1996

1

Deriving Active Rules for Work ow Enactment Abstract

Work ows consist of computer-supported, data-intensive activities which involve multiple \steps" of processing; Work ow management is an emerging and challenging eld, o ering opportunities for exporting database technology beyond its classical boundaries. In particular, active rules supported by many database systems appear as an ideal paradigm for expressing the control and data ows between processing steps, and consequently they are being proposed as a suitable implementation mechanism for Work ow managers. On the other end, active rules appear a too low level description of Work ows to be presented to Work ow system users. In this paper, we propose automatic derivation techniques of active rules from conceptual Work ow speci cations. In addition, the paper includes a full collection of case-independent rules at the basis of any Work ow enactment. The objective and challenge of this research is to give a precise operational semantics to Work ow enactment through active rules, thereby addressing an issue which is still lacking concrete and precise proposals.

1 Introduction Work ows are activities involving the coordinated execution of multiple tasks performed by di erent processing agents. A task de nes some work to be done by a person, by a software system, or by both of them. Speci cation of a Work ow (WF) involves describing those aspects of its component tasks (and the processing agents that execute them) that are relevant to control and coordinate their execution, as well as the relations between the tasks themselves. A WF speci cation mainly concerns when a certain work task (WT) has to start, the criteria for assigning the WT to agents and which WTs it activates after its end; therefore, less emphasis is placed on the speci cation of WTs (which may be informally described and only partially automated), while the focus is on WTs' coordination. Connections among WTs can be rather complex, and some of them may be time dependent. A Work ow Management System (WFMS) permits both to specify WFs and to control their execution. During a WF execution (enactment), a WFMS has to schedule WTs (including their assignment to agents) on the basis of the (static) WF speci cations and of the (dynamic) sequence of events signaling the completion of WTs and of generic events produced within the execution environment (including exceptions). Active database technology is particularly suited for providing an operational model of - and implementation technology for - Work ow enactment. The use of an active DBMS (ADBMS) provides some advantages, where the most important can be sketched out as: 

information exchange among tasks does not require an external communication service, such as e-mail monitor or OLE drivers;



transaction mechanisms are provided by the ADBMS and do not need to be re-implemented;



the designer of the Work ow application can de ne the schema of the Work ow according to the needs the application must solve without having to take care of task scheduling mechanisms: in most Work ow system, the control ow is embedded in the application programs. Active database technology can be applied to control Work ow execution starting from a set of active rules automatically generated from the schema de ned by the Work ow designer. interoperability with other information systems and/or Work ow systems: data exchange can be made easier by federated and distributed systems, thus allowing a Work ow management system to share data with other systems.



2

Active rules follow the event - condition - action (ECA) paradigm: events are typically changes of the database contents, conditions are database queries, and actions are arbitrary computations, possibly causing database changes [25]. In this paper, we describe how formal Work ow descriptions can be used as input in order to automatically generate both schema and instances of Work ow data and the code of speci c active rules for their management. In our approach, Work ow enactment is traced by means of manipulations to Work ow data, and the behavior of the WFMS is modeled by active rules. In addition, the active rule paradigm provides a convenient formalism for expressing reactive computations due to \external events" generated outside the WFMS, such as exceptions and preconditions. Work ows are modeled through applicationindependent and application-speci c components, and each component is separately translated into data and rules; speci cally designed rule templates drive the generation of application-speci c rules. Based on functionality, we decompose rules into modules, and show that their execution terminates on any input. Our main research contribution consists of the speci cation of a very precise and powerful operational semantics for Work ow enactment, an area which is lacking concrete proposals; indeed, several graphical Work ow speci cation languages supported by products lack a formal description of computations that are allowed by the language itself [15]. Our operational semantics supports exception management and interoperability with external data sources, two critical areas of Work ow management which are often neglected. We do not advocate a direct implementation of rules as presented in this paper, as we believe that their structure can be improved for eciency; note that for the ease of speci cation we use in this paper the relational model and high-level, datalog-like active rules, but we believe that an object-oriented rule language is more suitable for the implementation. However, this paper contributes a rst required step on the road leading to the implementation of Work ows by active rules.

1.1 Previous Related Work

The rst WF models have been proposed in the oce information system area, as a way of describing oce procedures [4], based on extensions of classical formal models, such as Petri Nets, production rules and

owcharts. The need of a closer relationship between modeling techniques and enactment of processes has been particularly developed within the process modeling area in software engineering. This research has produced several methodological contributions and WF speci cation languages [15, 11]. Several tools for process modeling, generally based on Petri Nets, are focused on the ability of \animating" WFs, thereby understanding their dynamic behavior [2]. Recently, a growing interest has been concentrated on connecting WF systems to existing information systems. In particular, the desire of interconnecting to existing data and of coping with large volumes of WF information has provided impetus to the bridging of WF and database technologies. The challenge posed by WF management pushes towards removing some of the classical limitations of databases in the context of concurrency and transactional models [18]. Active rules were indicated as a promising operational model for Work ows [10, 25], but so far few concrete proposals were made to substantiate this claim: most proposals consider application-speci c rules, i.e. rules to cope with situations related to the Work ow domain. Work of Dayal et al. [10] can be considered as predecessor of this paper; it rst describes the use of active rules for supporting Work ow management, however without focusing on their automatic speci cation. Also in [19], a detailed collection of active rules is presented for a speci c Work ow application, without discussing their derivation. A decentralized model for multiple executions of the same task based on active rules is presented in [5]; in this model all eligible agents are noti ed, but only the correct number of task instances are executed. This model focuses on a very speci c subproblem in Work ow enactment, as it neither discuss task interconnections and interactions, nor exceptions and access to shared databases.

3

1.2 Outline

In Section 2, in order to make this paper self-consistent, we brie y summarize the Work ow Conceptual Model presented by the authors in [6]1. Then, Section 3 illustrates our proposed architecture for a WFMS and we illustrate the assumed semantics for worktask execution by means of a state-transition diagram. These descriptions enable a rst characterization of the events which must be tracked during Work ow enactment, and of the (relational) schema which is best suited to model Work ow description data. Section 4 illustrates how Work ow enactment is modeled by active rules. In particular, we distinguish generic from Work ow-speci c active rules; the former do not depend on speci c applications and can be fully speci ed, while the latter are provided in the format of rule templates. A simple syntactic translation, discussed in Section 5, enables the generation of Work ow data (either tuples of application-independent relations or schemas of application-speci c relations) and of Work ow-speci c rules from templates.

2 Conceptual Work ow Model Informally, a WF schema contains the speci cations of a collection of WTs and of the dependencies between them. This speci cation indicates which WTs should be executed, in which order, which agent may be in charge of them, which operations should be performed on external databases. We call WF instance (or \WF case") any execution (enactment) of a WF schema. For example, a WF schema may describe the process of military enrollment (Fig. 1); a WF case is created whenever a given candidate goes through the test for military enrollment. Thus, normally, several WF cases of the same WF schema may be active at the same time. A WF schema is described by means of a Work ow Description Language (WFDL). A speci cation in WFDL is composed of two sections, respectively dedicated to task and ow descriptions. Task descriptions are focused on the single work units: ow descriptions are focused on intertask relationships and dependencies, and have an associated graphical representation. For instance, Fig. 1 describes the military enrollment process mentioned above. Each section starts with de nitions of constants, types, variables, and functions; de nitions in the context of ow descriptions are global (visible to every WT in the WF), while de nitions in the context of WTs are local [6]. In both cases, variables exist only during an execution of the WF or WT instance; WF variables enable intertask communications (e.g., messages from one task to its successors). For uniformity, variables are stored within temporary relations whose schema is de ned at WF compilation time; these temporary tables, however, play the role of internal data structures, and as such they can be eciently implemented. The ow declaration may also refer to persistent data (DB) which are shared by all WF agents and possibly by agents of other WFs. These data are usually de ned externally (i.e. they are part of the information system of the organization and their existence is independent of the particular WF being modeled); for the sake of simplicity, we use the relational data model as well to denote persistent data. We model data exchange by means of DB manipulation and retrieval, following a blackboard approach.

2.1 Task Description

WTs are the elementary work units that collectively achieve the WF goal. Each WT has ve major characteristics:  Name: a string identifying the WT.  Description: few lines in natural language, describing the WT. The model was designed in order to describe, at a conceptual level, WF structures supported by Foro (SEMA, [16]) and by Work ow Manager (HP, [17]). 1

4



Preconditions: a boolean expression of simple conditions which must yield a truth value before the actions in the task can be executed. Simple conditions may either contain (conventional) boolean expressions in WFDL, or be based on the (boolean) query exists in a SQL2 statement, which is interpreted as false if the corresponding query is the empty relation and true otherwise, or temporal predicates.



Actions: sequence of statements in WFDL which serves as a speci cation of the intended behavior of the WT. WFDL actions describe data manipulations of temporary and persistent WF data occurring while the WT is active; therefore, WFDL includes instructions for getting input from agents, for manipulating the contents of WT or WF variables, and for retrieving and manipulating shared databases (performed by means of SQL2 update queries). The user executing the WT has full freedom on the way the WT itself should be executed, provided that eventually the actions which are listed in its action part are performed.



Exceptions: in every WT it is possible to specify a set of pairs to handle abnormal events: every time an exception is raised, the corresponding reaction is performed. An exception is a WFDL predicate, which may include time-related and query predicates. All exceptions are monitored by the WFMS; when they become true (possibly at the start of the WT), the exception is raised. A reaction is next performed by the WFMS to handle the exception. Reactions can be selected among a restricted set of options that includes end (imposes the termination of the WT), cancel (the WT is canceled), notify (a message is sent to the person responsible for the WT) and a few others; a detailed description of available reactions is available in [7]. A typical exception is raised when a WT is not completed within a speci ed deadline, and an agent is noti ed.

2.2 Work ow Descriptions

A Work ow description consists of several interconnections between tasks. Two tasks can be directly connected by an edge, with the intuitive meaning that, as soon as the former ends, the latter is ready for execution. In all other cases, connections among WTs are performed by two special-purpose routing tasks: forks, for initiating concurrent executions, and joins, for synchronizing after concurrent execution [2, 19, 22]. Each fork is preceded by one WT, called its predecessor, and followed by many WTs, called successors. Forks are classi ed as:  Total: after the predecessor ends, all successors are ready for execution.  Non deterministic: the fork is associated with a value k; after the predecessor ends, k successors nondeterministically selected are ready for execution.  Conditional: each successor is associated with a condition; after the predecessor ends, conditions are instantaneously evaluated and only successor WTs with a true condition are ready for execution.  Conditional with mutual exclusion: it adds to the previous case the constraint that only one condition can be true; thus, after the predecessor ends, one of the successors is ready for execution; otherwise, if no condition or more than one condition are true, an exception is risen. A join is preceded by many WTs, called its predecessors, and followed by one WT, called successor. Joins are classi ed as:  Total: the successor becomes ready only after the end of all its predecessors.  Partial: the join task is associated with a value k (quorum); the successor becomes ready after the end of k predecessor WTs. Subsequent ends of predecessor WTs have no e ect. 5

Iterative: the join task is associated with a value k; the successor becomes ready whenever k predecessor WTs end; subsequent ends of groups ok k predecessor WTs may turn again the successor to ready. Iterative join with two predecessors and k = 1 is used to describe cycles. The above quorum values k may be associated with constants, variables, or functions expressed in WFDL; in the last two cases, their value becomes known at execution time. Each WF schema has one start symbol and several stop symbols; the start symbol has one successor WT (possibly a routing WT) and each stop symbol may have several predecessor symbols. WFDL includes also modularization mechanisms (called \supertask" and \multitask") which are omitted from this paper; these mechanisms enable hierarchical Work ows, and therefore can be used for modeling the decomposition of a complex Work ow application into several simple applications; the interested reader is referred to [7] for further details. In the graphical notation, a successor relationship is indicated by an arrow, a conditional fork by a losangle, total forks, nondeterministic forks and joins by bubbles. Start and stop symbols are indicated by double segments, and task descriptions are rectangles subdivided horizontally in four areas, for preconditions, name and description, actions, and exceptions. 

2.3 Agents

Each WF is speci ed by a \Work ow administrator" (WFA) who is responsible of generating and compiling the WF schema. Some agents have the privilege of creating new WF cases. These agents are known to the WFMS as \case responsible" (CR); they are noti ed of exceptional behaviors and informed when the WF case is terminated. Execution of each WT is performed by assigning it to an executing agent. The assignment of a WT to an agent can be prede ned in the WF description, or can be selected by the WFMS. In this latter case, which is most interesting and also most frequent in practice, the WFMS performs the selection by means of application-speci c rules (such as: equalization of load, use of \experienced" agents for \critical tasks", and so on). In this case, agents are described by suitable dictionary information in the WFMS. A detailed of the mechanism for task assignment, however, is out of the scope of the present paper.

2.4 An Example: Military Enrollment

We present here a brief example of a Work ow handling military enrollment activities, using the graphical notation illustrated above (Fig. 1). The enrollment WF handles the compulsory enrollment procedure of a military oce. The candidate being examined gives his personal data (get Applicant), which is entered into the global WF variable Applicant by the task's agent. At this point, the identity of the applicant becomes known; if the applicant is already known as Drafted, an exception is risen and the case is forced to completion. The exception is expressed as a dynamic SQL2 query on the Drafted table, which uses the Applicant variable. The candidate has to pass some physical and psychological tests: these tests are performed into a visiting room. Thus, before starting the physical test, the candidate has to wait for a visiting room to become free; this is a precondition, also expressed as a SQL2 query on the FreeVisitRoom table. The action's speci cation consists in allocating the room to the speci c test; the room is then made free at the end of the visit, when the candidate is either drafted or rejected. After the physical test, the physician enters data about the result of the test itself in the form of a binary variable (get TestResult). If the result is Bad, the candidate is refused. Otherwise, he goes through a psychological test. The outcome of the psychological test is also summarized into the same binary variable, which nally indicates whether the candidate is drafted or rejected. These two tasks terminate the Work ow.

6

Military Enrollment Workflow variables:

Get and record data A new candidate is registered get Applicant; exists (select * from Drafted where Drafted.SSN = Applicant.SSN): endWF

struct Applicant_type { int SSN; string Name; string Data} Applicant; enum TestResult_type {Good, Bad} TestResult; int Room;

exists (select * from FreeVisitRoom)

Physical test The candidate is submitted to physical test Room = select-one Room from FreeVisitRoom; delete from FreeVisitRoom where FreeVisitRoom.Room = Room; get TestResult;

TestResult=Bad

R1 TestResult=Good

Psychological test The candidate is submitted to psychological test

get TestResult;

TestResult=Good

TestResult=Bad

R2

R3

Draft

Reject

The candidate is enrolled

The candidate is refused

insert into Drafted ; insert into FreeVisitingRoom

insert into FreeVisitingRoom

Figure 1: Example: military enrollment Work ow.

7

3 Work ow Execution Model In this section, we rst give a description of the WFMS architecture, and then describe WT evolution by means of state-transitions. Finally, we describe relational data structures describing Work ow schemas and instances.

3.1 Architecture

In order to give an operational speci cation of Work ow enactment we need to introduce a reference architecture, illustrated in Figure 2, and discuss the ow of events between architectural elements. The proposed architecture is composed of two cooperative environments, one dedicated to WF coordination (WF management environment) and one to WT execution (agent environment); WT execution is applicationspeci c. WF management environment

Agents Descriptions

WF Execution History

WF Admin. Tool

WF Compiler

WF Schema Description

WF Engine

Time-related Events

WF Administrator

Clock

WF Execution Description

Insert, Delete, Update

Shared DB

End, Cancel, Suspend, Resume, Refuse

Create, End, Cancel

Warning Messages

WT Server

Start_case

Client (agent appl.)

WF Agent

Agent environment

Figure 2: WFMS architecture

3.1.1 WF Management Environment

WF coordination is performed by a Work ow engine (server), which is responsible of the execution of WF instances. The WF engine makes access to stored data describing agents and active WTs; it is driven by the information in the WF schema, stored in a WF Schema Description repository. The behavior of a WF engine is event-driven: the engine is sensible to events, such as start case (generated by the agent who initiates a case), end, cancel, suspend, resume, refuse (generated by WTs during or at the end of their execution; see next section), time-related events (generated by a clock), and manipulation of shared databases (insert, delete, or update operations). The WF engine reacts to events by activating WTs (i.e. creating WT instances), assigning them to agents, compiling historical information, and sending warning 8

messages to agents. The WF management environment supports also several client tools for editing and compiling WF schemas and for administration (for agent management and for reporting the WF history).

3.1.2 Task Execution

The execution of a WT is initiated by the WF engine and next controlled by the agent. The state diagram in Figure 3 represents the sequence of execution of WTs as observed from the Work ow engine perspective. When a WT becomes ready for execution, if the WT has no precondition or if the precondition is true, then the WT becomes active on the agent's environment by creating a unit of execution within the agent's WT server. If instead the WT's precondition is false, then the WT's state becomes inhibited and the WF engine waits for some external event which changes the truth value of the precondition; after such an event occurs, the WT becomes active. However, exceptional conditions (refuse, end or cancel events) may cause the WT termination from the inhibited state. WT termination is represented by two exclusive states: a WT can be done, in which case the WF continues with the WT's successors selected according to the WF schema; or it can be re-assign, in which case the WT's execution must be repeated by re-assigning it to a di erent agent. Precondition FALSE

Ready

Precondition TRUE

Precondition TRUE

Refuse

Active

EndCancel

Inhibited

EndCancel Refuse

Done

Re-assign

Figure 3: State-transition diagram describing WT execution from the perspective of the WF engine (Done and Re-assign are nal states). The active state can be furthermore exploded. Initially, a created WT is in the waiting state, and the agent changes the WT's state to executing as soon as it starts operating on the WT (for instance, by opening a window on his screen which corresponds to the WT). The agent can suspend execution, by entering a suspended state, and then resume execution. Eventually, the agent indicates that the WT is ended, canceled, or refused; in all these cases, the control returns to the WF engine. The rst case corresponds to a normal termination; the second case corresponds to an abnormal termination which, however, does not suspend the WF execution. Thus, in both cases the WT enters the done state; the two cases, however, are distinguished in the WF history. Finally, refuse forces the WT to the re-assign state on the WF engine. When a WT is waiting, executing, or suspended, it can be forced into a nal state also by exceptions which are generated by the WF engine.

3.2 Events

The WF engine reacts to external and internal events. Internal events are those generated by WTs: start case, end, cancel, suspend, resume, execute, refuse. External events are either changes to the shared DB (insert, delete, update) or temporal events. Temporal events (new day, @5:00:00) are monitored by 9

making use of the time at the WF engine site. The WF engine observes events by monitoring changes to internal WF Event Tables and to the Shared DB.

3.3 Work ow Description Tables

Work ow schemas and instances are described by means of suitable Work ow Description Tables. These include both application-independent tables and application-speci c tables, used in order to store the values of WF variables during WF execution. In the following, we illustrate WF schema description tables, which contain an internal representation of the WF schemas de ned using the model described in the previous sections, and WF Execution Description tables, which store events, data, and history of WF cases being executed.

3.3.1 WF Schema Description Tables

WF Schema Description Tables describe, at meta-level, WF schemas. We assume that each WF name is unique, and that WT names are unique within a WF. Table Work ow includes the name of the schema and the name of the starting WT. WorkTask includes the names of all WTs belonging to a schema. RoutingTask includes the description of forks and joins in a schema, their type and the required quorum. For each routing task, an identi er is generated by the system (an identi er is needed because routing tasks have no name). Next includes the name of single successor tasks while AfterFork includes the (many) successors for forks with their condition for activation. The contents of WF Schema Description Tables is generated during the compilation of WFDL speci cations and is not modi ed during WF enactment2.

Work ow (WFName, StartTask) WorkTask (WFName, WTName) RoutingTask (WFName, RTName,Type, Quorum) Next (WFName, TaskName, NextTask) AfterFork(WFName, ForkTask, NextTask, Cond) For instance, from the Military Enrollment WF schema presented in Fig. 1, we generate the following tuples for the WF Schema Description Tables: Work ow WFName StartTask Military enrollment Get and record data WorkTask WFName Military enrollment Military enrollment Military enrollment Military enrollment Military enrollment RoutingTask WFName Military enrollment Military enrollment Military enrollment

WTName Get and record data Physical test Psychological test Draft Reject

RTName R1 R2 R3

Type mutualex fork mutualex fork join

Quorum 1

Note that WF Tables give a relational description of WF schemas that could evolve due to Work ow restructuring operations; although Work ow evolution is outside the scope of this paper, we believe that our architecture is ideal for this 2

application.

10

Next WFName Military enrollment Military enrollment Military enrollment Military enrollment Military enrollment Military enrollment AfterFork WFName Military enrollment Military enrollment Military enrollment Military enrollment

TaskName Get and record data Physical test Psychological test Draft Reject R3

ForkTask R1 R1 R2 R2

NextTask Physical test R1 R2 end ow end ow Reject

NextTask Psychological test R3 Draft R3

Cond TestResult = Good TestResult = Bad TestResult = Good TestResult = Bad

3.3.2 WF Execution Description Tables

WF Execution Description Tables describe WF cases and their evolution. We associate a unique identi er WFCaseId to each WF instance. Table WFCase associates each case to its schema and indicates the responsible and starting time. WTInstance is identi ed by a triple including the case identi er, the task name, and an activation number; each task activation has a start-time, an end-time, and the agent selected for its execution. Notify stores all the messages generated by the WFMS and sent to agents in the context of speci c tasks.

WFCase (WFCaseId,WFName, Responsible, StartTime) WTInstance (WFCaseId, WTName, ActivNum, State, StartTime, Agent) Notify (WFCaseId, WTName, ActivNum, MessageId, Message) Other execution description tables describe internal information for managing Work ows, such as the number of ended tasks of a join and its quorum (table JoinHandler), the number of current activations of a task (table Activations), tasks which are ready for execution (table Ready), and the WF case just ended (table EndCase). JoinHandler (WFCaseId, JTask, ActivNum, Counter, Quorum) Activations (WFCaseId, WTName, Counter) Ready (WFCaseId, WTName, ActivNum) EndCase (WFCaseId) WF Event Tables store the internal events which occur during the life of a WF case. Tables are selfexplanatory, with the exception of attribute FinalState in the Done table which assumes the values end or cancel (based on the nal state reached by the WT instance).

NewCase (WFName, Agent) Done (WFCaseId, WTName, ActivNum, FinalState) Cancel (WFCaseId, WTName, ActivNum) Execute (WFCaseId, WTName, ActivNum) Refuse (WFCaseId, WTName, ActivNum) Resume (WFCaseId, WTName, ActivNum) Suspend (WFCaseId, WTName, ActivNum) 11

Application Speci c Tables are used for storing values of variables which are needed for interactions between tasks in a Work ow. Work ow-speci c WF Variables tables are created to store variables which are global for the WF, while WT Variables tables store variables local to each task. Their semantics is application speci c, as it is illustrated in examples presented in Section 5. WF History Tables describe the history of the di erent WF cases and WT instances after they are completed.

WFHistory (CaseId, WFName, Responsible, StartTime, Duration) TaskHistory (WFCaseId, TaskName, ActivNum, StartTime, EndTime, FinalState,Agent)

4 Active Rules for Work ow Enactment In the present section, we introduce active rules for WF enactment, according to the model presented in the previous sections. Active rules constitute the reactive engine which operates inside the core of the WF engine. Two types of rules are de ned: 



Generic rules are common to any WF schema; they are part of the kernel of the WF engine and are never modi ed. Such rules govern the functioning of the WFMS, according to the state diagram described in the previous section and to the semantics of activation of tasks in a WF according to our model. For instance, one rule states that, when a new Work ow case is created, its rst task should become ready. Speci c rules depend on the characteristics of the WF schema; therefore they are added/removed when a Work ow schema is created/deleted. Such rules are automatically created by the Work ow compiler (see Figure 4), starting from a WF schema and a set of rule templates, as it will be illustrated in Sect. 5.

A complete collection of rules used by the WFMS is presented in the appendix, structured in three parts: generic rules, rule templates, and speci c rules for the Military Enrollment example.

4.1 Assumptions and Notations on Active Rules

In this paper, we need very few assumptions about active rules, which therefore apply to most products and research prototypes of active databases [14, 21, 25]. We assume that rules follow the Event-ConditionAction (ECA) paradigm, i.e. they are triggered by speci c events, include a declarative condition and a sequence of procedural actions. In the following, we use a simple notation for active rules, borrowed from [3]. Rules have the following syntax:

rule h rule-name i in group h group-name i when h events i if h condition i then h action i  

The event part contains a list of events, which are restricted to temporal events, insertions, deletions, quali ed updates (on speci c attributes), both in WF Description Tables and in the Shared DB tables. The condition part contains a boolean expression of predicates. Predicates can be either simple comparisons between terms (variables or constants), or database predicates with the usual Datalog [24] interpretation; the special predicates inserted and deleted uni es with newly inserted and deleted tuples. Temporal conditions can be tested (e.g. new day, delay, @5:00:00). 12

Rule templates

WF schema

WF compiler Schema compiler

Data for schema description tables

Rule compiler

Schema for application-specific tables

Application-specific rules

Figure 4: WF compilation The action part contains a sequence of commands. Bindings are passed from conditions to actions by means of shared variables: variables in the action are bound to the values that are computed for them by the condition. Bindings are not changed by the actions' evaluation, which consists of a sequence of set-oriented primitives. We use C-like formalisms to denote arithmetic expressions; in updates, we pre x by semicolons (:) variables or constants that are assigned to the new state instead of being uni ed with old state. Rules in the WFMS respond to events by updating WF Execution, WF History, Event, and Service tables. Each insert into tables WTInstance and Notify is followed by the actual activation of a task or the sending of a message. For instance, the following rule is triggered by inserts on the NewCase table: 

rule new case in group G2 /* a new case is started. The rule sets the starting task to the ready state*/ when inserted (NewCase) if inserted [NewCase(WF, AG)], Work ow(WF, ST) then insert [WFCase(new CASE, WF, AG, now)], insert [Ready(CASE, ST, 1)], delete [NewCase(WF, AG)] In the condition, predicate inserted(NewCase(WF,AG)) binds variables WF and AG to newly inserted tuples, thus being uni ed with the particular Work ow and case responsible, and predicate Work ow(WF,ST) binds variable ST to the rst task in the selected Work ow. In the action, a new case is created by an insert into table WFCase; the function new is used to generate an OID for the case, and the function now is used to denote the current time, assigned as the case start time. Next, the internal event Ready is generated for the rst task in the Work ow, and the internal event NewCase is deleted to clear the triggering event, which has been served by the rule. 13

A rule is triggered when one of its associated events occurs. Rule processing is started whenever some rule is triggered in the Work ow engine, and consists in the iteration of rule selection and rule execution.  Rule selection may be in uenced by static, explicitly assigned priorities: whenever two or more rules are triggered, if they are ordered, then the one with the maximum priority is executed. When a rule is selected, it is also detriggered.  Rule execution consists of evaluating the condition and next executing the action only if the condition is true. Action execution may cause events and therefore trigger other rules. We assume that rule processing initiates immediately after events are submitted to the WFMS, possibly in batches, and terminates when all triggered rules have been executed. We assume that the rate at which events are generated is lower than the actual rate at which events are processed, thus avoiding backlogs. We described above an example of generic rules: a complete list of generic rules is reported in Appendix B.

4.2 Groups of Rules

Rules can be clustered into seven groups based on their speci c function: 1. Group G1 includes the rules handling exceptions. All rules in this group are speci c, and are derived from the monitor exceptions rule template. The rules monitor relevant events and, if the exception condition is veri ed, execute the speci ed reaction. 2. Group G2 contains generic rules to update service tables when a case begin and a template to generate speci c rules to handle case end for each WF schema, to clean up case data from Execution and Application Speci c Tables and to ll in History tables. 3. Group G3 includes the three rule templates handling preconditions and a generic rule that may skip the execution of a task when it has become unnecessary due to the reaching of a quorum in a partial join. 4. Group G4 includes generic rules which, when a task is done, clean Execution tables, ll in History tables. 5. Group G5 includes generic rules determining the next WT(s) to become ready for execution after the end of a task and to increment activations counters. 6. Group G6 includes generic rules reacting to agent messages requiring task state transition, such as execute, suspend, resume and refuse. 7. Group G7 includes generic rules handling tasks of an ended WF case. These rules simply \trash" all event coming from these tasks. Groups are listed in decreasing priority order; in this way, for instance, exceptions are served at the highest priority, while reactions to suspend, resume, and refuse of tasks or the book-keeping of residual tasks for completed cases are at the lowest priority. Figure 5 represents these groups of rules, the events they react to, and the interaction between them. In particular, dashed edges on the right indicate groups of rules that trigger each other. Given that connections between groups are acyclic, this rule grouping is an event-based strati cation according to the classi cation of [3]; given that each group locally converges (i.e. if executed alone it terminates the execution initiated by any input transaction), we can conclude that the entire rule set terminates its execution on any input transaction. 14

Shared DB changes G1 or time-related event

start case

Exception handling (system generated and specific rules)

G2 Case startup and case end procedures

Shared DB changes G3 or time-related event Precondition handling (system generated and specific rules) and task skip G4 end and cancel handling: history and service table management

end or cancel

G5 end or cancel

execute, suspend, resume, refuse end, cancel, execute, suspend, resume, refuse

Next task(s) determination

G6 Agents' order handling G7 Late tasks orders' trashing

Figure 5: Rule groups and their triggering events.

5 Automatic Rule Derivation During the WF compilation process shown in Figure 4, three actions are performed:   

Instantiation of Work ow description tables; Generation of application-speci c tables; Generation of Work ow-speci c rules.

5.1 Instantiation of Work ow Tables

The compiler inserts into the WF tables information about the structure of the WF schema. For instance, the starting task is inserted into the Work ow table, the tasks composing the schema into the WorkTask and RoutingTask tables, and the successors of each task into the Next and AfterFork tables. An identi er is assigned to routing tasks, which are progressively numbered, since no name is associated to them. The algorithm for instantiating some of the WF tables is sketched in the following: Get SchemaName for every WorkTask in the schema do: get TaskName if predecessor is StartSymbol (* the task is the first to be executed *) then insert into Workflow values (SchemaName, TaskName) endif insert into WorkTask values (SchemaName, TaskName) get Successor (* get the task connected in output *) insert into Next values (SchemaName, TaskName, Successor)

15

endfor for every Routing Task in the schema do: get RTName, RTType, Quorum (* Quorum is requested only for join tasks *) insert into RoutingTask values (SchemaName, RTName, RTType, Quorum) if RTType is not ``Fork'' (* the task has only one successor *) then get Successor insert into Next values (SchemaName, RTName, Successor) else (* for forks, insert a tuple in AfterFork for every successor *) for every fork successor do: get Successor, Condition (* for non-conditional forks Condition is always true *) insert into AfterFork values (SchemaName, RTName, Successor, Condition) endfor endif endfor

The tuples generated for the Military Enrollment WF are depicted in Section 3.3.

5.2 Generation of Work ow-Speci c Tables

Work ow-speci c tables store the WF variables that, being shared among all WTs, enable the evaluation of conditions within forks and joins and exchange of data between tasks. In the speci c Military Enrollment example, only ve atomic variables are de ned, called Room, TestResult, and the three attributes of Applicant (Applicant SSN, Applicant Name, and Applicant Data); thus, the schema of the temporary table associated to the WF is simply: Military EnrollmentVars (WFCaseId, Applicant SSN, Applicant Name, Applicant Data, Room, TestResult)

5.3 Generation of Work ow-Speci c Rules

Rule templates de ne the general structure of Work ow-speci c rules; templates are translated into rules at WF compilation time. According to our translation schema, the compiler generates:  one rule for each exception of every task;  one rule to handle the termination of a case;  three rules for every task with preconditions (one rule to handle tasks ready with true preconditions, one rule to handle tasks ready with false preconditions, and one to monitor events which may turn the preconditions to true if the task is inhibited). A rule template has the same syntactic structure as rules, with the exception of input parameters and translation macroes. The input parameters are de ned immediately after the rule name and then used in the rule body; they are substituted at rule generation time with actual values. Translation macroes represent special-purpose syntax-directed translators which generate code from the WF speci cations in WFDL into the rule language.

16

The complete set of rule templates is presented in the appendix. As an example, we present the rule template for generating the rules which handle tasks in a WF with a precondition, when the precondition itself is true (translation macroes are indicated in italics):

rule template precond true(wf, wt) in group G3 when inserted (Ready) if inserted [Ready(CASE, wt, AN)], then

WFcase(CASE, wf, -, -), not (Skip(CASE, wt, AN)), task precond(wf, wt) AgentsSeek(wt, AG) update [Activations(CASE, wt, :AN)] insert [WTInstance(CASE, wt, AN, \waiting", now, AG)] delete [Ready(CASE, wt, AN)]

Parameters of the rule template denote the WF and WT names. Task preconditions are task-speci c, therefore we synthesize their expression in the template by means of a task precond translation macro, which generates task-speci c preconditions at rule generation time. AgentSeek denotes a system function which selects the agent to execute a task, now denotes a system function returning the current date and time. Note that in our model, preconditions and exceptions are expressed by means of SQL2 queries on the shared databases, so these expressions are translated into Datalog predicates by the compiler. For example, the only task with a precondition in the Military Enrollment example is PhysicalTest, and the task precond macro simply generates a Datalog literal: FreeVisitRoom(-)

In this way the rule action, causing the insertion of the task in the waiting state, will not be executed unless there is a visit room available, as required by the speci cations. The rule templates to generate the other speci c rules are analogous. Rule templates monitor preconditions in inhibited (which monitors preconditions of an inhibited tasks and set it to executing as those preconditions become true) and monitor exceptions (which monitors event that could rise the exception) are slightly more complex, since they also need expansion of the macroes relating possible triggering events. These expansions are determined following the methods speci ed in [8, 25], describing how to derive events that could verify a given condition. For example, the triggering event for the precondition of \Physical test" is inserted(FreeVisitRoom), which is also the expansion of the macro monitor preconditions in inhibited relating the same task.

6 Conclusions In this paper, we have illustrated an overall approach to the automatic generation of active rules for supporting Work ow enactment. The main research contribution of this paper is the identi cation of specialized translation schemes for generating suitable data structures (schema and instances) and structured collections of active rules, thereby demonstrating that active rules are a suitable instrument for providing the operational semantics of WFMSs. This work is part of a large research e ort on Work ow management; in particular, active database technology will be adopted within ESPRIT Project WIDE (Work ow on Intelligent and Distributed database Environments), started in November 1995, whose goal is the development of an industrial-strength Work ow manager speci cally based on active database technology. Within WIDE, the concepts presented 17

in this paper are being used in the following directions: to provide a semantics to the speci cation of a Work ow schema, in operational terms, as described in the present paper; to provide active support to those parts of a WF speci cation that are needed to handle WF behaviour outside its normal evolution. In particular, active database technology is being applied to exception management and to provide an advanced control of task assignment to agents. Exception management hi, based on the description of exceptions associated to tasks as described in this paper, will be implemented both using triggers provided by a currently available commercial system and realizing an advanced rule manager to handle case-related, temporal and external events. Advanced support to task assignment will also be based on rules describing the reaction to abnormal task assignment situations and will provide the possibility of rescheduling tasks according to changed situations (e.g., an agent becoming unavailable due to unexpected absence) and to changes in the organizational structure.

Acknowledgements

Part of this work has been supported by the European Commission under ESPRIT Project No. 20280 "WIDE" (Work ow on Intelligent and Distributed database Environments).

References [1] Attie P., Singh M., Sheth A., Rusinkiewicz M., \Specifying and Enforcing Intertask Dependencies", Proc. 19th VLDB Conf., Dublin, Ireland, 1993. [2] Bandinelli S., Fuggetta A., Ghezzi C., \Software Process Model Evolution in the SPADE Environment", IEEE Transactions on Software Engineering, vol. 19, n. 12, pp.1128-1144, December1993. [3] Baralis E., Ceri S., Paraboschi S., \Modularization Techniques in Active Rule Design", Tech. Report IDEA.WP.003.01, Politecnico di Milano, Milano, Italy, Dec. 1994. [4] Bracchi G., Pernici B., \The Design Requirements of Oce Systems", ACM Trans. on Oce Information Systems, 2(2), April 1984. [5] Bussler C., Jablonski S., \Implementing Agent Coordination for Work ow Management Systems Using Active Database Systems", Proceedings of the Fourth International Workshop on Research Issues in Data Engineering (RIDE-ADS '94), Houston, Texas, February 1994. [6] Casati F., Ceri S., Pernici B., Pozzi G., \Conceptual Modeling of Work ows", Proc. of the ObjectOriented and Entity-Relationship Conf., Gold Coast, Australia, 1995. [7] Casati F., Ceri S., Pernici B., Pozzi G., Conceptual Modeling of Work ows, Internal Report n. 95.018, Dipartimento di Elettronica e Informazione, Politecnico di Milano, Milano, Italy, 1995. The document can also be retrieved by ftp://xerox.elet.polimi.it/pub/papers/WF/InternalReport95 018.ps. [8] Ceri S., Widom J., \Deriving Production Rules for Constraint Maintenance", Proc. 16th VLDB Conf., Brisbane, Australia, 1990. [9] Ceri S., Fraternali P., Paraboschi S., Tanca L., \Active Rule Management in Chimera", in [25] [10] Dayal U., Hsu M., Ladin R., \Organizing Long-running Activities with Triggers and Transactions", Proc. ACM SIGMOD, 1990. [11] Ellis C., Nutt G., \Modeling and Enactment of Work ow Systems", in Application and Theory of Petri Nets, M. Ajmone Marsan Ed., Lecture Notes in Computer Science 691, New York: Springer Verlag, 1993. 18

[12] Ellis S., Keddara K. and Rozenberg G., \Dynamic Change within Work ow Systems", ACM Conf. on Organizational Computing Systems (COOCS 95), 1995. [13] Forst A., Kuhn E., Bukhres O., \General Purpose Work ow Languages", Distributed and Parallel Databases, vol. 3, n. 2, April 1995. [14] Fraternali P., Tanca, L.: \A Toolkit for the Design of Active Database Semantics", Dipartimento di Elettronica e Informazione, Politecnico di Milano, Technical Report 93-078, 1993. [15] Georgakopoulos D., Hornick M., Sheth A., \An Overview of Work ow Management: from Process Modeling to Work ow Automation Infrastructure", Distributed and Parallel Databases, vol. 3, n. 2, April 1995. [16] Gonzales-Quel A., Gonzales S., Perez M., \IDEA Technology Assessment Based on Work ow Applications. The Royal Life Application", IDEA Rep. IDEA.DE.21S.001.01, November 1994. [17] Hewlett Packard Company, \Work ow Module Programming Guide", Palo Alto, Ca, July 1994. [18] Hsu M. (ed.), Special Issue on Wor ow and Extended Transaction Systems, Data Engineering Bulletin, 16(2), June 1993. [19] Kappel G., Lang P., Rausch-Schott S., Retschitzegger W., \Work ow Management Based on Objects, Rules and Roles", Data Engineering, vol. 18, n. 1, March 1995. [20] Krishnakumar N., Sheth A., \Managing Heterogeneous Multi-system Tasks to Support Enterprisewide Operations", Distributed and Parallel Databases, vol. 3, n. 2, April 1995. [21] Paton N.W., Diaz O., Williams M., Campin J., Dinn A., and Jaime A: \Dimensions of Active Behaviour", in Rules in Database Systems, Norman W. Paton and M. Howard Williams (Eds), SpringerVerlag, 1993. [22] Rusinkiewicz M., Sheth A., \Speci cation and Execution of Transaction Work ows", in Modern Database Systems: the Object Model, Interoperability, and beyond, Kim W. (ed.), Addison-Wesley, 1994. [23] Sheth A., Rusinkiewicz M., \On Transactional Work ows", Data Engineering Bulletin, 16(2), June 1993. [24] Ullman, J.D., \Principles of Database and Knowledge Base Systems", 2 Volumes, Computer Science Press, Rockville, Maryland, 1989. [25] Widom J., Ceri S., \Active Database Systems", Morgan-Kaufmann, San Mateo, Ca, May 1995.

19

Appendix A: View, Functions, and Macroes VIEWS

/* WT to skip, because the following join task has already been satis ed */ Skip (CASE, WT, AN):WFCase (CASE, WF, -, -) Next (WF, WT, JT) JoinHandler (CASE, JT,AN,CT,QR) CT >= QR /* Direct connections between WT */ Direct(CASE,WT,NT):Next (WF,WT, NT) WFCase (WF,CASE) WorkTask (WF, NT) /* WTs followed by a RT */ NextIsRT (CASE, WT, JT, TY, QRM):Next(WF,WT, JT) WFCase (CASE,WF, -, -) RoutingTask (WF, JT, TY, QRM) /* JTs with quorum satis ed */ JoinReady (CASE, JT,AN, NWT,CT):JoinHandler (CASE, JT, AN, CT, QRM) CNT = QRM-1 WFCase(CASE, WF) Next ( WF, JT, NWT) /* Tasks to active after a fork, along with activation numbers and conditions */ ToActiveAfterFork (CASE, FT, NWT, CND, AN):WFCase(CASE,WF, -, -) AfterFork(WF, FT, NWT, CND) Activations(CASE, NWT, AN)

FUNCTIONS /* Returns in AG the name of the task executor */ agent seek (in :WT, out : Agent) /* Returns the current date-time */ now /* WT and WTO are vars representing a set of bindings. QTY is a var bound to a constant or a constant */ choose (in: WT, in: QTY, out: WTO)

MACROES 20

/* Macroes are placeholders in rule templates for application- speci c code generation */ task precond, representing task preconditions task precond event, representing events capable of modifying task preconditions task exception, representing a task exception task exception event, representing events capable of raising task exceptions task reaction, representing the reaction to a task exception delete vars tables, representing the deletion of all the tables containing local WF variables

Appendix B: Generic Rules

Group G2 create rule new case in group G2 /* a new case is started. The rule set the starting task to ready */ when inserted (NewCase) if inserted [NewCase(WF, AG)], Work ow(WF, ST) then insert [WFCase(new CASE, WF, AG, now)], insert [Ready(CASE, ST, 1)], delete [NewCase(WF, AG)]

create rule initialize for iter join in group G2

/* when a new case is started, JoinHandler is initialized to handle iterative join*/ when inserted (WFCase) if inserted [WFCase(CASE, WF, -, -)], RoutingTask(WF, IJ, \iter join", QRM) then insert [JoinHandler(CASE,IJ,1,0,QRM)]

create rule initialize activation numbers in group G2 /* when a new case is started, the activation number is set to 0 for every task*/ when inserted (WFCase) if inserted [WFCase(CASE, WF, -, -)], WorkTask(WF, WT) then insert [Activations(CASE, WT, 0)] Group G3 create rule skip task in group G3

/* check if the ready task can be skipped, because it would have no e ect on the following join task */ when inserted (Ready) if inserted [Ready(CASE,WT,AN)], Skip(CASE,WT,AN) then update [Activations(CASE, WT, :AN)], delete [Ready(CASE,WT,AN)]

Group G4 21

create rule register task done in group G4 /* insert data in TaskHistory and remove the instance from WTInstance */ when inserted (Done) if inserted [Done(CASE, WT, AN, FS)], WTInstance(CASE, WT, AN, -, ST, AG) then insert [TaskHistory(CASE, WT, AN, ST, now, FS, AG)], delete [WTInstance(CASE, WT, AN, -, -, -, -)], delete [Done(CASE, WT, AN, - )] create rule next is end ow in group G4 /* if the ended task was the last, the end of case is signaled */ when inserted (Done) if inserted [Done(CASE, WT, -, -)], WFCase(CASE, WF, AG, ST), Next(WF, WT, \end ow") insert [EndCase(CASE)]

then create rule handle new join in group G4

/* if the next task is a JT, and it is the rst with this activation number, an insert in joinHandler is made. */ when inserted (Done) if inserted [Done(CASE, WT, AN, -)], NextIsRT(CASE, WT, JT, \join", QRM), not (JoinHandler(CASE, JT, AN, -, -)) then insert [JoinHandler(CASE, JT, AN, 0, QRM)]

Group G5 create rule handle direct connection in group G5 /* if the next task is a WT, the rule sets it to ready */ when inserted (Done) if inserted [Done(CASE, WT, -, -)], Direct(CASE, WT, NT), Activations(CASE, NT, AN) insert [Ready(CASE, NT, AN++)]

then create rule handle satis ed join in group G5

/* if the next task is a JT, and quorum is satis ed, the rule sets the WT to ready and increments the counter */ when inserted (Done) if inserted [Done(CASE, WT, AN, -)], NextIsRT(CASE, WT, JT, \join", -), JoinReady(CASE, JT, AN, NT, CT), Activations(CASE, NT, ACT) then update [JoinHandler(CASE, JT, AN, :CT++, -)], insert [Ready(CASE, NT, ACT++)]

create rule handle not satis ed join in group G5

/* if the next task is a JT, and quorum is not exactly satis ed, the rule increments the counter*/ 22

when inserted (Done) if inserted [Done(CASE, WT, AN, -)],

NextIsRT(CASE, WT, JT, \join", -), not (JoinReady(CASE, JT, AN, -,CT) ) update [JoinHandler(CASE, JT, AN, :CT++, -)]

then create rule handle satis ed iterative join in group G5

/* if the next task is an iterative join, and quorum is satis ed, the rule sets the WT to ready and increments the counter */ when inserted (Done) if inserted [Done(CASE, WT, -, -)], NextIsRT(CASE, WT, IJT, \iter join", -), JoinReady(CASE, IJT, -, NWT, -), Activations(CASE, NWT, ACT) then update [JoinHandler(CASE, IJT, -,:0, -)], insert [Ready(CASE, NWT, ACT++)]

create rule handle not satis ed iterative join in group G5

/* if the next task is an iterative join, and quorum is not satis ed, the rule increments the counter*/ when inserted (Done) if inserted [Done(CASE, WT, -, -)], NextIsRT(CASE, WT, IJT, \iter join", -), not (JoinReady(CASE, IJT, -, -, CNT) ) then update [JoinHandler(CASE, IJT, -, :CNT++, -)]

create rule handle fork in group G5 /* a speci ed number of output task is activated */ when inserted (Done) if inserted [Done(CASE, WT, -, -)], NextIsRT(CASE, WT, FT, \fork", QTY), ToActiveAfterFork(CASE, FT, NT, -, AN), Choose(NT, QTY, NWO) insert [Ready(CASE, NWO, AN++)]

then create rule handle conditional fork in group G5 /* output tasks satisfying the condition are activated */ when inserted (Done) if inserted [Done(CASE, WT, -, -)], NextIsRT(CASE, WT, CFT, \cond fork", -), ToActiveAfterFork(CASE, CFT, NT, true, AN), insert [Ready(CASE, NT, AN++)]

then create rule handle conditional mutualex fork in group G5 /* the output task satisfying the condition is activated */ when inserted (Done) if inserted [Done(CASE, WT, -, -)], NextIsRT(CASE, WT, MFT, \mutualex fork", -), ToActiveAfterFork(CASE, MFT, NT, true, AN), Choose(NT, 1, NWO) 23

then insert [Ready(CASE, NWO, AN++)] Group G6 create rule handle execute in group G6 /* the task enters the executing state */ when inserted (Execute) if inserted [Execute(CASE, WT, AN)] WTInstance(CASE, WT, AN, \waiting", -, -, -) then update [WTInstance(CASE, WT, AN, :\executing", -, -, -)], delete [Execute(CASE, WT, AN)]

create rule handle suspend in group G6 /* the task is suspended */ when inserted (Suspend) if inserted [Suspend(CASE, WT, AN)] then update [WTInstance(CASE, WT, AN, :\suspended", -, -, -)], delete [Suspend(CASE, WT, AN)]

create rule handle resume in group G6 /* the task re-enters the executing state */ when inserted (Resume) if inserted [Resume(CASE, WT, AN)] WTInstance(CASE, WT, AN, :\suspended", -, -, -) then update [WTInstance(CASE, WT, AN, :\executing", -, -, -)], delete [Resume(CASE, WT, AN)]

create rule handle refuse in group G6 /* puts the task back into the ready state */ when inserted (Refuse) if inserted [Refuse(CASE, WT, AN)], WTInstance(CASE, WT, AN, -, ST, AG) then delete [WTInstance(CASE,WT, AN, -, -, -, -)]

insert [TaskHistory(CASE, WT, AN, ST, now, \refused",AG)], insert [Notify(CASE, WT, AN, new ID, \Task refuse")], insert [Ready(CASE, WT, AN)], delete [Refuse(CASE, WT, AN)]

Group G7 create rule delete late done in group G7

/* deletes the Done tables if the case-id belongs to a case already ended or not yet created */ when inserted (Done) if inserted [Done(CASE, -, -, -)], not (WFCase(CASE, -, -, -)) then delete [Done(CASE, -, -, -)]

create rule delete late refuse in group G7

/* deletes the Refuse tables if the case-id belongs to a case already ended or 24

not yet created */

when inserted (Refuse) if inserted [Refuse(CASE, -, -, -)], not (WFCase(CASE, -, -, -)) then delete [Refuse(CASE, -, -, -)] create rule delete late suspend in group G7

/* deletes the Suspend tables if the case-id belongs to a case already ended or not yet created */ when inserted (Suspend) if inserted [Suspend(CASE, -, -, -)], not (WFCase(CASE, -, -, -)) then delete [Suspend(CASE, -, -, -)]

create rule delete late resume in group G7

/* deletes the Resume tables if the case-id belongs to a case already ended or not yet created */ when inserted (Resume) if inserted [Resume(CASE, -, -, -)], not (WFCase(CASE, -, -, -)) then delete [Resume(CASE, -, -, -)]

Appendix C: Rule Templates

Group G1 create rule template monitor exceptions(wf,wt) in group G1

/* the system creates a rule according to this template for every WT. precond is replaced by task preconditions. If preconditions are not satis ed, the instance enters the inhibited state */ when task exceptions event(wf,wt) if task exception(wf,wt), WFcase(CASE, wf, -, -), WTInstance(CASE, wt, -, -, -, -) then reaction(wf,wt)

Group G2 create rule template end case(wf) in group G2

/* at the end of the case, the history table is lled and the execution tables are deleted */ when inserted (EndCase) if inserted [EndCase(CASE)] then insert [WFHistory(CASE, WF, AG, ST, now)], insert [Notify(CASE, 0, 0, new ID, \Case end")], delete [WFCase(CASE, -, -, -)], delete [JoinHandler(CASE, -, -, -, -)], delete [Activations(CASE, -, -)], delete vars tables(wf) 25

Group G3 create rule template precond true(wf,wt) in group G3

/* the system creates a rule according to this template for every WT. precond is replaced by task preconditions. If preconditions are satis ed, the instance enters the waiting state */ when inserted (Ready) if inserted [Ready(CASE, wt, AN)], WFcase(CASE, wf, -, -), not (Skip(CASE, wt, AN)), task precond(wf,wt) then AgentsSeek(wt, AG), update [Activations(CASE, wt, :AN)], insert [WTInstance(CASE, wt, AN, \waiting", now, AG)], delete [Ready(CASE, wt, AN)]

create rule template precond false(wf,wt) in group G3

/* the system creates a rule according to this template for every WT. precond is replaced by task preconditions. If preconditions are not satis ed, the instance enters the inhibited state */ when inserted (Ready) if inserted [Ready(CASE, wt, AN)], WFcase(CASE, wf, -, -), not (Skip(CASE, wt, AN)), not (task precond(wf,wt)) then update [Activations(CASE, wt, :AN)], insert [WTInstance(CASE, wt, AN, \inhibited", now, AG)], delete [Ready(CASE, wt, AN)]

create rule template monitor precond in inhibited(wf,wt) in group G3

/* the system creates a rule according to this template for every exception of every WT. When the exception is raised, the reaction is executed*/ when task precond event(wf,wt) if WTInstance(CASE, wt, -, \inhibited", -, -), WFcase(CASE, wf, -, -), taskprecond(wf,wt) then AgentsSeek(wt, AG), update [WTInstance(CASE, wt, -, :\waiting", -, -)]

Appendix D: Rules for the Military Enrollment Work ow

create rule monitor exceptions getAndRecordData 1 in group G1 /* system generated rule to handle the exception. The reaction causes the end of the case. */ when inserted (Military EnrollmentVars) if inserted (Military EnrollmentVars(CASE, SSN, -, -, -, -) Drafted(SSN, -, -), WFcase(CASE, \Military Enrollment", -, -), WTInstance(CASE, \GetAndRecordData", -, -, -, -) 26

then insert [EndCase(CASE)] create rule physicalTest true in group G3

/* the system creates this rule to manage the case of true precondition when the task is ready. If this is the case, the task enters the waiting state */ when inserted (Ready) if inserted [Ready(CASE, \PhysicalTest",AN)], WFcase(CASE, \Military Enrollment", -, -), not (Skip(CASE, \PhysicalTest", AN)), FreeVisitRoom(-) then AgentsSeek(\PhysicalTest", AG) insert [WTInstance(CASE, \PhysicalTest", AN, \waiting", now, AG)] update [Activations(CASE, \PhysicalTest", :AN)] delete [Ready(CASE, \PhysicalTest", AN)]

create rule physicalTest false in group G3 /* the system creates this rule to manage the case of false precondition when the task is ready. If this is the case, the task enters the inhibited state */ when inserted (Ready) if inserted [Ready(CASE, \PhysicalTest", AN)], WFcase(CASE, \Military Enrollment", -, -), not (Skip(CASE, PhysicalTest,AN)), not (FreeVisitRoom(-)) then insert [WTInstance(CASE, \PhysicalTest", AN, \inhibited", now, AG)] delete [Ready(CASE, \PhysicalTest",AN)] create rule monitor physicalTest precond in group G3 /* the system creates this rule to monitor PhysicalTest precondition: when it becomes true, an agent is searched and the task enters the waiting state*/ when inserted (FreeVisitRoom) if inserted [FreeVisitRoom(-)], WTInstance(CASE, \PhysicalTest", -, \inhibited", -, -), WFcase(CASE, \Military Enrollment", -, -) then AgentsSeek(\PhysicalTest", AG) update [WTInstance(CASE, \PhysicalTest", -, :\waiting", -, -)] create rule Military Enrollment case end in group G2 /* at the end of the case, the history table is lled; service tables are deleted. */ when inserted (EndCase) if inserted [EndCase(CASE)] then insert [WFHistory(CASE, WF, AG, ST, now)] insert [Notify(CASE, 0, 0, new ID, \Case end")] delete [WFCase(CASE, -, -, -)] delete [JoinHandler(CASE, -, -, -, -)] delete [Activations(CASE, -, -)] delete [Military EnrollmentVars(CASE, -, -, -, -, -)]

27