 |
Claims  |
|
|
We claim:
1. A system for performing scalable distribution of process flow activities
in a distributed workflow management system, comprising:
a computer network comprising a plurality of interconnected computers, each
computer including a processor, memory and input/output facilities, the
distributed workflow management system operating over the computer
network;
a plurality of resources which are each operatively coupled to at least one
of the computers and execute at least one of the activities in the process
flow;
a process flow engine, including a database in which is stored data used in
effecting each of the process flow activities, the process flow engine
coordinating and scheduling execution of the process flow activities on
the resources; and
bidirectional proxy components operatively interposed between the process
flow engine and the resources, the bidirectional proxy components
comprising logic for handling application data for the resources, logic
for handling worklists for access by the resources and logic for managing
transport of messages between the process flow engine and each of the
resources.
2. A system according to claim 1, wherein the database of the process flow
engine categorizes the data into process-specific data used in effecting
the process flow, application-specific data used in effecting the process
flow activities and process-relevant data used in effecting the process
flow and the process flow activities.
3. A system according to claim 1, further comprising a generic database
associated with the distributed workflow management system and whereby the
logic for handling application data comprises a plurality of application
data handler, each application data handler being associated with one of
the resources, each application data handler comprising:
means for accessing data stored in the generic database;
means for augmenting the accessed data with data specific to the activity
prior to the execution of the at least one process flow activity on the
associated resource; and
means for storing back changes in the data to the generic database.
4. A system according to claim 3, wherein the generic database comprises
the database of the process flow engine, the means for accessing data
further comprising means for accessing the data stored in the database of
the process flow engine and the means for storing back changes further
comprising means for storing back changes in the data to the database of
the process flow engine.
5. A system according to claim 3, wherein the generic database comprises a
further database substantially distinct from the database of the process
flow engine, the means for accessing data further comprising means for
accessing data stored in the further database and the means for storing
back changes further comprising means for storing back changes in the data
to the further database.
6. A system according to claim 3, the application data handler further
comprising means for providing transactional semantics to a plurality of
the process flow activities, the transactional semantics including means
for obtaining data from the database of the process flow engine for each
resource.
7. A system according to claim 1, whereby the logic for handling worklists
for access by the resources comprises a plurality of worklist handlers,
each worklist handler being associated with one of the resources, each
worklist handler comprising:
a queue of work to be performed by the resources in effecting the process
flow activities, the process flow engine further comprising means for
dispatching work requests to each work queue of the worklist handlers;
an interface enabling each resource to interactively access the work queue
of the associated worklist handler; and
means for selecting the work to be performed by the resource to effect one
such process flow activity.
8. A system according to claim 1, whereby the logic for managing transport
of messages between the process flow engine and each of the resources
comprises a plurality of transport managers, each transport manager being
associated with one of the resources, each transport manager comprising:
a first message interface between the process flow engine and the transport
manager;
a second message interface between the transport manager and each
associated resource; and
means for exchanging the messages between the flow process engine and each
associated resource via the first and second message interfaces.
9. A method for performing scalable distribution of process flow activities
in a distributed workflow management system, the distributed workflow
management system operating over a computer network comprising a plurality
of interconnected computers and a plurality of resources, each computer
including a processor, memory and input/output facilities, each resource
operatively coupled to at least one of the computers and executing at
least one of the activities in the process flow, the method comprising the
steps of:
coordinating and scheduling the execution of the process flow activities on
the resources using a process flow engine, including storing data used in
effecting each of the process flow activities in a database of the process
flow engine;
providing application data accessed from the database of the process flow
engine to the resources using a application data handler interposed
between the resources and process flow engine;
managing worklists for access by the resources using a worklist handler
interposed between the resources and process flow engine; and
transporting messages between the process flow engine and each of the
resources using a transport manager interposed between the resources and
process flow engine.
10. A method according to claim 9, further comprising the steps of:
providing process-specific data used in effecting the process flow into the
database of the process flow engine;
providing application-specific data used in effecting the process flow
activities into the database of the process flow engine; and
providing process-relevant data used in effecting the process flow and the
process flow activities into the database of the process flow engine, the
step of handling application data using the application data handler
further comprising augmenting the process-relevant data augmented with the
application-specific data.
11. A method according to claim 9, wherein the distributed workflow
management system further comprises a generic database and the step of
providing application data further comprises the steps of:
accessing data stored in the generic database;
augmenting the accessed data with data specific to at least one such
activity to be performed by one of the associated resources prior to the
execution of the at least one process flow activity on the associated
resource; and
storing back changes in the data to the generic database upon completion of
the execution.
12. A system according to claim 11, wherein the generic database comprises
the database of the process flow engine, the step of accessing data
further comprising accessing the data stored in the database of the
process flow engine and the step of storing back changes further
comprising storing back changes in the data to the database of the process
flow engine.
13. A system according to claim 11, wherein the generic database comprises
a further database substantially distinct from the database of the process
flow engine, the step of accessing data further comprising accessing data
stored in the further database and the step of storing back changes
further comprising storing back changes in the data to the further
database.
14. A method according to claim 11, further comprising the step of
providing transactional semantics to a plurality of the process flow
activities, the transactional semantics including means for obtaining data
from the database of the process flow engine for each resource.
15. A method according to claim 9, wherein the step of managing worklists
further comprises the steps of:
maintaining a queue of work to be performed by the resources in effecting
the process flow activities, the step of coordinating and scheduling
further comprising dispatching work requests to each work queue of the
worklist handlers using the process flow engine;
accessing the work queue of the associated worklist handler interactively
from each resource an interface on each worklist handler; and
selecting the work to be performed by the resource to effect one such
process flow activity.
16. A method according to claim 9, wherein the step of transporting
messages further comprises the steps of:
providing a first message interface between the process flow engine and the
transport manager;
providing a second message interface between the transport manager and each
associated resource; and
exchanging the messages between the flow process engine and each associated
resource via the first and second message interfaces.
17. A method for managing process flow activities in a distributed
processing environment, each of the process flow activities comprising
units of work performed by a resource operating within the distributed
processing environment, the method comprising the steps of:
coordinating the process flow activities using a process management engine
operating on a computer system within the distributed processing
enviromnment, the process management system identifying the work units to
be performed;
augmenting data maintained by the process management engine with further
data specific to each such process flow activity using an application data
handler functionally interposed between the process management engine and
each such resource within the distributed processing enviromnment;
maintaining a list of the work units using a worklist handler functionally
interposed between the process management engine and each such resource
within the distributed processing environment, the process management
engine providing the work units list to the worklist handler and each such
resource interactively selecting such work units from the work units list;
and
exchanging messages containing descriptions of the work units using a
transport manager functionally interposed between the process management
engine and each such resource within the distributed processing
environment, each such resource interpreting the descriptions for the
selected work units.
18. A method according to claim 17, wherein the step of augmenting data
further comprises the steps of:
processing an outbound message received from the process management engine
for dispatch to one of the resources; and
processing an inbound message received from one of the resources for
dispatch to the process management engine.
19. A method according to claim 18, wherein the step of processing an
outbound message further comprises the steps of:
receiving the outbound message with a value list from the process
management engine for dispatch to one of the resources, the value list
comprising a destination address list, a source address list and program
commands;
identifying the program commands in the value list;
executing the program commands against a data repository associated with
one of the resources in the destination address list;
augmenting the source address list with a return processing address if
return trip processing of the outbound message is required;
omitting or adding an alternate processing address if return trip
processing is not required;
removing a first element from the destination address list to thereby form
a new first element in the destination address list; and
forwarding the message to one of the resources as determined by the new
first element in the destination address list.
20. A method according to claim 18, wherein the step of processing an
inbound message further comprises the steps of:
receiving the inbound message with a value list from the process management
engine for dispatch to one of the resources, the value list comprising a
destination address list, a source address list and program commands;
identifying the program commands in the value list;
executing the program commands against a data repository associated with
one of the resources in the destination address list;
applying required updates against the data repository associated with one
of the resources in the destination address list;
removing a first element from the destination address list to thereby form
a new first element in the destination address list; and
forwarding the message to one of the resources as determined by the new
first element in the destination address list.
21. A method according to claim 18, wherein the step of processing an
inbound message further comprises the steps of:
receiving the inbound message with a value list from the process management
engine for dispatch to one of the resources, the value list comprising a
destination address list, a source address list and program commands;
removing a first element from the destination address list to thereby form
a new first element in the destination address list; and
forwarding the message to one of the resources as determined by the new
first element in the destination address list.
22. A method according to claim 17, wherein the step of maintaining a list
of work units further comprises the steps of:
processing an outbound message received from the process management engine
for dispatch to one of the resources; and
checking a claim from one of the resources against the outbound message.
23. A method according to claim 19, wherein the step of processing an
outbound message further comprises the steps of:
receiving the outbound message with a value list from the process
management engine for dispatch to one of the resources, the value list
comprising a destination address list, a source address list and program
commands;
parsing the value list for a destination claim;
validating the destination claim for the worklist handler against the work
units identified by the process management engine; and
storing the outbound message in the worklist handler using the claim as an
index to the stored outbound message.
24. A method according to claim 19, wherein the step of checking a claim
further comprises the steps of:
receiving a client message with a claim list from a client corresponding to
one of the resources;
validating the claim list with a security service associated with the
worklist handler against outbound messages stored in the worklist handler;
identifying available messages in the worklist handler matching the client
claims, each of the matching available messages having an index
corresponding to one of the client claims; and
supplying the client resource with a list of validly claimable messages.
25. A method according to claim 17, wherein the step of exchanging messages
further comprises the step of processing a message, the message comprising
either an outbound message or an inbound message.
26. A method according to claim 23, wherein the step of exchanging messages
further comprises the steps of:
receiving the message with a value list from the process management engine
for dispatch to one of the resources, the value list comprising a
destination address list, a source address list and program commands;
augmenting the source address list associated with the message with a
return processing address;
removing a first element from the destination address list to thereby form
a new first element in the destination address list; and
forwarding the message to one of the resources as determined by the new
first element in the destination address list. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
This invention relates to the field of workflow process management and more
particularly to a system and method for performing scalable distribution
of process flow activities in a distributed workflow management system.
Workflow process re-engineering, that is, the fundamental rethinking and
re-implementation of workflow processes to achieve never-before-possible
levels of quality, cost, throughput and service, is emerging as one of the
crucial business strategies of the 1990s. The need for re-engineering is
especially significant in an era of workforce downsizing coupled with
greater demands for shortened time to market and faster customer response.
Moreover, the need is pervasive. Organizations are currently engaging in
workflow process re-engineering in many domains, including financial
services, telecommunications services, healthcare services, customer order
fulfillment, manufacturing procedure automation and electronic commerce.
While workflow process re-engineering provides a business management
concept, workflow process management (WFPM) software--or more accurately,
middleware--provides the enabling technologies for actually performing
workflow process re-engineering. WFPM supports flexible solutions for the
management of enterprise-wide operations, including workflow process
control, automation and monitoring; resource allocation, authorization and
authentication; task initialization and data exchange; and end-to-end
communication and security. However, while WFPM offers an overall
environment and approach to unifying, automating and measuring workflow
processes, it is not limited to supporting workflow process re-engineering
and can be used to manage existing nonautomated legacy or work processes.
In general, WFPM systems perform a wide range of tasks. For instance, they
can provide a method for defining and managing the flow of a work process
or support the definition of resources and their attributes. In addition,
they can assign resources to work, determine which steps will be executed
next within a work process and when they will be executed and can ensure
that the workflow process continues until proper termination. Moreover,
they can notify resources about pending work, enforce administrative
policies, such as access control and track execution and support user
inquiries of status. Finally, they can provide history information in the
form of an audit trail for completed workflow processes and collect
statistical data for process and resource bottleneck analysis, flow
optimization and automatic workload balancing.
Moreover, given the trend towards open systems and standards, a WFPM system
must coexist with and take advantage of standards-based commercial
products for network communication, legacy application invocation and
system monitoring. In particular, these standards include the Object
Management Group's Common Object Request Broker Architecture (CORBA), the
Open Software Foundation's Distributed Computing Environment (OSF DCE),
Hewlett Packard's OpenView and the International Standards Organization
Open Systems Interconnection (ISO OSI) X.400 technologies.
In general, WFPM systems, or simply, process flow systems, effect workflow
processes on a small- to large-scale basis by controlling the scheduling
of and parameters used by activities, acquiring the results of the
activities and using those results to determine other activities to run.
Each individual business process describes the sequencing, timing,
dependency, data, physical agent allocation, business rule and
organization policy enforcement requirements for performing work.
Prior art process flow systems have been disclosed. However, those
disclosed prior art process flow systems cannot be readily applied to
large-scale applications for two reasons.
First, application-specific data, further described below in the Detailed
Description, is improperly treated as process-relevant data. End
activities are required to perform all data accesses directly upon the
database storing the application-specific data. However, when the
application-specific data is copied into the process-relevant data, the
data may be independently modified by the process flow system. Such
updates often damage the intended transactional semantics of the
application database. Moreover, the amount of information that the process
flow engine must log, process and dispatch increases.
Second, users must review and select from lists of available work by
communicating directly with the process flow system. This direct interface
adds work to the system that could be done by separate processes on
independent resources and limits the system's size. Also, since the
process flow system must deal directly with client worklist requests,
potential performance is lost in dealing with user requests to see what
work is available. Moreover, such user requests are often non-randomly
distributed and the system must have sufficient computing capacity
available to deal with these bursty requests.
Therefore, there is a need for a system and method for providing high
degree of scalability to process flow systems. Preferably, such a system
and method would provide an enterprise-wide process flow solution.
There is a further need for a system and method for managing a process flow
system providing a bidirectional proxies for processing user work
requests, handling application-specific data and effecting transport
interfacing.
SUMMARY OF THE INVENTION
The present invention provides a system and method for performing scalable
distribution of process flow activities in a distributed process flow
management system.
An embodiment of the present invention is a system and method for
performing scalable distribution of process flow activities in a
distributed workflow management system. The distributed workflow
management system operates over the computer network which includes a
plurality of interconnected computers. Each computer includes a processor,
memory and input/output facilities. A plurality of resources are each
operatively coupled to at least one of the computers and execute at least
one of the activities in the process flow. A process flow engine,
including a database in which is stored data used in effecting each of the
process flow activities, coordinates and schedules execution of the
process flow activities on the resources. Bidirectional proxy components
are operatively interposed between the process flow engine and the
resources. The bidirectional proxy components include logic for handling
application data for the resources, logic for handling worklists for
access by the resources and logic for managing transport of messages
between the process flow engine and each of the resources.
The foregoing and other objects, features and advantages of the invention
will become more readily apparent from the following detailed description
of a preferred embodiment of the invention which proceeds with reference
to the accompanying drawings.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a process flow management system implemented
in a network of computers coupled to a plurality of users and machines for
management and control of workflow process activities performed by the
users and machines.
FIG. 2 is a block diagram of a hardware and software machine for a typical
node in the network of FIG. 1 showing the architecture of an example of
process flow management middleware employing the present invention.
FIG. 3 is a computer display of the user interface for the user of the
machine of FIG. 2 to interact with the process flow management system, the
display showing an example of a process flow diagram for a business
process flow managed by the system.
FIG. 4 is a block diagram of the preferred form of workflow process
software engine that coordinates execution flow of the managed process.
FIG. 5 is a block diagram of the system architecture with optional worklist
handler and application data handler features to enhance scalability.
FIG. 6 is a diagram showing management function layers provided by business
process flow management using the system of FIGS. 1-5 for the example of
management of a telecommunications network.
FIG. 7 is a process definition diagram for configuration management of the
telecommunications network in the example of FIG. 6.
FIG. 8 is a block diagram of the system architecture of FIG. 5, including
bidirectional proxy components according to the present invention.
FIG. 9 is a flow diagram of a procedure for processing an outbound message
using the application data handler of FIG. 8.
FIG. 10 is a flow diagram of a procedure for processing an inbound message
using the application data handler of FIG. 8.
FIG. 11 is a flow diagram of an alternate procedure for processing an
outbound message using the application data handler of FIG. 8.
FIG. 12 is a flow diagram of a procedure for processing an outbound message
using the worklist handler of FIG. 8.
FIG. 13 is a flow diagram of procedure for processing a claim check using
the worklist handler of FIG. 8.
FIG. 14 is an example showing the high communications costs in a prior art
process flow system.
FIG. 15 is an example showing the scalable communications costs in process
flow system of FIG. 8.
FIG. 16 is a flow diagram of procedure for processing an inbound or
outbound message using the transport manager of FIG. 8.
DETAILED DESCRIPTION
Workflow Process Management System
FIG. 1 shows a block diagram of a workflow process management (WFPM) system
10 implemented in a network 11 of computer systems 12a-d coupled to a
plurality of users 14a-b and machines 15a-b for management and control of
workflow process activities. Each computer system 12a-d is shown coupled
with a single user 14a-b or machine 15a-b, but multiple users or machines
or combinations thereof can also be employed. The WFPM system 10 is shown
from an enterprise perspective with the control and coordination of each
of the computer systems 12a-d being accomplished by computer software,
preferably object-oriented software, executed as a distributed application
by the computer systems 12a-d. Optionally, workflow process activity
information, such as resource data and rules, can be stored in a database
on a centralized WFPM server 17 which is accessible by the computer
systems 12a-d over the network 11 or can be stored in a plurality of
databases on each of the computer systems 12a-d. The computer systems
12a-d and centralized WFPM server 17 conventionally include a processor,
memory and input/output interface including network communications
facilities and user input and output devices.
Each workflow process 18 includes a sequence of activities, each of which
is ordinarily performed by one of the computer systems 12a-d in
conjunction with an associated user 14a-b or machine 15a-b, although some
activities can be performed by microprocessor-controlled devices 16 (one
such device shown in FIG. 1, although multiple devices can be used), such
as a telephone or facsimile machine, printing device or similar
self-controlling mechanism. In addition, each machine 15a-b can be a work
instrument or computer resource.
The workflow process 18 can span several business organizations (only one
organization is shown in FIG. 1) with multiple activities potentially
performed in parallel. In such cases, the WFPM system 10 acts as the
"superstructure" that ties together disparate computer systems 12a-d whose
business purposes are interconnected. The WFPM system 10 provides
procedural automation 13 of the workflow process 18 by managing the
sequence of process activities and the invocation of appropriate user
14a-b, machine 15a-b or microprocessor-controlled device 16 resources
associated with the various activity steps.
Workflow Process Specification
The procedural automation 13 of the workflow process 18 involves the
high-level specification of individual workflows (examples shown in FIG. 3
and FIG. 7) which provides the operational "glue" and environment support
needed by the WFPM system 10 for managing and automating the workflow
processes 18, recovering from failures and enforcing consistency. As
further described hereinbelow, the WFPM system 10 also enforces various
administrative policies associated with resources and work.
The specific structure and flow of each workflow process 18 managed by the
WFPM system 10 can be preplanned or developed in an ad hoc fashion. For
example, in a WFPM system 10 used for managing the workflow process 18 of
providing telecommunications services, some aspects of the workflow
process 18 are determined ad hoc and depend in part on the services
required by each individual customer. However, other aspects of the
workflow process 18 can be preplanned and deliberately structured. For
instance, independent from the individual services required by a single
customer, the workflow process 18 always originates in the sales
department and typically ends in the billing department. The parts of the
workflow process 18 involving these departments can be preplanned.
HP OpenPM
FIG. 2 is a block diagram of a hardware and software machine for a typical
node 12a in the network 11 of FIG. 1 showing, by way of example, an
architecture for WPFM middleware employing the present invention. An
example of middleware suitable for implementing the present invention is
the Hewlett Packard (HP) OpenPM system. HP OpenPM is an open,
enterprise-capable, object-oriented WFPM system developed at Hewlett
Packard Laboratories, Palo Alto, Calif. for managing process activities
that support complex enterprise processes in a distributed, heterogeneous
computing environment. The use of a WFPM system 10 implemented in
middleware represents a substantial evolution over traditional workflow
technologies. HP OpenPM provides a generic framework and complete set of
services for workflow process management using a middleware-based approach
with an emphasis on performance, availability, scalability and system
robustness.
Briefly, HP OpenPM provides an open system adhering to the CORBA
communications infrastructure with a Workflow Management
Coalition-standard interface. Second, it offers high performance as a
result of optimized database access and commitment features. It also
provides effective management when coupled with an HP OpenView-based
system management environment. Finally, HP OpenPM presents a comprehensive
solution for business re-engineering, including an extensive set of
products.
The overall architecture of the HP OpenPM system is depicted in FIG. 2. The
core is the HP OpenPM engine 20, which supports five interfaces. The
interfaces enable the HP OpenPM engine 20 to interact with workflow
process designer 22A-C, workflow process instance execution 23a-b,
workflow process monitor 24A-C, workflow management 28A-C and business
object management modules 30, 31, 32, 33. In addition, worldwide web
client support is provided by each individual network node 12a which can
execute middleware modules expressed in platform-independent languages,
such as Java Applets and HTML code. An HP OpenPM database 21 is maintained
on the centralized WFPM server 17 (shown in FIG. 1) for use by the HP
OpenPM engine 20.
A workflow process 18 is specified by the process design modules 22A-C via
the workflow process definition interface. An instance of a workflow
process 18 can be started, controlled or stopped by the process instance
execution modules 23a-b via the process execution interface. Status
information of each process instance and load information for the WFPM
system 10 can be queried using the process status monitor modules 24A-C
via the process status monitoring interface. The workflow management
interface is used to allocate, at run time, execution resources to a task,
according to the policies defined by the organization (including
authorization and authentication) and the availability of the resources
using the workflow management modules 28A-C. Interaction with the external
world, such as invoking an application, controlling an instrument or
delivering a work order to a person's electronic mail in-box, is performed
by the various business object management modules 30, 31, 32, 33.
HP OpenPM Process Model
In general, a workflow process 18 is a description of the sequencing,
timing, dependency, data, physical agent allocation, business rule and
organization policy enforcement requirements of process activities needed
to enact work. FIG. 3 shows, by way of example, a workflow process 18
which is represented as a directed graph 40 consisting of a set of nodes
connected by arcs as displayed on the HP OpenPM user interface.
There are two kinds of nodes: work nodes 41, 43, 45, 46, 48, 50, 52, 54,
which are shown as squares, and rule nodes 42, 44, 47, 49, 51, 53, 55,
which are shown as circles. There are also two kinds of arcs, forward arcs
and reset arcs. A work node has at most one inward arc and one or more
outward arcs. A rule node can have any number of inward and outward arcs.
Forward arcs represent the normal execution flow of process activities and
form a directed acyclic graph 40. Successful completion of a node at the
source end of a forward arc triggers the starting of the node at the
destination end of the forward arc.
Reset arcs are used to support repetitions or explore alternatives in a
workflow process 18. Reset arcs differ from forward arcs in that they
reach backwards in the process graph.
Work nodes 41, 43, 45, 46, 48, 50, 52, 54 represent activities to be
performed external to the HP OpenPM engine 20. These activities include
authorization, resource allocation, execution of business objects 93A-C
and provision of input data for the business objects 93A-C and output data
from them. Rule nodes 42, 44, 47, 49, 51, 53, 55 represent processing
internal to the HP OpenPM engine 20. This processing includes decisions of
about which nodes should execute next, generation or reception of events,
and simple data manipulation.
A work node 41 is a placeholder for a process activity, which is a logical
representation of a piece of work contributing towards the accomplishment
of a process 18. A process activity is mapped to the invocation of an
operation on business objects 93A-C during the execution of the process
and each process activity can represent a manual operation by a human or a
computerizable task to execute legacy applications 30, 31, 32, 33 (shown
in FIG. 2), access application databases 34a, 34b (also shown in FIG. 2),
control instrumentation, sense events in the external world or effect
physical changes. A process activity definition includes a forward
activity and optionally, a compensation activity, a cancel activity, a
workflow management activity, timeout and deadline information and input
and output data.
Rule nodes 42, 44, 47, 49, 51, 53, 55 are used to specify workflow
processes 18 that are more complex than a simple sequence. A rule language
is used to program the rule node decision. When executed, a rule node 42
determines which outward arcs to fire based on the status passed along the
inward arcs, the time at which each i | | |
