Dehydration In SOA

Why Dehydration

• Long running process or processes waiting for response consumes memory and CPU
• While waiting for the response the bpel engine can store the process, thus freeing up server resources.
• Over the life cycle of the BPEL instance, the instance with the current state of execution may be saved in database.

Dehydration

• Storing the current status of the BPEL process(i.e. long running process, asynchronous process) into the database tables is known as dehydration
• SOA_INFRA schema is the dehydration store which contains tables to hold the meta data of the process.
• Synchronous Process

– Process gets dehydrated only at the end of the process.
– Using Dehydrate activity we can explicitly dehydrate process state if required.

• Asynchronous Process

– Automatically dehydrated the process based on the activities used.
Dehydrate Activities

• Few activities causes the BPEL instances to be dehydrated
• If the process is dehydrated, then transaction ends and a new transaction is started once the bpel process resumes.
• Dehydration activities:

Wait
Dehydrate(11g) / Checkpoint(10g)
Receive(without create instance)
Commit(Java embedded)
Pick
Invoke(nonBlocking property set on PL)
Non-idempotent activity(Invoke, receive) is encountered.
Types of BPEL Process

When and how dehydration occurs differ based on process types. Based on the dehydration we can categorize process in to 2 categories

1. Transient Process: Oracle BPEL server dehydrates the process instance only at the end of the process. If server crashes in middle of the running process instance, the instances will not be visible in EM
2. Durable Process: 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.

When Dehydration Occur

1. When the BPEL instance encounters a mid-process breakpoint activity (not including the initial receive).

Activities like wait, receive, pick, 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 mid process breakpoint activities.

1. 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 non-idempotent 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 effect as one invocation.
E.g. Read only services, Receive activity

1. 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.
Note: A BPEL invoke activity is by default (true) 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.
Skipping dehydration

• Skipping dehydration will increase performance with a cost of auditing.
• By Default, all BPEL processes are dehydrated regardless of whether they are Synchronous or Asynchronous process.
• For Synchronous processes that do not need to be durable, you can turn off the dehydration mechanism by setting the following properties at process or engine level:
  • Set inMemoryOptimization to true.
  • Set completionPersistPolicy property to faulted or Off.
• Asynchronous process invocation messages are always saved to the dehydration store.
• Durable process are always dehydrated regardless of the settings of the persistence properties.

Dehydration Tables

1. Cube_Instance: Stores the information about the composite instance that gets created.
2. Cube_scope: Stores information about the scopes and variables declared and used.
3. DLV_Message: All the incoming payload details are stored.
4. Invoke_Message: All the outgoing message payload details are stored.
5. Audit_Trail: Used to store information of the xml that is rendered in EM console.

Working with Multiple Webservices In BPEL

In this blog we will discuss how we can create BPEL using multiple operations in WSDL

   Scenario:  We will take the example of four basic mathematic binary operations (addition, subtraction, multiplication, division) to demonstrate this.  Our task is to build a web service that has four different operations.  The condition however we have is to do that only one BPEL Process.  We cannot have four BPEL process implementing four different web services.

   Step wise discription provided to implement the process

  Step 1: create an Empty BPEL process project  ‘MultipleWSDLoperations’ (Define Interface later template )
Step 2: Add a new schema MAthCalculations.xsd  to the BPEL process project.  In this example I used simple types for input and output.  You may have complex types depending on your business use case. Also as all operations are binary and all of them share the same input and output signature, Request and Response elements are reused in this example.  You may have different Request Response element types/structure. You can declare them in the same schema file.

Step 3:     create my WSDL with the required Operations in it. My WSDL uses the schema created in the previous step

   <?xml version="1.0" encoding="UTF-8" ?>
<definitions targetNamespace="tns:MAthCalculationWSDL"
             xmlns="http://schemas.xmlsoap.org/wsdl/"
             xmlns:tns="tns:MAthCalculationWSDL"
             xmlns:xsd="http://www.w3.org/2001/XMLSchema"
             xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
             xmlns:mime="http://schemas.xmlsoap.org/wsdl/mime/"
             xmlns:ns2="http://www.example.org"
       xmlns:soap12="http://schemas.xmlsoap.org/wsdl/soap12/">
               
   
  <types>
    <xsd:schema targetNamespace="tns:MAthCalculationWSDL/types"
                elementFormDefault="qualified">
 <xsd:import namespace="http://www.example.org" schemaLocation="xsd/MathCalculations.xsd" />
 </xsd:schema>
  </types>
  <message name="MathoperationrequestMessage">
    <part name="MathoperationInputmessage" element="ns2:Inputvales"/>
  </message>
  <message name="MathoperationresponseMessage">
    <part name="MathoperationOutputmessage" element="ns2:Outputvales"/>
  </message>
  <portType name="MathOperation">
    <operation name="add">
      <input message="tns:MathoperationrequestMessage"/>
      <output message="tns:MathoperationresponseMessage"/>
    </operation>
    <operation name="Substract">
      <input message="tns:MathoperationrequestMessage"/>
      <output message="tns:MathoperationresponseMessage"/>
    </operation>
    <operation name="Multiply">
      <input message="tns:MathoperationrequestMessage"/>
      <output message="tns:MathoperationresponseMessage"/>
    </operation>
    <operation name="Divide">
      <input message="tns:MathoperationrequestMessage"/>
      <output message="tns:MathoperationresponseMessage"/>
    </operation>
  </portType>
</definitions>

  Step 4: add a partner link using the WSDL above. Name this ‘client’ with Role as ‘Provider’.  This action imports the WSDL and adds a partnerLinType tag to the imported WSDL.


 <plnk:partnerLinkType name="MathOperation_PL">
     <plnk:role name="MathOperation_Role">
     <plnk:portType name="tns:MathOperation"/>
      </plnk:role>
    </plnk:partnerLinkType>


and also  Namespace as : xmlns:plnk="http://schemas.xmlsoap.org/ws/2003/05/partner-link/"

During this step also create two global variables ‘inputVariable’ and ‘outputVariable’ for the Request and Response data using the Project WSDL.

You can directly add sourcecode  in  Bpel

<variables>
        <!-- Reference to the message passed as input during initiation -->
        <variable name="inputVariable"
                  messageType="ns1:MathoperationrequestMessage"/>

        <!-- Reference to the message that will be sent back to the requester during callback -->
        <variable name="outputVariable"
                  messageType="ns1:MathoperationresponseMessage"/>
</variables>

note: the code above creates two global variables namely  inputVariable,outputVariable

Step 5:  add a pick activity to the empty BPEL process,. This activity waits for the occurrence of one event in a set of events and performs the activity associated with that event. In our case an event translates to a web service operation.  If more than one of the events occurs, then the selection of the activity to perform depends on which event occurred first. If the events occur nearly simultaneously, there is a race and the choice of activity to be performed is dependent on both timing and implementation. As our implementation is going to be state-less atomic services, we may not have a racing condition.  Coming back to the pick activity The pick activity provides two branches, each one with a condition. When you double-click the pick icon, the pick activity shown in figure below, appears and displays these two branches: onMessage (on the left) and onAlarm (on the right). The onMessage branch contains the code for receiving a reply, for example, from a loan service. The onAlarm branch contains the code for a timeout, for example, after one minute. Whichever branch completes first is executed; the other branch is not. The branch that has its condition satisfied first is executed.

 Step 6:  delete the alarm branch (from BPEL Source) as we will not be using it.  Also add 3 more onMessage branches to implement all the four operations in the WSDL.

Create a webservice with the created "MAthCalculationWSDL" above

 Step 7: for each of the onMessage branch, associate the WSDL operation as shown below.

Create 4 variables namely
OnMessage_add_InputVariable
OnMessage_Substract_InputVariable
OnMessage_Multiply_InputVariable
OnMessage_Divide_InputVariable

with respective Operations
add
Substratct
Multiply
Divide




Now you have a BPEL process that can branch based on the operations invoked by the client.

 Step 8:  implement the mathematical operations under each branch and provide a synchronous response to the client.  Add a simple assign step followed by reply activities  to achieve this.






 

For each Assign  assign activities  I use a simple copy operation to perform the mathematical operation.

   Same as for 4 Assigns add simple copy operations to define the Mathematical fuction we implement

Step 9: In each of the reply activities assign the output variable and partner link
                              Deploy and test the service.


                                                                         
                                                                                                                    By-DeepthiReddy