DEHYDRATION IN ORACLE BPEL

Dehydration in Oracle BPEL

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 also known as being dehydrated. The database where the BPEL instance is saved is called a dehydration store.

Dehydration:

§  Storing the current status of the BPEL process(i.e. long running process, asynchronous process) into the 

§database tables is known as dehydration. SOA_INFRA schema is the dehydration store which contains tables to hold the Meta data of the process.

§  In Synchronous Process

·         Process gets dehydrated only at the end of the process.

·         Using Dehydrate activity we can explicitly dehydrate process state if required.

§  In Asynchronous Process

·         Automatically dehydrated the process based on the activities used.

Why Dehydration Occurs:

·         Long running process or processes waiting for response consumes memory and CPU

·         While waiting for the response the BPEL engine can store the process, thus freeing up server resources.

·         Over the life cycle of the BPEL instance, the instance with the current state of execution may be saved in database.

Dehydrate Activities:

·         Few activities causes the BPEL instances to be dehydrated

·         If the process is dehydrated, then transaction ends and a new transaction is started once the BPEL process resumes.

Dehydration activities:

·         Wait

·         Dehydrate (11g) / Checkpoint (10g)

·         Receive (without create instance)

·         Commit (Java embedded)

·         Pick

·         Invoke (nonBlocking property set)

·         Non-idempotent activity (Invoke, receive) is encountered. 

Types of BPEL Processes:

Oracle BPEL Process Manager uses the dehydration store database to maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous call-backs. Storing the process in a database preserves the process and prevents any loss of state or reliability if a system shuts down or a network problem occurs. There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways.

·         Transient Process: 

Oracle BPEL server dehydrates the process instance only at the end of the process. If server crashes in middle of the running process instance, the instances will not be visible in EM

·         Durable Process: 

Oracle BPEL Server dehydrates the process instance in-flight at all mid-process breakpoint 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 (breakpoint activity) once the server restarts. If the server crashes before the process instance reaches the first mid-process breakpoint activity, the instance is not visible in Oracle BPEL Control after the server restarts.

An Idempotent Activity:

·         An idempotent activity is an activity that can be retried (or) 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 effect as one invocation.

E.g. Read only services, Receive activity, the assign activity. 

·         A non-idempotent activity is an activity that can happen only once.

The default value of idempotent property is true. By default, in a BPEL process invoke activity is an idempotent activity, It means that the BPEL engine will not dehydrate the instance right after invoke activities. This property can be set for each partner link. If it is set to true and when you invoked a BPEL process and your environment get crashed all of a sudden then when you will restart the system the invoke will be executed again. But when we will set this property to false the BPEL engine will dehydrate the activity after the invoke and when you will start the server it will start from the last saved activity and not from the invoke activity. Thus it will enhance performance.

When Dehydration Occurs:

·         When the BPEL instance encounters a mid-process breakpoint activity (not including the initial receive).

            Activities like wait, receive, pick, and 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 break point activities. A transient process does not have any mid process break-point activities.

    ·         When the BPEL instance encounters a non-idempotent activity

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 non-idempotent 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.

·         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.

Note: A BPEL invoke activity is by default (true) 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.

It can be set within the bpel.xml file.
General syntax is
<partnerLinkBindings>
<property name="idempotent">true</property>
</partnerLinkBinding> 

Skipping Dehydration:

·        Skipping dehydration will increase performance with a cost of auditing.

·        By Default, all BPEL processes are dehydrated regardless of whether they are Synchronous or Asynchronous process.

·        For Synchronous processes that do not need to be durable, you can turn off the dehydration mechanism by setting the following properties at process or engine level:

·        Set inMemoryOptimization to true.

·        Set completionPersistPolicy property to faulted or Off.

·        Asynchronous process invocation messages are always saved to the dehydration store.

·        Durable processes are always dehydrated regardless of the settings of the persistence properties.

Dehydration Tables:

·        Cube_Instance: Stores the information about the composite instance that gets created.

·        Cube_scope: Stores information about the scopes and variables declared and used.

·        DLV_Message: All the incoming payload details are stored.

·        Invoke_Message: All the outgoing message payload details are stored.

·        Audit_Trail: Used to store information of the xml that is rendered in EM console.