Method for incorporating human-based activities in business process models

COMPUTER PROGRAM LISTING APPENDIX

[0001] The computer program listing appendix attached hereto consists of two (2) identical compact disks, copy <b>1</b> and copy <b>2</b>, each containing a listing of the software code outlining an exemplary method for incorporating human-based activities in business process models. The contents of the compact disks are a part of the present disclosure, and are incorporated by reference herein in their entireties.

TECHNICAL FIELD OF THE INVENTION

[0002] The present invention relates generally to computer software and to methods for business process management. More particularly, the present invention includes a method that extends business process models to include human-based activities.

BACKGROUND OF THE INVENTION

[0003] A business process management system (BPM system) is a computer system that automates business processes. Business processes are steps that a business undertakes to accomplish some objective, such as hiring an employee or procuring components required for production. BPM systems automate business processes by managing business process objects. A business process object is an entity that exists within the context of a BPM system and represents a business process instance.

[0004] As an example, consider the case of a retail business. For this type of application, a BPM system might be constructed to track customer orders. A business process object would represent each order. The BPM system used by the retail business would manage customer orders by manipulating the corresponding business process objects.

[0005] BPM systems are typically designed in a way that makes their behavior easy to customize. This allows the same underlying system to be deployed in a range of different environments and applications, such as manufacturing, retail sales, and business to business applications.

[0006] To provide this type of flexibility, some BPM systems have adopted a model-driven approach. BPM systems of this type allow model-designers to describe business processes in terms of business process models. A business process model is a formal definition of a business process in a high-level graphical modeling language such as UML (Uniform Modeling Language).

[0007] Business process models define the runtime behavior of business process objects using state diagrams. FIG. 1 shows an example of a state diagram of this type. This particular state diagram begins with an initial state where an order is received. The initial state is followed by two states: a first for existing customers and a second for new customers. These two states are followed by a final state where the order is processed.

[0008] The connections between states are known as transitions. Model designers define transitions as part of the process of defining state diagrams. In this way, users get to choose the permissible paths through state diagrams.

[0009] Objects traverse transitions and move between states in response to events. Events are notification within the BPM system that something has happened in the real world. Customers placing orders and customers canceling orders are two examples of events.

[0010] The ability to define objects, state diagrams (including states and transitions) and events provides model designers with a highly flexible and intuitive mechanism for customizing the behavior of model-driven BPM systems. Model designers get to define the entities processed by the BPM systems (in term of objects), the runtime behavior of those entities (state diagrams) and the interaction between the real world and the BPM system (events). This mechanism is even more powerful because it lends itself to creation and manipulation within graphical or visual design environments. This allows users to define state diagrams by drawing, for example. In this way, model-driven BPM systems greatly reduce the need for highly skilled programmers.

[0011] One shortcoming of current BPM systems arises when business processes involve human-based activities. As an example, consider the case of an online order taking system. For some systems of this type, incoming orders must be approved by a manager (or other human) before they can be accepted. This might be the case with orders involve large amounts of money, for example. Unfortunately, model-driven BPM systems don't provide a mechanism for modeling human-based activities. As a result, many business processes may be difficult (and in some cases, impossible) to accurately model.

[0012] As a result, there is a need for BPM systems that can be extended to include human-based activities. This need is particularly true for business processes that includes a large number of human-based activities or where human-based activities otherwise become the dominant portion of a business process.

SUMMARY OF THE INVENTION

[0013] An embodiment of the present invention provides a method for incorporating human-based or manual activities in business process models. For this method, the modeling environment within a BPM system is extended to allow model designers to add manual steps to business process models. Each manual step is represented by an activity state. Each activity state includes attributes identifying one or more performers for the activity state. For typical implementations, these attributes also allow model designers to associate information, referred to as reference data with each activity states. A range of other attribute types and functions are also supported.

[0014] At runtime, business process objects transition into activity states in response to events and conditions that have been identified by the model designer. When an activity state is entered, the BPM system identifies the performers associated with the activity state. The BPM system then generates a respective task for each performer. The BPM system also distributes copies of the reference data to each task.

[0015] The BPM system then waits for the performers to complete their tasks. As each task completes, the BPM system collects any reference data that has been changed by the respective performer. When all tasks have been completed, the BPM system transitions the business process object out of the activity state. The particular transition or transitions taken from an activity state may be conditionally based on the reference data collected during the activity sate.

[0016] Stated differently, the present invention includes a method for providing a BPM system, the method comprising the steps of receiving an event, causing a business process object to transition to an activity state corresponding to the event, identifying one or more performers for the activity state, and creating a task for each performer.

[0017] Other aspects and advantages of the present invention will become apparent from the following descriptions and accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0018] For a more complete understanding of the present invention and for further features and advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, in which:

[0019]FIG. 1 is a state diagram as used in a business process model.

[0020]FIG. 2 is a block diagram of an Internet-like network shown as a representative environment for deployment of the present invention.

[0021]FIG. 3 is a block diagram of a computer system as used within the network of FIG. 2.

[0022]FIG. 4 is a block diagram showing the components of a BPM system compatible with an embodiment of the present invention.

[0023]FIG. 5 is a state diagram of a business process model including a manual activity. FIG. 6 is a state diagram of a business process model including three manual activities.

[0024]FIG. 7 shows the state diagram of FIG. 6 with an additional state to handle a timeout event.

[0025]FIG. 8 is a state diagram of a sub-process model invoked by the timeout event of FIG. 7.

[0026]FIG. 9 shows the state diagram of FIG. 7 with an additional state to handle a user-defined cancellation event.

[0027]FIG. 10 is a state diagram of a business process model including two concurrent manual activities.

[0028]FIG. 11 is a state diagram of an activity control model as used within an embodiment of the present invention.

[0029]FIG. 12 is a state diagram of a task control model as used within an embodiment of the present invention.

[0030]FIG. 13 is a block diagram showing a federation of BPM systems.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0031] The preferred embodiments of the present invention and their advantages are best understood by referring to FIGS. 1 through 14 of the drawings. Like numerals are used for like and corresponding parts of the various drawings.

[0032] Definitions

[0033] Activity: a human-based or manual part of a business process is referred to as an activity.

[0034] Performer: an individual who is responsible for a portion of an activity is referred to as a performer.

[0035] Task: a task is the portion of an activity that is assigned to a performer.

[0036] Activity Supervisor: an individual who manages or has responsibility for an activity is referred to as an activity supervisor.

[0037] Process Supervisor: an individual who manages or has responsibility for all of the activities within a process is referred to as a process supervisor.

[0038] Business Process: steps that a business undertakes to accomplish some objective, such as hiring an employee; acquiring a new customer; fulfilling a customer order; provisioning a new service; enrolling a new partner. For the purposes of this document this definition includes lower-level processes that support businesses, such as processes to synchronize disparate databases, etc. The steps in a business process may be automated, manual or a combination of both.

[0039] Business Process Model: A formal definition of a business process in a high-level graphical modeling language.

[0040] Business Process Instance: An instance of a business process. For example, the fulfillment of Joe Smith's order is considered an “instance” of the more general order fulfillment business process. Note that each customer order being fulfilled would be an instance of the Order Fulfillment Business Process. Hence, a business process typically will have many instances.

[0041] Business Process Object: A computerized representation of a business process instance.

[0042] Environment

[0043] In FIG. 2, a computer network <b>200</b> is shown as a representative environment for an embodiment of the present invention. Computer network <b>200</b> is intended to be representative of the complete spectrum of computer network types including Internet and internet-like networks. Computer network <b>200</b> includes a number of computer systems, of which computer systems <b>202</b><i>a </i>through <b>202</b><i>f </i>are representative. Computer systems <b>202</b> are intended to be representative of the wide range of large and small computer systems that are used in computer networks of all types.

[0044]FIG. 3 shows a representative implementation for computer systems <b>202</b>. Structurally, each computer system <b>202</b> includes a processor, or processors <b>302</b> and a memory <b>304</b> Processor <b>302</b> can be selected from a wide range of commercially available or custom to processor <b>302</b> and memory <b>304</b> Input device <b>306</b> and output device <b>308</b> represent all types of I/O devices such as disk drives, keyboards, modems, network adapters, printers and displays. Each computer system <b>202</b> may also include a disk drive <b>310</b> of any suitable disk drive type (equivalently, disk drive <b>310</b> may be any non-volatile mass storage system such as “flash” memory).

[0045] Overview of Compatible BPM System

[0046] An embodiment of the present invention provides a method for incorporating human-based or manual activities in business process models. This method is preferably (but not necessarily) used in combination with a model-driven BPM system. To better describe this method, FIG. 4 shows a model-driven BPM system <b>400</b> deployed as part of an EAI system. BPM system <b>400</b> is intended to be representative of BPM systems that are suitable for use with the method for incorporating manual activities.

[0047] As shown in FIG. 4, BPM system <b>400</b> includes a process modeler <b>402</b>. Process modeler <b>402</b> is an interactive interface, preferably graphical, that allows users to create and modify business process models. As described with reference to FIG. 2, users define business process models as collections of states interconnected by transitions. The process models are preferably UML (Uniform Modeling Language) based, with process modeler <b>402</b> being a visual environment for manipulating UML constructs.

[0048] Businessware server <b>404</b> maintains the business process models created by process modeler <b>402</b>. Process modeler <b>402</b> retrieves business business models from businessware server <b>404</b> and stores business process models to businessware server <b>404</b> on an as-needed basis.

[0049] BPM system <b>400</b> also includes a user manager <b>406</b>. User manager <b>406</b> allows definitions of performers, groups of performers, activity supervisors and process supervisors to be created, modified and persistently stored. These definitions are available within process modeler <b>402</b> for inclusion within business process models.

[0050] Business Process Manager <b>408</b> is the runtime environment for business process objects within BPM system <b>400</b>. Business process manager creates <b>408</b> business process objects using the business process models maintained by businessware server <b>404</b>. Each business process objects is an instance of the corresponding business process model. Task Manager <b>410</b> helps by adding support for the human-based or manual portions of the business process models.

[0051] BPM system <b>400</b> interacts with human performers and human supervisors by generating performer pages <b>414</b> and supervisors pages <b>416</b>. Web server <b>412</b> (“server” here refers to server software executable on a computer system) provides a web-based (i.e., World Wide Web) interface to BPM system <b>400</b> by utilizing performer pages <b>414</b> and supervisors pages <b>416</b>. The two sets of pages are directed at performers and supervisors of BPM system <b>400</b>, respectively.

[0052] Communications channels <b>418</b> largely handle the bulk of communications between the components of BPM system <b>400</b>. Communications channels <b>418</b> are preferably configured to provide asynchronous and guaranteed communications. This increases the performance of BPM system <b>400</b> by allowing different components (such as task manager <b>410</b> and business process manager <b>408</b>) to work in an independent, asynchronous fashion. Guaranteed communications simplifies the design of BPM system <b>400</b> since each component may be designed with the assumption that communications are reliable. Communications channels <b>418</b> may be part of BPM system <b>400</b> or supplied by the environment in which BPM system <b>400</b> operates.

[0053] To provide software application integration, BPM system <b>400</b> works in combination EAI system <b>420</b>. EAI system <b>420</b> provides an object-oriented interface to third party applications and databases. BPM system <b>400</b> allows the interactions between the models exposed by these interfaces to be defined as business process models. In effect the combination of EAI system <b>420</b> and BPM system <b>400</b> provides a model driven EAI system.

[0054] The components that have just been described support business process models of the type traditionally associated with BPM systems. The following sections describe how these components may be used to support business process models that incorporate human-based or manual activities.

[0055] Activities

[0056]FIG. 5 shows an example of a business process model <b>500</b> incorporating a human-based or manual activity. Business process model <b>500</b> includes three states. The first state corresponds to the receipt of a new order. The final state corresponds to the order being shipped. These two states represent automated processes. Application programs might perform both of these steps, for example. The second, intermediate state corresponds to the manual step of having the order approved. Manual steps are referred to as activities.

[0057] Activity State Semantics

[0058] Within process modeler <b>402</b>, manual steps (such as the second state of business process model <b>500</b>) are modeled using a construct known as an activity state. Activity states share many of the characteristics of normal states. Normal states are used to model automated processes. The equal treatment of activity states and normal states results in a richly expressive BPM modeling environment.

[0059] Like normal states, each activity state may have one or more outgoing transitions. Each transition is associated with an event and, optionally, a condition. The default outgoing transition for an activity state is triggered when a predefined activity completion event is raised. Other (non-default) outgoing transitions are associated with other events. As an example, FIG. 6 shows a state diagram <b>600</b> that includes three activity states. The ReviewContract state has two transitions. Both transitions are associated with the activity completion event. The first transition is conditioned upon the contract being approved. Thus, this transition is chosen if the contract reviewed in the first state is approved. The second transition is conditionally traversed if the contract is rejected. This transition leads to the Re-negotiateContract state.

[0060]FIG. 7 extends the example of FIG. 6 by adding a third transition to the initial state. The third transition is associated with a time-out event. This transition is traversed if the contract review process becomes overdue (times out). In this case, the third transition is taken to invoke the escalation sub-model (represented in FIG. 7 as a nested state).

[0061]FIG. 8 shows the escalation sub-model. Within this sub-model, the escalated review process forwards the contract directly to a vice president and CEO. Either one of them can approve or reject the contract. The review results are indicated by two termination states: approved and rejected.

[0062] The activity complete and the time out events are both pre-defined. BPM system <b>400</b> also allows the user to define additional events as needed. This is shown, for example, in FIG. 9. Within FIG. 9, a ContractCanceled state has been added to the state diagram last seen in FIG. 7. The ContractCanceled state is implemented as a normal (i.e., non-activity state) and is reachable via transitions from the ReviewContract and EscalateReview activity states. In each case, the transition to the ContractCanceled state is traversed in response to a receipt of a user-defined cancellation event. Receipt of this event terminates the ReviewContract or EscalateReview activity states and leads immediately to the ContractCanceled state.

[0063] For the particular implementation being described, activity states are not permitted to be the first or last (Start or End) State of a business process model.

[0064] Activity State Definition

[0065] The activity state extends the normal state to include the following attributes:

[0066] 1) Name: each activity may have a name.

[0067] 2) Description: a string describing the nature of the activity.

[0068] 3) Priority: a value indicating the priority of an activity state within its containing process. The priority may be used to communicate with users (e.g., by prioritizing or ordering communications such as email).

[0069] 4) Performer: the user or group of users who may perform the activity.

[0070] 5) Reassignable: a boolean value each indicating whether the performer of an activity may reassign the activity to another performer. If the value is false only the process/activity supervisor has such permission.

[0071] 6) Time limit: a value indicating the deadline required for completion of the activity.

[0072] 7) Details: a string containing a URL pointing to a description of the activity.

[0073] 8) Reference data: data that is useful to the performers who will complete the activity. Reference data is described in greater detail below.

[0074] In general, it should be appreciated that not all implementations will include this exact set of attributes. In other cases, additional attributes may also be included.

[0075] Within an activity state, reference data refers to information that is intended to help performers complete their tasks. There are two kinds of reference data: Business process object reference data and activity reference data.

[0076] Business process object reference data is a portion of a business process object that a model designer wants to make available to the performers of an activity. For example, business process objects used to model a stock purchase process might include attributes for stock price and stock quantity. The model designer might want to make these attributes available to the performers within activity states for this process.

[0077] Activity reference data refers to data that is useful only within an activity state. For the stock purchase process example, activity reference data might include a purchase limit or a report string. Activity reference data is defined on an activity state by activity state basis. This means that activity reference data is not shared between different activity states, even if they are associated with the same business process object. This differs from business process object data because business process object data may be shared between any or all of the activity states associated with a business process object.

[0078] Both activity reference data and business process object reference data may be configured to be read-only or editable. Read-only reference data cannot be changed by the performers of an activity. Editable reference data can be changed. This can be used, for example, to allow performers to enter comments or other information.

[0079] Activity State Runtime

[0080] Within BPM system <b>400</b>, the runtime environment for business process objects is provided by a cooperative effort between Business Process Manager <b>408</b> and Task Manager <b>410</b>. Business Process Manager <b>408</b> creates business process objects using the business process models defined in process modeler <b>402</b>. Each business process object tracks a business process instance as it moves through its associated state diagram.

[0081] When an event causes a business process object to transition into an activity state, Business Process Manager <b>408</b> prepares and sends an activityCreate event to Task Manager <b>410</b>. The activityCreate event includes an ActivitySpec data structure describing the activity state. This includes the performer specification, activity reference data and business process object reference data that are associated with the activity state.

[0082] Task Manager <b>410</b> controls the runtime behavior of activity states using activity control model <b>1100</b> of FIG. 11. The activityCreate transition within activity control model <b>1100</b> is traversed when Task Manager <b>410</b> receives an activityCreate event published by Business Process Manager <b>408</b>. During this transition, task manager <b>408</b> uses the performer specification included with the activityCreate event to resolve or identify the performers for the activity state.

[0083] For each identified performer, Task Manager <b>410</b> generates an object known as a task. Each task object records progress for the portion of an activity that is assigned to its performer. Task Manager <b>410</b> includes a copy of all activity reference data and business process object reference data in each generated task.

[0084] After completing the activityCreate transition, the activity state instance stays in the WaitForCompletion state. It remains in this state until all of the previously generated tasks have completed. As each task is completed, task manager collects any changes made to the activity reference data and business process object reference data distributed to that task. In this way, Task Manager <b>410</b> collects input from all task performers.

[0085] When all tasks for a particular activity have completed, Task Manager <b>410</b> generates and publishes an activityComplete event to Business Process Manager <b>408</b>. The activityComplete event includes the activity reference data and business process object reference data that have been collected by Task Manager <b>410</b>. The activityComplete event also includes other data associated with the activity state, such as the identities of the performers of the activity state. Task Manager <b>410</b> then generates an internal taskcomplete event to cause the activity state instance to transition to the Complete state.

[0086] In some cases, the activity instance may receive an activityTerminate event from Business Process Manager <b>408</b>. This happens, for example in cases when an activity times out. User defined conditions may also trigger the activityTerminate event.

[0087] In these cases, the activity state instance terminates any incomplete tasks and traverses the terminate transition. In these cases, no event will be sent to Business Process Manager <b>408</b> and any collected reference data will is discarded.

[0088] Business Process Manager <b>408</b> receives the activityComplete event published by Task Manager <b>410</b>. Business Process Manager <b>408</b> then updates the business process object associated with the just-completed activity state to incorporate any changes that were made to the business process object reference data during execution of the activity state. Business Process Manager <b>408</b> also selects the next state for the business process object. In some cases, the transitions out of an activity state will be conditioned upon the activity reference data or business process object reference data associated with an event.

[0089] In general, it should be appreciated that this particular division of labor between Business Process Manager <b>408</b> and Task Manager <b>410</b> is somewhat arbitrary. For other implementations, these functions could be combined into a single module or subdivided in other ways.

[0090] Concurrent Activity States

[0091] Business Process Manager <b>408</b> is configured to allow only a single instance of an activity state to be active within a given process instance at any point in time. This prevents a single step from being simultaneously performed by different performers.

[0092] A single process instance may, however, have multiple instances of different activity states that are concurrently active. A case like this is illustrated by business process model <b>1000</b> of FIG. 10. Business process model <b>1000</b> has four activity states. Two of these “review by director” and “review by manager” are configured to occur concurrently. Completion of the first state of business process model <b>1000</b> triggers both of these concurrent activity states.

[0093] To support concurrent activity states, BPM system <b>400</b> is configured to allow events to be targeted to specific activity states (this differs from traditional UML modeling where each event is delivered to each active state). Targeting, ensures that events don't get applied to the wrong state (e.g., as would be the case if the completion event for “review by director” were applied to “review by manager’). BPM system <b>400</b> provides the following method for targeting events to activity states:

[0094] 1) Event publishers can optionally include a parameter in an event that indicates the name of the activity state to which the event is directed.

[0095] 2) Business Process Manager <b>408</b> forwards an event of this type to the active activity states that have the name specified by the activity parameter.

[0096] Activity Transition Transaction Protection

[0097] All components of BPM system <b>400</b> carefully handle transactions in order to guarantee system integrity. A transition between activity states is encapsulated in an atomic transaction (“atomic” here meaning that all steps of the transaction are guaranteed to succeed or the transaction is rolled back (undone)). The transaction consists of the following steps performed by Business Process Manager <b>408</b>:

[0098] 1) Business Process Manager <b>408</b> pre-processes the data (e.g., activity reference data and business process object reference data) returned in the activity completion event.

[0099] 2) Business Process Manager <b>408</b> then selects one or more outgoing transitions of the activity state.

[0100] 3) Business Process Manager <b>408</b> then executes any actions that are associated with the one or more transitions selected in the previous step. Business Process Manager <b>408</b> also executes any entry action that it associated with the destination state.

[0101] 4) Business Process Manager <b>408</b> then updates the business process object associated with the just-completed activity state to incorporate any changes that were made to the business process object reference data of the activity state.

[0102] 5) Business Process Manager <b>408</b> then generates and sends an activityCreate event to Task Manager <b>410</b> to dispatch the destination activity.

[0103] The single-transition transaction guarantees either all the five steps occur successfully or none upon errors.

[0104] Tasks

[0105] As mentioned, Task Manager <b>410</b> generates an object, referred to as a task, for each performer of an activity state. Task Manager <b>410</b> transitions its task objects through a state diagram known as a task control model. The position of a task object within the control model reflects the status of the task from creation to assignment to completion. The task object includes a series of control methods. Each method provides an interface that allows performers to control the status of their task and its position within the task control model.

[0106] The attributes of the task object include:

[0107] 1) Reassignable: The reassignable attribute is a boolean value each indicating whether the originally assigned performer can re-assign the task to someone else. Business Process Manager <b>408</b> initializes the reassignable attribute to be equal to the reassignable attribute of the associated activity state.

[0108] 2) Performer: each task has an associated performer. The performer may be a particular user or a group. In the group case, one of the group members is expected to perform the task.

[0109] 3) State. Each task exists in one of four states: pending, acquired, completed, or terminated.

[0110] The control methods of the task object include:

[0111] 1) Acquire. A performer or a process/activity supervisor may invoke the inquire method to inform Task Manager <b>410</b> that they have claimed ownership of a task. A user can only acquire a task that is:

[0112] directly assigned to him or her,

[0113] assigned to a group to which he or she belongs, or

[0114] assigned to a role that he or she can assume.

[0115] 2) Reassign. A performer or a process/activity supervisor may invoke the reassign method to cause Task Manager <b>410</b> to change ownership of a task. Performers are not allowed to reassign their tasks unless the reassignable attribute of the task is set to true.

[0116] 3) Release. A performer may invoke the release method to cause Task Manager <b>410</b> to return a previously acquired task. This is particularly useful to release a task back to a group task list and allow other group members to acquire it.

[0117] 4) Complete. A performer may invoke the complete method to inform Task Manager <b>410</b> that a task has been completed.

[0118] Task Control Model

[0119]FIG. 11 shows a state diagram <b>1100</b> corresponding to the task control model. Within state diagram <b>1100</b>, the create transition is traversed each time Task Manager <b>410</b> creates a new task. During creation, Task Manager <b>410</b> initializes each task to reflect the attributes of the associated activity state including activity and business process object reference data.

[0120] Once initialized, Task Manager <b>410</b> marks each task as being in the pending state. In this state, the performers for tasks have been at least partially resolved (in some cases, the specific identity of a performer will not be known until the performer accepts the task). The performers, however, have yet to acknowledge or otherwise take responsibility for their tasks.

[0121] The pending state has two possible outgoing transitions. The acquire transition is traversed when a performer invokes the task's acquire method. This informs Task Manager <b>410</b> that the performer has acquired or taken responsibility for the task. Task Manager <b>410</b> marks each task making this transition as being in the acquired state.

[0122] The terminate transition out of the pending state occurs when a task is terminated. This can happen when a task times out or in response to a user defined event.

[0123] The acquired state has four possible outgoing transitions. The complete transition is traversed when a performer invokes the task's complete method to inform Task Manager <b>410</b> that the task is finished. Task Manager <b>410</b> marks each task making this transition as being in the complete state. When a task enters the complete state, it generates a task complete event. The task complete event includes any changes that the performer has made to activity reference data or business process object reference data. As previously described, Task Manager <b>410</b> aggregates the changed reference data all of the task associated with an activity state for return to Business Process Manager <b>408</b>.

[0124] The terminate transition out of the acquired state occurs when a task is terminated. This can happen when the time limit for a task expires (task timeout) or in response to a user defined event.

[0125] The reassign transition out of the acquired state occurs when a performer invokes the task's reassign method. A performer or a process/activity supervisor may invoke the reassign method to cause Task Manager <b>410</b> to change ownership of a task. Task Manager <b>410</b> marks each state making this transition as being in the pending state.

[0126] The release transition out of the acquired state occurs when a performer invokes the task's release method. A performer may invoke the release method to cause Task Manager <b>410</b> to return a previously acquired task. This is particularly useful to release a task back to a group task list and allow other group member to acquire it. Task Manager <b>410</b> marks each state making this transition as being in the pending state.

[0127] Performance and System Throughput

[0128] BPM system <b>400</b> uses a range of techniques to maximize performance and system throughput. As previously described business process objects transition between states in response to events. BPM system <b>400</b> encapsulates these transitions as transactions to ensure system integrity.

[0129] To increase throughput, BPM system <b>400</b> may be configured to include multiple transitions within a single transaction. For one method, BPM system <b>400</b> keeps a running count of the number of completed transitions. When the count reaches a predetermined number n, BPM system <b>400</b> initiates a transaction processing for the last n transitions. BPM system <b>400</b> then restarts the running count from zero. In this way, BPM system <b>400</b> batches transitions even when those transitions involve different business process objects. Batching transition not only shorten transactions, but may also reduce number of updates to business process objects in the repository. For example, two subsequent modifications of an attribute become one update.

[0130] Business Process Manager <b>408</b> uses an update list to avoid long transactions caused by multiple transitions. The update list is a queue of business process objects that have been changed or modified but have yet to be stored persistently. In cases where a business process object is involved in multiple transitions, it may have multiple changes to the same attributes. Use of the update list means that intermediate changes to a business process object may never have to be stored persistently. Shorter transactions result in better concurrency and overall system throughput, as operations are less likely to block each other.

[0131] Communication between Business Process Manager <b>408</b> and Task Manager <b>410</b> is done via guaranteed (i.e. transactional) event publication. Asynchronous communication results in better performance and system throughput, as one component does not wait for completion of a service provided by the other component. In addition, events published by Business Process Manager <b>408</b> to Task Manager <b>410</b> are not sent until the model transaction succeeds. This mechanism ensures that each individual event reaches Task Manager <b>410</b> and is not duplicated (i.e., is received once and is not received multiple times). This ensures that Task Manager <b>410</b> does not create duplicated activities and tasks. The same applies to the communication from Task Manager <b>410</b> to Process Business Manager <b>410</b>.

[0132] Scalability

[0133] As previously mentioned, the division of labor between Business Process Manager <b>408</b> and Task Manager <b>410</b> is somewhat arbitrary. This means that the same tasks could be performed by different architectures, such as a combination of Business Process Manager <b>408</b> and Task Manager <b>410</b>. It should be noted however, that the described architecture does provide certain advantages that might not be realized with other implementations.

[0134] One of these advantages is the ability to shut down Business Process Manager <b>408</b> without requiring a concurrent shutdown of any task managers <b>410</b>. Performers interact directly with Task Manager <b>410</b>. This means that, in at least some cases, Business Process Manager <b>408</b> may be shutdown (for maintenance or other reason) without the shutdown being noticeable to the performers.

[0135] The division of labor between Business Process Manager <b>408</b> and Task Manager <b>410</b> also makes BPM scaleable for large-scale enterprise deployment. As shown in FIG. 4, multiple business process managers <b>408</b> and multiple task managers may be used for load balancing. As an organization grows, more business process managers <b>408</b> and task managers <b>410</b> may be added to the infrastructure.

[0136] Task Managers <b>408</b> are extremely stable and easy-to-maintain; no matter how many process models and Business Process Managers <b>408</b> are deployed. Task Managers <b>410</b> do not subscribe to any user-defined types. As a result, any schema or model changes do not require Task Managers <b>410</b> to be restarted.

[0137] BPM system <b>400</b> has strong federation support over its distributed architecture. As shown in FIG. 13, typical federated environment consists of two or more instances of BPM system <b>400</b> executing on computer systems in different environments that are networked together. In such a system, Business Process Managers <b>408</b>, Task Managers <b>410</b> and the web-based GUI (such as Performer Pages) in different instances of BPM system <b>400</b> communicate through federated channels. This allows Business Process Managers <b>408</b> to, for example, invoke task managers <b>510</b> on a remote system.

[0138] Security

[0139] BPM system <b>400</b> is configured to enforce security at several points. Businessware server <b>404</b> maintains an access control list (ACL) for each business process model. Users of process modeler <b>402</b> must supply credentials that match the appropriate ACL before being allowed access to a business process model.

[0140] Web server <b>412</b> is configured to authenticate each performer using information managed by user manager <b>406</b>. Once authenticated, web server <b>412</b> uses performer pages <b>414</b> to supply each performer with their task list. Task Manager <b>410</b> prevents performer from accessing tasks assigned to others.

[0141] BPM system <b>400</b> is configured to support two special classes of users: process supervisors and activity supervisors. These two user classes have special privileges to ensure smooth execution of process models. For example, a supervisor may want to reassign an overdue task to a different performer. The difference between process supervisors and activity supervisors is the scope of responsibility: process supervisor have responsibility and privileges over entire process models. Activity supervisors, on the other hand, have responsibility and privileges over particular activities.

[0142] Conclusion

[0143] Although particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that changes and modifications may be made without departing from the present invention in its broader aspects, and therefore, the appended claims are to encompass within their scope all such changes and modifications that fall within the true scope of the present invention.