We can perform simple split and merge with the gateway (inclusive gateway) offered by Oracle BPMS. It can perform token evaluation and also synchronize the token merging at the convergence. An inclusive gateway (OR) specifies that one or more of the available paths will be taken. They could all be taken, or only one of them will be taken. This capability is also termed Multichoice. Sometimes, you need to select a subset of alternatives from a set of possible alternatives. This is what the multiple choice (inclusive) patterns are for. The multiple choice pattern is a point in the workflow where, based on a decision or control data, one or more branches are chosen, triggering one or more paths of the process.
An inclusive OR merge is simply an OR gateway that is used to merge multiple sequence flows into one outgoing sequence flow. Each outgoing sequence flow from the gateway will have a Boolean expression that will be evaluated to determine which sequence flow should be used to continue the process. The downstream inclusive gateway is used to merge the paths created by the upstream inclusive gateway. The downstream inclusive gateway synchronizes all the alternative paths created by the multiple choice gateway. The following table shows details of the multichoice pattern:
|
Signature |
Multichoice Pattern |
|
Classification |
Advance Flow Control Pattern |
|
Intent |
Breaks the flow into one of the two or more mutually exclusive paths. |
|
Motivation |
Fundamental constituent to enable selection of a subset of alternative paths from a set of possible alternatives. |
|
Applicability |
Decision point in the business process where the sequence flow will take one or more of the possible outgoing paths. |
|
Implementation |
Widely adopted in most of the modeling languages using the OR split. |
|
Known issues |
Ensure at least one path selection. |
|
Known solution |
Inclusive gateway splits the process at the divergence; however, process tokens can advance to multiple outgoing flows/paths. Sequence flow is picked based on the conditional evaluation where a token is generated for each flow for which the condition is evaluated as |
Download SalesQuoteProject from the download link of this chapter. Open the project in JDeveloper. Open the SalesQuoteSimpleMerge process. The process accepts QuoteRequestData and waits for the sales representative's approval, which will be performed by the salesrep user (we already created a salesrep user in WebLogic myrealm in the previous section). Deploy the process to a WebLogic server.
Let's consider an example scenario. In this business process (SalesQuoteProcess), after SalesQuoteApprovalTask, the approval request also needs to be sent to Legal and Terms for approval. Once Legal and Terms approve, other activities are performed over Quote.
When Legal and Terms act on the task, the gateway will merge them, and the process will move ahead. Perform the following steps to test the SalesQuoteSimpleMerge process:
Test the process from EM or use SOAPUI.
Enter the QuoteRequest elements and submit QuoteRequest. We can use the test data (SalesQuoteSimpleMerge.xml) available in the
testsuitesfolder in the project.We will notice that the process token is waiting at SalesQuoteApprovalTask to be acted upon by the
salesrepuser.Log in to the BPM workspace at
http://<server>:<port>/bpm/workspaceas asalesrepuser and approve the QuoteRequest.
We will find that the process token will reach both the user tasks, Legal and Terms, for approval. There will be two threads created to process the LegalApproval and TermsApproval tasks and both will be in the processing mode.
As per the process design, both these tasks will again be assigned to the salesrep user. You can customize the sample and associate different users for Terms and Legal approval. For the moment, log in to the BPM workspace again as the salesrep user and approve the legal task. You will find that in the process, the thread processing the LegalApproval task is completed, while the thread processing the TermsApproval task is still processing.
As we can check in the following screenshot, the process flow shows the point where the process token is awaiting. The audit trail on the left-hand side showcases the snapshot when the Legal task is approved; however, the Terms task is not being acted upon by the salesrep user. We will notice that for both the tasks (Legal and Terms), there are two separate threads for processing. Even though the Legal task is approved, the process token waits at the merge inclusive gateway (MergeQuoteApproval). Log in back to the BPM workspace as the salesrep user and approve the Terms tasks. In the right-hand side of preceding screenshot, we can witness that once both tasks are acted upon by the user, the process token converges at the inclusive gateway (MergeQuoteApproval), and the process moves ahead to subsequent activities. This is shown in the following screenshot:
The process token will diverge to that sequence flow for which the conditional expression gets evaluated as true, and if not, then it routes to the default sequence flow.
In the preceding sample process, the sequence flow from the inclusive gateway's divergence is Conditional and is based on the approval status from the SalesQuoteApprovalTask user task.
Run another test of the same process and reject the SalesQuoteApprovalTask. You will find that the token passes along the default sequence flow, as the other two sequence flows have not been evaluated as true.
Similar to the exclusive gateway, the inclusive gateway also splits the process at the divergence; however, the process tokens can advance to multiple outgoing flows/paths. The sequence flow is picked based on the conditional evaluation where a token is generated for each flow for which the condition is evaluated as true; otherwise a default sequence flow is picked. The tokens are merged at the convergence, which can be an inclusive gateway.
Synchronizing merge, also known as structured synchronizing merge, is implemented using the inclusive gateway in Oracle BPMS. When the inclusive gateway is used downstream, it is used to merge the paths created by the upstream inclusive gateway. The downstream inclusive gateway synchronizes all the alternative paths created by the multiple choice gateway (inclusive gateway in the upstream). The following table shows details of the structured synchronizing merge pattern:
|
Signature |
Synchronizing Merge Pattern |
|
Classification |
Advance Flow Control Pattern |
|
Intent |
Merging and synchronizing two or more paths. |
|
Motivation |
Fundamental constituent to enable structured synchronizing merge. |
|
Applicability |
An ordered merging of all the previous activations of the divergence point and then to synchronize them. |
|
Implementation |
Widely adopted in most of the modeling languages using OR-Join. All of the tokens associated with a multichoice divergence point must reach the structured synchronizing merge before they can fire. In the case of structured synchronizing merge, there will be a single multichoice divergence point, and the structured synchronizing point will merge all the paths from that particular multichoice divergence point. |
|
Known issues |
Arbitrary loops in complex process models. |
|
Known solution |
General synchronizing merge. |
Perform the following steps to execute the SalesQuoteSimpleMerge process from EM Console, as we did in the previous section:
Log in to the Oracle BPM workspace as a
salesrepuser and approve SalesReqApprovalTask. As per the process design, the Legal and Terms tasks will also gets assigned to thesalesrepuser.Being logged in as the
salesrepuser, approve the LegalApproval task.Check the status of the process in EM; it would be in the running state.
The following are the observations:
Tokens wait at the merge gateways till all the tokens from the multichoice split have converged to the merge point. When all the tokens arrive, the merge gets completed, and then, the process can advance to subsequent activities/tasks.
Inclusive gateways are used when you need an ordered execution of all the previous activations of the divergence point (inclusive gateway) and then to synchronize them using a convergence element (exclusive gateway).
The following table shows details of the local synchronizing merge pattern:
|
Signature |
Local Synchronizing Merge Pattern |
|
Classification |
Advance Flow Control Pattern |
|
Intent |
Merging and synchronizing two or more paths. |
|
Motivation |
Fundamental constituent to enable the local synchronizing merge. |
|
Applicability |
An ordered merging of all the previous activations of the divergence point/points and then to synchronize them. |
|
Implementation |
Widely adopted in most of the modeling languages using OR-Join. All of the tokens associated with multichoice divergence point/points must reach the local synchronizing merge before it can fire. |
|
Known issues |
Determining the number of branches that need synchronization. |
|
Known solution |
Local synchronizing merge will determine it on the basis of local data, for example, threads of the control that arrive at the merge. |