This article is a look at Oracle’s BPEL Sensor approach to publishing real time data and events for in flight BPEL Processes.
Oracle BPEL has tried to fill a gap in the BPEL Spec using sensors. Specifically, sensors allow users to overlay listeners on BPEL tasks and process variables that will generate events out of a process that is being executed. This is definitely a step in the right direction, and does a good job of staying true to the BPEL specification. This document will define what sensors are, how they should be designed into BPEL Processes, and a future outlook of event models.
Oracle BPEL Sensors
- Send real-time business process information to downstream systems such as Business Activity Monitoring, reporting systems, or even just a message queue or Enterprise Service Bus
- Are graphically represented as part of the business process to visually indicate when and where events will be automatically triggered during process execution
- Allow events to be triggered based on changes in process meta data that would be complex and sometimes impossible to place as tasks within a BPEL Flow
JDeveloper currently makes sensors look like an overlay on top of a BPEL Flow. Instead of thinking of a sensor as something added as an overlay to the tasks and variables within a flow, to a BPEL Architect it should be thought of as listeners that are deployed with a flow that will trigger events as the flow is executed. They exist in separate XML files outside of the BPEL, and are interpreted at runtime by the BPEL Engine. Even though the default behavior is to write these sensors to a table, I would strongly encourage that they be written to message queues or directly to BAM and thought of as published events.
Incorporating Sensors into BPEL Flow Design
There are tasks within BPEL flows that let you publish events to a database. Any tasks that require compensation or fault handling, or would be written into a flow by a business analyst should be explicit within a BPEL Process as they are part of the business process.
If an event is required that is not part of a Business Analyst model of the process, a sensor should be considered with some of the following guidelines:
- BPEL Sensors are helpful for reporting on the metadata about a process, or when the event is not viewed as part of the business process. Using explicit BPEL tasks to report on value changes in variables or state changes in tasks in BPEL Processes would be too time consuming and sometimes impossible. I have found that the escalation and notification functionality currently provided is not adequate for some clients, so to extend the BPEL functionality, sensor events containing state and timestamp information can be easily sent to an external system which can handle the escalations and notifications.
- BPEL Sensors are also often used to clean up a process flow. For instance, if a status update had to be sent potentially 15 times throughout a process, it is substantially easier to configure one variable sensor on a status variable which triggers only when it is changed rather than adding 15 or more tasks to send the status to a downstream system
- Sensors are very closely integrated with Oracle BAM, so placement of sensors will be straightforward based on the real-time reporting needs of BAM reports
Variable and Activity Sensors
The following will give further details on the two basic types of sensors, Variable and Activity Sensors
Break down of an Activity Sensor:
- Listeners that are assigned to a single Task or Scope
- Fires an event when the state of the task it is assigned to reaches the desired state( Activation, Completion, Error, Compensation, All)
- Needs one or more variables assigned to it. These Variables are written at the specified states throughout the activities lifecycle to represent a snapshot of the activity at a certain point in time
- To get the duration of the activity, you would need to write a piece of data on Activation and on completion, and read both times out of the database
Break down of a Variable Sensor:
- Listeners that track the value of a variable across a full process and scopes (cannot be specified at task level)
- Fires an event whenever the value of a variables changes (across the entire process)
- Assigned to a single variable, and follow the variable to show how it changes across the lifecycle of a business process
My Thoughts on Sensors
Sensors have a good intention, but there needs to be a paradigm shift in how sensors are thought about and supported in the future. Adding sensors is currently not a scalable activity in JDeveloper’s IDE. Unfortunately, a programmer has to double click, configure, and test every task in a process that a sensor is going to be set. Also, though it is not enforced, I recommend having unique task names on all tasks within a process, so that events can be differentiated.
Hopefully, Oracle will make it easier to configure and publish events out of the BPEL Engine. It would be great if other systems could subscribe to changes in tasks and variable data. This way, a dynamic and generic framework could be put in place to act and report on sensor data in a scalable fashion.
It’s nice that JDeveloper provides a graphical utility to overlay sensors onto a flow, but I think this is its design weakness. A good reusable listener that can be applied to all tasks is not going to have a good visual representation. In the future, hopefully I can inject generic listeners across tasks and processes or dynamically flip events on and off for only critical or high priority flows. If Oracle does not provide it, there is a good chance M&S Consulting will build this as customers build a demand for it. We have already built something similar in the past, though nothing we have offered as a product just yet.
Event publishing of process metadata is important for an enterprise. The BPEL specification does not and should not contain any guidelines on how BPEL Engines should publish real time data and events, or what APIs need to be exposed so systems can interact with in flight processes to get to get live metadata. To me, these topics are the number one way of adding proprietary value to a BPEL Engine.
I think it would be strategic for any Business Process Management company supporting BPEL to standardize a robust and configurable event model and metadata API. Since BPEL is standardized and focused on orchestration, reusable extensions can be developed around the interface and proprietary systems could be written to extend the out of box functionality and enhance the BPEL offering.