Oracle SOA Performance tuning with Dehydration & Process Types

Dehydration – Offers Reliability, fail-over protection:Over the life cycle of a BPEL instance, the instance with its current state of execution may be saved in a database. When a BPEL instance is saved to a database, the instance is known as being dehydrated. The database where the BPEL instance is saved is called a dehydration store.Once a BPEL instance is dehydrated, Oracle BPEL Server can off load it from the memory of Oracle BPEL Server. When a certain event occurs, such as the arrival of a message or the expiration of a timer, Oracle BPEL Server locates and loads the persistent BPEL instance from the dehydration store back into the memory of Oracle BPEL Server and resumes the execution of the process instance. Dehydrating BPEL instances offers reliability. If Oracle BPEL Server crashes in the middle of executing a process, the instance can be recovered automatically, programmatically, or manually from the dehydrated states. When Oracle BPEL Server resumes the execution of the process instance, it resumes from the last dehydration point, which is the last state of the instance that Oracle BPEL Server saves to the dehydration store.

When and how the dehydration occurs differs based on the process types:

Transient process: - Oracle BPEL Server dehydrates the process instance only once at the end of the process. When a host crashes in the middle of running the process instance, the instances are not visible from Oracle BPEL Control. Transient processes do not incur dehydration during their process execution. If an executing process experiences an unhanded 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 process: - Oracle BPEL Server dehydrates the process instance in-flight at all mid process breakpoints and non-idempotent activities, plus the end of the process. When the server crashes, this process instance appears in Oracle BPEL Control up to the last dehydration point (breakpoints activity) once the server restarts. If the server crashes before the process instance reaches the first mid process breakpoints activity, the instance is not visible in Oracle BPEL Control after the server restarts.

Transient vs. durable BPEL processes: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. By default all the BPEL process are durable process and its instances are stored in the dehydration tables.

Oracle SOA gives us flexibility to make any process transient forcefully by setting few properties.These properties are bpel.config.inMemoryOptimization and bpel.config.completionPersistPolicy.
By setting these properties in tandem we can forcefully make a durable process transient.As we know oracle SOA BPEL engine executes a process depending upon its message exchange pattern, if the process is synchronous then dehydration happens at the end of the execution or else if the process is asynchronous then the dehydration happens wherever the process encounters a dehydration point/activity ( wait , receive , pick , onAlarm , dehydrate).
We can make a synchronous process transient by setting above properties in the composite.xml provided the synchronous process does not have any dehydration points within its flow or else these properties won't work.  

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

When dehydration occurs: -There are three cases when dehydration occurs.

1. When the BPEL instance encounters a mid-process breakpoints activity (not including the initial receive)Activities like wait, receive, onMessage, onAlarm, call to an async WSDL,That is where an existing BPEL instance must wait for an event, which can be either a timer expiration or message arrival. When the event occurs (the alarm expires or the message arrives), the instance is loaded from the dehydration store and execution is resumed. This type of dehydration occurs only in durable processes, which have mid-process breakpoint activities. A transient process does not have any midprocess breakpoint activities.
2. When the BPEL instance encounters a non-idempotent activity(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.),When Oracle BPEL Server recovers after a crash, it retries the activities in the process instance. However, it should only retry the idempotent activities. Therefore, when Oracle BPEL Server encounters a nonidempotent activity, it dehydrates it. This enables Oracle BPEL Server to memorize that this activity was performed once and is not performed again when Oracle BPEL Server recovers from a crash.Idempotent activities are those activities where the result is the same irrespective of no. of times you execute the process.Repeated invocations have the same affect as one invocation.
3. When the BPEL instance finishes At the end of the BPEL process, Oracle BPEL Server saves the process instance to the dehydration store, unless you explicitly configure it not to do so. This happens to both durable and transient processes. For transient processes, the end of the process is the only point where the process instance is saved. This is because a transient process does not have any mid-process breakpoint activities and nonidempotent activities where the in-flight dehydration can occur.

BPEL Dehydration Stores:As already explained, when a BPEL process instance is saved in the database, it uses the schema that is configured using Repository Creation Utility(RCU) that you would use during SOA environment setup.Here are some of the tables that a BPEL engine uses to store its current instance state.

cube_instance – stores instance metadata, eg. instance creation date, current state, title, process identifier,cube_scope – stores the scope data for an instance,work_item – stores activities created by an instance,document – stores large XML variables, etc.

The Dehydration Store database is used to store process status data, especially for asynchronous BPEL processes,  like BPEL’s metadata and instance data. This exists in x_SOAINFRA schema created by running RCU.A very important to remember if a BPEL process fails without reaching a dehydration point then the instance will not show up on the BPEL console.This instance never gets stored to the database.
Below are the main Dehydration tables for BPEL:

1.CUBE_INSTANCE
2.CUBE_SCOPE
3.AUDIT_TRAIL
4.AUDIT_DETAILS
5.DLV_MESSAGE
6.DLV_MESSAGE_BIN
7.INVOKE_MESSAGE
8.INVOKE_MESSAGE_BIN
9.DLV_SUBSCRIPTION
10.TASK
11.WORK_ITEM

What should you do:

1. If the design of the process allows it, design your BPEL processes as short-lived, synchronous transactions.
2. 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.
3. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization totrue 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)
4. Do not include any settings to persist your process such as (Dehydrate, mid process receive, wait or Onmessage)
5. Have good logging on your BPEL Process, so that you can see log messages in the diagnostic log files for troubleshooting.

Reference documents:@Oracle