Sunday, January 19, 2014

Tracking progress of your BPEL process using sensors

Often when you start using Oracle SOA Suite11g and BPEL you need a mechanism to help the end users keep track of the progress of the overall process instances. The EM shows this to administrators, but this is not suitable for end users.

What about the worklist application?

The SOA Suite offers the worklist application to handle tasks and to view progress using views and reports. It shows human tasks, crossing multiple process definitions. It does not show invocation of services or specific data changes in the process. The figure below shows three instances of one specific process definition. In this example relevant milestones are reached when the process starts, the first automated step is executed, the second human task is executed and when the process ends. In the worklist application you would be able to see what human tasks are open or executed by which user. With the worklist application you can't keep track of the first, second and last milestone, only of the third one because that is the only one associated with a human task. 


Sensors and sensor actions

The required functionality can be accomplished using sensors and sensor actions on relevant parts in the BPEL process. There are different types of sensors that can be used in SOA Suite 11g: activity sensors, variable sensors and fault sensors.

After you have configured the sensor in your BPEL process, you need to define one or more sensor actions. There are four types of actions: three sensor actions and one BAM sensor action:

  • Database to publish it to the BPEL dehydration store
  • JMS to publish it to a JMS topic or queue. If the JMS provider is not local, you can use the JMS adapter
  • Custom Java class to handle it in a different way. 
  • BAM Sensor actions to publish them to Oracle BAM.
You can chose to publish the sensor to AQ, so you can handle it both with Java clients and with PL/SQL because JMS queues in WebLogic can be implemented using AQ. 

Displaying the information with BAM or a custom application

There are two ways to show the progress to the end user: using BAM or building a custom application on top of the sensor data. You can easily decide to implement BAM later: you can either add BAM sensor actions to the BPEL sensor, or define a Enterprise Message Source in BAM. 



Option 2 (defining an Enterprise Message Source) has the advantage of not having to change the BPEL process (design time) when you decide to start using BAM rather than or on top of the custom application. 

Steps

Now that we have established how we want to implement the functionality, we can get started :) The following steps need to be taken:
  1. Define the relevant milestones you want to show to the user;
  2. Configure the sensors;  
  3. Configure the sensor actions;
  4. Create the database user and queues for AQ;
  5. Configure WebLogic Server and add JMS objects;
  6. Create PL/SQL code to read from the queue and store it in the table;
  7. Deploy the BPEL process;
In parallel you can build the GUI or configure BAM, depending on what you decided upon. 

Resources






2 comments:

  1. Good (and nicely illustrated) explanation on using sensors to track BPEL processes. If time/budget is limited (defining Enterprise Messages and custom BAM dashboards is not an option), you can also use activity monitoring from BPEL and the standard Monitor Express dashboard to give some out of the box functionality to keep track of BPEL process activities. This is less suitable though for business users. I wrote a blog post about this (from a different angle as this post) on http://javaoraclesoa.blogspot.nl/2013/12/oracle-bam-looking-at-different.html

    ReplyDelete
    Replies
    1. that is very interesting, thank you for the link Maarten :)

      Delete