Download PDF (1.3 MB) - IBM Redbooks

3.2.6 Business Process Execution Language business process
considerations
This section presents considerations for authoring performance specific to BPEL business
processes.
Modeling best practices for activities in a business process
For best performance, use the following guidelines when modeling a BPEL business process:
►
►
►
►
Use the Audit Logging property for Business Processes only setting if you need to log
events in the Business Process Choreographer database (BPEDB). You can set this
property at the activity or process level. If you set it at the process level, the setting is
inherited by all activities.
For long-running processes, in Integration Designer, click Properties Server, and clear
the Enable persistence and queries of business-relevant data property for both the
process and for each individual BPEL activity. Enabling this flag causes details of the
execution of this activity to be stored in the BPC database, which increases the load on the
database and the amount of data stored for each process instance. Use this setting only if
you must retrieve specific information later.
For long-running processes, a setting of Participates on all activities generally provides
the best throughput performance. See “Avoiding two-way synchronous invocation of an
asynchronous target” on page 39 for more details.
Human tasks can be specified in business processes (for example, process
administrators), start activities, and receive activities. Specify human tasks only if
necessary. When multiple users are involved, use group work items (people assignment
criterion: Group) instead of individual work items for group members (people assignment
criterion: Group Members).
Avoiding two-way synchronous invocation of long-running processes
When designing long-running business process components, ensure that callers of a two-way
(request/response) interface do not use synchronous semantics because this function ties up
the caller’s resources (such as threads and transactions) until the process completes.
Instead, start such processes either asynchronously, or through a one-way synchronous call,
where no response is expected. In addition, calling a two-way interface of a long-running
business process synchronously introduces difficulties when exceptions occur. Suppose that
a non-interruptible process calls a long-running process using the two-way request/response
semantics, and the server fails after the long-running process completes, but before the
caller’s transaction is committed. The following results occur:
►
►
If the caller was started by a persistent message, upon server restart, the caller’s
transaction is rolled back and tried again. However, the result of the execution of the
long-running process on the server is not rolled back because it was committed before the
server failure. As a result, the long-running process on the server runs twice. This
duplication causes functional problems in the application unless corrected manually.
If the caller was not started by a persistent message, and the response of the long-running
process was not submitted yet, the process ends in the failed event queue.
36 IBM Business Process Manager V8.0 Performance Tuning and Best Practices