The conditional parallel split and parallel merge pattern is a part of advance branching and synchronization. It's similar to parallel split and merge; however, it is based on conditions, that is, it must follow a conditional transition. This process is shown in the following screenshot:
Let's consider an example scenario. When the token diverges at the first parallel gateway, it should perform conditional transition to different parallel tasks as follows:
ApprovalDeals should be performed only when effective discount is greater than 10 percent; otherwise, it should converge to the second parallel gateway without requesting for the deal's approval.
Similarly, we implement conditional parallel merge based on conditional transition. For the sake of example, let the equation of conditional transition be as follows:
Check customer status to find if it's a new or old customer. Converge to join at the parallel gateway. If the customer is old, you would not need an approval of deals; however, request for a deal's approval if the customer is new.
After TermsApproval, if the term approval request status is approved, then it converges at the join at the parallel gateway. Otherwise, the quote request can be ended, as shown in the preceding screenshot.
Oracle BPM does not have conditional transitions from the parallel gateway. If we try to implement a conditional transition outgoing from or incoming to a parallel gateway, it throws a Parallel Gateway cannot have outgoing Conditional Sequence Flows error . As we don't have a method to do conditional transition from the parallel gateway, we can still implement it in combination with the other gateway; in this case, it's the exclusive gateway (XOR). This scenario would be developed using parallel gateway in combination with exclusive gateway.
Download SalesQuoteProject from the download link for this chapter and open ConditionalParallelSplit&Merge. Check the configuration of the outgoing sequence flows from the parallel split point (ParallelSplit) and incoming sequence flow to the parallel merge gateway (ParallelSplit).
Open EM console and test the ConditionalParallelSplit&Merge process using the ConditionalParallelSplit&Merge.xml test data available in the testsuites folder in the project.
The test data contains the following data:
Effective discount:
9Quote request status:
OldRest all fields can be user choice
Log in to the Oracle BPM workspace as a
salesrepuser and approve the AcceptQuote task.Log in again to the BPM workspace as a
fkafkauser to approve the BusinessReview task.Process flow will reach the fork divergent parallel gateway (ParallelSplit) and would initiate the parallel flow to perform the DiscountCheck, ApproveDeals, and ApproveTerms task, as shown in the following screenshot:
As the effective discount is
9, which is less than 10 percent condition on the transition flow (<10%), the process will flow at the sequence flow (<10%) pathway and halts at parallel gateway (ParallelMerge) to get synchronized at the join convergence parallel gateway.Log in to the Oracle BPM workspace as a
jsteinuser and approve the ApproveTerms task. Post approval, the token will get synchronized at the convergent point parallel gateway (ParallelMerge), and the process flow will move ahead.
A token gets created for each outgoing flow from the split parallel gateway, and none of the outgoing sequence flows are evaluated as the parallel gateway doesn't allow for outgoing conditional flow. However, we can use exclusive gateways to perform conditional transitions. This is not a direct offering of Oracle BPM; however, we can implement this using a combination of gateways. The parallel merge gateway waits for all the concurrent tokens to reach it. Until 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.
In this section, we will demonstrate the fact that one cannot use conditional parallel split and merge by just merging some of the gateways. Process modeling needs to be performed meticulously. Hence, in this book, we are talking about patterns that offer techniques to solve repeatable issues and enhance the process modeling approach.
We will test the ConditionalParallelSplit&Merge process using the ConditionalParallelSplit&Merge.xml test data available in the testsuites folder in the project. However, this time, we will change the effective discount to any value greater than 10. Let the customer type be old, and keep all other fields as they are as follows:
Log in to the Oracle BPM workspace as the
salesrepuser and then as thefkafkauser to approve the AcceptQuote and BusinessReview tasks.Log in to the BPM workspace as the
jsteinuser. It's the user to whom the ApproveTerms task is assigned. Log in and reject the task as follows:The ApproveTerms task is now rejected, and the ConditionalParallelSplit&Merge process is modeled in such a way that if the ApproveTerms task is rejected, then the process should end. We can verify an outgoing sequence flow from the ApproveTerms task to the TermsOutcome exclusive gateway, which checks for task's outcome. If the outcome is REJECT, then the process should end.
Check Process Trace and Audit Trail in EM console as shown in the following screenshot. We will notice the following behavior:
Once the ApproveTerms task is rejected, the process moves to the Terms Outcome exclusive gateway and then to the message end event of the process.
However, we can check the process trace, as encircled in the following screenshot; the process is still running.
Now, if we log in to the BPM workspace as the jcooper user and approve the Approve Deals task, then only the parallel paths will converge, and the process will move ahead. This is demonstrated in the following screenshot:
