Dehydration - Offers
Reliability, fail-over protection
Over the life cycle
of a BPEL instance, the instance with its current state of execution may be
saved in a database. When a BPEL instance is saved to a database, the instance
is known as being dehydrated. The database where the BPEL instance is saved is called
a dehydration store.
Once a BPEL instance
is dehydrated, Oracle BPEL Server can off load it from the memory of Oracle
BPEL Server. When a certain event occurs, such as the arrival of a message or
the expiration of a timer, Oracle BPEL Server locates and loads the persistent BPEL
instance from the dehydration store back into the memory of Oracle BPEL Server
and resumes the execution of the process instance. Dehydrating BPEL instances
offers reliability. If Oracle BPEL Server crashes in the middle of executing a
process, the instance can be recovered automatically, programmatically, or
manually from the dehydrated states. When Oracle BPEL Server resumes the
execution of the process instance, it resumes
from the last dehydration point, which is the last state of the instance
that Oracle BPEL Server saves to the dehydration store.
When and how the dehydration
occurs differs based on the process types:
■ Transient process — Oracle BPEL Server dehydrates
the process instance only once at the end of the process. When a host crashes
in the middle of running the process instance, the instances are not visible
from Oracle BPEL Control.
■ Durable process/idempotent — Oracle BPEL Server
dehydrates the process instance in-flight at all midprocess breakpoint and
non-idempotent activities, plus the end of the process. When the server
crashes, this process instance appears in Oracle BPEL Control up to the last
dehydration point (breakpoint activity) once the server restarts. If the server
crashes before the process instance reaches the first midprocess breakpoint
activity, the instance is not visible in Oracle BPEL Control after the server
restarts.
There are three cases in which
dehydration occurs:
1. When the BPEL
instance encounters a mid-process breakpoint activity (not including the
initial receive)
Activities like
wait, receive, onMessage, onAlarm, call to an async WSDL
That is where an
existing BPEL instance must wait for an event, which can be either a timer
expiration or message arrival. When the event occurs (the alarm expires or the
message arrives), the instance is loaded from the dehydration store and
execution is resumed. This type of dehydration occurs only in durable
processes, which have mid-process breakpoint activities. A transient process
does not have any midprocess breakpoint activities.
2. When the BPEL
instance encounters a non-idempotent activity
When Oracle BPEL
Server recovers after a crash, it retries the activities in the process
instance. However, it should only retry the idempotent activities. Therefore,
when Oracle BPEL Server encounters a nonidempotent activity, it dehydrates it.
This enables Oracle BPEL Server to memorize that this activity was performed
once and is not performed again when Oracle BPEL Server recovers from a crash.
Idempotent
activities are those activities where the result is the same irrespective of
no. of times you execute the process.
Repeated
invocations have the same affect as one invocation.
Ex
: Read-Only services
3. When the BPEL
instance finishes
At the end of the
BPEL process, Oracle BPEL Server saves the process instance to the dehydration
store, unless you explicitly configure it not to do so. This happens to both
durable and transient processes. For transient processes, the end of the
process is the only point where the process instance is saved. This is because
a transient process does not have any mid-process breakpoint activities and
nonidempotent activities where the in-flight dehydration can occur.
------------------
Dehydration
triggered by:
(a)Breakpoint
activities: <receive>, <onMessage> (including <pick>),
<onAlarm>, <wait>, and <reply>
(b)When using
checkPoint()within a <bpelx:exec>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. This is because no record exists that the invoke activity has
executed. This property is applicable to both durable and transient processes.
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 in the
bpel.xml file.
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.
--------------------
BPEL Dehydration
Stores
As already explained, when a BPEL process instance is saved in the database, it uses the schema that is configured using Repository Creation Utility(RCU) that you would use during SOA environment setup.
Here are some of the tables that a BPEL engine uses to store its current instance state.
cube_instance -
stores instance metadata, eg. instance creation date, current state, title,
process identifier
cube_scope - stores
the scope data for an instance
work_item - stores
activities created by an instance
document - stores
large XML variables, etc.
Thanks. Its informative !
ReplyDeleteThanks a lot
ReplyDeleteThis is really very good info, I was looking to understand this topic for quite some time now, Oracle documentation is very vast, this post explains it in detail in a very simple manner. Keep ging!
ReplyDeleteThanks. Do you know how can one test/execute a bpel/composite from Jdev without having to deploy on server ?
ReplyDeleteAs far as I know, in 11g, simulation of BPEL processes is not available.
DeleteThank you. Very well detailed
ReplyDelete