Book Image

Oracle BPM Suite 12c Modeling Patterns

By : Vivek Acharya
Book Image

Oracle BPM Suite 12c Modeling Patterns

By: Vivek Acharya

Overview of this book

Table of Contents (19 chapters)
Oracle BPM Suite 12c Modeling Patterns
Credits
Disclaimer
About the Author
Acknowledgments
About the Reviewers
www.PacktPub.com
Preface
Index

Discriminator and partial join pattern


This section will cover the advance flow control patterns such as structured discriminator pattern and structured partial join pattern. The scenario for this section is about employee request for resources such as machine, e-mail ID, batch ID, and so on at the time of on-boarding. These resources will be credited to the employee only when their request for the resource gets approved by their manager. Another scenario is as per the following process screenshot. If the credit check fails, then there is no need to perform inventory check and order review. This is shown in the following screenshot:

To achieve this, you need a mechanism to set a trigger or an indicator in the converging point. When conditions related to the indicator meet, the synchronize activity in the process instance will be immediately released, and the BPM engine will automatically remove the instances struck in Check Inventory and Review Order. Then, the process instance converges at the convergence point and continues on through the rest of the process.

Structured discriminator pattern

The structured discriminator describes a convergence point in the business process that waits for one of the incoming branches to complete before activating the subsequent activity. All other incoming branches will be omitted after they are completed. Until all the incoming branches are complete, the discriminator is not reset. Once all the incoming branches are completed, the discriminator is reset. Structured discriminator construct resets when all incoming branches have been enabled. Upon completion, the first branch out of the given number of branches triggers a downstream activity. A token will be generated for all other branches. However, all the remaining tokens that were generated from the parallel split will eventually arrive at the discriminator, but they will be blocked and hence, will also not be able to trigger the subsequent branch.

The following table shows the details of the structured discriminator pattern:

Signature

Structured Discriminator Pattern

Classification

Advance Flow Control Pattern

Intent

A convergence point in the business process that awaits one of the incoming branches to complete before activating the subsequent activity.

Motivation

When the first branches gets completed, the subsequent branch gets triggered, but completions of other incoming branches thereafter have no effect on the subsequent branch.

Applicability

One out of M joins. It's a special case of M out of N Join, that is, structured partial join.

Implementation

Widely adopted in most of the modeling languages using the complex join.

Structured discriminator occurs in a structured context, that is, there must be a single parallel split construct earlier in the process model with which the structured discriminator is associated, and it must merge all of the branches that emanate from the structured discriminator.

Known issues

Nonreceipt of input on each of the incoming branches means there might be cases when some of the incoming branches might not have input.

Known solution

Canceling the discriminator pattern will look for the first token to be received at the incoming branch, and upon the receipt of the first token at the incoming branch, all other branches will be skipped. The branches that are not yet commenced will be aborted, and the discriminator will get restarted.

Structured partial join

The structured partial join is an "N out of M Join" pattern. In this pattern, an AND split (parallel gateway) or a multichoice (inclusive gateway) pattern produces a number of tokens on parallel branches (known as runtime). From the total number of "m" tokens, a subset "n" token will trigger synchronization and produce a single token for the outgoing edge. The remaining (m-n) tokens are suppressed, and they would not be able to trigger any subsequent branch. The following table shows the details of the structured partial join pattern:

Signature

Partial Join Pattern

Classification

Advance Flow Control Pattern

Intent

A convergence point in the business process of "m" branches into one subsequent branch only when "n" incoming branches are enabled, where "n" will be less than "m".

Motivation

The convergence point will trigger synchronization and produces a single token for the outgoing edge, only when a defined threshold is reached. In case of N out of M joins, N is defined as the trigger for the convergence point (complex join gateway). Once the trigger is fired and a single token is produced for the outgoing edge, then completion of the remaining incoming paths will not have any impact and they will not trigger any subsequent path.

Convergence point will reset only when all the active incoming branches are enabled.

Applicability

For "N" out of "M" joins, the convergence point will trigger synchronization when the defined threshold "N" is reached.

Implementation

Widely adopted in most of the modeling languages using the complex join.

Join should happen in a structured fashion, means at the convergence point. The complex join gateway must be associated with either a single parallel AND split gateway or a multichoice inclusive gateway. Once the partial number of paths is active, subsequent paths can be followed. Hence, there will be no requirement to wait for other incoming paths to complete

Known issues

NA

Known solution

NA

Working with a complex gateway to implement the discriminator and partial join pattern

Oracle BPM offers a complex gateway to implement the structured discriminator and structured partial join pattern. Parallel split is performed by a parallel gateway named Approvals, shown in the following screenshot. Synchronization will be performed at the ApprovalsMerge complex gateway. Perform the following steps to test the scenario:

  1. Download SalesQuoteProject from the download link for this chapter and open the PartialJoin process.

  2. To implement the "N out of M join" pattern, click on the ApprovalsMerge complex gateway and check its properties.

  3. In the properties, we can witness that Abort Pending Flow is unchecked, and the following expression is included in the complex gateway's properties. This is shown in the following code:

    "bpmn:getDataObject('quoteDO')/ns:Summary/ns:AccountName  = "FusionNX" and bpmn:getGatewayInstanceAttribute('activationCount') >= 1"

Note

Activation count is a predefined variable and keeps track of the active tokens at the complex gateway.

Expressions at the complex gateway translate to the fact that if the activation count of tokens at the merge gateway is 1 or greater than 1 and if the account name is FusionNX, the gateway exit expression will evaluate as true.

Hence, while testing this process, if the account name supplied with quote request data is FusionNX and the count of active tokens at the complex gateway is equal to or greater than 1, then the synchronization activity in the process instance will be immediately released and the process token will continue ahead.

Testing a process by failing the complex gateway exit expression

Execute the following steps:

  1. Test the PartialJoin process using the PartialJoin.xml test data available in the testsuites folder in the project.

  2. The PartialJoin.xml test data that is provided contains the value for the account name HP. This will never fulfill the condition at the complex gateway.

  3. Check the process audit trail to deep drive in the behavior by looking into the ApprovalsMerge complex gateway.

  4. When the token arrives at the same activity block, the merge gateway will be evaluated. However, the condition (the account name FusionNX) will fail, and the flow will not move forward.

  5. Log in to the BPM workspace as a jcooper user and jstein user one after the other to approve the DealsApproval and TermsApproval tasks.

  6. The TermsApproval and DealsApproval sequence flows will also fail. As no gateway exit expression will get evaluated successfully, the entire token will be suppressed and the process gets completed.

Testing process as success by the complex gateway exit expression

Perform the following steps to test the partial join process for a success gateway condition:

  1. Test the process again using the PartialJoin.xml test data. However, this time, change the account name and pass Account Name: FusionNX.

  2. Check Audit Trail for the process in EM.

  3. You can find that the process moves ahead of the merge gateway just after receiving the token from the first sequence flow. The gateway exit expression will evaluate as Success in the first case itself.

As we passed the account name as FusionNX and the activation count for the ApprovalsMerge complex gateway reaches 1, the gateway exit expression will evaluate as true and the process token moves ahead, as shown in the following screenshot:

We just tested the "N out of M Join" pattern. You can use the same project and refractor the complex gateway that is merging the parallel split branches and set the activation count as 1. The AND split (parallel gateway) which is the ApprovalsSplit gateway, will produce the number of tokens on parallel branches (known as runtime). There are exit conditions defined at the complex gateway, which is the merging point. The process will move ahead to subsequent branches once the gateway exit expressions are evaluated to Success. This means that the desired number of activation tokens is reached and all the other logical conditions expressed in the expression are fulfilled.