Open topic with navigation

TIBCO® BPM Enterprise 5.5.0

# Workflow Process Patterns Support

Control-flow patterns capture the various ways in which activities are represented and controlled in workflows. Implementing these patterns gives TIBCO BPM Enterprise the capability to handle the widest range of possible scenarios for modeling and executing processes.

See Workflow Patterns Support.

The table lists the control-flow patterns that are supported in this release of TIBCO BPM Enterprise. The pattern numbers, names and descriptions are those defined by the Workflow Patterns initiative. See:

- http://www.workflowpatterns.com/patterns/control/index.php
- N. Russell, A.H.M. ter Hofstede, W.M.P. van der Aalst, and N. Mulyar. Workflow Control-Flow Patterns: A Revised View. BPM Center Report BPM-06-22, BPMcenter.org, 2006.
- W.M.P van der Aalst, A.H.M. ter Hofstede, B. Kiepuszewski, and A.P. Barros. Workflow Patterns. Distributed and Parallel Databases, 14(3), pages 5-51, July 2003

  Supported control flow patterns
  Pattern Number | Pattern Name | Pattern Description
  --- | --- | ---
  Basic Control Flow Patterns
  1 | Sequence | An activity in a workflow process is enabled after the completion of a preceding activity in the same process.
  2 | Parallel Split | The divergence of a branch into two or more parallel branches, each of which execute concurrently.
  3 | Synchronization | The convergence of two or more branches into a single subsequent branch such that the thread of control is passed to the subsequent branch when all input branches have been enabled.
  4 | Exclusive Choice | The divergence of a branch into two or more branches. When the incoming branch is enabled, the thread of control is immediately passed to precisely one of the outgoing branches based on the outcome of a logical expression associated with the branch.
  5 | Simple Merge | The convergence of two or more branches into a single subsequent branch. Each enablement of an incoming branch results in the thread of control being passed to the subsequent branch.
  Advanced Branching and Synchronization Patterns
  6 | Multi-Choice | The divergence of a branch into two or more branches. When the incoming branch is enabled, the thread of control is passed to one or more of the outgoing branches based on the outcome of distinct logical expressions associated with each of the branches.
  7 | Structured Synchronizing Merge | The convergence of two or more branches (which diverged earlier in the process at a uniquely identifiable point) into a single subsequent branch. The thread of control is passed to the subsequent branch when each active incoming branch has been enabled.
  8 | Multi-Merge | The convergence of two or more branches into a single subsequent branch such that each enablement of an incoming branch results in the thread of control being passed to the subsequent branch.
  9 | Structured Discriminator | The convergence of two or more branches into a single subsequent branch following a corresponding divergence earlier in the process model. The thread of control is passed to the subsequent branch when the first incoming branch has been enabled. Subsequent enabling of incoming branches does not result in the thread of control being passed on. The discriminator construct resets when all incoming branches have been enabled.
  29 | Canceling Discriminator | The convergence of two or more branches into a single subsequent branch following one or more corresponding divergences earlier in the process model. The thread of control is passed to the subsequent branch when the first active incoming branch has been enabled. Triggering the Canceling Discriminator also cancels the execution of all of the other incoming branches and resets the construct.
  30 | Structured Partial Join | The convergence of two or more branches (for example, m) into a single subsequent branch following a corresponding divergence earlier in the process model such that the thread of control is passed to the subsequent branch when n of the incoming branches have been enabled where n is less than m. Subsequent enabling of incoming branches do not result in the thread of control being passed on. The join construct resets when all active incoming branches have been enabled. The join occurs in a structured context, that is, there must be a single Parallel Split construct earlier in the process model, with which the join is associated and it must merge all of the branches emanating from the Parallel Split. These branches must either flow from the Parallel Split to the join without any splits or joins, or be structured in form (that is, balanced splits and joins).
  32 | Canceling Partial Join | The convergence of two or more branches (for example, m) into a single subsequent branch following one or more corresponding divergences earlier in the process model. The thread of control is passed to the subsequent branch when n of the incoming branches have been enabled where n is less than m. Triggering the join also cancels the execution of all of the other incoming branches and resets the construct.
  Multiple Instance Patterns
  12 | Multiple Instances without Synchronization | Within a given process instance, multiple instances of an activity can be created. These instances are independent of each other and run concurrently. There is no requirement to synchronize them upon completion.
  13 | Multiple Instances with a priori Design Time Knowledge | Within a given process instance, multiple instances of an activity can be created. The required number of instances is known at design time. These instances are independent of each other and run concurrently. It is necessary to synchronize the activity instances at completion before any subsequent activities can be triggered.
  14 | Multiple Instances With a priori Run-Time Knowledge | Within a given process instance, multiple instances of an activity can be created. The required number of instances may depend on a number of runtime factors, including state data, resource availability and inter-process communications, but is known before the activity instances must be created. Once initiated, these instances are independent of each other and run concurrently. It is necessary to synchronize the instances at completion before any subsequent activities can be triggered.
  15 | Multiple Instances without a priori Run-Time Knowledge | Within a given process instance, multiple instances of a task can be created. The required number of instances may depend on a number of runtime factors, including state data, resource availability and inter-process communications and is not known until the final instance has completed. Once initiated, these instances are independent of each other and run concurrently. At any time, whilst instances are running, it is possible for additional instances to be initiated. It is necessary to synchronize the instances at completion before any subsequent tasks can be triggered.
  State-based Patterns
  16 | Deferred Choice | A point in a process where one of several branches is chosen based on interaction with the operating environment. Prior to the decision, all branches represent possible future courses of execution. The decision is made by initiating the first task in one of the branches, that is, there is no explicit choice but rather a race between different branches. After the decision is made, execution alternatives in branches other than the one selected are withdrawn.
  18 | Milestone | A task is only enabled when the process instance (of which it is part) is in a specific state (typically a parallel branch). The state is assumed to be a specific execution point (also known as a milestone) in the process model. The nominated task can be enabled when the execution point is reached. If the process instance has progressed beyond this state, then the task cannot be enabled now or at any future time (that is, the deadline has expired). Note that the execution does not influence the state itself, that is, unlike normal control-flow dependencies it is a test rather than a trigger.
  Cancellation and Force Completion Patterns
  19 | Cancel Task | An enabled task is withdrawn prior to it commencing execution. If the task has started, it is disabled and, where possible, the running instance is halted and removed.
  20 | Cancel Case | A complete process instance is removed. This includes currently executing tasks, those which may execute at some future time and all sub-processes. The process instance is recorded as having completed unsuccessfully.
  25 | Cancel Region | The ability to disable a set of tasks in a process instance. If any of the tasks are already executing (or are currently enabled), then they are withdrawn. The tasks need not be a connected subset of the overall process model.
  Iteration Patterns
  10 | Arbitrary Cycles | The ability to represent cycles in a process model that have more than one entry or exit point.
  21 | Structured Loop | The ability to execute a task or sub-process repeatedly. The loop has either a pre-test or post-test condition associated with it that is either evaluated at the beginning or end of the loop to determine whether it should continue. The looping structure has a single entry and exit point.
  22 | Recursion | The ability of a task to invoke itself during its execution or an ancestor in terms of the overall decomposition structure with which it is associated.
  Termination Patterns
  11 | Implicit Termination | A given process (or sub-process) instance should terminate when there are no remaining work items that are able to be done either now or at any time in the future.
  43 | Explicit Termination | A given process (or sub-process) instance should terminate when it reaches a nominated state. Typically this is denoted by a specific end node. When this end node is reached, any remaining work in the process instance is canceled and the overall process instance is recorded as having completed successfully, regardless of whether there are any tasks in progress or remaining to be executed.
  Trigger Patterns
  23 | Transient Trigger | The ability for a task instance to be triggered by a signal from another part of the process or from the external environment. These triggers are transient in nature and are lost if not acted on immediately by the receiving task. A trigger can only be utilized if there is a task instance waiting for it when it is received.
  24 | Persistent Trigger | The ability for a task to be triggered by a signal from another part of the process or from the external environment. These triggers are persistent in form and are retained by the process until they can be acted upon by the receiving task.

Did you find this helpful?

Yes No
Great!
Thanks for taking the time to give us some feedback.
Sorry about that

Why wasn't this helpful? (check all that apply)

Could not find what I was looking for
Instructions confusing or unclear
Instructions did not work

Want to tell us more?

Please select at least one option or provide details about the issue!!

Error occurred while submitting feedback.

Error2 occurred while submitting feedback.

TIBCO® BPM Enterprise

Copyright © 2015-2024. Cloud Software Group, Inc. All Rights Reserved.