Declarative workflow system supporting side-effects

Abstract

An object-focused workflow system for processing a received object in accordance with a declarative workflow specification. The specification includes modules and attributes, where module execution results in the evaluation of attributes, and may include the initiation of a side-effect action performed by an external component. Whether modules are to be executed for a particular received object is determined by associated enabling conditions. Attributes may be evaluated in accordance with computation rules and a combining policy, where the computation rules specify how values are to be contributed to an attribute, and the combining policy indicates how those contributed values are combined in order to assign a value to the attribute. Tasks in the workflow system may be executed eagerly in order to improve the performance of the workflow system. The eager evaluation of tasks includes the determination of whether such tasks are eligible for eager evaluation, and whether the tasks are unneeded or necessary for the processing of the received event. Workflows which satisfy described design properties allow for improved algorithms for the determination of the whether tasks are eligible, eager, and/or necessary. A graphical user interface is provided for displaying a representation of the evaluation status of the modules and attributes during workflow execution.

Claims

We claim:

1. A workflow system for processing a received object comprising:

a memory storing a declarative program specification, said program specification defining:

a plurality of modules in a workflow instance, the plurality of modules producing associated attributes when executed, wherein each attribute is produced by only one module, wherein at least one of said attributes depends on another attribute, and wherein the execution of at least one of said modules results in the initiation of a side-effect action performed by a component external to said workflow system;

a plurality of enabling conditions which are independent of the time duration of workflow instance execution, for determining whether associated ones of said modules are enabled, wherein evaluation of at least one of said enabling conditions depends on a value of an attribute;

wherein the set of data flow dependencies and enabling flow dependencies between said modules and said enabling conditions is acyclic; and

wherein one of the modules produces a particular attribute, and wherein data flow between the particular attribute and an enabling condition that depends on the particular attribute is defined in an implicit rather than explicit manner in said declarative program specification; and

a processor for executing said program specification, said execution comprising the steps of:

evaluating enabling conditions; and

executing modules based on said evaluated enabling conditions.

2. The workflow system of claim 1 wherein said execution of said program specification implements at least a portion of a customer care system.

3. The workflow system of claim 2 wherein said customer care system is a call center for processing incoming customer telephone calls.

4. The workflow system of claim 2 wherein said customer care system is an electronic commerce system.

5. The workflow system of claim 1 wherein the execution of at least one of said modules includes the execution of a procedural function.

6. The workflow system of claim 5 wherein said procedural function is specified by a procedural computer language.

7. The workflow system of claim 1 wherein at least one of said modules is a decision module.

8. The workflow system of claim 1, wherein:

once stable, values of the modules, attributes and enabling conditions cannot change for the time duration of workflow instance execution;

said execution further comprises:

determining if a first of said enabling conditions is stable;

evaluating said enabling condition when said enabling condition is stable; and

evaluating a module associated with said first enabling condition when said enabling condition is stable and said enabling condition evaluates to a predetermined value.

9. The workflow system of claim 1, wherein:

a first of said modules produces a first attribute value and a second of said modules uses said first attribute value to produce a second attribute value, wherein data flow from said first attribute value to said first module is defined in an implicit rather than explicit manner in said declarative program specification; and

said execution further comprises determining a sequence of execution between said first and second modules, whereby said first attribute value will be determined before said second module uses said first attribute value.

10. The workflow system of claim 1, wherein:

a first of said modules produces a first attribute value and a first of the enabling conditions uses said first attribute value to determine whether an associated one of said modules is enabled, wherein data flow from said first attribute value to said first enabling conditions is implicit; and

said execution further comprises determining a sequence of execution between said first module and said enabling condition, whereby said first attribute value will be determined before said first enabling condition uses said first attribute value.

11. The workflow system of claim 1, wherein the set of data flow dependencies and enabling flow dependencies between said modules and said enabling conditions is acyclic because there is no module M for which there is a directed path in a graph of data flow dependencies and enabling flow dependencies that starts at M and ends at M.

12. A computer readable medium storing a declarative program specification, said program specification capable of execution on a computer processor for implementing a workflow system, said program specification defining:

a plurality of modules in a workflow instance, the plurality of modules producing associated attributes when executed, wherein each attribute is produced by only one module, wherein at least one of said attributes depends on another attribute, and wherein the execution of at least one of said modules results in the initiation of a side-effect action performed by a component external to said workflow system;

a plurality of enabling conditions which are independent of the time duration of workflow instance execution, for determining whether associated ones of said modules are enabled, wherein evaluation of at least one of said enabling conditions depends on a value of an attribute;

wherein the set of data flow dependencies and enabling flow dependencies between said modules and said enabling conditions is acyclic; and

wherein one of the modules produces a particular attribute, and wherein data flow between the particular attribute and an enabling condition that depends on the particular attribute is defined in an implicit rather than explicit manner in said declarative program specification; and

wherein said execution of said program specification on said computer processor comprises evaluation of enabling conditions and execution of modules based on said evaluation.

13. The computer readable medium of claims 12 wherein said execution of said program specification implements a customer care system.

14. The computer readable medium of claim 13 wherein said customer care system is a call center for processing incoming customer telephone calls.

15. The computer readable medium of claim 13 wherein said customer care system is an electronic commerce system.

16. The computer readable medium of claim 12, wherein:

once stable, values of the modules, attributes and enabling conditions cannot change for the time duration of workflow instance execution;

said execution of said program specification on said computer further comprises:

determining if a first of said enabling conditions is stable;

evaluating said enabling condition when said enabling condition is stable; and

evaluating a module associated with said first enabling condition when said enabling condition is stable and said enabling condition evaluates to a predetermined value.

17. The computer readable medium of claim 12, wherein:

a first of said modules produces a first attribute value and a second of said modules uses said first attribute value to produce a second attribute value, wherein data flow from said first attribute value to said first module is defined in an implicit rather than explicit manner in said declarative program specification; and

said execution of said program specification on said computer further comprises determining a sequence of execution between said first and second modules, whereby said first attribute value will be determined before said second module uses said first attribute value.

18. The computer readable medium of claim 12, wherein:

a first of said modules produces a first attribute value and a first of said enabling conditions uses said first attribute value to determine whether an associated one of said modules is enabled, wherein data flow from said first attribute value to said first enabling conditions is defined in an implicit rather than explicit manner in said declarative program specification; and

said execution of said program specification on said computer further comprises determining a sequence of execution between the first module and the enabling condition, whereby said first attribute value will be determined before said first enabling condition uses said first attribute value.

19. The computer readable medium of claim 12, wherein the set of data flow dependencies and enabling flow dependencies between said modules and said enabling conditions is acyclic because there is no module M for which there is a directed path in a graph of data flow dependencies and enabling flow dependencies that starts at M and ends at M.

20. A method for operation of a workflow system for processing a received object, said workflow system comprising a memory storing a declarative program specification defining:

a plurality of modules in a workflow instance, the plurality of modules producing associated attributes when executed, wherein each attribute is produced by only one module, wherein at least one of said attributes depends on another attribute, and wherein the execution of at least one of said modules results in the initiation of a side-effect action performed by a component external to said workflow system;

a plurality of enabling conditions which are independent of the time duration of workflow instance execution for determining whether associated ones of said modules are enabled, wherein evaluation of at least one of said enabling conditions depends on a value of an attribute;

wherein the set of data flow dependencies and enabling flow dependencies between said modules and said enabling conditions is acyclic; and

wherein one of the modules produces a particular attribute, and wherein data flow between the particular attribute and an enabling condition that depends on the particular attribute is defined in an implicit rather than explicit manner in said declarative program specification; and

said method comprising the step of:

executing said program specification wherein said step of executing further comprises the steps of:

evaluating enabling conditions; and

executing modules based on said evaluation of enabling conditions.

21. The method of claim 20 wherein said execution of said program specification implements a customer care system.

22. The method of claim 21 wherein said customer care system is a call center for processing incoming customer telephone calls.

23. The method of claim 20 wherein the execution of at least one of said modules further comprises the step of executing a procedural function.

24. The method of claim 23 wherein said procedural function is specified by a procedural computer language.

25. The method of claim 20, wherein:

once stable, values of the modules, attributes and enabling conditions cannot change for the time duration of workflow instance execution;

the step of executing further comprises the steps of:

determining if a first of said enabling conditions is stable;

evaluating said enabling condition when said enabling condition is stable; and

evaluating a module associated with said first enabling condition when said enabling condition is stable and said enabling condition evaluates to a predetermined value.

26. The method of claim 20, wherein:

a first of said modules produces a first attribute value and a second of said modules uses said first attribute value to produce a second attribute value, wherein data flow from said first attribute value to said first module is defined in an implicit rather than explicit manner in said declarative program specification; and

the step of executing further comprises the step of determining a sequence of execution between said first and second modules, whereby said first attribute value will be determined before said second module uses said first attribute value.

27. The method of claim 20, wherein:

a first of said modules produces a first attribute value and a first of said enabling conditions uses said first attribute value to determine whether an associated one of said modules is enabled, wherein data flow from said first attribute value to said first enabling conditions is defined in an implicit rather than explicit manner in said declarative program specification; and

the step of executing further comprises the step of determining a sequence of execution between said first module and said enabling condition, whereby said first attribute value will be determined before said first enabling condition uses said first attribute value.

28. The method of claim 20, wherein the set of data flow dependencies and enabling flow dependencies between said modules and said enabling conditions is acyclic because there is no module M for which there is a directed path in a graph of data flow dependencies and enabling flow dependencies that starts at M and ends at M.

Description

FIELD OF THE INVENTION

The present invention relates to computer implemented workflow systems.

BACKGROUND OF THE INVENTION

A workflow specification is a description of how a class of objects should be handled. Such objects may be, for example, an incoming call to a call center, insurance claims arriving at a claim center, requests for information from an Internet web site, etc. The workflow specification describes how agents (humans) and/or components (software and hardware) interact to accomplish specific goals. Such components generally include components which are external to the workflow system. The present invention is concerned with workflow specifications executing on computer systems in order to implement workflow systems.

There is an increasing need to customize workflow systems based on a combination of information about the object being processed and the current operational status of the system. Such customization is complex as it often depends on various parameters. For example, in a workflow system implementing a call center which requires a customer credit check, there may be several types of credit checks, ranging from simple to complex, which could be selected for a particular customer. The specific type of credit check chosen could depend on a number of parameters, such as past experience with the particular customer, the amount of credit requested, etc.

Most current workflow systems are based on procedural specifications. In a procedural specification, the specification explicitly states the steps to be taken during workflow execution and the sequence of those steps. Such procedural workflow specifications may be represented using flowcharts, text based descriptions, or a combination of text and flowcharts. A procedural workflow may be specified using well known computer programming languages, such as C++.

One problem with the procedural specification of workflow systems is that modifications to the workflow specification may be difficult. As a result of the nature of procedural specifications, a modification to change one aspect of how an object is processed may require changes to many parts of the specification which implement that aspect. This is because one aspect of the workflow may depend on many execution threads within the procedural specification. Another problem with procedural specifications is that they are difficult to analyze because the resulting workflow execution may depend on many execution threads.

One solution to the problem of procedural specification of workflows is described in Narayanan Krishnakumar and Amit Sheth, Managing Heterogeneous Multi-system Tasks to Support Enterprise-wide Operations, Distributed and Parallel Databases, 3, 1-33 (1995). In the workflow system described therein, the flow of control is specified using rules having the form "event-condition-action", such that when a certain event occurs, if the condition is true, then the specified action is performed. As such, whether or not an action is performed is dependent on a condition being true at the time an event occurs, where the event may be, for example, the completion of some action. Thus, these rules are, at least implicitly, dependent on the duration of actions because the evaluation of whether a condition is true may depend on when an action completes. While this type of system provides some advantages over the purely procedural specification of workflows, the above described time dependence results in many of the same problems. Specifically, workflows described in this manner are difficult to analyze and understand.

U.S. Pat. No. 5,809,212 entitled Conditional Transition Networks and Computational Processes for Use Interactive Computer-Based Systems, is directed to a conditional transition network for representing a domain of knowledge in a computer system. Although the system described therein utilizes time independent rules for processing, the system is not a workflow system, but instead is directed to accessing stored information (e.g. documents). As such, the system does not control external components and is therefore not appropriate for a workflow system because most workflow systems require control of external components for the processing of objects.

SUMMARY OF THE INVENTION

The present invention is a workflow system which, as a result of certain properties, is an improvement over prior workflow systems. One such property is that the workflow system in accordance with the invention is specified declaratively, such that the workflow specification explicitly describes the steps to be taken during workflow execution, but the order of those steps is implicit in the specification. In addition, the specification includes modules which, when executed, result in the initiation of side-effect actions which are performed by components external to the workflow system. Whether or not the modules are executed is determined by associated enabling conditions which are independent of the time duration of module execution. The set of data flow dependencies and enabling flow dependencies between the modules and the enabling conditions is acyclic.

As will be apparent to those of ordinary skill in the art by reference to the following detailed description and the accompanying drawings, a workflow system designed in accordance with the present invention improves on prior workflow systems in several respects. First, since the specification is declarative, aspects of the workflow can be easily modified by changing the part of the specification which implements the aspect, rather than having to modify many parts of a procedural specification as in prior workflow systems. Further, since the enabling conditions are independent of the time duration of module execution, the behavior of the workflow system can be more easily analyzed and understood.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a high level block diagram of an object focused workflow system;

FIG. 2 shows a graphical representation of an example declarative language specification;

FIG. 3 shows a graphical representation of a flowchart module portion of the example declarative language specification;

FIG. 4 shows the textual representation of the flowchart module shown graphically in FIG. 3;

FIG. 5 shows a graphical representation of a declarative module portion of the example declarative language specification;

FIG. 6 shows the textual representation of the declarative module shown graphically in FIG. 5;

FIG. 7 shows the textual representation of a foreign module portion of the example declarative language specification;

FIG. 8 shows the textual representation of a foreign module portion of the example declarative language specification;

FIG. 9 shows a graphical representation of a declarative module portion of the example declarative language specification;

FIG. 10 shows the textual representation of the declarative module shown graphically in FIG. 9;

FIG. 11 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 12 shows the textual representation of a foreign module portion of the example declarative language specification;

FIG. 13 shows the textual representation of a foreign module portion of the example declarative language specification;

FIG. 14 shows the textual representation of a foreign module portion of the example declarative language specification;

FIG. 15 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 16 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 17 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 18 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 19 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 20 shows the textual representation of a foreign module portion of the example declarative language specification;

FIG. 21 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 22 shows the textual representation of a foreign module portion of the example declarative language specification;

FIG. 23 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 24 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 25 shows the textual representation of a decision module portion of the example declarative language specification;

FIG. 26 shows a data and enabling flow diagram;

FIG. 27 shows the typing rules for Combining Policy Language operators;

FIG. 28 shows a high level functional diagram of a decision engine;

FIG. 29 shows the finite state automata for a non-side-effect attribute;

FIG. 30 shows the finite state automata for a side-effect attribute;

FIG. 31 shows the condition tree for an example enabling condition;

FIG. 32 shows a data and enabling flow diagram;

FIG. 33 shows a dependency graph;

FIGS. 34A-34D show pseudo code for the basic algorithm for determining whether a task is eligible or unneeded;

FIGS. 35A-35G show pseudo code for the extended algorithm for computing whether an attribute is necessary;

FIG. 36 shows the finite state automata for decision modules;

FIG. 37 shows the finite state automata for computation rules;

FIG. 38 shows an illustrative display screen shot of the graphical user interface;

FIG. 39 shows an illustrative display screen shot of the graphical user interface; and

FIGS. 40A and 40B show pseudo code for the algorithm for maintaining and dynamically updating the graphical user interface display.

DETAILED DESCRIPTION

A high level block diagram of an object-focused workflow system in which the present invention may be implemented is shown in FIG. 1. As used herein, a workflow system is a system that facilitates the systematic execution of activities and tasks on a class of similar input objects based on common modules and/or functions. The workflow system may treat most or all of the objects in a uniform way, or may treat the input objects in highly differentiated ways. An instance of the workflow includes the processing that is performed by the workflow system and by external components as a result of an input object being provided to the workflow system. Multiple instances of the workflow might execute simultaneously. The workflow system may operate in real-time, near real-time, or at slower speeds. In accordance with the embodiment shown in FIG. 1, the object-focused workflow system 100 implements a customer care system for processing incoming calls. Of course the techniques described herein may be used to implement many different types of systems, such as electronic commerce systems. The system 100 includes a Declarative Language (DL) specification 102, a decision engine 104, a graphical user interface (GUI) 105, and an abstraction layer 106.

DL specification 102 represents a specification describing the desired operation of the object-focused workflow system 100 upon the receipt of some object. For example, the object may be the receipt of an incoming telephone call to the customer care system. At least a portion of the DL specification 102 includes a declarative description of the operation of the system. The declarative description explicitly describes the steps to be taken during workflow execution, but the order of those steps is implicit in the DL specification 102. This is a departure from the prior art workflow systems which generally describe workflow procedurally, that is, the specification explicitly states the steps to be taken during workflow execution and the sequence of those steps. The benefit of a declarative workflow specification is that it allows a system designer to focus on the core logic of an application and lets the underlying computer system address implementation details, including the particular order in which steps should be taken. The details of the DL specification 102 will be described in further detail below.

The decision engine 104 receives the DL specification 102 and processes objects in accordance with the DL specification 102. Such processing of objects includes the control of various external components 108 such as a private branch exchange (PBX) 110, interactive voice response unit (IVR) 112, outbound call processor 114, e-commerce server 116, and database 120. These components are external in that they are not part of the workflow system 100, but may be controlled by the workflow system 100 during processing of an object. Only one of each of these external components is shown in FIG. 1 for clarity, however external components 108 may include more than one of each of these components. For example, it would be common for the external components to include multiple databases. Further, the external components 108 shown in FIG. 1 is only an illustrative list of the types of components that may be controlled by an object-focused system implementing a customer care system. An object-focused system implementing other types of systems would likely contain other types of components.

A graphical user interface 105 is provided for displaying a representation of the execution of the workflow on a computer display screen and will be described in further detail below.

An abstraction layer 106 is provided between the decision engine 104 and the external components 108 so that the decision engine 104 may communicate with and control the external components using a high level communication protocol, without the need to deal with the particular communication protocols of each of the different external components. This is particularly useful because the external components 108 will generally be heterogeneous with different components being manufactured by different companies. The abstraction layer 106 includes an integrated view 122, system wrappers 124, and data source wrappers 126. The system wrappers 124 provide abstract interfaces to the external components 108, exposing properties relevant to the workflow application while hiding irrelevant details concerning particularities of the components' interfaces and aspects of the components' behavior. The data source wrappers 126 provide abstract interfaces to the databases and reporting features of the other external components 108, exposing relevant data and update capabilities. The integrated view 122 provides a unified interface to the functionalities supported by the external components 108, using abstract data types or similar interfacing modules. For example, the integrated view 122 may expose a functionality without exposing what components the functionality is implemented by, and expose a computed data set without showing what databases the raw data is residing on.

The decision engine 104, GUI 105, and abstraction layer 106 are high level representations of functions that may be performed by one or more appropriately programmed computers. The components of such computers are well known in the art and the details of such computers will not be described herein.

The contents of the DL specification 102 will now be described. In the embodiment described herein, the DL specification 102 comprises a textual specification which is provided to the decision engine 104 for processing. However, the DL specification 102 may be represented in other ways as well. For example, the DL specification 102 may comprise a graphical specification which is provided to the decision engine via data structures. The description of the DL specification 102 will be provided in conjunction with an example application of a travel agency customer care system. It is noted that the sole purpose of describing the DL specification 102 in conjunction with a particular example is to provide a context for describing the principles of the present invention. The use of the travel agency example used herein provides such a context. The purpose of this description is not to provide a complete description of how to implement a travel agency call center.- Therefore, the example graphical and textual descriptions included herein will only be described in enough detail so as to clearly describe aspects of the present invention. Further, although a fair level of detail is provided with respect to the example, not all details of the figures (in particular the textual specification) will be described herein. Further, the example is not to be taken as a complete description of the specification needed to implement such a travel agency call center. Portions of the specification which would be required to implement the example have been omitted for clarity. Further, portions of the specification have been included solely for the purpose of describing a certain aspect of the invention, and such portions may be inconsistent with other portions of the specification which have been included to describe certain other aspects of the invention.

In accordance with the example, it is assumed that a travel agency call center receives incoming calls from customers. The object passing through the system in this example is an incoming call, and the system operates to determine how to route the incoming call and what so-called side-effects should be executed. Side-effects will be described in further detail below. Assume that the call center has multiple agents, and each agent has one of 4 skill levels numbered 1-4. Each of the skill levels represents a particular level of expertise in a different type of call. During operation, it is desirable to route calls to appropriate agents in order to best utilize the agents' skills. Further details regarding the example application will be described below.

FIG. 2 shows a graphical representation of a DL specification for one portion of the travel agency example. More particularly, FIG. 2 shows a graphical representation of the Routing_To_Skill module 202 which will determine, based on various parameters of an incoming call, how to route the call. The term module is used herein to describe a logical grouping of related processing functions. The input parameters to the Routing_To_Skill module 202 are ANI, DNIS, WEB_DB_LOAD, and PROMOS_OF_THE_DAY. The output parameters of the Routing_To_Skill module 202 are SKILL, ON_QUEUE_PROMO, and WRAP_UP. These input parameters and output parameters are called attributes. The term attribute is used herein to describe a data item associated with an object which may be evaluated during processing of the object. An attribute in an object-focused workflow system is similar to a variable in a procedural system.

For purposes of this discussion, since the Routing_To_Skill module 202 is the highest level module described, it is assumed that values for the input attributes to the Routing_To_Skill module are provided to the system prior to execution of the workflow. Such attributes which are provided from some external source are called source attributes. Similarly, the output attributes of the Routing_To_Skill module are called target attributes, because these are the attributes for which values are produced when processing is completed. Attributes which are used during processing which are neither source attributes nor target attributes are called internal attributes.

There are four types of modules in a DL specification. Declarative modules have a declarative semantics and contain sub-modules. Declarative modules are represented in the figures using rounded corner rectangles. Decision modules produce a single attribute value through a novel technique for aggregating and synthesizing information using computation rules and a combining policy which will be described in further detail below. Decision modules are represented in the figures using solid line hexagons. Flowchart modules are specified using a flowchart language to describe the processing. Flowchart modules are represented in the figures using rectangles with a cut corner. Foreign modules are implemented using some type of external function (e.g. database query or web server routine). Foreign modules are represented in the figures with a rectangle. Each of these types of modules will be described in further detail below.

As shown in FIG. 2, the Routing_To_Skill module 202 is made up of six sub-modules: Identify_Caller 210, Info_About_Customer 220, Info_From_Web 230, Promo_Selection 240, Routing_Decisions 250, and Calculate_Wrap_Up 260. Module 210 is represented as a rectangle with a cut corner indicating that it is a flowchart module. Modules 230 and 240 are represented as rectangles which indicates that these modules are foreign modules and obtain values for attributes by executing external functions. Modules 220 and 250 are represented as rounded corner rectangles, which indicates that these modules are declarative modules which are specified at a lower level using another DL specification. These types of modules are used to conveniently represent at a high level a substantial amount of lower level processing. Such high level representation makes it easier for a designer to visualize the overall function of a DL specification. Module 260 is represented as a hexagon, which indicates that this module is a decision module and evaluates a single attribute using computation rules and a combining policy as will be described in further detail below.

Each module has input attributes and output attributes. As will become clear from the description which follows, the workflow system 100 is attribute-based, that is, much of the processing which occurs in the workflow system is based on the evaluation of attribute values. Attributes are assigned triples as follows: (State, Value, Exception-Value) where: ##EQU1##

The meaning of these states is as follows. VALUE indicates that the attribute currently has a value assigned to it. EXCEPTION indicates that there has been some error in evaluating the attribute. DISABLED indicates that it has been determined that the attribute will not be assigned any value. It is noted that a DISABLED State does not indicate any error, but is part of normal processing. UNINITIALIZED indicates that essentially no information is available about the attribute. FAIL indicates that the module defining the attribute was enabled (as described below), but aborted before producing a state of VALUE, EXCEPTION, or DISABLED for the attribute. It is also noted that attribute assignments are monotonic, that is, once an attribute is assigned a state other than UNINITIALIZED, further processing of the workflow object will not change the state and any assigned value.

The value of an attribute will be some value assigned to the attribute if the state of the attribute is VALUE. Otherwise, the value will contain .perp., which indicates no value. The Exception-Value of an attribute will contain an exception value indicating a particular error condition if the state of the attribute is EXCEPTION. Otherwise, the Exception-Value will contain .perp..

Modules also have associated states. Module states are UNINITIALIZED, SUCCESS, EXCEPTION, and DISABLED. The module state UNINITIALIZED indicates that essentially no information is available about the module. The module state SUCCESS indicates that the enabling condition (as described below) for the module was true, and the module executed successfully. The module state EXCEPTION indicates that the module was enabled, but an exception occurred. The module state DISABLED indicates that the module's enabling condition is false.

Each of the modules is associated with an enabling condition, which is a condition which determines whether the module will be evaluated for a given input object. Enabling conditions can refer to attribute values, attribute exception values, attribute states (e.g., whether the attribute has a value or whether an exception occurred when attempting to evaluate it), module states and module exception values. The enabling conditions are graphically represented as broken line hexagons 211, 221, 231, 241, 251, 261. Enabling conditions 211, 251, and 261 contain TRUE, which will always evaluate to a true condition, and therefore the Identify_Caller module 210, Routing_Decisions module 250, and Calculate_Wrap_Up module 260 will be evaluated for each input object. Enabling condition 221 contains the expression: VAL (ACCOUNT_NUMBER). The function VAL (X) will return a true condition if the attribute X is in the state VALUE, otherwise, false will be returned. Therefore, the enabling condition 221 indicates that the Info_About_Customer module 220 will be evaluated if the attribute ACCOUNT-NUMBER is in the state VALUE. If the attribute ACCOUNT-NUMBER is in state EXCEPTION, DISABLED, or FAILED, then enabling condition 221 will evaluate to false and the Info_About_Customer module 220 will not be evaluated. If the attribute ACCOUNT_NUMBER is in state UNINITIALIZED, then enabling condition 221 cannot yet be evaluated. Thus, the evaluation of enabling condition 221 depends on the attribute ACCOUNT-NUMBER first receiving a state other than UNINITIALIZED. It is noted that this dependency is implicit in the DL specification and not explicitly specified by the system designer or programmer.

Various expressions can be used for enabling conditions. For example, enabling condition 231 indicates that the Info_From_Web module 230 will be evaluated if the value of the WEB_DB_LOAD attribute is less than 95% or if the ACCOUNT_NUMBER attribute does not have a value. Enabling condition 241 indicates that the Promo_Selection module 240 will be evaluated if the CUST_REC.HATES-PROMOS attribute is false.

FIG. 2 gives a high level graphical representation of the DL specification of the Routing-To-Skill module 202. Relevant portions of each of the sub-modules will now be described. A graphical representation showing further detail of the Identify_Caller module 210 is shown in FIG. 3. The DL specification in textual language corresponding to the graphical representation of FIG. 3 is shown in FIG. 4.

As shown in FIG. 4, the module name is specified in line 1, and an indication of which module the current module is a sub-module of is given in line 2. The next section defines the input attributes (line 3). The next section defines the output attributes (lines 4-14). Line 15 specifies the enabling condition, which corresponds to the enabling condition 211 shown in FIG. 2. The type of the module, in this case flowchart, is specified on line 16. The computation section of the textual specification (line 17) indicates how attributes are to be evaluated. For this module, the attributes will be evaluated according to the flowchart shown in FIG. 3. Of course, one skilled in the art could convert the flowchart of FIG. 3 to program code to implement the logic flow shown in FIG. 3. Such code is not included in FIG. 4 because it is not necessary for an understanding of the principles of the present invention. Finally, line 18 indicates that this module has a side-effect. The side-effect action is an interactive voice response (IVR) unit dip (line 19).

A side-effect action is an action which has a significant impact on a system or user that is external to the workflow system. Stated another way, the execution of a side-effect action imparts a substantial overhead on the workflow system. Some actions may be deemed as being side-effect actions because a cost is associated with each occurrence of the action. For example, queries against some databases may have no associated cost because the databases are maintained by the same organization that maintains the workflow system, while queries against other databases may have associated costs because the database is maintained by an external organization. An action may be considered to be a side-effect action if the effect of the action cannot be undone by a subsequent separate action. Side-effects may include actions such as executing financial transfers, issuing checks or other instruments of monetary value, invoking actions by other workflow engines, updating databases that are used by other software systems or users, or engaging users in an activity. An internal action is an action that is not a side-effect action. As described above in connection with line 18 of FIG. 4, an indication of whether a module includes a side-effect action is included in the DL specification.

The details of how attributes are evaluated by the Identify_Caller module 210 are given in the flowchart of FIG. 3. The decision of step 302 determines whether the attribute ANI has a value. As shown in FIG. 2, ANI is a source attribute which is an input to the high level Routing_To_Skill module 202, and represents the telephone number from which the incoming call originated. Since such a telephone number is not always available, the decision in step 302 is needed. If the ANI attribute has a value, then in step 304 the ACCOUNT-NUMBER and CUST_REC attributes for the customer associated with the ANI are evaluated by performing a lookup to an external database. If the decision in step 306 indicates that one customer has been identified, then in step 308 the attributes ACCOUNT_NUMBER and CUST-REC are assigned the values retrieved in step 304. The assigning of values to the attributes ACCOUNT_NUMBER and CUST-REC includes assigning values to the associated tuple: (State, Value, Exception-Value) for each of the attributes. Thus, the state of these attributes becomes VALUE, the value gets the value retrieved, and exception-value is assigned .perp., as described above. Further, in step 308, the attribute HOME_PHONE is disabled, such that its associated tuple (State, Value, Exception-Value) is updated such that state becomes DISABLED, value becomes .perp., and exception-value becomes .perp.. As described above, since attribute assignments are monotonic, the values and states for these attributes will not change during further processing of this particular incoming telephone call.

If the test in step 306 is false, then in step 310 the customer is asked for a home phone number. Such a step may be performed by initiating such a request from an interactive voice response unit, such as unit 112 (FIG. 1). Step 310 specifies a side-effect action because it impacts the caller by asking him/her to input some information. Upon receipt of the home phone number, the ACCOUNT_NUMBER and CUST_REC attributes are retrieved in step 312 in a manner similar to that in step 304. If one customer is identified then the test in step 314 will be true and in step 316, the ACCOUNT_NUMBER, CUST_REC, and HOME_PHONE attributes are assigned values. If one customer is not identified, then the test in step 314 will be false and in step 318 the HOME-PHONE attribute is assigned, and the ACCOUNT_NUMBER and CUST-REC attributes are disabled.

The DL specification further defining the Info_About_Customer module 220 (FIG. 2) is shown graphically in FIG. 5 and textually in FIG. 6. This Info_About_Customer module 220 is a declarative module and is therefore further defined in terms of sub-modules. The Get_Recent_Contacts_For_This_Customer module 504, the Get_Recent_Purchases_For_This_Customer module 508, the Get_Account_History_For_This_Customer module 512, and the Calculate_Cust_Value module 528 will always be evaluated because their respective enabling conditions 502, 506, 510, 526 are always true. It is noted that the graphical representation of these modules indicate that they are foreign modules. Each of these modules performs an external database retrieval function. If the attribute RECENT_CONTACTS has a state of VALUE, then the enabling condition 514 will be True and the Calculate_Frustration_Score module 516 will be evaluated. If the attribute RECENT_CONTACTS has state EXCEPTION, DISABLED, or FAILED, then the enabling condition 514 will be False and the Calculate_Frustration_Score module 516 will not be evaluated. If the attribute RECENT_CONTACTS is in state UNINITIALIZED, then enabling condition 514 cannot yet be evaluated. Enabling conditions 518, 522 and 530 are evaluated in a similar manner. The modules 516, 520, 524, 528, and 532 are all represented as solid line hexagons, which indicates that these modules are decision modules and the processing of these modules is specified in terms of computation rules and a combining policy, as will be described in further detail below.

The corresponding textual DL specification of the Info_About_Customer module 220 is shown in FIG. 6. It is noted that the type of the module as specified in line 16 is declarative, indicating that the module is a high level abstraction of processing details which are specified using sub-modules with enabling conditions.

Returning now to FIG. 2, the Info_From_Web module 230 will now be described in further detail. Module 230 is represented as a rectangle, which indicates that this is a foreign module which obtains values for attributes by executing external functions. The enabling condition 231 of module 230 indicates that the module will only be evaluated if the attribute WEB_DB_LOAD has a value which is less than 95% or if the attribute ACCOUNT_NUMBER has a state other than VALUE or UNINITIALIZED. The textual DL description of the Info_From_Web module 230 is shown in FIG. 7. The computation specified in line 13 indicates that data from an external web server will be obtained using the attributes ANI, HOME_PHONE, and ACCOUNT_NUMBER. The information returned will be assigned to the attribute WEB_DESTINATIONS, which will contain information regarding a customer's prior interactions with an associated Internet web site.

The Promo_Selection module 240 will now be described in further detail. Like module 230, module 240 is represented as a rectangle, which indicates that this is a foreign module which obtains values for attributes by executing external functions. The enabling condition 241 of module 240 indicates that the module will only be evaluated if the attribute CUST_REC.HATES_PROMOS has a value False. The textual DL description of the Promo_Selection module 240 is shown in FIG. 8. The computation specified in lines 15-18 indicates that data from an external source (e.g. a database, expert system, another workflow system) will be obtained using the input attributes. The information returned will be assigned to the attribute PROMO_HIT-LIST, which will contain a list of promotions which would be appropriate to present to a customer during a call.

The DL specification further defining the Routing_Decisions module 250 (FIG. 2) is shown graphically in FIG. 9 and textually in FIG. 10. This Routing_Decisions module 250 is a declarative module and is therefore further defined in terms of sub-modules. The Ask_Reason_For_Call module 910 will be evaluated if the CUST_VALUE attribute has a value less than 7, as indicated by enabling condition 912. Module 910 is represented as a rectangle, which indicates that the module is a foreign module. This module 910 performs an IVR interaction asking the caller the reason for calling, and the reason is assigned to attribute IVR_CHOICE. Modules 920, 940, and 950 will all be evaluated because their associated enabling conditions 922, 942, and 952, are all True. Module 960 will not be evaluated if the attribute BUSINESS_VALUE is greater than 100 or if the attribute FRUSTRATION_SCORE is greater than 5. This enabling condition 962 illustrates that enabling conditions can also specify when a particular module is disabled, rather than specifying when it is enabled. Module 930 will be evaluated if the test in its enabling condition 932 is True. The modules 920, 940, 950, and 960 are represented as hexagons, which indicates that these modules are decision modules and that their attributes are evaluated using computation rules and a combining policy. These modules will be described in further detail below. Module 930 is represented as a rectangle which indicates that this is a foreign module.

The corresponding textual DL specification of the Routing_Decisions module 250 is shown in FIG. 10. The type of the module (line 20) is declarative, and is therefore further defined in terms of sub-modules. Thus, the module is a high level abstraction of processing details which are specified using sub-modules with enabling conditions. It is noted that line 21 of the textual DL specification indicates that the module has a side-effect. This side effect is a result of the Calculate_Send_Bonus_Check module 930 and will be described below in conjunction with that module.

Referring back to FIG. 2, the final module in the Routing_To_Skill module 202 is the Calculate_Wrap_Up module 260. Calculate_Wrap_Up module 260 is graphically represented in FIG. 2 as a hexagon, which indicates that the module is a decision module and that the processing of the module is specified in terms of computation rules and a combining policy. The use of computation rules and a combining policy to evaluate attributes will now be described in detail.

In general, the format of computation rules and a combining policy within a DL specification is as follows:

Computation rules:

If condition-1 then Attribute.rarw.term-1

If condition-2 then Attribute.rarw.term-2 . . .

If condition-n then Attribute.rarw.term-n

Combining Policy:

Program in Combining Policy Language (CPL) or CPL function.

In the above format, the specification of:

If condition then Attribute.rarw.term

indicates that the term contributes to Attribute if the condition has a True value. Thus, each of the computation rules is evaluated to determine whether the condition is True or False. If the condition is True, then the term contributes to the attribute. If the condition is False, then the term does not contribute to the attribute. After each of the computation rules has been evaluated, the attribute is assigned a value based on the combining policy language (CPL) program, or the CPL function (where the CPL function is specified by a CPL program). Thus, the computation rules only contribute their terms to attributes, which is different from assigning a value to the attribute. The attribute is only assigned a value based on the combining policy (e.g. CPL program or CPL function). For example, a CPL function may indicate that the highest <value of the contributed terms is to be assigned to the attribute or that the sum of all the contributed terms is to be assigned to the attribute.

It is noted that the use of computation rules and a combining policy has been described in the context of the object-focused workflow system. As such, computation rules and combining policies are used to assign values to attributes. It is to be understood, however, that the use of computation rules and combining policies is not limited to use in an object-focused system. More generally, computation rules and combining policies may be used to evaluate any type of data item, whether that data item is an attribute in an object-focused system, a variable in a procedural system, or some other type of data item.

CPL provides a flexible and powerful mechanism that allows designers to specify how computation rules are to be combined in order to assign a final value to an attribute. CPL will first be specified formally using mathematical notation such that one skilled in the art of computer science could implement the language. Following the formal description, examples of how the language would be used to build useful combining functions will be described in conjunction with the ongoing example.

First, the values and types of the CPL language will be described. Then, the operators that form an algebra for the language will be defined.

CPL applies on homogeneous collections of data and is based on a type system that defines the following value types. Each CPL type admits .perp. (standing for "undefined") as a specific occurrence. The type definitions are as follows.

atom (e.g. bool, int, float, string)

<1: T.sub.1, . . . , an: T.sub.n >is a tuple type, if each T.sub.i is a value type.

[T] is a homogeneous list type, if T is a value type.

{T} is a homogeneous bag type, if T is a value type.

AM: T.sub.1 x . . . x T.sub.n.fwdarw.T is an atomic mapping type if T.sub.1, . . . , T.sub.n and T are atom types. This type allows the definition of arbitrary mappings over atoms.

Values in CPL are defined as follows:

.perp. is a CPL value called undefined. .perp. can be of any type. In others terms, .perp. belongs to all the domains of all the CPL types.

Any atom's value is a CPL value.

Any finite tuple (1:.nu..sub.1, . . . , a.sub.n :.nu..sub.n) of CPL values is a CPL value if 1, . . . , a.sub.n are names for the fields in the tuple and .nu..sub.1, . . . , .nu..sub.n are CPL values.

Any bag and any list of CPL values of a given type is a CPL value. {1, . . . , a.sub.n } is used to represent the bag value that contains the values 1, . . . , a.sub.n. [1, . . . a.sub.n ] is used as a shorthand to represent the list value that contains the values 1, . . . a.sub.n, and whose first element is 1, second element is a.sub.2 and n.sup.th element is a.sub.n.

Any arbitrary function defined over atoms is a CPL value. A function f of type AM: T.sub.1 x . . . xT.sub.n.fwdarw.T has for input types the atom types T.sub.1 . . . T.sub.n and for return type the atom type T.

In CPL, variables are assigned types using type inference, as commonly found in functional programming languages such as ML. The inference rules used in CPL are detailed below.

A CPL program is a sequence of declarations of variables and/or functions: ##EQU2##

where id.sub.1, id.sub.2, . . . are variable or function identifiers. A variable declaration has the form:

x: :=e

where e is an expression of CPL. A variable declaration is well formed if the free variables used in e are previously defined in another variable declaration statement (no recursive variable declaration is allowed). A function declaration has the form: ##EQU3##

where e is an expression of CPL. A function declaration is well formed if

.A-inverted.i.epsilon.1 . . . n, x.sub.i is a variable, and

the free variables used in e either are previously defined in a variable declaration statement or belong to {x.sub.1,x.sub.2, . . . ,x.sub.n }. (Recursively defined functions are not allowed).

The syntax of expressions depends on their types. Built-in operations (=, .ltoreq., .gtoreq.) that are associated with the built-in atom types are allowed. Also allowed are some Boolean expressions such as e.sub.1 and e.sub.2, e.sub.1 or e.sub.2, {character pullout}e.sub.1 and a conditional if e then e.sub.1 else e.sub.2 where e is a Boolean expression and e.sub.1,e.sub.2 have the same type. Expressions can also be constructed using the operators defined below. FIG. 27 presents the typing rules for these operators. Names starting with .nu. in FIG. 27 represent variable names, names starting with e represent terms in the CPL calculus, and names starting with t represent types. The notation .sigma..perp-right.e: t indicates that the term e is assigned the type t under the substitution .sigma.. If a type equation is a fraction, the numerator is the premise while the denominator is the consequence.

The interpretation of the operators of CPL is now described. I*(e) represents the interpretation of an expression e. If e is a variable name or a function name, I*(e)=I(e) where the interpretation I associates variables to values and function names to functions of the appropriate type. (If e is a constant, I(e)=(e)).

The value operator performs as follows:

I*(value (e))=if I*(e)=.perp. then False else, True

The AMapply operator performs as follows:

I*(AMapply (f,e.sub.1, . . . , e.sub.n))=I(f)(I*(e.sub.1), . . . , I*(e.sub.n))

Where f is any atomic mapping that applies on n atom values and returns an atom value.

Constructor operators are now described. A constructor operator is an operator which builds a composite object (e.g. tuple, list, bag) from other objects.

The operator tupling is defined as follows: ##EQU4##

The operator bagging is defined as follows: ##EQU5##

The operator listing is defined as follows: ##EQU6##

As a shorthand, we use <1:=e.sub.1, . . . , a.sub.n :=e.sub.n >, {e.sub.1 . . . , e.sub.n } and [e.sub.1, . . . , e.sub.n ] to respectively note tupling (1:=e.sub.1, . . . , a.sub.n :=e.sub.n), bagging(e.sub.1, . . . , e.sub.n), and listing(e.sub.1, . . . , e.sub.n).

Deconstructor operators are now described. A deconstructor operator is an operator which extracts a component object from a composite object.

The unitval operator is defined as follows: ##EQU7##

The operator Proj.sub.ai is a parameterized operator. A parameterized operator is an operator which is defined using a template with parameters. Specific operators are formed from a parameterized operator by specifying a value for these parameters. The Proj.sub.ai operator is defined as follows:

I*(proj.sub.ai (<a.sub.i :e.sub.i . . . , a.sub.n :e.sub.n >))=I*(e.sub.i)

I*(proj.sub.ia (.perp.))=.perp.

where i.epsilon.{1. . . n}.

The getelt, operator returns the i.sup.th element of a list. It is defined over lists as follows: ##EQU8##

where i is a positive integer.

The factor operator is a binary operator that is defined over lists and bags as follows: ##EQU9##

The map operator is an operator that is defined over lists and bags follows: ##EQU10##

Where f is any CPL function with only one input parameter.

The collect operator is recursively defined over lists and bags as follows: ##EQU11##

where .theta. is a collector. A collector is a complete binary operator with identity id.sub..theta.. A collector can be any function T.times.T.fwdarw.T where T is any CPL type except an atomic mapping type. The table below gives the predefined collectors that are used in the CPL.

                  .theta.                  Type
                  .orgate. (Union)         {T}
                  @ (concat)               [T]
                  or                       Boolean
                  and                      Boolean
                  +                        integer
                  -                        integer
                  *                        integer
                  sup                      atom

        aggval : := X -> tupling ( hash:= x.hash; val :=
            sum_true(x,vals,0))
        complist : :=
            [" collections" ," australia_promo" ," high_tier" ,
            " low_tier_intl" ," low_tier_down" ]
        ccomplist : := enum (complist)
        compsel : := X -> x.f_a.val = x.s_a
        poslist : := X -> (select(compsel) (factor(ccomplist,x) )#0.t_a.pos
        compval : := X,y -> if (x,val > y.val) then x
                    else if y.val > x.val then y
                    elseif poslist(x) < poslist(y) then x else y
        Skill_cp : := cont_vals -> collect(NULL, compval) (map (aggval)
            (group (cont_vals) ) )