Pattern 34 (Redo)
The ability for a resource to redo a work item that has previously been completed in a case. Any subsequent work items (i.e. work items that correspond to subsequent tasks in the process) must also be repeated.
The Inspector has decided to redo the Interview Key Witness work item.
The Redo pattern allows a resource to repeat a work item that has previously been completed. This may be based on a decision that the work item was not undertaken properly or because more information has become available that alters the potential outcome of the work item.
The Redo pattern effectively provides a means of "winding back" the progress of a case to an earlier task. The difficulties associated with doing this where a process instance involves multiple users means the pattern is not a common PAIS feature, however for situations where all of the work items in a case are allocated to the same user (e.g. in a case handling system), the problem is more tractable. One consideration in utilizing this pattern is that whilst it is possible to regress the execution state in a case, it is generally not possible to wind back the state of data elements, hence any necessary reversion of data values needs to be managed at the level of specific applications and is not a general PAIS feature. This pattern is illustrated by the R:redo arc in Figure 6.
There is one context condition associated with this pattern: any shared data elements (i.e. block, scope, case data etc.) cannot be destroyed during the execution of a case.
Of the offerings examined, only FLOWer provides the ability to redo a previously completed work item.
Redoing a previously completed work item can have significant consequences on the execution of a case. In particular, the validity of any subsequent work items is questionable as redoing a preceding work item may impact data elements utilised by these work items during their execution.
FLOWer addresses this issue by requiring any work items that depend on a "redone" work item to also be repeated before the case can be marked as complete.
Full support for this pattern is demonstrated by any offering which provides a construct which satisfies the description when used in a context satisfying the context assumption.
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.
|Websphere MQ Workflow||3.4||-||Not supported|
|FLOWer||3.0||+||Users can redo a work item that has already been completed|
|Oracle BPEL||10.1.2||-||Oracle BPEL PM offers no support for this pattern|
|jBPM||3.1.4||-||jBPM does not support this pattern.|
|OpenWFE||1.7.3||+/-||OpenWFE supports redo through the <cursor> construct for which only the "back" and "rewind" operations are allowed ("skip", "break" and "cancel" are disallowed in order to preserve the integrity of the overall process model). The support is partial, because in order to go back and redo a task, a user needs to have very detailed knowledge of the number of steps the process needs to be rewound. Not only task, but also all data-definition and manipulation steps in-between the tasks are counted by the rewind command.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|
Summary of Evaluation