Open post
Canceling Discriminator

Canceling Discriminator

Take a look at this BPMN example. Suppose that two processes are running in parallel, merge is activated when one of them ends. The result of the other is just ignored.

Example:
To speed up a query we send it to two databases once the first answer arrives we proceed and just ignore the second answer.

Import into your Project
Open post
Collaboration

Collaboration

Here is a BPMN business process diagram example that shows the representation of collaboration.

Sometimes there are valid business reasons to send the instance back upstream. Collaboration patterns as shown in the figure are quite common in BPM processes. Here the instance continues in a loop until the purchasing agent decides the negotiations are over either because they have the lowest price possible or they decided to purchase from another bidder.

Import into your Project
Open post
Cancel Case

Cancel Case

Here is a BPMN process diagram example that shows the use of the Cancel Case pattern.

The Cancel Case Pattern is an alternative of the Cancel Activity Pattern. However, it cancels an entire sub-process

Customers can call at any time and cancel their entire order no matter where the instance is located in the process. A cumbersome way to handle this is to have cancellation transitions in each activity of the process leading to the End.

Import into your Project
Open post
Cancel Activity

Cancel Activity

This is a BPMN example that shows the use of Cancel Activity pattern.

The Cancel Activity Pattern is used when it is necessary to terminate all concurrent activities if one of them is terminated.

In the example, the Receive Status Notification has no human interaction and is waiting for an external notification that might never come.

Adding a Discriminator and N-out-of-M Join pattern helps solve this problem for individual activities. The upper leg inside the Split/Join in this example has the transition with the long running activity with no human interaction. The lower transition was added here to:

1. Give the clerk the chance to view the orders that are pending in the upper leg and
2. Allow the clerk the chance to cancel any orders that are pending in the upper leg.

Once the clerk cancels an instance, it reaches the Complex Gateway Join activity. The instance is removed from the Receive Status Notification activity and it continues on through the rest of the process.

Import into your Project
Open post
Milestone

Milestone

Here is a BPMN diagram example for the Milestone pattern.

Sometimes, a Due transition (transition with a clock over it) can help keep a process instance moving along. Think of the Milestone pattern as a way to set an SLA for an individual activity. If an instance sits too long in the activity, it is automatically transitioned through the due transition to the next activity.

In this example, the purchasing agent will award the contract to the lowest bidder if either one of two things occurs:

1. If not all the suppliers have placed their bids, the due transition times out after one week or
2. If the same number of bids reach the Join activity that were spawned in the upstream Split-N activity.

Due transitions are sometimes used when Join, synchronous sub-process invocations and Notification Wait activities might cause bottlenecks in processes.

Import into your Project
Open post
Interleaved Routing

Interleaved Routing

This is a BPMM diagram that shows the use of the interleaved routing pattern.

The Interleaved routing pattern relax the sequencing requirement for activates within a process. There is a partial ordering requirement among a set of task for Interleaved parallel routing.

In this example, getting ready for school is a bunch of ad-hoc activates in the mooring. The drive to school however, cannot happen unless the kid are ready for school.

Import into your Project
Open post
Deferred Choice

Deferred Choice

Here is a BPD example for the BPMN process pattern Deferred Choice.

Processes sometimes need to wait for an event outside the process to occur before continuing. These events are fired from:

  • Notifications from other processes currently running and
  • Notifications from outside applications or web pages.
  • This friction built into the process is handled using an activity called a Notification Wait activity (envelope going into a box).

In this example, the instance in the process will remain in the Wait for Supplier Ok activity until it has been notified from outside the process. The event causing the notification sends in information in this example to let the process know if the product was in stock. Based on this, the instance will travel through either the conditional transition (product not in stock) or the unconditional transition.

Import into your Project
Open post
MI requiring Synchronization

MI requiring Synchronization

This is a BPD example that shows the use of Multiple requiring synchronization pattern.

The Multiple requiring synchronization pattern is similar to the multiple instances with A Priori Runtime Knowledge Pattern except that it requires that all the copies of the repeated simultaneous activities must be completed to let the process continue.

Import into your Project
Open post
MI without a priori Knowledge

MI without a priori Knowledge

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.

Import into your Project
Open post
MI with a priori Runtime Knowledge

MI with a priori Runtime Knowledge

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.

Import into your Project

Posts navigation

1 2 3 4 42 43 44