The parallel gateways are points in the process where multiple parallel paths are defined and they are also used to synchronize (wait for) parallel paths.
Parallel gateways represent concurrent tasks in business flows, and a fork gateway is always accompanied by a join gateway, where a fork gateway illustrates concurrent flows and expresses the fact that all outgoing paths must be pursued. On the other hand, a join synchronization gateway mandates that all the concurrent paths must be completed ahead of process advancement to subsequent tasks/activities.
A fork divides a path into two or more parallel paths and this is known as an AND split. It's the point in the process flow where activities can be performed concurrently rather than sequentially. In an OR gateway, one or another path is taken; however, in an AND gateway, a single thread of execution will be split into two or more branches that can execute tasks concurrently. For example, once an employee's on-boarding process has started, then enter the employee's information in the ERP system and also start the process for the provision of e-mail IDs, stationary, desk allocation, and so on in parallel.
The following table shows the details of the parallel split pattern:
|
Signature |
Parallel Split Pattern |
|
Classification |
Basic Flow Control Pattern |
|
Intent |
Breaks the flow into one of the two or more paths that execute concurrently. |
|
Motivation |
Fundamental constituent to the concurrent execution of two or more paths. |
|
Applicability |
Decision point in the business process where all the outgoing paths must be pursued. |
|
Implementation |
Widely adopted in most of the modeling languages using the AND split. When many activities have to be carried out at the same time and in any order, AND splits (parallel split) can be used to fork the concurrent flow where two or more concurrent threads independently process the activities (gateways, events, and so on) that reside on the corresponding control flow branches. |
|
Known issues |
NA |
|
Known solution |
NA |
The following table shows the details of the synchronization pattern:
|
Signature |
Synchronization Pattern |
|
Classification |
Basic Flow Control Pattern |
|
Intent |
Synchronize paths that exit a parallel split. |
|
Motivation |
To synchronize the flow from multiple parallel branches. Parallel join merge exactly one thread from each incoming branch into a single thread on the outgoing branch by converging the threads of all the parallel branches. |
|
Applicability |
Merge point to synchronize the parallel paths. The AND join to be symmetrically paired up with a corresponding upstream AND split. |
|
Implementation |
Widely adopted in most of the modeling languages using the AND join. Accepts multiple incoming sequence flow and blocks the sequence until all activities within the flows are completed; then, the flow continues. Till the concurrent tokens are not synchronized, multiple incoming sequence flows are blocked. Upon synchronization, one token is passed out of the merge gateway's outgoing flow. |
|
Known issues |
Nonavailability of a token at the AND join that got created from the AND split. |
|
Known solution |
The solution lies in how meticulously the process is modeled, and it's anticipated that the issue will not arise in a structured context. |
Note
Design consideration by modelers is taken into account if you really need parallel processing, that is, whether, in reality, the distinct branches are executed in parallel.
Navigate to SalesQuoteDemo | SalesQuoteProject | ParallelSplitSynchronization process. When the sales quote is initiated, it halts for quote acceptance by the salesrep user at the ApproveQuote user task. Once it is approved, it's reviewed by business practice, and on approval from the fkafka user, the token reaches the parallel gateway, which is the divergent fork point. Both DealsApproval and TermsApproval need to be performed in parallel, and hence, the choice was a parallel gateway to diverge the flow. This is discussed in the following bullet points:
Click on Organization Unit in the project to verify the user assignment to the roles. We will make sure that the user assignment to roles should happen based on following table:
Task
Role
User
Accept Quote
Salesrep
salesrepBusiness Review
Business practice
fkafkaApprovers
Approvers
jcooperContracts
Contracts
jsteinIf not already deployed, deploy SalesQuoteProject.
Log in to EM console or use any tool of choice to execute the ParallelSplitSynchronization process using the
ParallelSplitSynchronization.xmltest data available in the testsuites folder in the project.Log in to the Oracle BPM workspace as the
salesrepuser and approve the AcceptQuote task.Log in to the Oracle BPM workspace as the
fkafkauser and approve the Business Practice Review task.Token has now reached the ApproveDeal and ApproveTerms task.
Log in to EM console and check the Audit Trail of the process.
We can find that a group of threads is created for each sequence flow from the parallel gateway that forks/diverges the path. This is shown in the following screenshot:
Check the process flow using the graphical view of the process in the process audit trail, as shown in the preceding screenshot. We can analyze that both the paths are processed in parallel. Execute the following steps:
Log in to the BPM workspace as a
jcooperuser and approve the ApproveDeal task. We can notice that at the convergence point, that is, at the join (merge parallel gateway), tokens will be synchronized. Hence, the process waits for the other token to reach the convergence point, which is the AND join parallel gateway.Click on the process audit trail in EM for the process. We can witness that Approve Deal thread is completed, while the other thread for the Approve Terms is still processing.
Log in to the BPM workspace as a
jsteinuser and approve the Approve Terms task.Once both the tokens arrive at the AND join (Deals&TermsApproval_Merge) the tokens are synchronized, and one token is passed out of the merge gateway's outgoing flow.