Pattern 33 (Skip)
The ability for a resource to skip a work item allocated to it and mark the work item as complete.
The Ground Curator has elected to skip the Roll Pitch work item previously allocated to it.
The ability to skip a work item reflects the common approach to expediting process instances by simply ignoring non-critical activities and assuming them to be complete such that work items associated with subsequent tasks can be commenced.
The Skip pattern is generally implemented by providing a means for a resource to advance the state of a work item from allocated to completed. This pattern is illustrated by the R:skip arc in Figure 6.
There are no specific context conditions associated with this pattern.
WebSphere MQ, FLOWer, COSA and Oracle BPEL directly support the ability for a resource to skip work items allocated to them.
The main consideration that arises where work items could potentially be skipped is how to deal with data gathering requirements (e.g. forms that need to be completed by the resource) that are embodied within the work item. In the situation where a work item is skipped, it is generally just marked as complete and no furthur execution is attempted. Subsequent work items that may be expecting data elements or other side-effects resulting from the skipped work item could potentially be compromised.
Where an offering supports the ability for work items to be skipped, it is important that subsequent work items do not necessarily rely on the output of previous work items unless absolutely necessary. The use of static data elements such as default parameter values can avoid much of the consequences of data not being received. More generally however in order to avoid these problems, the ability is required within a PAIS to specify work items that must be completed in full and to specifically identify any resources that are allowed to initiate a skip action.
An offering achieves full support if it satisfies the description for the pattern.
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||+||Directly supported in the worklist handler|
|FLOWer||3.0||+||Directly supported via skip action|
|COSA||4||+||Directly supported via skip option in worklist handler|
|iPlanet||3.1||-||Achieved by changing the status of a work item to COMPLETED where it is in the PENDING state|
|Oracle BPEL||10.1.2||+||Oracle BPEL PM supports this pattern directly. As such any work item can be "withdrawn" by the task creator or the administrator. However, there is also possibility to model a user-action "skip", which marks a work item as completed and passes the flow of control to the subsequent task.|
|jBPM||3.1.4||-||jBPM does not support this pattern. The <cursor> construct with its "skip" command does not provide support for this pattern. Either is "skip" evaluated after the work item during which it was commanded gets completed (which is registered as successfully completed in the log), or when "skip" refers to the next-following task(s) in the flow, any work item(s) for this(these) task(s) never gets created.|
|OpenWFE||1.7.3||-||OpenWFE does not support this pattern.|
|Enhydra Shark||2||-||Enhydra Shark does not support this pattern.|
Summary of Evaluation