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 callbacks. 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.If you have a large number of composite instances present for a single or multiple composites the Enterprise Manager will not be a very ideal place to look at if we want to know the states of these instances.
The table below shows the various State Value for composite instances in the CUBE_INSTANCE table of the
SOA_INFRA schema in the
dehydration store.It stores instance meta data information like creation date,last modified date, current state, process id etc. Following are processes state codes and their meaning
| State | Code |
|---|
| Closed and Aborted | 8 |
| Closed and Cancelled | 7 |
| Closed and Completed | 5 |
| Closed and Faulted | 6 |
| Closed and (Pending or Cancel) | 4 |
| Closed and Stale | 9 |
| Initiated | 0 |
| Open and Faulted | 3 |
| Open and Running | 1 |
| Open and Suspended | 2 |
Instance data occupies space in Oracle BPEL Process Manager schema tables. Data growth from auditing and dehydration can have a significant impact on database performance and throughput.
Oracle BPEL Process Manager Tables Impacted by Instance Data Growth:-
(i)audit_trail:-Stores the audit trail for instances. The audit trail viewed in Oracle BPEL Control is created from an XML document. As an instance is processed, each activity writes events to the audit trail as XML.
(ii)audit_details:-Stores audit details that can be logged through the API. Activities such as an assign activity log the variables as audit details by default.Audit details are separated from the audit_trail table due to their large size. If the size of a detail is larger than the value specified for this property, it is placed in this table. Otherwise, it is placed in the audit_trail table.
(iii)cube_instance:-Stores process instance metadata (for example, the instance creation date, current state, title, and process identifier)
(iv)cube_scope:-Stores the scope data for an instance (for example, all variables declared in the BPEL flow and some internal objects that help route logic throughout the flow).
(v)dlv_message:-Stores incoming (invocation) and callback messages upon receipt. This table only stores the metadata for a message (for example, current state, process identifier, and receive date).
(vi)dlv_subscription:-Stores delivery subscriptions for an instance. Whenever an instance expects a message from a partner (for example, the receive or onMessage activity) a subscription is written out for that specific receive activity.
(vii)document_ci_ref:-Stores cube instance references to data stored in the xml_document table.
(viii)document_dlv_msg_ref:-Stores references to dlv_message documents stored in the xml_document table.
(ix)schema_md:-Stores metadata about columns defined in the Oracle BPEL Process Manager schema (orabpel).
(x)task:-Stores tasks created for an instance. The TaskManager process keeps its current state in this table.
(xi)work_item:-Stores activities created by an instance. All activities in a BPEL flow have a work_item table. This table includes the metadata for the activity (current state, label, and expiration date (used by wait activities)).
(xii)xml_document:-Stores all large objects in the system (for example, dlv_message documents). This table stores the data as binary large objects (BLOBs). Separating the document storage from the metadata enables the metadata to change frequently without being impacted by the size of the documents.
(xiii)Header_properties:-stores headers and properties information
Durable and Transient Processes:-There are two types of processes in Oracle BPEL Process Manager. These processes impact the dehydration store database in different ways.
(i)Transient processes:- this process type does not incur any intermediate dehydration points during process execution. If there are unhandled faults or there is system downtime during process execution, the instances of a transient process do not leave a trace in the system. Transient processes are typically short-lived, request-response style processes. The synchronous process you design in Oracle JDeveloper is an example of a transient process.
(ii)Durable processes:- this process type incurs one or more dehydration points in the database during execution because of the following activities:
* Receive activity
* OnMessage branch in a pick activity
* OnAlarm branch in a pick activity
* Wait activity
Instances of durable processes can be saved in-flight (whether they complete normally or abnormally). These processes are typically long-living and initiated through a one-way invocation.
Properties that can effect the Dehydration Store:-
(i)idempotent BPEL Property:-Idempotent Activities:-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.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.
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 property.Setting this parameter to true can significantly improve throughput. 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.
(ii)BPEL Properties Set Inside a Composite:-
ex:-
<property name="bpel.config.inMemoryOptimization">true</property>
<property name="bpel.config.completionPersistPolicy">faulted</property>
(a)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.
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.
(b)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
(i)On (default):-The completed instance is saved normally
(ii)Deferred:-The completed instance is saved, but with a different thread and in another transaction.
(iii)Faulted:-Only the faulted instances are saved.
(iv)Off:-No instances of this process are saved.
