Antonis Antoniou's Blog: Oracle BPM 12c Gateways (Part 5 of 5): Event-based Gateway

My last article on gateways is on the event-based gateway, another type of gateway supported by Oracle BPM 12c to provide divergence in processes.

The event-based gateway is very similar, conceptual wise, to the exclusive gateway in the sense that we can have various outgoing sequence flows but only one branch is followed. The operational difference though is that, as its name suggests, the event-based gateway uses events for defining the branching conditions and decisions rather than data-specific conditions.

An event-based gateway can consist of multiple events; however the first event that occurs will determine the execution path that will be followed.

Using the order process as an example, once an order is received and validated it needs to be processed. Assuming that we have multiple warehouses, the order will be processed by the warehouse that can process all inventory items ordered and responds first. The process will wait until one of the warehouses responds to the request for processing the order. However, the process cannot wait indefinitely.

So let's see how we can implement the above scenario using the event-based gateway.

Let's start with creating the basic BPM application and BPM project (named both application and project "EventBasedGatewayDemo") and selecting "Composite with BPMN Process" in step 3.

This will bring up the "BPMN 2.0 Process Wizard" where you are prompted to specify a process name and the service type. Give your process a name, for example OrderProcess and select "Asynchronous Service" as the service type.

In step 3 of the BPMN 2.0 Process Wizard you are prompted to specify the input and output process arguments. A typical order definition would consist of an order id, a collection of order items, the order total, customer details and bill and ship address details. For simplicity reasons my demo process will only consist of the order id (of type int) and the order total (of type decimal) as input arguments and a status argument of type string as output.

The event-based gateway is composed of the event-based split gateway and two or more target events. These events can be either message catch events, timer catch events or receive tasks. Please note that you cannot mix message catch events and receive tasks within the same event-based gateway.

Select and drop the "Event Based" gateway on the default sequence flow between the "Start" and "End" activities. You should notice that JDeveloper automatically has added three activities; an event based split gateway activity, a catch message activity and a timer catch activity.

There is an error on the Timer activity because it doesn't have an outgoing default sequence flow. Give the event based gateway split activity and the catch message activity some meaningful names and add a new catch message activity just below the default created catch message activity and define default sequence flows for all activities.

Next set the timer activity to wait for 30 seconds for a reply from the warehouses and define an implementation on the two catch message activities. Again for simplicity and demo reasons I have used the "Define Interface" message exchange type and created only a single argument, order id of type int. The implementation of both catch message activities are exactly the same, the only difference is the operation name.

So we have a process that expects some events to arrive from the two warehouses while its being executed. This means that the main process, which in our case its the order process needs to find a way to correlate these intermediate events with the itself. To do that we need to create a correlation property (an attribute to correlate the main process with the intermediate events) and a correlation key (which defines the properties to use in the correlation which consists of one or more correlation properties).

I will use the order id to correlate the events that will be flowing from the warehouses into the main order process, therefore I have created a correlation property named "orderId" and of type int and a correlation key named "ck_orderId" with the orderId correlation property selected.

We now need to instruct the process and intermediary events to use the orderId correlation property we created. The main process will be responsible for initiating the correlation and matching events that will be coming in from the warehouses with the main process. Therefore on the message start activity select under "Implementation" select "Correlations" and select the orderId correlation property and map it to the orderId process input argument. Ensure that you have selected the "Initiates" option to instruct the process to correlate an instance of the order process with the supplied order id.

The same correlation definitions need to be applied on the two catch message activities. Please ensure that the "Initiates" option is not selected since this will be done upon the instantiation of the process.

Deploy your process and run a test instance using the "start" operation. If you inspect the audit trail you should see that the instance is waiting at the event-based split gateway activity.

Run a new test instance of your order process but this time use one of the warehouse operations (for example, use the "warehouseB" operation). If you inspect the audit trail you should notice that the order is now completed and that the process followed the second branch.