BPEL Persistence Properties

Ø  BPEL Persistence Properties – 11g

BPEL Persistence properties are used to control, when a process need to dehydrate. Below are the properties which we can use to control it for BPEL Component in a Composite.

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, Oracle BPEL Server keeps the instances of this process in memory only during the course of execution. This property can only be set to true for transient processes (process type does not incur any intermediate dehydration points during execution).

• false (default): instances are persisted completely and recorded in the dehydration store database for a synchronous BPEL process.
• true: Oracle BPEL Process Manager keeps instances in memory only.

CompletionPersistPolicy

This property controls if and when to persist instances. If an instance is not saved, it does not appear in Oracle BPEL Console. This property is applicable to transient BPEL processes (process type does not incur any intermediate dehydration points during execution).

This property is only used when inMemoryOptimization is set to true.

This parameter strongly impacts the amount of data stored in the database (in particular, the cube_instance, cube_scope, and work_item tables). It can also impact throughput.

• on (default): The completed instance is saved normally.
• deferred: The completed instance is saved, but with a different thread and in another transaction, If a server fails, some instances may not be saved.
• faulted: Only the faulted instances are saved.
• off: No instances of this process are saved.

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

OneWayDeliveryPolicy

This property controls database persistence of messages entering Oracle BPEL Server. Its used when we need to have a sync-type call based on a one way operation. This is mainly used when we need to make an adapter synchronous to the BPEL Process.

By default, incoming requests are saved in the following delivery service database tables: dlv_message

• async.persist: Messages are persisted in the database.
• sync.cache: Messages are stored in memory.
• sync: Direct invocation occurs on the same thread.

<component name="UnitOfOrderConsumerBPELProcess">
...
<property name="bpel.config.transaction" >required</property>
<property name="bpel.config.oneWayDeliveryPolicy">sync</property>
...
</component>

General Recommendations:

1. If your Synchronous process exceed, say 1000 instances per hour, then its better to set inMemoryOptimization to true and completionPersistPolicy to 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.