Montag, 15. Oktober 2012

Fault Management Framework - Part 4

Configuration of composite.xml

The policy files are stored either locally or in the same folder where the composite.xml-file resides. The other option is to store them in a central place for unique error handling, e.g. in the Meta Data Repository (MDS). The folder is configured by two properties in the composite.xml-file. This configuration is used instead of other possible locally stored policy files.

Example of a central policy file
In this example the fault policy file is stored in the central SOA metadata store

<property name="oracle.composite.faultPolicyFile">oramds://folderpolicyfiles fault-policies.xml
</property>
<property name="oracle.composite.faultBindingFile">oramds://folderpolicyfiles/ fault-bindings.xml
</property>

You have to keep in mind, that a fault policy which is configured in the fault management framework overwrites an error handling in a catch activity inside a scope in a BPEL process. Nevertheless, the fault framework can be configured this way that the error is given to the catch activity

Montag, 8. Oktober 2012

Fault Management Framework - Part 3

Putting conditions and actions into the policy file

 The conditions in fault-policies.xml can be used to categorize errors into types:

·         Mediator-specific errors

·         Business- and SOAP-errors

·         Adapter-specific errors

By using the <test> element you can evaluate and filter the $fault.mediatorErrorCode. Following error types exist in the mediator component:

·         TYPE_ALL – all mediator errors

·         TYPE_DATA – for data related errors

·         TYPE_METADATA – for metadata related errors

·         TYPE_FATAL – for fatal errors

·         TYPE_TRANSIENT – for resolvable errors

These groups have sub-groups like e.g. TYPE_FATAL_DB for fatal database errors.

Example for Database-Adapter:  

<faultName

       xmlns:bpelx="http://schemas.oracle.com/bpel/extension" 

       name="bpelx:bindingFault">

        <condition><!—ORA-02292: Integrity constraint violated -->

            <test>$fault.code=”2292”</test>

            <action ref="ora-terminate"/>

        </condition>

    </faultName>

By using the <javaAction> it is possible to execute an external java class. This java object has to implement the interface IFaultRecoveryJavaClass, which returns a string of handleFault(). Different return values lead to another action, depending on the return value. If no <returnValue> elements are defined, the defaultAction will be executed.

    <Action id="ora-java-execute">

         <javaAction className="com.xxxxpackage.faultpolicy.UserJavaAction"  defaultAction="ora-terminate" propertySet="someProperty">

                <returnValue value="TERMINATE" ref="ora-terminate"/>

                <returnValue value="RETRY" ref="ora-retry"/>

                <returnValue value="HUMAN" ref="ora-human-intervention"/>

          </javaAction>

    </Action>
 
There will be a part 4 next week...

Dienstag, 2. Oktober 2012

ADF Essentials: Free version of Oracle ADF

The long waited for FREE version of Oracle's Application Development Framework has arrived!

"ADF Essentials" will contain most features of the original ADF. Unfortunately the SOA Suite integration part and ADF mobile will not be contained in the new ADF version.

The free ADF will run on the Glassfish OpenSoure Application Server, so no Weblogic Server is necessary!

Hope this will help spreading ADF in the community!

More information can be found in this german newsletter:

http://www.doag.org/home/aktuelle-news/article/adf-essentials-doag-begruesst-erscheinen-der-kostenfreien-version-von-adf.html

or on the Oracle Homepage:

http://www.oracle.com/technetwork/developer-tools/adf/overview/adfessentials-1719844.html

Freitag, 28. September 2012

Fault Management Framework - Part 2


Structure of a fault-bindings.xml file

The fault policy bindings file fault-bindings.xml, which is located in the same directory, binds the policies of the fault policy file with

·         The SOA composite application
·         The BPEL processes and Oracle Mediator components
·         The reference binding components for BPEL processes and Oracle Mediator Service components

<faultPolicyBindings>
 <composite>
 <component>
  <name>
 <reference>
  <name>
  <portType>

The framework identifies the fault policy bindings in the following order:

·         Reference Binding Component
·         BPEL Process or Oracle Mediator Service Component
·         SOA Composite Application

If no condition is found during evaluation, the execution checks the next level.


Example of fault-bindings.xml file

This example associates the fault policy with the composite application

<?xml version="1.0" encoding="UTF-8" ?>
<faultPolicyBindings version="2.0.2"
 xmlns="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="ApplicationProcessingFaults"/>
</faultPolicyBindings>

Another example with definitions for BPEL / Mediator Components and definitions for references of an external service

<?xml version="1.0" encoding="UTF-8"?>
<faultPolicyBindings version="2.0.2"
 xmlns="http://schemas.oracle.com/bpel/faultpolicy"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<composite faultPolicy="Connection_Faults"/>
<component faultPolicy="Service_Faults">
<name>Komponente1</name>
</component>
<reference faultPolicy="Service_Faults">
<name>Service1</name>
<name>Reference2</name>
<portType xmlns:credit="http://xxxxxxx">xxxxxxService</portType>
<portType xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/insert/">db:insert_plt</portType>
</reference>
<reference faultPolicy="test1">
<name>name3</name>
</reference>
</faultPolicyBindings>
Part 3 will follow...

Donnerstag, 20. September 2012

Fault Management Framework - Part 1

A colleague of mine just held a presentation about the fault management framework in Oracle SOA Suite 11g. With her permission, I publish the essential points here.

Oracle SOA Suite 11g provides a fault framework for handling errors in composites and BPEL processes. With this feature a consistent error handling for SCA components is possible.

Structure of fault-policies.xml

The policy file fault-policies.xml has an XML structure and contains conditions for errors (error names an XPath functions for the content) and actions, which can be executed. These are: retry, human intervention, replay scope, rethrow fault, abort, custom Java action.

<faultPolicies>
 <faultPolicy>
  <Conditions>
   <faultName>
    <condition>
     <test>
     <action>
  <Actions>
   <Action>
    <retry>
    <humanIntervention>
    <rethrowFault>
    ….

Furthermore process instances can be accessed during runtime. For example, if an action results in a user intervention, recovery actions can be initiated in the EM console.

Examples of a fault-policies.xml file

In this example the action “ora-retry” is allocated to all BPEL errors
The actions tries a repitition 2 times with an interval of 5 seconds. In case of error the “Human Intervention” will be executed afterwards.

<?xml version="1.0" encoding="UTF-8" ?>
<faultPolicies xmlns="http://schemas.oracle.com/bpel/faultpolicy">
  <faultPolicy version="2.0.2"
        id="ProcessingFaults"
               xmlns:env="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xs="http://www.w3.org/2001/XMLSchema"
               xmlns="http://schemas.oracle.com/bpel/faultpolicy"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
    <Conditions>
     <faultName xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault">
        <condition>
            <action ref="ora-retry"/>
        </condition>
    </faultName>
      </Conditions>
     <Actions>
      <Action id="ora-retry">
        <retry>
          <retryCount>2</retryCount>
          <retryInterval>5</retryInterval>
          <exponentialBackoff/>
          <retryFailureAction ref="ora-human-intervention"/>
        </retry>
      </Action>
      <Action id="ora-rethrow-fault">
        <rethrowFault/>
      </Action>
      <Action id="ora-human-intervention">
        <humanIntervention/>
      </Action>
    </Actions>
  </faultPolicy>
</faultPolicies>

Part 2 will follow...