(For more resources on Oracle, see here.)

It is important to understand the complexity of a BPEL process that creates the additional need for active operational monitoring. They are SOA enabled, which means they orchestrate interactions between different systems using a common Web Service Invocation Framework (WSIF). WSIF enables BPEL to build a façade to interact with any system that is Web service enabled. The Web service interactions are called “partner links” in the BPEL framework. This is quite powerful for orchestrating complex business processes that involve new and legacy systems.

Grid Control provides means to monitor critical BPEL processes, partner links, and Web services through service tests to determine availability and response time. Grid Control also provides a means of measuring critical metrics for actual requests initiated against each of the Web services deployed on the container. With a combined end-user and request perspective, Grid Control can determine the service availability of all monitored services.

Challenges

Once BPEL processes are deployed into a staging, preproduction, or a production environment, administrators find it difficult to track the health of these key processes. There is a paucity of tools and operational skills in the BPEL area, so it becomes difficult to understand where to look, and what to look for, when faced with a problem. These processes frequently are the automated representation of critical business functions, and they are required to work as expected. Each process could spawn hundreds or thousands of instances daily. If any process is not performing as expected, in terms of availability or performance, the administrators need to step in and resolve the problem. Administrators are required to fix problems as soon as possible, and typically spend most time triaging the problem to understand potential root causes. Further, in most cases, end users report these problems, whether they are consumers via the Internet or key business partners. If that is the case, the enterprise has already lost revenue or credibility, or both.

Solutions

Grid Control provides means to monitor critical BPEL processes, partner links, and Web services, through service tests to determine availability and response time. Grid Control also provides a means of measuring critical metrics for actual requests initiated against each of the Web services deployed on the container. Grid Control can determine the service availability of all monitored services by utilizing its active end-user monitoring capabilities.

Step-by-step exercises

This set of step-by-step exercises will walkthrough the discovery of a BPEL process home page, and setting up monitoring for the process and partner links.

Navigating to the BPEL PM target home page

Grid Control can monitor several types of targets. The first task is to get to the BPEL PM target home page. All the BPEL-specific monitoring views can be viewed from the target home page.

1. Navigate to the Grid Control home page.
2. In the Target Search region on the right, click on the Search dropdown.
3. Scroll down to locate and click on the BPEL Process Manager target type.
4. Click on the Go button.
5. A list of discovered BPEL Process Manager targets is displayed. Click on the one target name of choice. This takes you to the BPEL PM target home page.

If a single BPEL Process Manager target is discovered, the Go button will automatically take you to that target’s home page.

Navigating to the BPEL process home page

The BPEL target home page is mainly an infrastructure view. There is a section within the target home page to view the list of BPEL processes and their monitoring metrics.

1. From the BPEL target home page, click on the Processes tab.

   All the BPEL processes deployed on the server are discovered and displayed here. Note that the processes are displayed within the domain they are deployed in. Summary throughput process instance information is also displayed in the table. These metrics are gathered by default from the BPEL PM server at a preset polling frequency (collection interval). One can easily change the default polling frequency, as well as set thresholds for these out-of-the-box metrics so that alerts and notifications (with notification rules) can be fired.

   

   (Move the mouse over the image to enlarge.)

2. Click on the BPEL process name under the default domain, for example SOAOrderBooking(v1.0).

   This is the individual BPEL process page. Note the process-specific instance throughput graph. At the bottom, note that all the partner links (at the bottom) for the BPEL process are discovered along with the port type, operation, and WSDL information. Create the BPEL process aggregate service. Note that you need to create the BPEL Infrastructure Service before you attempt to create the BPEL process aggregate service.

3. From the BPEL process page, click on the Create Service button, as shown in the following screenshot:

   

4. Observe the confirmation message for the aggregate service creation.

   The aggregate service that was created is listed under the Services section. The previously created infrastructure service has automatically been associated with the aggregate service. In the Services section, starting from the left, you see the service name, type of service, status, and other alerts. The top-level service is the aggregate service. The next service is the infrastructure service—a subservice of the aggregate.

   

Creating a SOAP test to monitor a partner link

A synthetic transaction is a proactive way to emulate end user (or client) behavior and catch problems before the end user (or client). A BPEL process typically invokes one or more web services through a partner link framework, usually via SOAP. A synthetic check for testing the BPEL partner link availability and performance is a great way to uncover problems before the service consumers do.

1. Scroll down and select a partner link name from the radio button list, for instance, SelectService.
2. Click on the Add SOAP Test button to create a SOAP test for that partner link.

   

3. Enter the SOAP Test Name as SelectService_test.
4. Enter the test interval for the Collection Frequency (minutes) as 15.
5. Select Web service port from the Port Types drop-down list as SelectServiceCallbackPort.
6. Enter input parameters in the HTML input fields, for example, SupplierPrice {String} as 12345 and SupplierName {String} as 2.
7. Leave the Basic Authentication Credentials section empty.
8. Click on OK to continue after the fields on the Create SOAP Test page are filled as shown in the following screenshot:

   

9. Add a beacon. Click on the Add button.
10. From the pop-up window, check and select the available beacon(s), shown in the next screenshot:

    Beacons are agents that have been configured to issue synthetic tests to test websites, Web services, mail servers, FTP sites, and so on. A beacon is typically installed outside the firewall from a location where users access the website or Web service. A beacon thus “emulates” end user behavior and informs the administrator proactively about any problem with the website or Web service. You can read more about beacons and service management in the Grid Control documentation on the Oracle Technology Network—http://otn.oracle.com.

    

11. Click on OK to save the SOAP test and beacon settings.
12. Verify availability process creation and view SOAP test. On the BPEL process home page, note the availability Generic Service that was automatically created.
13. Expand the process availability service. For example, SOAOrderBooking(v1.0)_availability and verify that the SOAP test that you just created, for example SelectService_test, has been added.

    The availability service for the BPEL process is formed when the first SOAP test is created. Note the status of each test, and how it is rolled up (confi gurable) to determine process availability. The status of the SOAP test will take some time to show up, based on the frequency set for the test.