This is a BPD example that shows the use of the pattern MI without a priroi Knowledge.

A set of activities is executed sequentially in an order that is decided during the process instance run time. No two activities of this set are active at the same point in time. The activity instances do not interleave, and they are not executed in parallel.

This is a BPD example that shows the use of the pattern MI with a priori Runtime Knowledge.

For a given process instance, multiple instances of an activity are created. The number of instances required is known at design time. Once initiated, these instances are independent of each other and run concurrently. Subsequent activities can only be triggered after the instances are synchronized at their completion.

In the example, a purchasing agent decides at runtime how many suppliers will be allowed to bid. This number is used to spawn that number of instances in the synchronous Request Quote from Supplier activity. As each supplier bids in the child sub-process, the bid information is carried back into this parent process.

When the same number of bids reach the Join activity that were spawned upstream, the instance continues on. Use this pattern when there is a need to return information back from the sub-process. In this example the bids of the individual suppliers are compared and the contract is awarded to the lowest bidder in the Award Contract to Lowest Bidder activity.

Here is a BPMN process diagram example that shows the use of the pattern MI with a Priori Design Time Knowledge.

The patterns discussed to this point all deal with a single instance throughout the life of a process. Suppose now that each instance of a process handles a batch of insurance claims. Sometimes instance batches contain 40 claims and sometimes they contain 4000.

This pattern takes a batch job and processes each individual item in it without worrying about synchronizing them back into the process. It is usually modeled as shown in figure.

For example, depending on the number of claims in a job, each claim is sent without synchronization (asynchronously) to a task Process Individual Claim for processing. For every claim in the batch job, a new instance would be created.

This is a BPMN diagram example that shows the use of the pattern Implicit Termination.

The Implicit Termination pattern provides an alternative to forcing transitions directly to the End activity. This is sometimes necessary because a process might need to reach the End activity from many activities in a process.

Example 1: This End activity is often seen as a single funnel out of the process. The End activity can then be used as the point of the merge as shown in the figure 1 for the many transition branches in a process.

Example 2: The Connector icon (circle with an arrow) shown in figure 2 represents the End activity and prevents the unsightly clutter caused by drawing a transition across the entire width of the process.

This is a BPMN process diagram example of the use of pattern Arbitrary Cycle.

The Arbitrary Cycle Pattern reiterates a part of sequence flow. It support multiple ways of entering to an end, exiting the areas with repetitive activities. This Pattern is built with a combination of Exclusive Gateways

This example illustrates an arbitrary cycles to repeat an activity or a set of activities by cycling back in the process

Here is a BPMN example of the pattern Synchronizing Merge.

The instance flows from all the Split’s unconditional transitions. The instance also flows through any conditional transitions that evaluate “true” during runtime.

In the figure, here are 3 transitions coming into the Synchronize activity on the right. The default behavior is to have the instance not continue beyond the Synchronize activity until all the valid transitions leaving the Split activity reach it. This marshalling point (diamond with a “-”) is called a Join or Junction activity. Once again, suppose that the order is not being paid using credit. During runtime, the BPM server automatically detects this and knows to wait for only 2 out of the 3 transitions coming into the Synchronize activity (the transitions coming from the Check Inventory and Calculate Shipping Charge activities) before continuing. If the order is being paid by credit, the Synchronize activity will automatically wait for all three transitions during runtime.

This BPMN example shows the use of the pattern N out of M join.

The Parallel Split and Synchronization pattern can be extended to offer some flexibility as the transitions marshal in an activity called a Complex Gateway (diamond with a “*”).

In the example, if an order’s credit check fails, there is probably no need to wait for the transitions coming from either the Check Inventory or Calculate Shipping Charge activities. If the credit check fails, an indicator can be set in the Check Credit activity so that once it reaches the Synchronize activity the instance is immediately released. If this occurs, the BPM Server automatically removes the instances left stuck in the Check Inventory and Calculate Shipping, and the instance immediately continues on through the rest of the process.

This is a BPMN process diagram example that shows the use of the Discriminator pattern. Here are some of its characteristics:

• Allows only one branch to continue on the process at a given join point, based on a condition evaluated at runtime.
• The remaining branches are blocked.
• A special case of N-Out-of-M join pattern.
• Complex Join.

Here is a BPMN diagram example of the Multiple Merge pattern

• The intent of this pattern is to join branches spawned by a Multi-Choice
• It waits for all of the active paths in a parallel structure to complete
• Inclusive OR-join
• Many BPM product lack support for this pattern

Any branch leaving the Split activity (diamond with a “+”) in a Parallel Split and Synchronization pattern can be merged back into a single transition before it reaches the Join activity. In the figure, the Calculate Shipping Charge activity serves as the single merge activity and all transitions go through this activity before continuing on to the Synchronize activity.

This is a BPMN diagram example that shows the use of Multiple Choice pattern.

• The intent is to choose one or more parallel branches.
• A branch is only taken if it satisfy a particular condition.
• Inclusive OR-split.