Improving the performance of BPEL process navigation

You can tune the performance of long-running processes by enabling performance optimizations, and tuning various configuration parameters.

About this task

A long-running process spans multiple transactions. Before WebSphere® Process Server Version 7.0, the default was for transactions to trigger by a Java™ Messaging Service (JMS) message. Since version 7.0, the default is to use work-manager-based navigation, which provides better performance. However, if you migrated from an earlier version, and were using JMS-based navigation, you can improve the performance of process navigation, by configuring Business Flow Manager to use the work-manager-based implementation for triggering transactions.

The following summarizes the characteristics of the two process navigation modes:

JMS message-based navigation

Process navigation handled by JMS messages that are controlled by the process navigation message-driven bean (MDB).

If the topology is set up so that the messaging engines are local to the application, a process navigates with server affinity unless it is triggered by external events, such as asynchronous messages or human tasks.
If the topology is set up so that multiple servers in an application cluster use a single remote messaging engine, then navigation within a process is distributed over the servers in the cluster.

Work-manager-based navigation

Process navigation is handled by a thread pool that is controlled by the work manager.

Normal navigation of a process instance is done using only server affinity.
To ensure transactional integrity, the messages that trigger navigation steps are stored in the Business Process Choreographer database. A background recovery thread periodically scans these messages, and if messages exist that are older than a specified maximum age, it sends them to the JMS queue to be picked up by the process navigation MDB. Business Process Choreographer guarantees that each message is executed exactly once.
The intertransaction cache is used by default, and this has implications for BPEL variables that are passed by reference to the Business Process Choreographer APIs, or that are provided as return values. For example, the claim and the getVariable methods are affected when the local EJB interfaces are used. BPEL variables are cached across multiple transactions, so changes that are made to a BPEL variable that is held by the application after the transaction completes can be visible to Business Flow Manager in a new transaction.
If an error occurs that causes the navigation step to roll back, the navigation of the process reverts to JMS-controlled navigation.

Server affinity means that navigation within a process instance happens on one WebSphere Application Server, unless an asynchronous service is invoked, a wait or timeout condition is encountered, a receive or pick activity is activated, or a human task is executed. These events can cause navigation within a process to continue on another WebSphere Application Server.

Procedure

Configure Business Flow Manager to use work-manager-based process navigation.
In the administrative console, perform the following steps:
1. Click Servers > Clusters > WebSphere application server clusters > cluster_name, then on the Configuration tab, in the Business Process Manager section, expand Business Process Choreographer, and click Business Flow Manager.
2. On the Configuration tab, select the Enable advanced performance operations option. Now you can change the values of the following configuration parameters:
  - Message pool size
  - Maximum age for stalled messages
  - Recovery interval for stalled messages
  - Maximum process time on thread
  - Intertransaction cache size
Optional: Increase the maximum number of threads available to the workflow manager.
Business Flow Manager requires two threads for internal processing. The remaining threads are available for process navigation. Start with one additional thread for each processor. If you increase the thread pool size, you also need to increase the connection pool size for the Business Process Choreographer database (BPEDB) and for the connection factory (BPECFC).

To change the maximum number of threads, perform the following using the administrative console.
1. Click Resources > Asynchronous beans > Work managers > BPENavigationWorkManager.
2. Under Thread pool properties, change the value of Maximum number of threads.
3. Set the value of Work request queue size to be the same as the value of Maximum number of threads.
Save your changes.
Restart the server to activate your changes.

Results

The work manager now controls your process navigation.