Patterns3
From Business Process Management, BPM and Workflow Automation Wiki | BizAgi BPMS
<keywords content="keywords">
patterns, cycles, instances, cancellation
</keywords>
Contents |
Structural Patterns
Arbitrary Cycles
This pattern is a point in the process where one or more activities can be carried out repeatedly. There are no structural restrictions in the cycles.
Bizagi (BPMN) Implementation
In Bizagi or BPMN one or more activities can be done repeatedly with no restriction for a single entry point.
|
Example: When the factory analyst in a loan request decides to ask for more documents, the previous activities of receiving the documentation and analyzing it must be performed again. This cycle will be carried out until the analyst considers that the documentation and the information are sufficient to make the decision. |
Implicit Termination
A given sub process should be terminated when there is nothing else to be done. In other words, there are no active activities in the workflow and no other activity can be made active.
Bizagi (BPMN) Implementation
In Bizagi, there is just one End Event that explicitly indicates that the process will stop even if there are still activities pending or to be activated. However, the concept of terminating the process can appear when there is nothing more to do and the End Event is used.
If there are no other activities to be carried out in any of the branches, when the process reaches the End Event, it is closed automatically.
|
Example: The following diagram illustrates the use of the End Event in two parallel branches. When one of them has been performed completely and the other one arrives at the End Event, the process is closed automatically, given that there are no more activities pending execution. |
Patterns Involving Multiple Instances
Multiple Instances with Prior Design Time Knowledge
In certain cases, an activity can be carried out many times. The number of times the activity is carried out for each case is known at design time.
Bizagi (BPMN) Implementation
The activity will be included as many times as necessary, preceded by a Parallel Gateway (convergence element).
|
Example: The Approve Request activity will be carried out 3 times as defined at design time. Different actors will carry each of these activities out. |
Multiple Instances without Synchronization
This pattern is used when many instances of an activity are generated without the need to synchronize them after that. For each case, multiple instances of an activity can be created. Each of the control paths generated is independent from the others and it is not necessary to synchronize them.
Bizagi (BPMN) Implementation
In Bizagi, the process, information and user interface are managed comprehensively (the algorithms that coordinate it are known as “Infotuation”); the business data represent the context of the process. Bizagi manages the pattern using information extracted from the 1-N relationship between the process and the data entity. This relationship is specified in the figure that represents the multiple sub-processes.
In Bizagi, sub-process S is the process that includes the activities that must be carried out in the context of each process. If synchronization is not necessary to carry out activity B, sub-process S can be set up so as not to be integrated with the parent process. The multiple instances will be generated and after that, activity B will be enabled even though the sub-processes have not ended.
|
Example: Referring to van der Aalst’s example to describe this pattern, we will illustrate a particular case of its implementation: A client can order several books at the same time from a virtual bookstore like Amazon. Many of the activities (for instance, billing, updating client data) take place at the order level (regardless of the number of books ordered by the client). However, multiple instances can be created to handle the activities performed individually for each book (update stock, shipping, etc.) If the activities that are carried out for each book do not have to be synchronized, this pattern is used. |
Multiple Instances with Prior Runtime Knowledge
This pattern supports the execution of many instances of an activity.
The number of instances of an activity for a given case is variable and may depend on the characteristics of the case or the availability of resources, but is always known at some stage during runtime before the activity is created.
Bizagi (BPMN) Implementation
In Bizagi the process, information and user interface are managed comprehensively (the algorithms that group these variables together are called “Infotuation”).
The business data represent the context of the process. Bizagi manages the pattern using information extracted from the 1-N relationship between the process and the entity. This relationship is specified in the element of the multiple sub-processes.
For the implementation of this pattern, you have to indicate that the exit mode is “All Tokens” so that it is only possible to go on when all the sub-processes have been executed completely.
|
Example: In the Credit Request process, a client can ask for many loans in the same request and the activities are carried out at the request level. However, the activities corresponding to payment must be carried out for each of the loans requested as required |
Multiple Instances with No Prior Knowledge
In a given case, an activity can be carried out several times. The number of instances of an activity for a case is variable and can depend on the characteristics of the case or the availability of resources, but it is only known once the activity has been enabled entirely.
Bizagi (BPMN) Implementation
In Bizagi, a sub process can be started as many times as needed. The process can wait the sub process to finish or not.
|
Example: Activity A is carried out and sub-process S is enabled. Activity B will indicate whether it is necessary to enable sub-process S or not. |
Patterns Based on System Status
Implicit or Deferred Choice
A deferred choice takes place at a point in the process where one of several branches is chosen. In contrast to the Exclusive Gateway, the choice is not made explicitly (e.g. based on data or a decision) but several alternatives are offered based on the environment of the process.
Unlike the Parallel Gateway, only one of the alternatives is executed. This means that once the environment enables one of the branches, the other alternative branches are disabled. It is important to point out that the choice is delayed until the processing in one of the alternative branches actually begins.
Bizagi (BPMN) Implementation
The Event based Gateway shape triggers all the outgoing paths. When one of the activities is performed, the others are disabled.
|
Example: The Deliver Documents event can take place or not, but if it does not occur after three days (defined in the Timer Intermediate Event), the process ends and the Intermediate event is disabled. If the Intermediate event takes place within this period, the Timer Intermediate Event is disabled and the Revise Documents activity is carried out. |
Milestone
This pattern allows you to evaluate whether a process has met its objective or not. Once the objective has been met, some of the activities that were triggered are disabled.
Bizagi (BPMN) Implementation
The same as in the previous pattern, a Event based Gateway is used to trigger tasks A and C, considering that after A, the Event based Gateway will be triggered again, and thus cause task A many times provided that C has not been performed.
Let’s take three activities: A, B and C; Activity A is only enabled if B has been carried out and C has not been carried out. That is, A is not carried out before B and A is not enabled after C.
|
Example: The following are some examples illustrated by van der Aalst for this pattern: a. in a travel agency, flight reservation, car rental and hotel reservations can be made while the bill has not been printed. b. A client can cancel his/her purchase order up to two days before the final delivery of his/her products. c. A client can claim frequent flyer miles up to six months following the flight. |
|
Example: In a travel agency, you can make reservations up to the time the bills are printed. |
Cancellation Patterns
Cancel Activity
In a process, when one activity ends, another is usually performed (Sequence). However, in some cases, a different action can be required in some cases. The pattern to cancel an activity allows you to disable an activity before it is completed.
Bizagi (BPMN) Implementation
This pattern can be modelled using a Event Based Gateway and an Intermediate Event. Event Based Gateway enables the activity and the event in order to have the cancel option.
|
Example: An Event Base Gateway enables the Enter Products activity and the Intermediate Event “Abandon Request”. Only the activity or the Intermediate event can be performed (not both). If the Cancellation Intermediate Event takes place, the activity is not carried out and therefore, this thread of the flow is disabled. If the Enter Products activity is carried out, it will no longer be possible to cancel. |
Cancel Case
One case, that is, one instance of the workflow is removed completely.
Bizagi (BPMN) Implementation
When a transition reaches a Terminate End Event shape, the process ends. If there is an intermediate event or a cancellation activity that arrives after the terminal end event, this pattern may be shown. In order to implement it, use a Parallel Gateway (divergence element) that will enable the intermediate event or the activity during the process.
|
Example: When the Intermediate Event “Abandon Request” is executed, the case ends. In this case, the Intermediate Event is available after the “Enter Client” activity and it can be activated in any of the following activities. |
<comments />
