Year: 2017

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.

Here is a BPMN diagram example that shows the use of the pattern Simple Merge.

• When several exclusive conditional paths converges on a single activity, which starts when one chosen path completes.
• XOR-join
• Is the endpoint of a process split started by an exclusive choice.

The power of patterns in a process becomes clearer when one pattern combines with others to form processes. Simple Merge is one of the many examples of this. Anytime an Exclusive Choice pattern occurs, somewhere downstream in the process there will almost always be a Simple Merge pattern. Simple Merge combines several transitions back into a single activity.

As shown in Example, the "Close Claim" activity merges the transitions coming into it. The insurance claim instance coming into it came from only one of the activities upstream in the process.

Here is a BPMN diagram example of the pattern Exclusive Choice.

• The intent is to branch from a single activity to exactly one of several paths, based on the evaluation of a condition.
• Known as the XOR-split
• Widely supported pattern both in BPML, UML, BPEL and BPMN

As shown in the Example, it might be determined that there are two paths that could occur after the Check Credit activity (pass or fail). Depending on the credit score found in the Check Credit activity, the instance either flows to the Check Inventory (passed the credit check) or Notify Customer activity (failed the credit check).