Oracle SOA 11g 11.1.1.6 Performance Tuning of BPEL Processes:BPEL Properties Set Inside a Composite

Oracle SOA 11g 11. 1.1.6 Performance Tuning of BPEL Processes

BPEL Properties Set Inside a Composite

This section lists the config properties of some sections of the deployment descriptor. For each configuration property parameter, a description is given, as well as the expected behavior of the engine when it is changed.

All the properties set in this section affect the behavior of the component containing the BPEL process only. Each BPEL process can be created as a component of a composite. These properties can be modified in composite.xml or in the System MBean Browser of Oracle Enterprise Manager Fusion Middleware Control. 

Some Concepts First

As a general practice, it is better to design your BPEL processes as transient instead of durable if performance is a concern. Note that this may not always be possible due to the nature of your process, but keep the following points in mind.

The dehydration store is uses to maintain long-running asynchronous BPEL instances storing state information as they wait for asynchronous callbacks. This ensures the reliability of these processes in the event of server or network loss. Oracle BPEL Process Manager supports two types of processes; transient and durable.

Transient Processes

Transient processes do not incur dehydration during their process execution. If an executing process experiences an unhandled fault or the server crashes, instances of a transient process do not leave a trace in the system. Thus, these instances cannot be saved in-flight regardless if they complete normally or abnormally. Transient processes are typically short-lived, request-response style processes. Synchronous processes are examples of transient processes.

Durable Processes

Durable processes incur one or more dehydration points in the database during execution. Dehydration is triggered by one of the following activities:

• Receive activity
• OnMessage branch in a pick activity
• OnAlarm branch in a pick activity
• Wait activity
• Reply activity
• checkPoint() within a <bpelx:exec> activity

 inMemoryOptimization

This property indicates to Oracle BPEL Server that this process is a transient process and dehydration of the instance is not required. When set to True, the completionPersistPolicy is used to determine persistence behavior. This property can only be set to True for transient processes or processes that do not contain any dehydration points such as receive, wait, onMessage and onAlarm activities. The inMemoryOptimization property is set at the BPEL component level. When set to False, dehydration is disabled which can improve performance in some use cases.
Values:
This property has the following values:

• False (default): instances are persisted completely and recorded in the dehydration store database.
• True: The completionPersist policy is used to determine persistence behavior. 

completionPersistPolicy

This property configures how the instance data is saved. It can only be set at the BPEL component level. The completionPersistPolicy property can only be used when inMemoryOptimization is set to be True (transient processes). Note that this parameter may affect database growth and throughput (due to reduced I/O).

Value	Description
On (default)	The completed instance is saved normally
Deferred	The completed instance is saved, but with a different thread and in another transaction.
Faulted	Only the faulted instances are saved. Note: When an unhandled fault occurs, regardless of these flags, audit information of the instance is persisted within cube_instance table.
Off	No instances of this process are saved.

<component name="BPELProcess">
   <implementation.bpel src="BPELProcess.bpel" />

   <property name="bpel.config.completionPersistPolicy">faulted</property>
   <property name="bpel.config.inMemoryOptimization">true</property>
   ...
</component>

auditLevel

You can set the audit level for a BPEL process service component. This setting takes precedence over audit level settings at the SOA Infrastructure, service engine, and SOA composite application levels.

Set the bpel.config.auditLevel property to an appropriate value in the composite.xml file of your SOA project as shown in the example below:

<component name="BPELProcess">
<implementation.bpel src="BPELProcess.bpel" />
<property name="bpel.config.auditLevel">Off</property>
</component>

Value	Description
Inherit	Inherits the audit level from infrastructure level.
Off	No audit events (activity execution information) are persisted and no logging is performed; this can result in a slight performance boost for processing instances.
Minimal	All events are logged; however, no audit details (variable content) are logged.
Error	Logs only serious problems that require immediate attention from the administrator and are not caused by a bug in the product. Using this level can help performance.
Production	All events are logged. The audit details for assign activities are not logged; the details for all other activities are logged.
Development	All events are logged; all audit details for all activities are logged.

Partner Link Property

You can dynamically configure a partner link at runtime in BPEL. This is useful for scenarios in which the target service that BPEL wants to invoke is not known until runtime. The following Partner Link properties can be tuned for performance:

idempotent

An idempotent activity is an activity that can be retried (for example, an assign activity or an invoke activity). Oracle BPEL Server saves the instance after a nonidempotent activity. This property is applicable to both durable and transient processes.

Values:

This property has the following values:

• False: Activity is dehydrated immediately after execution and recorded in the dehydration store. When idempotent is set to False, it provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently.
• True (default): If Oracle BPEL Server fails, it performs the activity again after restarting. This is because the server does not dehydrate immediately after the invoke and no record exists that the activity executed. Some examples of where this property can be set to True are: read-only services (for example, CreditRatingService) or local EJB/WSIF invocations that share the instance's transaction.

A BPEL invoke activity is by default an idempotent activity, meaning that the BPEL process does not dehydrate instances immediately after invoke activities. Therefore, if idempotent is set to true and Oracle BPEL Server fails right after an invoke activity executes, Oracle BPEL Server performs the invoke again after restarting. This is because no record exists that the invoke activity has executed. This property is applicable to both durable and transient processes.

If idempotent is set to false, the invoke activity is dehydrated immediately after execution and recorded in the dehydration store. If Oracle BPEL Server then fails and is restarted, the invoke activity is not repeated, because Oracle BPEL Process Manager sees that the invoke already executed.

When idempotent is set to false, it provides better failover protection, but at the cost of some performance, since the BPEL process accesses the dehydration store much more frequently. This setting can be configured for each partner link in the bpel.xml file.

nonBlockingInvoke

By default, Oracle BPEL Process Manager executes in a single thread by executing the branches sequentially instead of in parallel. When this property is set to True, the process manager creates a new thread to perform each branch's invoke activity in parallel. This property is applicable to both durable and transient processes.

Consider setting this property to True if you have invoke activities in multiple flow or flow n branches. This is especially effective if the parallel invoke activities are two-way, but some benefits can be realized for parallel one-way invokes as well.

Note:

Invocations to the same partner link will happen in sequence and not in parallel. If you invoke different partner links each time with nonBlockingInvoke set to True, then each link will work in parallel even if all of the partner links point to the same source.

Values:

• True: Oracle BPEL Server spawns a new thread to execute the invocation.
• False (default): Oracle BPEL Server executes the invoke activity in the single process thread.

validateXML

Enables message boundary validation. Note that additional validation can impact performance by consuming extra CPU and memory resources.

Values:

• True: When set to True the engine validates the XML message against the XML schema during <receive> and <invoke> for this partner link. If the XML message is invalid thenbpelx:invalidVariables run time BPEL Fault is thrown. This overrides the domain level validateXML property.
• False (default): Disables XML validation.

General Recommendations:

1. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization to true and completionPersistPolicyto faulted, So that we can get better throughput, only faulted instances gets dehydrated in the database, its goes easy on the purge (purging historical instance data from database)

2. Do not include any settings to persist your process such as (Dehydrate, mid process receive, wait or Onmessage)

3. Have good logging on your BPEL Process, so that you can see log messages in the diagnostic log files for troubleshooting.

What should you do?

• If the design of the process allows it, design your BPEL processes as short-lived, synchronous transactions.
• If the design of the process allows it, avoid the activities listed above.

Any time your process is dehydrated to the dehydration store, this naturally impacts the performance of the process, and becomes a concern particularly in high volume environments.