Pattern 28 (Escalation)
FLASH animation of Escalation pattern
Description
The ability of a system to distribute a work item to a resource or group of resources other than those it has previously been distributed to in an attempt to expedite the completion of the work item.
Example
- The review earnings work item was reallocated to the CFO. It had previously been allocated to the Financial Accountant but the deadline for completion had been exceeded.
Motivation
Escalation provides the ability for a system to intervene in the conduct of a work item and assign it to alternative resources. Generally this occurs as a result of a specified deadline being exceeded, but it may also be a consequence of pre-emptive load balancing of work allocations undertaken by the system or manually by the process administrator in an attempt to optimise workflow throughput.
Overview
There are various ways in which a work item may be escalated depending on its current state of progression and the approach that is taken to identifying a suitable party to which it should be reassigned. The possible range of alternatives are illustrated by the S:escalate_oo, S:escalate_om, S:escalate_ao, S:escalate_sm, S:escalate_am, S:escalate_mm, S:escalate_so, S:escalate_sa and S:escalate_aa transitions in Figure 6. An escalation action is triggered by the system or process administrator and results in the work item being removed from the work lists of all resources to which it was previously offered or allocated and added to the work lists of the users to which it is being reassigned in either an offered or allocated state.
Context
There are no specific context conditions associated with this pattern.
Implementation
Staffware, COSA and iPlanet provide direct support for deadlines on work items and allow alternate work items to be triggered (with distinct routing options) in the event that a work item fails to be completed in the required timeframe. Oracle BPEL also provides an escalation mechanism that allows a work item to be automatically rerouted up to three times. WebSphere MQ provides reminders that notify a nominated resource that a given work item has exceeded a specified deadline.
Issues
None identified.
Solutions
N/A.
Evaluation Criteria
An offering achieves full support if it satisfies the description for the pattern. It achieves a partial support rating if programmatic extensions are required.
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 | + | Directly supported through withdraw actions and re-allocating another instance of the same task |
| Websphere MQ Workflow | 3.4 | + | Directly supported via reminders |
| FLOWer | 3.0 | - | Not supported |
| COSA | 4 | + | Supported via the Target Dates option for processes together with a trigger to reroute the work item |
| iPlanet | 3.1 | +/- | Indirectly supported via timers but the cleanup action for the escalated work item must be specified programmatically |
| BPMN | 1.0 | - | Not supported |
| UML | 2.0 | - | Not supported |
| Oracle BPEL | 10.1.2 | + | Oracle BPEL PM supports this pattern directly by allowing escalation of a task to the manager for further action. The escalation continues until a certain user, a certain level (number of escalations to a 'manager'), or a certain title is reached. The escalation feature works correctly if a task has been assigned to a specific user, however if a task has been assigned to a role or a group, Oracle BPEL PM does not seem to know an upper level where a task should be escalated to. |
| jBPM | 3.1.4 | - | jBPM does not support this pattern. |
| OpenWFE | 1.7.3 | + | OpenWFE supports escalation through the timeout attribute for a task, which is used to limit the time duration for the task it is specified on. After a work item is timed out (which may occur both when the work item is waiting to be started or after it has been started) the flow either continues to the next task or the timed out work is re-distributed to another group work list. This escalation needs to explicitly be specified through an if-than statement where the identity of the new resource allocated to the task is defined. |
| Enhydra Shark | 2 | - | Enhydra Shark does not support this pattern. The notion of deadline is present for limiting the duration of an activity, but the deadline never expires. (The provided example did not work as expected and we did not succeed in activating the deadline functionality.) |
Summary of Evaluation
+ Rating |
+/- Rating |
|---|---|
|
|