During my BPEL’s assignment, customer often ask me to :
- provide some BPEL design pattern guidelines for developers
- explain the BPEL transaction boundaries behavior and associated error handling
- speed up the BPEL development process
I will focus on theses 3 topics in my next posts. Today, let’s focus on how the dehydration process works in BPEL to provided reliability (non message lost) amongst others benefits. The dehydration point affect the transaction boundaries of your SOA composite. Some of the sentence below are quote and disseminated from Oracle documentation.
What is a BPEL dehydration process ?
BPEL dehydration process is the action from the BPEL engine to compressed and stored the BPEL instances into the database. The incoming messages are store in the database for processing later by worker threads.
Why do we need dehydration point in BPEL process ?
- to automatically maintain long-running asynchronous processes and their current state information in a database while they wait for asynchronous callback
- to preserve BPEL process and prevents any loss of state or reliability if a system shuts down or a network problem occurs.
- to increase both BPEL process reliability and scalability. But this might slows down the process if many instance are created at the same time, if the BPEL engine is not tuned correctly
- you can also use it to support clustering and failover
Note: BPEL Activity is dehydrated immediately after execution and recorded in the dehydration store. It provides better failover protection, but may impact performance if the BPEL process accesses the dehydration store frequently.
When a dehydration points occurs ?
The dehydration points occurs:
- when the activities are used : (not just after, depends on BPEL Engine)
- a mid-receive activities. Please not that the first receive activity will not automatically dehydrate the BPEL process. This depends on the pattern used and on the specific BPEL properties optimization.
- onMessage activity
- onAlarm activity
- just before wait activity (depends on the duration)
- dehydrate activity
- a (implicit) transaction is committed
- when calling a non-idempotent idempotent=false service or Partner Link
- when RequiresNew BPEL transaction is completed
Note1:Remember that theses dehydration statement must be avoided in synchronous BPEL process.
Note2:Idempotence is a mathematical term that basically means that calling a function multiple times doesn’t change the result for example f(f(x))=f(x).
Note3: What does it mean for messaging service system ?
If a service receives the same message again, it should be able to handle it without changing the state of the system. For example; in a bank scenario you wouldn’t want that withdraw message to be processed more than once !
Note4: An idempotent activity in BPEL (for example, an assign activity or an invoke activity) is an activity that can be retried
Note5:To ensure data consistency, the dehydration database is done using the same transaction context in which the BPEL process is executed. However, BPEL engine use a separate transaction context for the audit logging information, which aids (a lot) for debugging failed instance.
Engine dispatch messages are generated whenever an activity must be processed asynchronously by the BPEL engine. If the majority of processed deployed on the BPEL server are durable with a large number of dehydration points (mid-process receive, onMessage, onAlarm, wait), greater performance may be achieved by increasing the number of engine threads.