In this section, we will uncover the exclusive choice and simple merge pattern. It's also known as the exclusive choice pattern.
The control points in the process flow, where the sequence flows converge or diverge are known as gateways. There are different types of gateways, each supporting specific control logics. The gateway types are indicated with a marker in the center of the gateway symbol. Gateways can split and/or join (merge) sequence flows. You need gateways to control the process flow. A gateway is used to model decisions, merges, forks, and joins on a BPMN business process diagram. An exclusive gateway in Oracle BPMN offers simple split and merge patterns. An exclusive gateway (represented by XOR) evaluates the state of the business process and based on the condition, breaks the flow into one of the two or more mutually exclusive paths. This is how the name "mutually exclusive" got derived. The exclusive gateway splits the process into multiple paths, but the token follows only one path. The following table illustrates the details of the exclusive choice pattern:
|
Signature |
Exclusive Choice Pattern |
|
Classification |
Basic Flow Control Pattern |
|
Intent |
Breaks the flow into one of the two or more mutually exclusive paths. |
|
Motivation |
Fundamental constituent to enable dynamic routing decision. |
|
Applicability |
Decision point in the business process where the sequence flow will take only one of the possible outgoing paths when the process is performed. |
|
Implementation |
Widely adopted in most of the modeling languages, including Oracle BPMN, as the XOR gateway. |
|
Known issues |
Enforcing accuracy in triggering an outgoing path. |
|
Known solution |
Based on the evaluation of the conditions associated with the outgoing sequence flows from the gateway, routes are determinate. In case of multiple outgoing sequence flow, it is always a best practice to associate an order of their evaluation, as this will enable the fact that in case of multiple conditions getting evaluated as |
The decision mechanisms are categorized as follows:
Data: An example of data is conditional expression. The conditional expressions are evaluated at the gateway when the process token reaches the gateway. That path whose evaluation result is
trueis followed, and it can route to only one flowEvents (for example, the receipt of alternative messages): An event-based XOR gateway represents a divergence point where the alternatives paths are picked based on the event that occurs at that instance in the process flow. The event could be a receipt of message or a timer event. In an event-based gateway, it's the events that determine the path to be taken and not the conditional evaluations. The process becomes dynamic as process divergence is based on the external system's interaction with the process.
In order to evaluate the data-decision mechanism, refer to SalesQuoteProcess associated with the project (you have referred to it in the Working with sequence flow pattern section). Check the Approvals Outcome exclusive gateway, as shown in the following screenshot.
There are three outgoing sequence flows from the Approvals Outcome exclusive gateway. Two are conditional and one is default, as we discussed in The Sequence flow pattern section. Hence, these sequence flow conditions are based on the values of process data, the value of the data token itself, to determine which path should be taken. An order of evaluation is associated with the Approvals Outcome exclusive gateway, as this will enable the fact that in case of multiple conditions getting evaluated as true, the process token will route to the first sequence flow for which the evaluation is true. The following screenshot demonstrates this process:
Open the ExclusiveChoice&SimpleMerge process in JDeveloper 12c to evaluate the event-based gateway.
The use case illustrated in the preceding screenshot elucidates that quote processing can happen for both, New Quote Application and Existing Quote Application. In this case, use an event-based gateway, as there are multiple types of messages or events that can start a business process. The SalesReqApprovalTask human task is associated with the salesrep role, and we already assigned a user (salesrep) to this role. Hence, when the process executes the task, it will get assigned to the salesrep user, as shown in the following screenshot:
The following are the facts about the use case:
Quote Processing is an initiating type of event-based gateway. NewQuote Application and ReQuoteApplication will catch the event messages. SalesReqApprovalTask is a task to be performed by the sales representative.
QuoteApproval is the decision point based on process data which is the outcome of the user task (SalesReqApprovalTask) performed by the sales representative.
ReceivingQuoteSignedDocs is a non-initiating event-based gateway.
QuoteDocsReceived is a Message Catch Event, while the DocsNotReceived timer will move the token flow if documents are not received in
3days.OtherActivity is a drafted process that performs further quote processing. The correlation key is designed and associated with all the event messages (NewQuoteApplication, ReQuoteApplication, and QuoteDocsReceived). This is demonstrated in the following screenshot:
When the process initiates, it would either initiate for a new quote or an existing quote. If initiated for a new quote, it would be caught by the NewQuoteApplication event message. If initiated for an existing quote, it would be caught by the ReQuoteApplication event message, as shown in the following screenshot:
Test the process for the NewQuoteApplication event message by performing the following steps:
Open EM Console and click on the SalesQuoteProject project.
Execute ExclusiveChoiceSimpleMerge.service to execute the ExclusiveChoice&SimpleMerge process.
Select the NewQuoteApplication operation. As we can see in the preceding screenshot, ExclusiveChoiceSimpleMerge.service exposes multiple operations, which are essentially the event gateway's Message Catch Events.
Browse through the ExclusiveChoiceSimpleMerge.xml test data file in the project by navigating to SalesQuoteProject | SOA | testsuites.
Execute the process instance.
Log in to the BPMN workspace as a
salesrepuser and APPROVE the SalesReqApprovalTask task.
The Quote Processing event gateway initiates the sequence that has the NewQuoteApplication message event, and the instance reaches the SalesReqApprovalTask user task. Once the task is approved, we will find that the process halts at the ReceivingQuoteSignedDocs event gateway. The instance status will be running, and the token will stay there until a token arrives from any of the branches. Either the supporting document message will be received, or the waiting time will exceed three days.
Events receive communication, and hence, correlation needs to be defined to correlate them with the main process instance. A quote's opportunity ID is used as a correlation key. This correlation key is used in the intermediate events to correlate them with the existing process instance. With the correlation defined for the intermediate event gateway, the message will be correlated back to the original instance when it arrives at the QuoteDocsReceived event.
The message flow waits at the ReceivingQuoteSignedDocs event-based gateway, waiting for a token to arrive from any of its branches. In this case, the token can be a receipt of an event message or time. The first event triggers one of the alternatives that is an exclusion of any other path from the gateway. The event will basically pull the token from the gateway and continue to sequence flow that event.
We can use exclusive gateway to merge incoming sequence flows; however, there is no synchronization with other tokens that might be coming from other paths within the process flow. Simple merge combines several transitions back into a single activity. Tokens that merge at an exclusive gateway will be passed through as they are, and they would not be evaluated. Token merging at the exclusive gateway will not be synchronized. At the converging point, you would never have more than one token.
The following table illustrates the details of a simple merge pattern:
|
Signature |
Simple Merge Pattern |
|
Classification |
Basic Flow Control Pattern |
|
Intent |
Merging two or more paths. |
|
Motivation |
Fundamental constituent to enable simple merge. |
|
Applicability |
Combining several transitions back into a single activity. At converging point, you would never have more than one token. |
|
Implementation |
Widely adopted in most of the modeling languages using XOR-Join. |
|
Known issues |
Token merging at the exclusive gateway will not be synchronized. |
|
Known solution |
Multimerge. |
For example, we have an invoice payment, and there are different ways to pay the invoice, which include paying through credit card, bank transfer, or check. However, to make the payment, only one method will be used for an invoice, and once paid, the data need to be infused into Oracle E-Business Suite ERP. We would always use only one payment method. This is an ideal candidate for a simple merge using an exclusive gateway.