Use the multimerge pattern to model the convergence of two or more branches into a single path. Each time an incoming branch is enabled, it results in the activation of the next activity within the process. For each multimerge gateway, there should be an associated multibranch gateway.
The following table shows the details of the multimerge pattern:
|
Signature |
Multimerge Pattern |
|
Classification |
Advance Flow Control Pattern |
|
Intent |
Converges two or more branches into one subsequent branch and in doing so, it converges tokens of the incoming branch into one token and passes the token to the subsequent branch. The multimerge pattern allows each incoming branch to continue independently of the others, enabling multiple threads of execution through the remainder of the process. |
|
Motivation |
Offers convergence of parallel paths into a single path; however, parallel paths merging at the multimerge convergence point are not synchronized. |
|
Applicability |
Convergence point without synchronization. |
|
Implementation |
Widely adopted in most of the modeling languages using the XOR join. Accepts multiple incoming parallel sequence flow and passes the tokens as they arrive to the subsequent activity. |
|
Known issues |
Activity performed in the subsequent branch after the multimerge convergence point is not safe. With this pattern, more than one incoming branch can be active simultaneously, and this means that the activity that you are going to follow in the subsequent branch is not necessarily safe. For example, the subsequent branch performs a change in data. All the incoming parallel branches will act on the data, as the behavior of the subsequent branch is same for all the parallel flows. However, the order of the incoming parallel branches' execution is unpredictable. This behavior will make the change in data unpredictable, and hence, any subsequent process or activities will exhibit unpredictable behavior. |
|
Known solution |
NA. Workaround is to model the process flows meticulously. |
Let's consider an example scenario. The requirement is to check inventory and credit in parallel while reviewing the order. However, for each branch, the requirement is to calculate the freight. In this case, when the parallel gateway diverges (fork) the flow, three tokens will be generated and processed by three different threads. Each time the incoming branch is enabled, it would result in the activation of the Calculate Freight activity.
However, the process will move ahead only when all the divergent paths get synchronized at the convergent point (parallel gateway) after the Calculate Freight activity takes place, as shown in the following screenshot:
The multimerge pattern allows each incoming branch to continue independently of the others, enabling multiple threads of execution through the remainder of the process. However, with the usage of parallel gateway in Oracle BPM for divergence, it would always need either a parallel gateway for convergence or a complex gateway. This means that it would always lead to synchronization of the token, either all of the tokens (with parallel gateway as convergent point) or some of the tokens (with complex gateway as the convergent point).
Another multimerge example could be of an employee background check process. The requirement is to perform personal reference check, business reference check, and criminal background check in parallel. However, you need to notify Human Resources (HR) of the enterprise each time a branch gets activated and performs a reference check.
Download the SalesQuoteProject project from the download link for this chapter and open the MultiMerge process. While analyzing the MultiMerge process, you can witness Exclusive Gateway before Multi MergeActivity. This is the XOR gateway that will enable multimerge for this scenario. Execute the process with the MultiMerge.xml sales quote data available in the testsuites folder in the project.
The following are the key values being passed as input to the process:
Customer type: OLD
Effective discount:
10
The following screenshot demonstrates two states of the process. The left-hand side showcases the state when the Approve Deals task is approved by the jcooper user. However, the jstein user has not acted on the Approve Terms task. This showcases that the MultiMergeActivity activity was executed, but both the time and process didn't move ahead, as all the threads need to be synchronized at the ParallelMerge parallel gateway.
The right-hand side of the screen shows the Audit Trail process after the ApproveTerms task was approved. We can clearly witness that multiple threads are enabled for the process branch execution. You can witness different threads that process each parallel branch, the XOR exclusive gateway multimerge point, and the (MultiMergeActivity activity getting executed for all the branches, as demonstrated in the following screenshot:
You can witness that each merging branch at Exclusive Gateway has its own thread, and they are parallel processing. However, the Exclusive Gateway multimerge convergence point will get executed for each parallel branch that has its own token. You can check in the above screenshot that the AND split (ParallelSplit) will split the token in three parallel paths. However, each parallel path will execute the Exclusive multimerge convergence point, and all the parallel tokens will get synchronized at the AND join (ParallelMerge). Hence, the MultiMergeActivity activity will also get executed three times. The XOR gateway that acts as multimerge will pass the tokens, as they arrive to the subsequent activity.