Pattern 29 (Deallocation)

FLASH animation of Deallocation pattern

Description

The ability of a resource (or group of resources) to relinquish a work item which is allocated to it (but not yet commenced) and make it available for distribution to another resource or group of resources.

Example

As progress on the Conduct initial investigation work item is not sufficient, the Level 1 support officer resource has made it available for reallocation to another Support Consultant.

Motivation

Deallocation provides resources with a means of relinquishing work items allocated to them and making them available for re-distribution to other resources. This may occur for a variety of reasons including insufficient progress, availability of a better resource or a general need to unload work from a resource.

Overview

There are two possible variations to Deallocation - either the work item can be offered to a single resource or to multiple resources. These transitions are illustrated by the R:deallocate_s and R:deallocate_m arcs in Figure 6.

Context

There are no specific context conditions associated with this pattern.

Implementation

Despite the potential that this pattern offers for actively managing the workload across a process, it is not widely implemented. COSA supports this pattern through the redistribution function. iPlanet provides the ability for the workflow engine to reset the status of an active work item to ready. This has the effect of causing the work item to be reallocated using the same set of distribution criteria as were previously utilised for the work item. Oracle BPEL provides a similar "release" feature.

Issues

One problem that can arise when deallocating a work item is that it could ultimately be re-allocated to the same resource that it was previously retrieved from.

Solutions

As the act of deallocating a work item is generally disjoint from that of reallocating it, the potential always exists for reallocation to the same resource unless active measures are taken to ensure that this does not occur. Generally there are three approaches for doing this:

  • Make the resource unavailable for the period in which the reallocation will occur so that it is not considered in the work item redistribution.
  • Stop the resource accepting new allocations or offers.
  • Ensure that the distribution algorithm does not attempt to allocate a work item to a resource to which it has previously been allocated.

For iPlanet, the second and third options are both possible solutions where the workflow is running in "heads up" mode and resources have work items offered to them. Where it is running "heads down" and resources are directly allocated the next work item without an offer occurring, only the third option is feasible. In COSA and Oracle BPEL, there is no direct solution to this problem.

Evaluation Criteria

An offering achieves full support if it satisfies the description for the pattern.

Product Evaluation

To achieve a + rating (direct support) or a +/- rating (partial support) the product should satisfy the corresponding evaluation criterion of the pattern. Otherwise a - rating (no support) is assigned.

Product/Language

Version

Score

Motivation
Staffware 9 - Not supported
Websphere MQ Workflow 3.4 - Not supported
FLOWer 3.0 - Not supported
COSA 4 + Directly supported through redistribution
iPlanet 3.1 + Achieved by changing the status of a work item to READY
BPMN 1.0 - Not supported
UML 2.0 - Not supported
Oracle BPEL 10.1.2 + Oracle BPEL PM supports this pattern directly. If a work item has been assigned to a set of users of a group, one of the users in the list can "acquire" the task. At anytime before the task expires or before a user has updated the task, the user can "release" the task to the set of users/group the task was originally assigned to
jBPM 3.1.4 - jBPM does not support this pattern.
OpenWFE 1.7.3 + In OpenWFE a started work item can be deallocated. Selecting the "cancel" menu results in a stateless deallocation with the work item being sent back to the group work list. Selecting the "save" menu results in a stateful deallocation. The semantics deviate slightly from those for the Deallocation pattern. As the state "allocated" is missing in OpenWFE, a work item needs to be started in order to be deallocated. This also implies that a distinction can be made between stateful and stateless deallocations.
Enhydra Shark 2 + Enhydra Shark supports this pattern directly. If a work item has been assigned to a set of users of a group, one of the users in the list can "accept" the task. At anytime before the task expires or it has been completed, the user can "release" the task to the set of users/group the task was originally assigned to. Any changes in data will be lost. This is because, on commencement, a work item only receives a copy of the data values necessary for it and any data is not copied back until the work item is completed.

Summary of Evaluation

+ Rating

+/- Rating
  1. A resource is able to remove (allocated or commenced) items from its work queue and make them available for reallocation to other resources.
  1. Only allocated work items can be redirected.