Oracle BPM 12c Subprocesses (Part 3 of 3): Event Subprocess

In this third and last part of a three part series on subprocesses we will explore a special type of subprocess referred to as an “Event” subprocess.

This type of subprocess is triggered by an event that can occur anytime during the execution of a process flow that allows you to interrupt the normal flow of an instance.

Such capability can be applicable in various use cases. For example, an error might occur in the process, or you can very well define various service level agreements to delineate execution times or you can even have a business requirement to cancel a flow (for example cancel an order).

You can use the “Event” subprocess to implement such requirements (i.e. handle system and business exceptions).

“Event” subprocesses posses various unique characteristics. One of them is that, by configuration, you can have an “Event” subprocess either as interrupting, that is interrupting the normal process flow execution or have an “Event” subprocess running in parallel (concurrently) to the main flow of your process.

Another really nice and useful characteristics of an “Event” subprocess is that it shares the same context as the main flow of the process, meaning that from the “Event” subprocess you can have access to all the data objects that are used by the main process (and of course update their state).

An “Event” subprocess resembles like an embedded subprocess (except that it’s displayed in a dashed-line boarder), however an “Event” subprocess cannot have outgoing or incoming sequence flows. And just as with the other types of subprocesses an “Event” subprocess can define data objects that are local to its scope.

We will implement a very simple process that will make use of the event sub-process to simulate the functional use case depicted by the image above; the scenario is straightforward, you can cancel an order as long as it’s not shipped.

Create the basic BPM application and BPM project (I named it OracleBPM12cEventSubProcessDemoApp and OracleBPM12cEventSubProcessDemo respectively) and choose "Compsite with BPMN Process" in step 3 of the "Create BPM Application" and click “Finish”.

This will bring up the “BPMN 2.0 Process Wizard”. Give your process a name (for example “OrderProcess” and select the “Asynchronous Service” message pattern. In the second step of the wizard I will define a single input string argument that I will name “OrderId”. For the purpose of this demo I will not create any output arguments.

The first thing that I will do is to create a corresponding string process data object to pass the “OrderId” process input argument for reference throughout the process.

I will also create a Boolean process data object that I will use later to define whether an order cancellation can be performed or not.

Next assign the “OrderId” process input argument to the “orderId” process data objects and set the “orderCancellationAllowed” data object to true (since it’s the start of the process and a cancellation is allowed).

Drag and drop two interactive human task activities onto the sequence flow that connects the message start and message end components. In the first human task we will simulate the order submission while in the second human task we will simulate the dispatch of the order.

Notice how the human task activities are marked as incomplete. That’s because they haven’t been implemented yet. So let’s create a single human task definition to serve both interactive activities..

Double click on the “Place Order” human task and from the “Properties” window go to the “Implementation” tab and click on the green “Add” button to create a new definition. Specify a name, (for example DemoHT) and leave the rest on defaults.

Before closing the properties of the first human task activity make sure you specify a title it (just as you would like it to appear in the BPM Workspace task inbox; I named it “Place Order”).

Just to keep things simple I will make use of the same human task definition for the second interactive activity that I have in my process (don’t forget to define a title).

To simplify the assignment of tasks, open the human task definition file and in the task assignments switch from lane participants to "Names and Expressions" and define "weblogic" as the user to be assigned our order item tasks.

Next I will add a “Script” activity between the two human tasks to update the “orderCancellationAllowed” process data object and set it to false (since I don’t want an order to be cancelled once it has been placed.

Now it’s time to use the “Event” sub-process to allow but also control the cancellation of an order. Drag and drop an “Event” sub-process activity just below your order definition (in the same swimlane).

Interrupting event subprocesses can start with a message, timer, signal or error activity. The default start activity is a message that we will also use.

Also notice how the message start activity of the event sub-process is marked with a warning; that’s because it has no implementation defined. So double click on the message start activity, go to the “Implementation” tab and from the “Type” drop down select “Define Interface”.
Now here is the trick; the event sub-process will invoke a request for cancelling an order. However, we will need a way to associate the request for cancellation with the initiated order. To achieve such functionality we will use a custom correlation that needs to rely on a common identifier. This will be the order id. Therefore I will create an event sub-process “OrderId” string argument.

Click on the “Correlations” link to define our custom correlation and click on the “New Correlation Property” button. Define a name for the correlation property and ensure “STRING” is selected as the correlation property type.

Using the expression builder map the “OrderId” event sub-process argument to the correlation property you just created and click “OK” to dismiss the “Correlation Definition” window.

The “Start” properties window should still be open. Please notice, just below the “Implementation Type”, the two options for configuring your event sub-process; “Interrupting Event” to basically forcibly stop the execution of your process flow and “Suspending Event” (with the options pause and resume the process flow). Ensure you selected “Suspending Event”.

There is one thing left to enable our custom correlation to work and that is to define the same correlation logic to the message start component of the main process. Since this will be the “parent” process you need to make sure you select the “Initiates” checkbox.

We have configured the event sub-process to be a suspending sub-process, meaning that it will pause the normal execution of the parent process flow. This option has a really nice feature that you can instruct the BPMN engine to resume the execution of the parent flow based on specific conditions (in our case this will be the “orderCancellationAllowed” data object.

Therefore drag and drop an exclusive gateway inside the event sub-process on the default sequence that connects the event sub-process start and end components (named it “Order Cancellation Allowed?”).

To define the resume functionality described above we will need to use a “Script” activity and use the “action” predefined variable and assign it the value “resume” (using “Data Associations”).

 Add a conditional sequence flow from the exclusive gateway to the script task and a default sequence flow from the script task to the end component.

In the properties of the conditional sequence flow define a condition that should enable that branch of the exclusive gateway only if the “orderCancellationAllowed” data object value is false (hint: you will have to negate the data object value using the “not” logical operator).

Your process should look like below.

We are finally ready to deploy and test our process (and event sub-process). From the EM (Enterprise Manager) invoke a new instance of your process (ensure you are using the “start” operation which maps to the message start event of the core process).

Go to the BPM Workspace and you should see a task in the weblogic user’s inbox.

Without submitting the task, go back to the Enterprise Manager console and invoke a cancellation request. Make sure that you use the same order id as you used for initiating your previous order request instance (because we are correlating requests from the event sub-process to the main process via the order id).

Go to the BPM Workspace and refresh your inbox. The previously task should be removed.

Initiate a new order request but this time submit the “Place Order” task. You should get another task in your inbox (“Ship Order”). Go back to the Enterprise Manager console and invoke a cancellation request (for the same order id). If you go to the BPM Workspace you should notice that the “Ship Order” task is still in your inbox. That’s because the main process has passed the acceptable cancellation threshold that we’ve defined.

Download sample application: Event Subprocess