What is Oracle BPEL dehydration?
Ans: Storing the state of BPEL process in to Database (SOA_INFRA) is called dehydration.
When dehydration occurs?
Ans: Asych process always dehydrated
Wait, checkpoint or Dehydrate, Receive, commit (embeded java activity), Pick, Invoke Activities causes dehydration.
Non-idempotent enabled activities (such as Invoke and Receive).
By default all BPEL processes are dehydrated.
How does BPEL Process type impacts dehydration?
Ans: "Transient" Type BPEL process alows the BPEL server to dehydrate the state of the process only at the end of the execution of process. Where as, "Durable" Type BPEL processes alows the BPEL server to dehyerate the state of the process only at the time of reaching the non-idempotent and breakpoint activities (refer my 2nd question answer)
Also, note that by default "Inovke" activities idempotent flag value is true, so BPEL Server doesnot persist the state of the process in dehydration tables. So changing the idempotent flag value to "false" causes the BPEL Server to store the state of the process (irrespective of whether it is Transient or Durable process).
How can we skip Dehydration?
Ans: By default, all BPEL process (synch, Async, Transient, Durable) are dehydrated. But for Synch process, by setting the BPEL processes below properties Dehydration can be skipped. Those properties are : inMemoryOptimization = true; completionPersistPolicy = Faulted or OFF. You cannot avoid/skip dehydration for Async and durable processes.
Usefull dehydration tables:
Ans: Composite_instance, cube_instance, cube_scope, Dlv_message, invoke_message, Audit_trail, work_item, Mediator _Instance are key tables.
Ans: Storing the state of BPEL process in to Database (SOA_INFRA) is called dehydration.
When dehydration occurs?
Ans: Asych process always dehydrated
Wait, checkpoint or Dehydrate, Receive, commit (embeded java activity), Pick, Invoke Activities causes dehydration.
Non-idempotent enabled activities (such as Invoke and Receive).
By default all BPEL processes are dehydrated.
How does BPEL Process type impacts dehydration?
Ans: "Transient" Type BPEL process alows the BPEL server to dehydrate the state of the process only at the end of the execution of process. Where as, "Durable" Type BPEL processes alows the BPEL server to dehyerate the state of the process only at the time of reaching the non-idempotent and breakpoint activities (refer my 2nd question answer)
Also, note that by default "Inovke" activities idempotent flag value is true, so BPEL Server doesnot persist the state of the process in dehydration tables. So changing the idempotent flag value to "false" causes the BPEL Server to store the state of the process (irrespective of whether it is Transient or Durable process).
How can we skip Dehydration?
Ans: By default, all BPEL process (synch, Async, Transient, Durable) are dehydrated. But for Synch process, by setting the BPEL processes below properties Dehydration can be skipped. Those properties are : inMemoryOptimization = true; completionPersistPolicy = Faulted or OFF. You cannot avoid/skip dehydration for Async and durable processes.
Usefull dehydration tables:
Ans: Composite_instance, cube_instance, cube_scope, Dlv_message, invoke_message, Audit_trail, work_item, Mediator _Instance are key tables.
No comments:
Post a Comment