A very important feature is dehydration in BPEL Service Engine in Oracle SOA 11g. This happens especially in asynchronous scenarios where a business process invokes a partner web service by using the invoke activity and then waits for the response by using receive activity or pick activity. While waiting for the response, the oracle engine can store the process in the database, thus someone activity the server resources. This process is called Dehydration.
When the engine receives the response, it first restores the process with its state from the database (hydration) and then continues with the execution of the process.
This data store is installed under db schema-ORABPEL Meta data includes bpel process descriptor, human task modelling data etc.
The database schema can be found in the DDL script domain_oracle.dll in the $ORABPEL$\ integration\orabpel\system\database\scripts directory.
When the engine receives the response, it first restores the process with its state from the database (hydration) and then continues with the execution of the process.
This data store is installed under db schema-ORABPEL Meta data includes bpel process descriptor, human task modelling data etc.
The database schema can be found in the DDL script domain_oracle.dll in the $ORABPEL$\ integration\orabpel\system\database\scripts directory.
CUBE_INSTANCE | Instance metadata information (creation date, current state, process ID) |
CUBE_SCOPE | Scope data for an instance |
AUDIT_TRAIL | Audit trail information for an instance; this information can be viewed from BPEL Console |
AUDIT_DETAILS | Large detailed audit information about a process instance |
DLV_MESSAGE | Callback message metadata |
DLV_MESSAGE_BIN | Payload of callback messages |
INVOKE_MESSAGE | Invocation messages metadata |
INVOKE_MESSAGE_BIN | Payload of invocation messages |
DLV_SUBSCRIPTION | Delivery subscriptions for an instance |
TASK | Tasks created for an instance (i.e. title, assignee, status, expiration) |
No comments:
Post a Comment