Oracle BPM Suite 12c Modeling Patterns

4.5 (2 reviews total)
By Vivek Acharya
    What do you get with a Packt Subscription?

  • Instant access to this title and 7,500+ eBooks & Videos
  • Constantly updated with 100+ new titles each month
  • Breadth and depth in over 1,000+ technologies
  1. Free Chapter
    Flow Control Patterns
About this book

This book gives you an exemplary and comprehensive exposure to Oracle BPM modeling and implementation patterns. During the journey, it will walk you through various BPM patterns based on real-life examples. It offers projects to download with each chapter, which allows you to design, model, and analyze the patterns discussed in each chapter, providing you with an interactive way to learn and implement BPM patterns.

With this title in hand, you will gain practical experience in using Oracle BPM effectively, while using the most useful modeling patterns for your implementations. The book also covers topics that demonstrate different BPM patterns including flow control and advance patterns, invocation and interaction patterns, correlation and integration patterns, human interaction, collaboration patterns, and case management patterns. The book also provides an insight on patterns for strategic alignment, business-IT collaboration, sharing of processes and architecture assets, and infusing business context.

Publication date:
September 2014
Publisher
Packt
Pages
454
ISBN
9781849689021

 

Chapter 1. Flow Control Patterns

A pattern is a generic solution to a recurring problem. Patterns describe a problem and its solution, which can be adopted in discrete situations. Patterns are adorned best practices that deliver a reusable architecture outline. Business Process Management (BPM) is widely adopted for process transparency, process intelligence, business empowerment, and business alignment. While designing business processes, we are not just automating and managing processes; it's more about how an enterprise adapts to a comprehensive view of business processes.

This chapter offers an exemplary and comprehensive exposure to flow control patterns, which are helpful in the modeling and implementation of Oracle BPM 12c solutions. During the journey, it will walk you through various BPM patterns based on real-life examples. The book offers projects to download with each chapter; these projects allow you to design, model, and analyze the patterns discussed in each chapter. Hence, it offers an interactive way to learn and implement BPM patterns. It allows you to fill the gaps and offers content that allows you to use BPMN to its full potential.

Process analysts, architects, and process developers deal with process modeling, define and design process models, and implement them. While performing process modeling and implementing them, they constantly deal with varied common challenges. Process modeling and BPM patterns offer techniques to solve repeatable issues, enhance the process-modeling approach, improve process modeling and implementation quality, and offer great productivity.

This chapter covers the basic and advanced flow control patterns in Oracle BPM. Perceptible regularity in the world of process control flow is demonstrated here. During the course of modeling from the "As-Is" to "To-Be" process, a process analyst models, designs, drafts, and publishes a sequence of activities and their flow control. This chapter starts off the book by showcasing the essentials of flow control patterns. Flow control patterns capture the various ways in which activities are represented and controlled in workflows. Implementing these patterns gives Oracle BPM the capability to handle the widest range of possible scenarios to model and execute processes.

This chapter will focus on the flow control patterns in the following points:

  • Sequence flow pattern

  • Exclusive choice and simple merge pattern

  • Multichoice and synchronizing merge pattern

  • Structured synchronizing merge pattern

    • Local synchronizing merge pattern

  • Parallel split and synchronization pattern

  • Conditional parallel split and parallel merge pattern

  • Multimerge pattern

  • Discriminator and partial join pattern

    • Structured discriminator pattern

    • Structured partial join pattern

  • Complex synchronization pattern

    • Canceling discriminator pattern

    • Canceling partial join pattern

 

Sequence flow pattern


One of the fundamental steps in the BPM process modeling is to build a process model (diagram) which enables a shared understanding between participants on a process flow pattern. The process participants are not going to discuss each and every page of the document, neither will a collaborative, iterative process improvement or approach succeed with a group of people sitting and walking through documents. However, this group will be interested in a process model (diagram) and discuss the flow, sequence, and process patterns visible through the process model. This makes sequence flow patterns of paramount importance, as each and every activity is related to the other. In a process diagram, this relationship is created and managed through sequence flows. The following table summarizes the details of the sequence flow pattern:

Signature

Sequence Flow Pattern

Classification

Basic Flow Control Pattern

Intent

Offers sequence routing.

Motivation

The fundamental constituent to weave process components and demonstrate dependency and state transition between tasks/activities.

Applicability

The sequence pattern enforces a transitive temporal ordering to process activities. In business terms, sequences denote a strong dependency between activities and cater to strictly separating process involvement at organizational boundaries. They define the behavior of a business process.

Implementation

Widely adopted in most of the modeling languages including Oracle BPMN.

Known issues

Difference in acceptance.

Known solution

Usage of tokens in process instances.

The sequence is the simplest pattern and is implemented through a graphical sequence of actions, as graphical form is used for the sequencing of patterns. In BPMN, the model elements that are to be executed in sequence are connected with sequence flow connectors. When activities are connected with sequence flow connectors, processing of the second activity will not commence before the first activity is completed. This pattern defines the dependency of one task on the other and governs the fact that execution of one task is dependent on the other and cannot be completed until that task gets completed. Ordering of tasks in a business process is determined by sequence flow, and it governs how the process token will flow through the process. With sequence pattern, you can create a series of consecutive tasks, which are executed one after another based on the sequence connector's connections.

Categories: The sequence flow can be categorized as follows:

  • Incoming sequence flow: This refers to flow that leads into a flow object

  • Outgoing sequence flow: This refers to flow that leads out of a flow object

Some activities/flow objects can have both the sequence flows, and most of the activities/objects in a process have them. However, the start object can only contain an outgoing sequence flow and the end object can only contain an incoming sequence flow.

There are different types of sequence flows which are as follows:

  • Default sequence flow/unconditional sequence flow

  • Conditional sequence flow

Working with the sequence flow pattern

Perform the following steps to check the sequence flow usage in action:

  1. Download the application (SalesQuoteDemo) contained in the download link of this chapter.

  2. Open SalesQuoteProject in JDeveloper 12c.

  3. Open SalesQuoteProcess; this will open the process flow in the design area.

  4. Go to Approvers Swim lane and click on Exclusive Gateway (ApprovalsOutcome) that works on the ApproveDeals and ApproveTerms outcomes. The process is shown in the following screenshot:

  5. Click on the outgoing sequence flow with the Approve tag. In the properties, you will find that the type of sequence flow is Unconditional. This is the default sequence flow from the Exclusive Gateway.

  6. Now, click on the sequence flow with the Deal or Terms Reject tag and check its properties.

  7. The sequence flow type is Condition, and it has a conditional expression build. When this conditional expression returns true, the process token will take this sequence flow path. This is shown in the following screenshot:

  8. Click on the sequence flow with the OnlyDealsApproved tag and check its properties. This sequence flow is also a conditional flow with the following expression:

    DealapproverAppr ovalStatus == "APPROVE" and termsapproverApprovalStatus == "REJECT"

Tip

Downloading the example code

You can download the example code files for all Packt books you have purchased from your account at http://www.packtpub.com. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.

Elucidating the sequence flow pattern

The conditional sequence flow governs the token movement based on conditions associated with the sequence flows, where conditions are expressed using the x-path expressions. A path that is taken out of the gateways when none of the conditions specified on the conditional flow is evaluated. This is termed as default sequence flow, and it's drawn as an arrow line with a tick mark at one end.

Upon the arrival of token at the gateways, conditions associated with the drawn sequence flows are evaluated, and that sequence route is picked whose conditional evaluation returns true. Then, the token starts trailing this path. However, if none of the evaluations of the conditional flow returns true, then the default route is picked.

Note

Conditional sequence flows can be associated with exclusive and inclusive gateways for split.

 

Getting ready for executing use cases


This section talks about the steps that we will perform to get ready to execute the use cases demonstrated in this chapter. As we check SalesQuoteProcess, there are various human tasks. The following is the list of roles associated with the human task and users associated with the role:

Task

Role

User

Accept Quote

Salesrep

salesrep

Business Review

Business practice

fkafka

Approvers

Approvers

jcooper

Contracts

Contracts

jstein

We have to perform the following steps to execute the processes that have human task:

  1. Log in to the WebLogic console and navigate to myrealm (embedded LDAP).

  2. Click on the User and Group tab.

  3. Verify that we have the aforementioned listed users in myrealm. If not, we can create users (salesrep, fkafka, jcooper, and jstein) in myrealm.

    Note

    If we execute demo community that is installed while configuring Oracle BPM 12c, we will get users (fkafka, jcooper, and jstein). However, we can follow the preceding steps and create a user (salesrep).

  4. Open JDeveloper and navigate to Organization in SalesQuoteProject.

  5. Click on Roles and associate users to roles as listed in the preceding table. Save the changes.

Human tasks are executed with respect to organization units. Hence, we will create an organization unit and associate the users to it. We will also make sure that the organization unit is passed to the process when the process executes. Execute the following steps:

  1. Log in to the Oracle BPM workspace as an admin user (weblogic).

  2. Navigate to Administration | Organization | Organization Units.

  3. Click on the + icon to create a root organization.

  4. Enter the name of the organization as SalesOrg.

  5. In the Members section, add the users we listed in the preceding table. To add users, we can browse the myrealm LDAP.

  6. When users are added, we can save the changes. This process is shown in the following screenshot:

  7. Go back to JDeveloper and open SalesQuoteProcess.

  8. Click on the Message Start Event (Start) and open its properties.

  9. Go to the Implementation tab and open data association.

  10. On the right-hand side of data association, scroll to the predefined variable (Organization Unit).

  11. Assign the newly created organization units, SalesOrg, to the predefined variable (Organization Units) and save the project. This is demonstrated in the following screenshot:

 

Exclusive choice and simple merge pattern


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 true, the process token will route to the first sequence flow for which the evaluation is true.

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 true is followed, and it can route to only one flow

  • Events (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.

Working with exclusive choice and simple merge pattern

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 3 days.

  • 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:

  1. Open EM Console and click on the SalesQuoteProject project.

  2. Execute ExclusiveChoiceSimpleMerge.service to execute the ExclusiveChoice&SimpleMerge process.

  3. 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.

  4. Browse through the ExclusiveChoiceSimpleMerge.xml test data file in the project by navigating to SalesQuoteProject | SOA | testsuites.

  5. Execute the process instance.

  6. Log in to the BPMN workspace as a salesrep user 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.

Knowing about the exclusive choice pattern

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.

Elucidating the simple merge pattern

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.

 

Multichoice and synchronizing merge pattern


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 true, otherwise, a default sequence flow is picked. The solution is the default path.

Demonstrating multichoice and synchronization with the OR gateway

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:

  1. Test the process from EM or use SOAPUI.

  2. Enter the QuoteRequest elements and submit QuoteRequest. We can use the test data (SalesQuoteSimpleMerge.xml) available in the testsuites folder in the project.

  3. We will notice that the process token is waiting at SalesQuoteApprovalTask to be acted upon by the salesrep user.

  4. Log in to the BPM workspace at http://<server>:<port>/bpm/workspace as a salesrep user 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 working of multichoice and synchronization pattern

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.

Structured synchronizing merge pattern

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:

  1. Log in to the Oracle BPM workspace as a salesrep user and approve SalesReqApprovalTask. As per the process design, the Legal and Terms tasks will also gets assigned to the salesrep user.

  2. Being logged in as the salesrep user, approve the LegalApproval task.

  3. 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).

Local synchronizing merge pattern

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.

 

The parallel split and synchronization pattern


The parallel gateways are points in the process where multiple parallel paths are defined and they are also used to synchronize (wait for) parallel paths.

Parallel gateways represent concurrent tasks in business flows, and a fork gateway is always accompanied by a join gateway, where a fork gateway illustrates concurrent flows and expresses the fact that all outgoing paths must be pursued. On the other hand, a join synchronization gateway mandates that all the concurrent paths must be completed ahead of process advancement to subsequent tasks/activities.

A fork divides a path into two or more parallel paths and this is known as an AND split. It's the point in the process flow where activities can be performed concurrently rather than sequentially. In an OR gateway, one or another path is taken; however, in an AND gateway, a single thread of execution will be split into two or more branches that can execute tasks concurrently. For example, once an employee's on-boarding process has started, then enter the employee's information in the ERP system and also start the process for the provision of e-mail IDs, stationary, desk allocation, and so on in parallel.

Parallel split pattern

The following table shows the details of the parallel split pattern:

Signature

Parallel Split Pattern

Classification

Basic Flow Control Pattern

Intent

Breaks the flow into one of the two or more paths that execute concurrently.

Motivation

Fundamental constituent to the concurrent execution of two or more paths.

Applicability

Decision point in the business process where all the outgoing paths must be pursued.

Implementation

Widely adopted in most of the modeling languages using the AND split. When many activities have to be carried out at the same time and in any order, AND splits (parallel split) can be used to fork the concurrent flow where two or more concurrent threads independently process the activities (gateways, events, and so on) that reside on the corresponding control flow branches.

Known issues

NA

Known solution

NA

Synchronization pattern

The following table shows the details of the synchronization pattern:

Signature

Synchronization Pattern

Classification

Basic Flow Control Pattern

Intent

Synchronize paths that exit a parallel split.

Motivation

To synchronize the flow from multiple parallel branches. Parallel join merge exactly one thread from each incoming branch into a single thread on the outgoing branch by converging the threads of all the parallel branches.

Applicability

Merge point to synchronize the parallel paths. The AND join to be symmetrically paired up with a corresponding upstream AND split.

Implementation

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

Accepts multiple incoming sequence flow and blocks the sequence until all activities within the flows are completed; then, the flow continues. Till 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.

Known issues

Nonavailability of a token at the AND join that got created from the AND split.

Known solution

The solution lies in how meticulously the process is modeled, and it's anticipated that the issue will not arise in a structured context.

Note

Design consideration by modelers is taken into account if you really need parallel processing, that is, whether, in reality, the distinct branches are executed in parallel.

Navigate to SalesQuoteDemo | SalesQuoteProject | ParallelSplitSynchronization process. When the sales quote is initiated, it halts for quote acceptance by the salesrep user at the ApproveQuote user task. Once it is approved, it's reviewed by business practice, and on approval from the fkafka user, the token reaches the parallel gateway, which is the divergent fork point. Both DealsApproval and TermsApproval need to be performed in parallel, and hence, the choice was a parallel gateway to diverge the flow. This is discussed in the following bullet points:

  1. Click on Organization Unit in the project to verify the user assignment to the roles. We will make sure that the user assignment to roles should happen based on following table:

    Task

    Role

    User

    Accept Quote

    Salesrep

    salesrep

    Business Review

    Business practice

    fkafka

    Approvers

    Approvers

    jcooper

    Contracts

    Contracts

    jstein

  2. If not already deployed, deploy SalesQuoteProject.

  3. Log in to EM console or use any tool of choice to execute the ParallelSplitSynchronization process using the ParallelSplitSynchronization.xml test data available in the testsuites folder in the project.

  4. Log in to the Oracle BPM workspace as the salesrep user and approve the AcceptQuote task.

  5. Log in to the Oracle BPM workspace as the fkafka user and approve the Business Practice Review task.

  6. Token has now reached the ApproveDeal and ApproveTerms task.

  7. Log in to EM console and check the Audit Trail of the process.

We can find that a group of threads is created for each sequence flow from the parallel gateway that forks/diverges the path. This is shown in the following screenshot:

Check the process flow using the graphical view of the process in the process audit trail, as shown in the preceding screenshot. We can analyze that both the paths are processed in parallel. Execute the following steps:

  1. Log in to the BPM workspace as a jcooper user and approve the ApproveDeal task. We can notice that at the convergence point, that is, at the join (merge parallel gateway), tokens will be synchronized. Hence, the process waits for the other token to reach the convergence point, which is the AND join parallel gateway.

  2. Click on the process audit trail in EM for the process. We can witness that Approve Deal thread is completed, while the other thread for the Approve Terms is still processing.

  3. Log in to the BPM workspace as a jstein user and approve the Approve Terms task.

  4. Once both the tokens arrive at the AND join (Deals&TermsApproval_Merge) the tokens are synchronized, and one token is passed out of the merge gateway's outgoing flow.

 

Conditional parallel split and parallel merge pattern


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.

Working with conditional parallel split and merge

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).

  1. Open EM console and test the ConditionalParallelSplit&Merge process using the ConditionalParallelSplit&Merge.xml test data available in the testsuites folder in the project.

  2. The test data contains the following data:

    Effective discount: 9

    Quote request status: Old

    Rest all fields can be user choice

  3. Log in to the Oracle BPM workspace as a salesrep user and approve the AcceptQuote task.

  4. Log in again to the BPM workspace as a fkafka user to approve the BusinessReview task.

  5. 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:

  6. 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.

  7. Log in to the Oracle BPM workspace as a jstein user 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.

Antipattern – the conditional parallel split and merge

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 salesrep user and then as the fkafka user to approve the AcceptQuote and BusinessReview tasks.

  • Log in to the BPM workspace as the jstein user. 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:

 

Multimerge pattern


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.

Exploring multimerge

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.

 

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.

 

Complex synchronization pattern


The complex gateway can also be used for complex synchronization. Complex gateway gets activated when the conditional expression is evaluated as true. Once the complex gateway gets activated, it would create a token on the output sequence flow.

If Abort pending flows is checked on the complex gateway properties, then complex gateway will abort all the pending flows and the remaining tokens will be suppressed. They will not be able to trigger any subsequent branch, as shown in the following screenshot:

The suppression of tokens is translated to various patterns, which are shown as follows:

  • Canceling discriminator pattern

  • Canceling partial join pattern

Canceling discriminator pattern

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

Signature

Canceling 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. It can also cancel the execution of all other remaining branches

Motivation

When the first branch gets completed, the subsequent branch will trigger. However, the remaining incoming branches will not be triggered as they would be cancelled.

Applicability

1-out-of-M joins with a flag being set, is to set to abort the remaining flow pattern.

Implementation

Widely adopted in most of the modeling languages using the complex join. On the complex gateway, Abort Pending Flows must be checked, and the completion condition testing for the number of active instances should be equal to 1. When this complex gateway gets triggered, it would cancel the execution of all of the other incoming branches and reset the construct.

Known issues

NA

Known solution

NA

Canceling partial join pattern

The following table shows the details of the Canceling 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". However, once the join is triggered, it would also lead to cancelling the execution of all the remaining incoming paths and reset the convergence point.

Motivation

The convergence point will trigger synchronization and produce a single token for the outgoing edge, only when a defined threshold is reached. In case of N out of M join, N is defined as the trigger for the convergence point (the complex join gateway). Once the trigger is fired and a single token is produced for the outgoing edge, then the remaining incoming paths will be cancelled.

The convergence point will reset only when all the active incoming branches will be enabled.

Applicability

N-out-of-M joins and a flag being set to Abort Remaining Flows.

Implementation

Widely adopted in most of the modeling languages using the complex join. On the complex gateway, Abort Pending Flows must be checked.

Known issues

Determination of cancel region.

Known solution

Structured processes.

 

Summary


This chapter offered a comprehensive knowledge of the flow control patterns by showcasing the essentials of flow control patterns, which are used in designing and modeling business processes. Recipes can be served as reference to control flow patterns in BPM and are explained with simple sample processes and examples. The next chapter will demonstrate how processes can handle batch jobs and how to simultaneously spawn multiple work item instances in a process. The chapter will also uncover iteration patterns by demonstrating structured loop and unstructured looping mechanisms. Implicit and explicit termination patterns in the end will showcase the termination pattern.

About the Author
  • Vivek Acharya

    Vivek Acharya is an IT professional and has been in the world of design, consulting, and architecture for approximately 12 years. He is a certified expert on blockchain, Hyperledger Fabric, Software as a service (SaaS), and analytics. He loves all things associated with the cloud, permissioned decentralized autonomous organization (pDAO), blockchain, predictive analytics, and social business process management (BPM).

    Browse publications by this author
Latest Reviews (2 reviews total)
Muito bom. Muito bom. Muito bom.
Oracle BPM Suite 12c Modeling Patterns
Unlock this book and the full library FREE for 7 days
Start now