Understanding Event Based Gateways in Oracle BPM Suite 11g

In my previous blog post I had covered an example and use case to use Complex Gateways in Oracle BPM Suite 11g. Complex Gateways allows you to implement a special type of dead path elimination modelling and may be very useful in scenarios where it is required to synchronize N paths from M incoming transitions. The full post can be accessed at the link here : http://blog.rubiconred.com/2012/03/using-complex-gateways-in-oracle-bpm-11g.html

In this post, I will try to provide a pattern, example, use case and practical demonstration to use an Event Based Gateway, which is yet another important modelling concept in BPMN based process. Apart from the usual stuff I would also share a few interesting observations on Interrupting events that may be useful among other things.

Knowhows of an Event Based Gateway

Event based gateways are a special case of deferred choice pattern where the process chooses a specific sequence and branch depending on the interaction with an external environment thereby allowing for true dynamicity. This is different from the exclusive gateway in the sense that it allows a branching point where alternative paths are determined based on intermediate events coming from external systems. The message flow waits at the event based gateway waiting for a token to arrive from any of its branches. The token can be a receipt of an event message, a time cycle or a receive task. The first event triggers one of the alternative to the exclusion of any other path from the gateway. Essentially, the Event “pulls” the Token from the Gateway, where it will continue down the sequence flow that leaves the Event.

Introducing the Use Case

The use case explained here in this blog is that of a simple banking process to automate online opening of Bank Accounts. The process initiates with an application request being received from an Online Portal and verifying if a customer has already made an application earlier. If a similar request is already in process it is rejected and an appropriate notification is sent to the customer. Otherwise the process generates a provisional Account/Application Id and initiates a process to mail the account starter and contract kit to the address received from the customer. The customer is additionally sent an email with the necessary details and asking him to send back the proof of identity related documents and a signed copy of the contract within 7 days. This is where the process waits to receive documents from customer or remind him again after 7 days. The event based gateway branches into two sequence; 1) an intermediate event that receives an acknowledgement of customer documents being received and 2) a timer based event that waits for 7 days, sends a reminder email to the customer and loops back into the gateway.

Notice the illustration of the BPMN process for AccountOpeningProcess above has two event based gateways.

1. Process Online Application
2. Receive Supporting Documents

The Process Online Application gateway is a gateway of instantiating type meaning that it doesn’t need any incoming sequence flow. This kind of a gateway is useful if there are multiple types of messages or events that can start a business process. To demonstrate this use case follow the Event subprocess for cancelling in-flight applications. Whenever a cancellation event is received intermittently within a process an exclusive gateway decides whether a CustomerExperienceExecutive should make a personal call and deter the cancellation. If a resolution is reached i.e by means of changing the account type, account charges and privileges, the main process is re-initiated. Thus the process ends up having multiple start events, one that is for new applicants and one that is for re-applicants for whom the CheckCustomerSummary step may be skipped.

On the other hand the Receive Supporting Documents gateway is non-instantiating type and hence has both incoming and multiple mutually exclusive outgoing sequence flows. The event based gateway after the task indicates that the process actually waits for two different events that could happen next: Either the acknowledgement is received from the process handling document acknowledgements from the customer, as indicated with the Supporting Documents Received message event, or there is no acknowledgement for 7 days after which a reminder is sent to the customer.

It is important to know that Event based gateways with one outgoing Event/Receive Task and one timer event can be modelled in a different way as well, thereby completing the need to have a gateway at all. The timer boundary event can be used on the Receive task as shown under. But anyways the idea here is to show how event based gateways work in real life use cases.

 
Prerequisite(s)

The modelling workspace and the version of Oracle BPM Suite 11g used in this demonstration is 11gR1PS5 i.e 11.1.1.6.

Modelling the Process

Follow the BPMN model explained in the use case and recreate it in JDeveloper BPM Studio. Else the modelled process can be downloaded from the link here.

For the sake of reusability I created a reusable process to send email notifications that can be invoked from multiple places in the main process using a Call Activity.

A Call Activity identifies a point in the Process where a reusable global Process is used. The Call Activity acts as a wrapper for the invocation of the reusable process by transferring the control to the called reusable process. A Reusable Process on the other hand is a reusable, atomic process definition that can be called from within any Main Processes by a Call Activity. The reusable process in this example determines the content and subject of the customer notification by using a rule activity and sends an email notification accordingly.

Implementing the Process

Open the downloaded application workspace for the project or if you have created a one of your one, then double click on the Process Online Application event based gateway and in the Implementation tab check the Instantiate checkbox.

The first thing required is to add all the Request and Response types from the schemas in the xsd folder as business objects in the business catalog of the process. The two message events sequences for new applications and reapplications are based NewAccountRequest type and the Send Application Status end event is based on the AccountApprovalResponse type.

Take a close look at the three events intermediate events in the process:

1. Supporting Documents Received
2. Cancel Application
3. Reapply

All of these intermediate events receive some form of communication in the middle of the process and hence has to correlate with the actual instance of the main process. If a correlation is not defined then two things can happen. Either a mid-process receive will create its own instance or there will be an error in the process due to conflicting receive. Hence the message start events has to initiate a correlation and these intermediate events need to use them.

For the purpose of this example, the taxNumber of the applicant is used as the correlation key as it is assumed that this should be unique.

And similarly in the intermediate message receive events, the same correlation key needs to be used to relate the incoming request to existing instances. So when an external system sends the acknowledgement when supporting documents from the customer has been received the message is correlated back to the original instance.

The rest of the process is easy to implement. Activities that cannot be implemented may marked as draft and the exclusive gateways can have conditions that favour the happy path of the process. All the Call Activities invoke a reusable process that run a business rule to populate the Email subject and body and sends an email. Creating reusable processes is an attractive pattern and should be widely adopted as this allows to keep fragments of common functionalities globally that are accessible for multiple processes.  A sub-process or an event sub-process on the other hand may contain functionality that is common in a particular process and may be accessed from multiple process points.

The implemented process and the JDeveloper workspace can downloaded from here in case you want to spare yourself from the work and go straight to test and see results.
Testing the Process and Seeing Results
New Application Request

Deploy the implemented process to a BPM domain. The process has an event gateway of instantiation type that waits for either a new application request or a reapplication event message to arrive. A business process that has a message start event like this, has a service endpoint and can be invoked as a standard soap based service. Use any SOAP testing tool (SOAPUI for instance) to invoke the business process operation that accepts new account opening application request.

The Process Online Application event gateway initiates the sequence that has the New Application message event and the instance stalls at the Receive Supporting Documents event gateway. The instance status will be Running and the token will stay here until an acknowledgement is received from a support process or the waiting time exceeds seven days.

The process Flow trail gives another diagrammatic view of the sequence of activities executed for this instance.

Now for the sake of testing the intermediate event based gateway, the Supporting Documents Received message is sent to the process with the same taxNumber as the original request and the event will correlate it with the running instance.

Executing the above request will result in another instance ID being generated in the BPMN service engine but this instance correlates with the already in flight one. Since the documents are successfully received within the given time frame the token moves from the event based gateway to the Supporting Documents Received message event and consequently completing the instance.

Check out the flow view to see a graphical trail to see how the instance executes forward from the event based gateway and completes.

Cancel Application Leading to Reapplication

The above example show how an intermediate event based gateway behaves. Now let me demonstrate how an event based gateway of instantiation type works. For this example, I will again invoke the process with a new application request, but while the process is waiting to receive documents from the applicant, a Cancel Application event will be fired. This is picked up by the Cancellation Event Subprocess and correlated to the running instance. The subprocess evaluates the reason for cancellation and if required creates a task for a CustomerExperienceExecutive role to personally call the customer and seek a resolution. If a settlement is reached i.e by altering the account charges, privileges or type etc., the instance is sent back for reapplication. The Process Online Application at the beginning of the main process has a sequence flow that waits for this kind of event that picks up the message and continues the process flow, only this time there is no check performed to check client history.  The first step is to create a new request once more and then invoke the cancellationRequest operation.

In the Composite dashboard, there will be two instance of the process now, one that has completed (original) and one that is running (reapplication).

The first instance is marked as Completed as the Cancel Application Event is an intermediate event of Interrupting Type and hence when it reaches an End activity the actual instance itself is marked as completed.

The audit flow shown below gives a better picture of what happens to the instance in this case.

Now inspect the other instance that is marked as Running. This spawns from the Reapply intermediate event and this time the gateway branches to the sequence that has the Reapplication Event Message type.

The flow trace exactly reveals this behaviour where a new instance is created, only this time with a different message types and executes upto the next gateway.

I made some following interesting observations while implementing and verifying the test results for this process that I would like to share.

1. If the Cancel Application throw intermediate event in the Event Subprocess is of non-interrupting type and the end event is of Terminate type, the process behaviour should ideally be the same. But it is not. While a new instance spawns up correctly but the original instance is marked as faulted.
2. Since there is a process service call being made from the Reapply throw event that is caught by the Reapplication message catch event, it is not necessary to create a correlation between these events. If a correlation is not defined, the engine should mark the original instance as completed (as it flows to the End event) and create a new independent instance from the Process Online Application gateway. But there is a little deviation here. In this case both the instance states are marked as Completed in the dashboard view but when drilled down to the audit trail, the process instance is shown to be running and waiting at the Receive Supporting Documents gateway.

This article comes to a conclusion here and hopefully it was able to provide an insight into how Event based gateways can be used in Oracle BPM Suite 11g and also some thoughts on intermediate events. Event based gateways are extremely handy while designing loosely coupled business processes using a deferred choice pattern.

The JDeveloper workspace and sample requests to execute this Oracle JDeveloper/SOA Suite 11.1.1.6 is available to download from here.

Feel free to provide comments, suggestions and feedback for this post and we will be happy to do respond back.