Configure Auto Recovery In Weblogic

 
 
Oracle SOA Suite 11g has some great features to recover faulted instances automatically. When a BPEL process flow errors out, it is retried with all its invocations. This is undesirable in some cases. For example if re-calling a composite results in duplicated data, data have been changed before the recovery is planned to be executed or you do not want to create too many composite instances in order to save the space in your SOAINFRA-schema. See below the different places where automatic recoveries are configured / disabled.
1) Change RecurringScheduleConfig (see also the screenshot below) 

• Right-click soa-infra (SOA_cluster_name) 
• Choose SOA Administration > BPEL Properties 
• Click "More BPEL Configuration Properties" 
• Click "Recovery Config" 
• Change values for RecurringScheduleConfig 
• maxMessageRaiseSize = 0 
• startWindowTime = 00:00 
• stopWindowTime = 00:00 
• Click Apply 

2) Change StartupScheduleConfig (see also the screenshot below)

• Right-click soa-infra (SOA_cluster_name)
• Choose SOA Administration > BPEL Properties
• Click "More BPEL Configuration Properties"
• Click "Recovery Config"
• Change values forStartupScheduleConfig
• maxMessageRaiseSize = 0
• startupRecoveryDuration = 0
• subsequentTriggerDelay = 0
• Click Apply

 
 
The properties startWindowTime and stopWindowTime specify the period during which Auto Recovery is active. By default auto recovery feature will be active from 12AM to 4AM everyday (remember that it’s SOA server time), shown in above screenshot. We can change these settings by simply updating the time values in 24 hr format and do click on Apply.
The property maxMessageRaiseSize specifies the number of messages to be sent in each recovery attempt, in effect resembles the batch size.
The property subsequentTriggerDelay specifies interval between consecutive auto recovery attempts and the value is 300 sec by default.
The property threshHoldTimeInMinutes is used by BPEL engine, to mark particular instance eligible for auto recovery once the recoverable fault occurs which is 10 min by default.
If we observe closely, none of these properties mention about number of recovery attempts to be made which is altogether a separate MBean property. To set, navigate to soa-infra -> SOA Administration -> BPEL Properties -> More BPEL Configuration Properties -> MaxRecoverAttempt. The default value is 2.


To disable ‘Auto Recovery’, set the maxMessageRaiseSize property value to 0. 


3) Change GlobalTxMaxRetry
The property GlobalTxMaxRetry specifies how many retries are performed if an error is identified as a retriable one. For example, after several web service invocations, if dehydration fails due to a data source error, then this is identified as a retriable error and all activities from the prior dehydration state are retried. If the activities being retried are not idempotent (that is, their state can change with each retry and is not guaranteed to give the same behavior), then multiple retries can be problematic.
You can set GlobalTxMaxRetry to 0 in the Systems MBean Browser.

• Right-click soa-infra (SOA_cluster_name)
• Choose SOA Administration > Common Properties
• Click "More SOA Infra Advanced Configuration Properties"
• Click "GlobalTxMaxRetry"
• In the Value field, enter an appropriate value
• Click Apply

BPEL Recovery Console:
Navigate to soa-infra -> Service Engines -> BPEL -> Recovery to view the recoverable instances. Note that, the console shows all recoverable instances irrespective of enabled/disabled ‘Auto Recovery’. We can manually recover the  faulted instances from this console when Auto recovery is not enabled.




Auto Recovery Behavior:
Whenever a recoverable fault (this term is more abstract, I verified this behavior with Remote, Binding and User Defined Faults) occurs during the BPEL processing, it will be visible in Recovery console. If Auto Recovery is enabled, after threshHoldTimeInMinutes BPEL runtime will try to auto recover the instance. If it’s not successful, again number of recovery attempts will be made as given for MaxRecoverAttempt with an interval as given for subsequentTriggerDelay. If instance fails even after these maximum recover attempts, the instance will be marked as exhausted (can be queried on recovery console using message state as exhausted). We can use ‘Reset’ button to make these instances eligible for Auto Recovery again.
Note that, we observe this behavior only when the fault is thrown back to BPEL runtime or fault is not caught within BPEL process.


 

Base64 Binary Encoding and Decoding - BPEL 11G

Hi Guys,

Sometimes there are requirements where we receives request from consumer in opaque/binary format or we may have to interact with applications using binary format.To facilitate this requirement Java embedding activity is used in BPEL.I will be demonstrating how to convert string to binary format and vice verse.

For this use case I have already created a BPEL process that will receive string in string format.In the BPEL code I have added 2 java embedding activities one for encoding and one for decoding the data.

 

Firstly, I will encode the payload received in binary format using below code:

addAuditTrailEntry("Encoding started");       
try {       
oracle.xml.parser.v2.XMLElement input = (oracle.xml.parser.v2.XMLElement) getVariableData("inputVariable","payload","/ns1:encode/ns1:PIN-NUMBER");       
java.lang.String input_str = input.getTextContent();       
addAuditTrailEntry("Input String = "+input_str);       
oracle.soa.common.util.Base64Encoder encoder = new oracle.soa.common.util.Base64Encoder();           
java.lang.String encoded = null;          
encoded = encoder.encode(input_str);       
addAuditTrailEntry("encoded string = "+encoded);       
setVariableData("EncodeVar",encoded);       
} catch (Exception e) {       
  addAuditTrailEntry("Exception: "+e.getMessage());       
}       
addAuditTrailEntry("Encoded ended");

Pass the input variable name in the input string and create one more variable of 64binary format that will store the encoded string.

Now, we will decode the string that we encoded in previous step using below code:

addAuditTrailEntry("decoding started");
String encodedString = (String)getVariableData("EncodeVar");
Base64Decoder Decoder = new Base64Decoder();
addAuditTrailEntry("encoded String = "+encodedString);
try
{
String decoded = Base64Decoder.decode(encodedString);
addAuditTrailEntry("decoded string = "+decoded);  
setVariableData("Decodedvar",decoded);
}
catch(Exception e)
{
  addAuditTrailEntry("Exception: "+e.getMessage());
}

Create one more variable of string type that will contain the decoded string.In this case we will pass the variable we created in previous step as input.Decoded string will be stored in variable we created for storing decoded string.

Now, we will test our composite to verify the changes we have made.String passed is encoded using 1st java embedding activity and decoded using second java embedding java activity.

Happy Learning

                                                                                                                By Deepthi Reddy

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