 |
Claims  |
|
|
What is claimed is:
1. An automated method of managing distributed resources for a workflow
process of executing a coordinated set of process activities requiring
said distributed resources, said automated method comprising steps of:
forming a hierarchy of resource managers that are operatively associated to
provide multi-level control of said resources, at least one level of said
hierarchy having more than one resource manager; and
enabling communication among said resource managers in response to requests
for said resources, said communication that is responsive to a specific
request for said resources including:
(1) sending a Delegate message to a resource manager at a lower level of
said hierarchy if a resource manager that receives said request is
authoritative with regard to a lower level resource manager that can
invoke a requested resource, said Delegate message being specific to and
including said request;
(2) sending a Refer message to a resource manager at a same level if said
resource manager that receives said request is not authoritative and is
configured to include an identification of a same level resource manager
that is authoritative with regard to said request, said Refer message
being specific to and including said request; and
(3) sending a Plead message to a resource manager at a higher level if said
resource manager that receives said request is not authoritative and is
not configured to send said Refer message to said same level resource
manager, said Plead message being specific to and including said request.
2. The automated method of claim 1 wherein said communications further
include:
sending a Report message to said resource manager that receives said
request following a Plead message, said Report message including an
identification of a same level resource manager that is authoritative with
regard to said request.
3. The automated method of claim 2 further comprising a step of storing
resource data at each resource manager such that each said resource
manager includes at least a portion of an enterprise-wide view of
accessible resource capabilities, each said resource capability of which a
specific resource manager is configured to identify having stored resource
data indicative of:
(a) ability of said specific resource manager to satisfy a request for said
resource capability;
(b) a Delegate address of a lower level resource manager which can satisfy
a request for said resource capability;
(c) a Refer address of a same level resource manager which can satisfy a
request for said resource capability; and
(d) a Plead address of a higher level resource manager to which a Plead
message can be sent.
4. The automated method of claim 1 wherein said communications further
include:
sending a Do message if said resource manager that receives said request is
enabled to satisfy said request.
5. The automated method of claim 1 further comprising a step of storing
policy data at each said resource manager, said policy data being
indicative of selecting particular resources in response to said requests,
said policy data being specific to said resource manager at which said
policy data is stored.
6. A system for managing distributed resources for workflow processing
within an enterprise of interest comprising:
an upper level resource manager having stored data indicative of an
enterprise-wide representation of resource capabilities to perform process
activities for workflow processes of said enterprise;
a plurality of middle level resource managers that are subordinate to said
upper level resource manager with respect to invoking said resource
capabilities, said middle level resource managers having stored data
indicative of portions of said enterprise-wide representation, each said
middle level resource manager being related to a different portion of said
enterprise-wide representation; and
a plurality of base level resource managers that are subordinate to said
middle level resource managers with respect to invoking said resource
capabilities, said base level resource managers having stored data
indicative of specific resource instances for providing said resource
capabilities, said resource instances being divided and assigned to said
base level resource managers at least partially based on types of said
resource capabilities, said base level resource managers being assigned to
said middle level resource managers in an arrangement which defines said
different portions.
7. The system of claim 6 wherein said stored data of said middle level
resource managers in indicative of said types of resource capabilities and
is not indicative of said specific resource instances.
8. The system of claim 7 wherein said stored data of said middle level
resource managers is indicative of current availability of said types of
resource capabilities and wherein said stored data of said base level
resource managers is indicative of current availability of said resource
instances, said current availabilities being specific to present ability
to perform process activities.
9. The system of claim 8 wherein each middle level resource manager
includes data that identifies policies regarding invoking said base level
resource managers to invoke a resource instance of a particular type.
10. The system of claim 6 further comprising a plurality of intermediate
level resource managers that are subordinate to said upper level resource
manager and authoritative to said middle level resource managers, thereby
providing at least four distinct levels of resource managers, each said
intermediate level resource manager being authoritative to selected middle
level resource managers and having stored data indicative of an
integration of said portions related to said selected middle level
resource managers.
11. An automated method of managing distributed resources for a workflow
process of executing a coordinated set of process activities requiring
said distributed resources, said automated method comprising steps of:
assigning said resources into a plurality of groups;
forming a base level of resource managers having a plurality of local
resource managers (LRMs), including associating each said LRM with at
least one of said groups such that each said LRM is authoritative over at
least one but not all of said groups with respect to invoking said
resources within said groups, including storing data at each said LRM
relating to availability status and capability of each said resource in
said group over which said LRM has authority;
forming a middle level of resource managers having a plurality of site
global resource managers (SRMs), including associating each SRM with at
least one but not all of said LRMs such that said SRMs are authoritative
over said LRMs with respect to invoking said LRMs, including storing data
at each said SRM relating to availability and capability of each said
group associated with an LRM over which said SRM has authority; and
forming an upper level of resource managers having at least one enterprise
global resource manager (ERM), including associating each said ERM with
each said SRM such that said ERM is authoritative over said SRMs with
respect to invoking said SRMs, including storing data at each said ERM
relating to capabilities of said SRMs to invoke said LRMs.
12. The method of claim 11 further comprising a step of forming an
intermediate level of more than one first SRM that is subordinate to each
said ERM, including associating each first SRM with at least one but not
all of said SRMs of said middle level such that said first SRMs are
authoritative with respect to invoking said SRMs of said middle level.
13. The method of claim 12 wherein said steps of forming said middle,
intermediate and upper levels include providing each said ERM and SRM with
information regarding capabilities of SRMs and LRMs over which said ERM
and SRM are authoritative, each said ERM thereby having said information
relating to all said SRMs and LRMs.
14. The method of claim 13 wherein said steps of forming said middle,
intermediate and upper levels further include leaving said SRMs and ERMs
without information regarding said availability status of individual
resources in said groups, said information regarding said availability of
individual resources thereby being limited to storage at said base level.
15. The method of claim 11 wherein said steps of forming said resource
managers of said middle and upper levels include storing policies at each
SRM and ERM relevant to executing said process activities, wherein said
policies are specific to each said SRM and ERM.
16. The method of claim 15 wherein said step of storing said policies
further includes storing substitution policies at each said SRM, said
substitution policies of a specific SRM being indicative of selection of a
second group of said resources upon determination that a resource for
executing a particular process activity is not accessible to said specific
SRM at which a request is processed, said request being specific to
execution of said particular process activity.
17. The method of claim 11 further comprising a step of exchanging requests
for resources among said resource managers, said requests being exchanged
as messages, including exchanging (1) Delegate request messages to lower
level resource managers, (2) Refer request messages to same level resource
managers, and (3) Plead request messages to higher level resource
managers.
18. The method of claim 17 wherein said step of exchanging requests
includes enabling Report messages having information regarding which
groups of said resources are accessible via which SRMs, each said message
including an address of a resource manager to which said message is
directed. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
TECHNICAL FIELD
The invention relates generally to workflow process management and more
particularly to automating the coordination of process activities in order
to accomplish tasks of an enterprise.
BACKGROUND ART
Workflow process management is a technology that provides the ability to
define and automate the flow of work through an enterprise in order to
accomplish business tasks. The business tasks may be first modeled as
workflow processes, which are then automated by workflow management
systems (WFMSs). Commercially available WFMSs, such as the Hewlett-Packard
Changengine, are capable of supporting a large number of workflow
processes in an efficient, reliable and secure manner.
A "workflow process" is a coordinated set of process activities that are
connected in order to achieve a common business goal. Thus, a workflow
process is typically a sequence of process activities. A "process
activity" is a logical step or description of a piece of work that
contributes to the accomplishment of the workflow process. A process
activity can be executed manually or automatically. Each process activity
is related to a work item and a workflow participant. A "work item"
defines the work that is to be processed in the context of the related
process activity and is performed by one or more workflow participants. A
"workflow participant" is either a person that performs the work item for
a manual process activity or a computer-based application that performs a
work item for an automated process activity. "Resources" are defined as
workflow participants and the objects that they utilize in performing work
items.
A workflow participant can usually perform work items for more than one
process activity. In the reverse, work items can generally be performed by
more than one resident workflow participant. A workflow participant often
requires use of or access to other resources when performing a work item.
For example, a person that prints a document requires use of a printer.
Workflow participants together with the objects that are used by the
workflow participants are external resources for a WFMS.
One of the important features of modern WFMSs is the realization of dynamic
resource allocation, which provides resource independence to business
processes. Thus, a workflow process does not need to be modified when
underlying resources change. Moreover, resources are more efficiently
utilized. A modern WFMS includes a resource manager, which allows run time
resource allocation. The resource manager provides a resource model for
process designers to use for resource specification at process definition
time. The model is an abstraction of the physical resources and shields
the process designers from the detailed specification of the required
resources. The resource manager also manages workflow resources (e.g.,
keeps track of status of resources) and assigns workflow resources to
business steps (i.e., process activities) when requested to do so by a
workflow execution engine.
One problem with resource management in WFMSs relates to efficiently
assigning resources to process activities at process execution times when
there are a number of workflow processes being executed simultaneously.
Workflow resource management is concerned with: (1) keeping track of
resource status (e.g., availability and load) and (2) finding eligible,
available, and hopefully least loaded resources for workflow activities
when needed. The resource management problem is not trivial in many
workflow environments, since workflow resources are distributed, the
number of work-flow resources are large, and resource status changes
frequently.
Traditional approaches to workflow resource management have been to either
manage distributed resources globally at a central site or to manage the
distributed resources locally. Under the global management approach, the
distributed resources are under control of a global resource manager
(GRM). The resources are registered to the GRM, with an identification of
the roles that the individual resources can assume. The GRM is responsible
for keeping track of the status of each of the registered resources. The
main advantage of the global management approach is that resource
assignment is relatively easy and efficient, since all resource
information is contained at a single site. However, this approach incurs
huge overhead in keeping track of status of remote resources. The approach
is impractical in many real workflow environments for a number of reasons.
First, the number of remote resources can be large. For example, in the
workflow process of providing employee expense reimbursement, a large
corporation may have more than 10,000 employees as workflow resources. It
is extremely difficult for the GRM to keep track of load information about
remote resources, since the information changes frequently. Second,
resources of a large enterprise usually belong to different organizations.
Workflow resources at different organizations and locations are often
managed by different systems independently. These external resource
systems can be heterogeneous with respect to resource models, query
language and communication protocol. Third, process designers need
different views of workflow resources at different levels. Most business
processes only involve local resources. On the other hand, there are cases
in which an enterprise-wide view of all workflow resources is needed.
In the local management approach, resources are managed by multiple,
distributed local resource managers (LRMs). Each LRM has all status
information regarding resources and has full control over resources at its
site. The approach may include utilizing a GRM at a central site to
maintain role information for all the resources and their managing LRM,
but resource management system relies on individual LRMs for resource
assignment when a work item is to be performed. The local resource
management approach avoids the huge overhead of keeping track of dynamic
changes of resources by managing them locally. However, this approach
makes run-time resource assignment difficult and sometimes inefficient.
A system that overcomes some of the problems of the two traditional
approaches is described in U.S. Pat. No. 5,826,239 to Du et al., which is
assigned to the assignee of the present invention. The system provides
distributed resource management in a computer network that includes
multiple computers operating under control of a WFMS which manages
available resources to carry out a workflow process. Resources are grouped
according to shared sets of capabilities. Each resource group includes at
least one resource. One or more computers in the network stores a GRM and
data to define the resource capability of at least some of the groups, and
further stores the resource status for each group for which it has the
data relating to resource capability. Preferably, each computer that does
not store a GRM stores an LRM for at least one of the groups and includes
data that defines the capability and the status for each resource in each
group to which it is assigned. Thus, instead of doing resource management
in one step, either at a central site (in the global management approach)
or at remote sites (in the local management approach), the approach of Du
et al. first checks the availability of resource groups at a central site
and then selects (at remote sites) specific resources from the group.
FIG. 1 is a schematic view of a simplified workflow process. A workflow
process is a description of sequencing, timing, dependency, data, physical
agent location, and business rule and authorization policy enforcement
requirements of business activities needed to enact work. An upper portion
10 of FIG. 1 represents the activities that are required to implement the
workflow process, while the lower portion 12 represents the resources for
executing the activities. The example is one in which a claim for payment
is processed. In a first step 14, the claim is submitted. The enterprise
that is represented in this example utilizes an employee 15 to receive the
claim, but automated resources may be used by different enterprises to
execute the step. In step 16, the claim is checked to determine whether it
meets business requirements. The claim is also checked to determine the
class 17 in which it is fit under procurement rules of the enterprise. The
employee 15 enters the information from the claim into a computer 18. The
computer may be one of a number of computers that are interconnected to
form a network. Each computer is managed and controlled by a user or by a
machine. The coordination of the computers within the network can be
accomplished by computer software, such as object-oriented software. The
determination of the class in activity 17 is part of the process
management rules 19 of the enterprise in the execution of the workflow
process. Workflow process activity information, such as resource data and
rules, can be stored in a database on a centralized WFMS server, not
shown, which is accessible by the computers 18 via a bus line.
Alternatively, each computer may store the resource data and the rules.
The determination of the class at process activity 17 may merely be a
determination of whether the submitted claim can be handled using petty
cash or requires an authorization of a manager, as shown at activities 20
and 21. This determination may be based merely upon the dollar amount
identified in the claim. If insufficient information is contained within
the claim, the claim is resubmitted, as indicated at activity 22. The
steps 17, 20, 21 and 22 are executed in computer software under control of
the process management rules 19. If the claim can be processed using petty
cash, the procedure ends at activity 23 by paying the persons who
submitted the claim. The resource for executing this activity may be an
employee 24 or may be an automated device. For claims that require manager
authorization, an activity 25 of recognizing the authorization is executed
in computer software 26. For example, electronic signatures may be
required in order to allow automated processing.
A claim which does not include the required authorization may be rejected
at activity 27, so that the process is completed at activity 28. Resources
for implementing these activities may be a printer 29 that outputs an
explanation to the person that submitted the claim and a delivery system
30 that may include mailing or electronically transmitting the explanation
to the person that submitted the claim.
When the required authorization is provided for the submitted claim, the
appropriate activity 31 is to notify the payroll department, which can
initiate the payment process at activity 32. Notification may be provided
by a facsimile device 33. The initiation of the payment process may
require a handoff 34 of the processing to a second workflow process that
requires additional resources.
In the operation of the WFMS of Du et al., the GRM is invoked with a
request for a specific activity, such as a request for the facsimile
device 33 to transmit notice to the payroll department in order to execute
activity 31. The GRM responds by checking the stored capabilities and the
status of the resource groups, selecting one of the resource groups having
the capability to perform the specific activity and having the status that
enables the group to do so, and forwarding the request to the LRM of the
computer that is specific to the selected resource group. The LRM of the
specific computer can respond to the request by selecting one of the
resources (e.g., one of the available facsimile devices) in the selected
resource group to perform the specified activity and by assigning the
activity to the selected resource. The LRM then updates the stored status
data of the resource and forwards the updated status data to the GRM.
While the approach of Du et al. provides a significant reduction in
operation overhead without introducing long delays in run-time resource
assignment, further improvements are desired. Specifically, what is needed
is a method and system for providing resource management such that the
flexibility and the scalability of implementation are enhanced. What is
further needed is such a method and system that allow different views of
workflow resources at different levels of an enterprise, while still
providing an enterprise-wide view of all workflow resources.
SUMMARY OF THE INVENTION
A method for providing resource management in an enterprise and a system
for implementing the method support different views of enterprise workflow
resources by providing at least three levels of resource managers. The
multi-level resource management hierarchy is combined with inter-level and
intra-level communication techniques (i.e., a resource query processing
algorithm and an interaction protocol) for efficient distributed resource
management. The method and the system provide a capability-based resource
hierarchy for modeling static resource characteristics and a rule-based
resource policy manager for dealing with dynamic resource properties.
In order to accommodate wide distribution of enterprise workflow resources
across organizational and physical boundaries, resource management is also
distributed. To support different views of enterprise workflow resources,
global resource managers (GRMs) are subdivided into Enterprise GRMs (ERMs)
and Site GRMs (SRMs). ERMs represent the enterprise-wide view of workflow
resources and interface with the underlying SRMs, which represent partial
views of workflow resources based upon organizational or physical
boundaries.
There may be more than one level of SRMs in order to represent different
levels of views. Thus, a tree hierarchy of resource managers is formed,
with ERMs as roots. SRMs at the same level represent views in different
organizations or within different physical boundaries. In other than the
lowest level, an SRM is an integrated view of its subordinate SRMs. The
lowest level SRM represents imported and possibly integrated views of one
or more external local resource manager (LRM).
There can be more than one ERM. All of the ERMs represent the same
enterprise-wide view of the enterprise workflow resources, but may provide
variations in fault tolerance.
The LRMs may have different resource models and communication protocols,
since they may be designed for unique purposes and may use different
resource models and technologies. However, the GRMs (i.e., ERMs and SRMs)
represent integrated views of part or all of the underlying LRMs. All of
the GRMs utilize the same resource model and the same communication
protocol.
In the preferred embodiment, each SRM and ERM has an architecture that is
formed of four layers: the interface layer, the policy manager and
resource model layer, the request processing engine layer, and the
integration layer. The interface layer allows other components (e.g., a
workflow engine) to send requests to the GRM and allows communication with
other GRMs. Moreover, the interface layer provides administrative and
security features. The policy manager and resource model layer implements
the policy rules and the resource model. This layer also provides a
database having an extensive schema that is used to store model and
historical information and may be used to store other information needed
for resource management. The request processing engine layer routes the
actual requests to the appropriate information sources. It also assembles
all of the results that are returned by information sources. Finally, the
integration layer manages all of the different protocols utilized by local
information sources, such as the LRMs. The integration layer enables the
LRMs to be advertised and manages the wrappers that need to go around each
LRM.
The four layers are employed to provide a response query algorithm that
maps physical resources to workflow activities based on the resource model
and policies. When a request reaches a particular GRM, the first step is
to determine whether the GRM can handle the request. If not, the request
is passed to another resource manager. On the other, if the receiving GRM
is able to handle the request, the request is passed to a policy engine
component that provides query rewrite. After the policy enforcement, the
request is forwarded to a resource engine, which determines whether a
particular resource can be found to satisfy the request. If an appropriate
resource is found, an appropriate return is generated. However, if no
resource is found, the request is sent to a policy engine, which applies
substitution policies. When an appropriate resource is found in view of
the substitution policies, an appropriate result is generated. If not, a
NULL is returned.
Preferably, the system utilizes a resource model that is a hierarchical
collection of resource types. A resource type is used to organize
resources into groups of resource instances with the same capabilities.
The resource hierarchy shows resources organized into types. Each of the
types in the hierarchy has a list of capability attributes, which
represent its capabilities. Furthermore, a resource type inherits
capabilities (attributes) from its parents. Each type in the resource
model of a resource manager has four fields. A first field relates to the
ability of resource managers to satisfy requests for the resource. The
second field relates to delegating satisfaction of a request for the
resource at a lower level resource manager in the hierarchy. The third
field is the address of cache that represents a same level resource
manager that has been discovered as being able to satisfy a request or the
resource. The fourth field is an address of a resource manager that can
satisfy requests for the resource, but at a higher level in the resource
manager hierarchy.
An interaction protocol among the resource managers is also important to
efficient distributed resource management. There are four types of
messages that a GRM can send to another GRM: Plead, Delegate, Refer and
Report. A Plead is used by a GRM to send a request to a higher level GRM.
On the other hand, the Delegate message is used by a GRM to send a request
to a lower level GRM. A Refer message allows a GRM to pass a request to
other GRMs that are horizontally positioned in the hierarchy. The Report
message is a response sent back to a GRM which originated a request. This
message is used to create and update cache entries at the originating GRM.
Cache among the SRMs does not have to be consistent. While it is not
within the same protocol, a Do message is a message that is sent from a
resource manager to a local resource manager that has direct control over
the resource to be used to satisfy a resource request.
The resource management system and method provide a number of advantages.
Efficient resource mapping based on a hierarchical resource model is
enabled, as well as flexible resource handling using resource policies.
Moreover, the system and method allow different types of local resource
managers (i.e., database, corporate directory, or any legacy applications)
to be integrated and local resources to be mapped to the global resource
model. Another advantage is that the system and method allow for
distributed resource management that crosses organization boundaries
without compromising local autonomy by deploying multi-level resource
management hierarchy. As another advantage, the system and method can
easily scale up to handle a large number of resources at the enterprise
level. Additionally, the system and method enable efficient assignment of
resources at any level and by any GRM using the interaction protocol for
communications among the resource managers.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a schematic representation of a workflow process in accordance
with either the prior art or the present invention.
FIG. 2 is a block diagram of a three-tier hierarchy of resource managers in
accordance with one embodiment of the present invention.
FIG. 3 is a block diagram of a second embodiment of a hierarchy of resource
managers in accordance with the invention.
FIG. 4 is a schematic view of layers of a global resource manager of FIG.
2.
FIG. 5 is a block diagram of the components of the global resource manager
of FIG. 4.
FIG. 6 is a process flow of steps for routing a request for a resource in
accordance with the invention.
FIG. 7 is a block diagram of an example of a workflow process to be
controlled using the resource managers of FIG. 2.
FIG. 8 is a schematic view of a resource hierarchy in accordance with the
invention.
FIG. 9 is a schematic view of the resource hierarchy of FIG. 8, but with
definitions of roles.
FIG. 10 is a schematic view of a communication protocol among resource
managers in accordance with the invention.
FIG. 11 is a process flow of steps for utilizing the messages of FIG. 10.
DETAILED DESCRIPTION
With reference to FIG. 2, a hierarchy of an enterprise workflow resource
management system (WFMS) 36 is shown as having at least three levels 38,
40 and 42 of resource managers. Since enterprise workflow resources can be
widely distributed across organizational and physical boundaries, resource
management is distributed. That is, the multi-tier system is highly
compatible with large scale business architectures. Moreover, the
multi-tier system supports different views of enterprise workflow
resources. The different views are provided by dividing the global
resource managers (GRMs) of the above-cited Du et al. system (U.S. Pat.
No. 5,826,239) into enterprise GRMs (ERMs) and site GRMs (SRMs).
In the embodiment of FIG. 2, there is only one ERM 44. The ERM represents
the enterprise-wide view of workflow resources. Thus, the ERM 44 provides
an overview of the capabilities of the entire system 36.
The ERM 44 interfaces with the underlying SRMs 46, 48, 50 and 52. Each SRM
represents a partial view of workflow resources. The partial views may be
based upon organizational boundaries or physical boundaries. For example,
the SRM.sub.1, may be specific to a first building of a campus of
buildings of an enterprise. The other three SRMs may be specific to other
buildings on the same campus. Alternatively, the SRMs may be specific to
different locations of an enterprise having sites in different cities or
countries. The SRMs report to the ERM 44. While not shown in FIG. 2, the
SRMs are able to communicate with each other using the interaction
protocol to be described below.
The third tier 42 includes LRMs 54, 56, 58, 60 and 62. Each LRM is
dedicated to a group of resources. In the preferred embodiment, the WFMS
36 utilizes a resource model that is a hierarchical collection of resource
types. A resource type is used to organize resources into groups of
resource instances having the same capabilities. The individual LRMs have
information regarding and full control over the resources that they
manage. The LRMs include individual resource databases which keep track of
static information such as roles and addresses, as well as dynamic status
information such as availability and workload. The LRM for a selected
group maps the group into individual resources and checks their
availability and workloads. When a request is received from an SRM 46 | | |
