Workflow Patterns

While you're designing and implementing workflow functional interfaces, it is important to consider workflow standards. Standardized workflows are important for business re-engineering, operational flexibility, and interoperation with other workflow systems because interacting business processes often use different workflow systems.

The WebLogic BPM permits the creation of unstructured workflows, so it is important to be careful while designing workflows. Structured workflows also help migration to different, newer releases of the workflow engine and different workflow systems.

Certain workflow patterns have been identified toward making workflows structured. These patterns try to address some simple techniques that should be followed. The patterns are explained in the following sections.

Parallel Execution

You can design a workflow that has two or more parallel paths. To make a workflow with parallel paths structured, it is important to have all parallel paths originating from a common node end at the same And node. The parallel paths should have the same entry and exit points to make them structured (see Figure 34.14).

Figure 34.14. Implementing the parallel execution pattern.

In the case that a subset of parallel paths (say, path1 and path2) needs to merge at a different And node, a dummy task node that simply marks itself as done can be placed to create nested parallelism. Figure 34.15 shows how a single entry point is created using a dummy task for two parallel paths that merge at a different And node (see the dotted section in the figure).

Figure 34.15. Single entry and exit points.

It is important not to have any "dangling paths" in a workflow. A path is said to be dangling when it contains a task with no subsequent node.

Choice of Events

The Choice of Events pattern is for solutions that have parallel paths, that need to execute in a mutually exclusive manner, and their execution is dependent on the occurrence of one or more events. It is important to have a cancel event in place to achieve this mutual exclusion; that is, after an event that starts an execution path is received, a cancel event action should be used to cancel other possible events, which may trigger other execution paths. All mutually exclusive paths should end at an Or node (see Figure 34.16).

Figure 34.16. Implementing the Choice of Events pattern.

Event with Timeout

The Event with Timeout pattern represents a workflow where mutually exclusive events can trigger different execution paths within a set time frame. So, there is a deadline in which the events must occur to trigger the respective execution paths. The timeout logic is typically implemented using a Timed Event action or a Set Task Due Date action. The latter is preferred and recommended as it results in a cleaner and easier-to-understand implementation. All the paths except one that has timeout functionality should start with an event node. (All paths except the execution path 3 shown in Figure 34.17 start with an event node.) The execution path 3 starts with a task node, which has a Set Due Date action for timeout. The last sub-action of this node should mark this task as done. After this node, a decision node checks the occurrence of events E1 and E2 with a flag (this flag is set when either E1 or E2 occurs). If the flag is not set, a task node with Cancel Event actions is executed, thereby suppressing other execution paths. All the execution paths should converge at the same Or node.

Figure 34.17. Implementing the Event with Timeout pattern.

Cancellation via Event

The Cancellation via Event pattern represents a workflow where it is required to cancel an execution path if an event occurs. There are two variations to this pattern, depending on whether the execution path can be canceled in the middle of its execution. In the first variation, the cancellation event does not have any effect if the path has already started its execution. The second variation occurs when checks for the cancellation event are made at various points of execution in the workflow, so the cancellation may be effective throughout the execution path. This variation is complex and may require careful coordination of execution and cancellation paths (see Figure 34.18).

Figure 34.18. Implementing the Cancellation via Event pattern.

The cancellation path should start with an event node waiting for a cancel event. The regular execution path should start with a task node, which provides some latency by entering a quiescent state for a short span, allowing the event node to register properly. The cancellation path should set a flag after the event occurs; the event can be checked in the regular execution path after the quiescent state is exited. A decision node after the timeout node should test the value of the flag. After the regular execution path starts, the event node must be prevented from firing. This can be done by a Cancel Event action that cancels the cancellation event. Both of these execution paths must converge to an Or node.

Similar guidelines should also be followed for the second variation. The cancellation path should start with an Event node that waits for the cancellation event. As in the previous variation, start the normal execution path with a Task node that blocks for a short duration. The last action should disable the Event node by canceling the cancellation event through use of a Cancel Event action. Both execution paths should converge to an Or node.

Execution Timeout

The Execution Timeout pattern is similar to the Cancellation via Event pattern in that a timeout, instead of an event, causes the cancellation of the execution path. A scenario in which a workflow's execution path must be completed in a certain amount of time fits into this pattern. Some of the guidelines for such a pattern are as follows . The timeout path must contain a task node that contains the timeout action. A task with a Set Task Due Date action is recommended. Both the normal execution path and the timeout path should have a single point of entry and should converge at an Or node. The timeout path must be disabled after the regular execution path has completed. This can be achieved by setting a timeout disabled flag (as shown in Figure 34.19) after the regular execution path has finished execution. A decision node must check this flag before doing any processing in the timeout path.

Figure 34.19. Implementing the Execution Timeout pattern.