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:
- Define the relevant milestones you want to show to the user;
- Configure the sensors;
- Configure the sensor actions;
- Create the database user and queues for AQ;
- Configure WebLogic Server and add JMS objects;
- Create PL/SQL code to read from the queue and store it in the table;
- Deploy the BPEL process;
In parallel you can build the GUI or configure BAM, depending on what you decided upon.
Resources
- Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite11g Release 1 (11.1.1.7), chapter 18;
- Oracle® Fusion Middleware Developer's Guide for Oracle SOA Suite11g Release 1 (11.1.1.7), part X;
- Oracle® Fusion Middleware Configuring and Managing JMS for Oracle WebLogic Server11g Release 1 (10.3.6)
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
ReplyDeletethat is very interesting, thank you for the link Maarten :)
Delete