BPEL dehydration data store tables and their significance.

Dehydration store is the database where BPEL engine stores all BPEL processes meta data and run time instance data.This data store is installed under db schema- ORABPEL

Meta data includes bpel process descriptor (bpel.xml), human task modelling data etc..

Run time instance data includes process instance records, process activities execution data, invoke and call back xml messages etc..

Table name	Description
CUBE_INSTANCE	Contains one entry for each BPEL instance created. 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
CUBE_SCOPE	Stores the scope data for an instance. It stores BPEL scope variable values
INVOKE_MESSAGE	Stores incoming (invocation) messages (messages that result in the creation of an instance). This table only stores the meta data for a message (for example, current state, process identifier, and receive date). Following are message states and their meanings State Description Code CANCELLED Message Processing Cancelled 3 HANDLED Message is processed 2 RESOLVED Message is given to BPEL PM but not yet processed 1 UNRESOLVED Message is not yet given to BPEL PM 0
DLV_MESSAGE	Call back messages are stored here
WORK_ITEM	Stores activities created by an instance. All activities in a BPEL flow have a work_item table. This table includes the meta data for the activity (current state, label, and expiration date (used by wait activities))
SCOPE_ACTIVATION	Scopes that need to be routed/closed/compensated are inserted into this table. In case of system failure, we can pick up and re-perform any scopes that should have been done before the failure
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. Once a delivery message is received the delivery layer attempts to correlate the message with the intended subscription
AUDIT_TRAIL	Stores record of actions taken on an instance. As an instance is processed, each activity writes events to the audit trail as XML
AUDIT_DETAILS	Stores details for audit trail events that are large in size. Audit details are separated from the audit_trail table due to their large size. The auditDetailThreshold property in Oracle BPEL Control under Manage BPEL Domain > Configuration is used by this table. 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
XML_DOCUMENT	Stores process input and output xml documents. Separating the document storage from the meta data enables the meta data to change frequently without being impacted by the size of the documents
WI_EXCEPTION	Stores exception messages generated by failed attempts to perform, manage or complete a work item. Each failed attempt is logged as an exception message
PROCESS_DESCRIPTOR	Stores BPEL processes deployment descriptor(bpel.xml) Record of events (informational, debug, error) encountered while interacting with a process.
INVOKE_MESSAGE_BIN	Stores invoke payload of a process. This table has foreign key relationship with INVOKE_MESSAGE table
DLV_MESSAGE_BIN	Stores received payload of a call-back process.This table has foreign key relationship with DLV_MESSAGE
WFTASK	Stores human workflow tasks run time meta data like taskid,title,state,user or group assigned, created and updated dates
WFTASKMETADATA	Stores task meta data. Content in this table comes from '.task' file of BPEL project
WFASSIGNEE	Stores task assignee information
WFMESSAGEATTRIBUTE	Stores task input payload parameters
WFATTACHMENT	Stores task attachments
WFCOMMENTS	Stores task comments