Download PDF (1.3 MB) - IBM Redbooks

Client systems that follow a page-flow pattern should consider the following issues:
► Use the completeAndClaimSuccessor() API if possible. This API use provides optimal
response time.
► Applications that assign the next available task to the user can use the following method
on the Human Task Manager EJB interface. This method implements a
performance-optimized mechanism to handle claim collisions.
claim(String queryTableName, …)
► Do not put asynchronous invocations between two steps of a page flow because the
response time of asynchronous services increases as the load on the system increases.
► Where possible, do not start long-running subprocesses between two steps of a page flow
because long-running subprocesses are started using asynchronous messaging.
Clients that present task lists and process lists should consider the following factors:
► Use query tables for task list and process list queries.
► Do not loop over the tasks shown in the task or process list and run an additional remote
call for each object. This practice prevents the application from providing good response
times and good scalability.
► Design the application so that all information is retrieved from a single query table during
task list and process list retrieval. For example, do not make calls to retrieve the input
message for task list or process list creation.
3.2.9 Transactional considerations
One of the strengths of the Business Process Manager BPEL platform is the precise control it
provides for specifying transactional behavior. When modeling a process or mediation
assembly, be sure the modeler carefully designs the transaction boundaries as dictated by
the needs of the application because boundaries are expensive in terms of system resources.
The objective of this section is to guide the modeler to avoid unnecessary transaction
boundaries. The following list details several guiding principles:
►
►
►
►
The throughput of a particular usage scenario is inversely related to the number of
transaction boundaries traversed in the scenario, so fewer transactions is faster.
In user-driven scenarios, improving response time might require more granular transaction
boundaries, even at the cost of throughput.
Transactions can span across synchronous invocations but cannot span asynchronous
invocations.
Avoid synchronous invocation of a two-way asynchronous target. The failure recovery of a
caller transaction can be problematic.
Taking advantage of Service Component Architecture transaction
qualifiers
In an SCA assembly, you can reduce the number of transaction boundaries by allowing
transactions to propagate across components. For any pair of components where you want to
reduce the number of transaction boundaries, use the following settings:
► For the reference of the calling component: SuspendTransaction= false
► For the interface of the called component: joinTransaction= true
► For implementation of both components: Transaction= any|global
These settings assume that the first component in such a chain either starts or participates in
a global transaction.
38 IBM Business Process Manager V8.0 Performance Tuning and Best Practices