Last Tuesday Ted Farell gave a short technical presentation about JDeveloper 11g in the Oracle offices in the Netherlands. Not too much new information, especially if you’ve downloaded the preview of JDeveloper 11. But the good news is that a new preview will be available soon, probably the begining of October.
ADF Faces has improved quite a bit in release 11. You’ll be able to render AJAX based webpages, including drag and drop and tables that retrieve new rows in the fly while you move the scrollbar. Charts can be rendered in flash and svg. JDeveloper 11g allows you to set up templates, and visually modify the editable sections in JDeveloper. You will also be able to visually create composite components which can be reused in multiple pages.
Another bit improvement in JDeveloper 11 is MDS, Metadata services. MDS will contain all modification and customization to an application. For more info see Oracle Webcenter.
Oracle is moving towards more and more declarative development, but different from the way it worked in Oracle Designer. Declarative mostly means xml files, for example bpel processes or jsf pages. All these declarative pieces of your application can be customized and these customizations will be stored in MDS (either in a database or in files). Previously, you would use code generators to turn your declarative application definition into runable code. According to Ted Farell, the problem with this approach is that it’s hard to monitor. You are not running what you defined. The current approach is different in that your declarative components are actually running (the bpel specification, the jsf page), and when monitoring and debugging you are seeing what you defined.
I’m not sure i fully agree with this statement. At least in the case of JSF/JSP the code generation has just moved, from compile time, to just before runtime. I’ve opened generated java source code quite often to debug jsp problems.
The next release of ADF will allow you to create ADF Data Controls which can be used in MS-Office. This will enable you to use for example Excel as a gui tool, while implementing your business and data layer in java.
Also new in the next release of ADF Faces is the Activity Guide. This is a UI component for BPEL processes.
Faults
In bpel-processes we can categorize the faults into: business faults and runtime faults. Business faults are application specific faults and will occur when we use the “throw”-activity or if we invoke a partnerlink which returns with some fault. It’s up to the “business” to decide what needs to be done when the fault occurs and what activities are needed for handling it.
Besides the business faults we have the runtime faults. Runtime faults will not be defined by the user, so we need to design parts in the process to handle them. In bpel we will make use of the catch-activity for this. In the catch itself we can invoke our own fault-handling processes or do some other activities (retry etc) which are needed to get a valid situation again.
Oracle made a nice technote for some good information about all the possible faults and some extra faults defined by Oracle Process Manager.
Framework
In the good old days (before patch 10.1.3.3) we needed to design the fault-handling part for every bpel-process.
Possibilities were there by making use of for example some Error Hospital, but still, every process individually needed changes for being able to handle faults.
With the latest patch for the Oracle Soa Suite (10.1.3.3) , Oracle provided a new Fault Management framework. This framework will gives us the opportunity to handle all the business and runtime faults for an “invoke” activity. With the framework we can define 1 policy for every bpel domain.
In a so called “fault-binding” (/bpel/domains/default/config/fault-policy-binding.xml) , we can setup which policies we’re going to use and which processes/partnerlinks/porttypes will be part of it. The framework will use the binding in order of the following priority :
- bpel.xml
- policy defined on the server
In a so called “fault-policy” (/bpel/domains/default/config/fault-policies/DefaultPolicy.xml), we can define what type of faults we want to catch and what actions need to get executed.
If there is already some fault-handling (catch) defined in the the bpel process, the framework will overrule this, and use a policy if possible.
fault-policy-binding
The fault-bindings will be defined on the next location : /bpel/domains/default/config/fault-policy-binding.xml
The xsd-schema for the fault-bindings can be found on this location : /bpel/system/xmllib/fault-policy-binding.xsd
< ?xml version="1.0" encoding="UTF-8"?>
<faultpolicybindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<!-- Enabling this will cause all processes in this domain to use this
fault policy
<process faultPolicy="DefaultPolicy"/>
-->
<!-- DefaultPolicy is defined in ./fault-policies/DefaultPolicy.xml -->
<partnerlink faultPolicy="DefaultPolicy">
<!-- Enabling this will cause all invoke faults at partner link
name of "creditRatingService" to use fault policy with
id id = DefaultPolicy
<name>creditRatingService
-->
<!-- all invoke faults at partner link below port type use fault policy
with id = DefaultPolicy
The following entry covers the samples/tutorials/122.DBAdapter/InsertWithCatch sample. -->
<porttype xmlns:db="http://xmlns.oracle.com/pcbpel/adapter/db/insert/">db:insert_plt</porttype>
</partnerlink>
</faultpolicybindings>
In the policy we can define on several levels (process,partnerLink,portType) if we want to make use of a policy. In the comment of the xml you will see what needs to be turned on or off to apply to policy.
fault-policies
The fault-policies will be defined on the next location : /bpel/domains/default/config/fault-policies. The xsd-schema for the fault-policies can be found on this location : /bpel/system/xmllib/fault-policy.xsd.
Oracle delivers the following policy by default.
< ?xml version="1.0" encoding="UTF-8"?>
<faultpolicy version="2.0.1" id="DefaultPolicy"
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">
<!-- This section describes fault conditions. Build more conditions with faultName, test and action -->
<conditions>
<!-- Fault if wsdlRuntimeLocation is not reachable -->
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault">
<condition>
<action ref="ora-retry"/>
</condition>
</faultname>
<!-- Fault if location port is not reachable-->
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:bindingFault">
<condition>
<action ref="ora-rethrow-fault"/>
</condition>
</faultname>
</conditions>
<actions>
<!-- This action will attempt 8 retries at increasing intervals of 2, 4, 8, 16, 32, 64, 128, and 256 seconds. -->
<action id="ora-retry">
<retry>
<retrycount>8</retrycount>
<retryinterval>2</retryinterval>
<exponentialbackoff />
</retry>
</action>
<!-- This is an action will cause a replay scope fault-->
<action id="ora-replay-scope">
<replayscope />
</action>
<!-- This is an action will bubble up the fault-->
<action id="ora-rethrow-fault">
<rethrowfault />
</action>
<!-- This is an action will mark the work item to be "pending recovery from console"-->
<action id="ora-human-intervention">
<humanintervention />
</action>
<!-- This action will cause the instance to terminate-->
<action id="ora-terminate">
<abort />
</action>
</actions>
</faultpolicy>
A policy consists of a conditions-section and an actions-section.
In the conditions-sections we will define which faults need to be handled and which actions will be executed.
<conditions>
<!-- Fault if wsdlRuntimeLocation is not reachable -->
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault">
<condition>
<action ref="ora-retry"/>
</condition>
</faultname>
</conditions>
In this part of the code the framework will “catch” all remoteFaults and execute the ora-retry action.
<condition>
<test>$fault.code/code="INVALID_WSDL"</test>
<action ref="ora-terminate"/>
</condition>
In this part of the code we will check if the fault-code = “INVALID_WSDL”. The action to be executed is : ora-terminate.
Oracle delivers a few default actions as part of the framework. At this moment that list isn’t extensible. If we still need some custom fault-handling we could make use of the ora-java action. This action will allow us to make us of some custom java, and inhere we will be able to decide what to do with the fault.
Default available actions :
- ora-retry ( retry the activity )
- ora-replay-scope ( replay the scope in which the fault occurred )
- ora-rethrow-fault ( system will throw the fault to the bpel fault handlers )
- ora-human-intervention ( the current activity will freeze. In the console the user will be able to take several actions on this
- instance )
- ora-terminate ( terminate instance )
- ora-java ( execute custom java )
Lets practice!
To show how the framework works we will build a little example. We deployed a simpe java webservice (helloWorld). We also build a little bpel-process with a few steps in it (assign and invoke of the java service).As part of the error-handling we added a catch on the remoteFault. In the catch we won’t be doing any fault-handling, just the catch and an assign to the output.
![]()
To generate a remoteFault we undeployed the javaservice from the oc4j, and executed the bpel-process again. After executing again, the process will fall into the catch we defined.
![]()
We will not change the structure of the process, and only define a new policy on the server.
First step is to define the fault-binding. fault-bindings.xml:
< ?xml version="1.0" encoding="UTF-8"?>
<faultpolicybindings version="2.0.1"
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<process faultPolicy="BlogTestPolicy"/>
<!-- DefaultPolicy is defined in ./fault-policies/DefaultPolicy.xml -->
<partnerlink faultPolicy="BlogTestPolicy"/>
</faultpolicybindings>
The policy is named “BlogTestPolicy” and all processes and partnerlinks will use it.
Next step is to define the policy. BlogTestPolicy.xml:
< ?xml version="1.0" encoding="UTF-8"?>
<faultpolicy version="2.0.1" id="BlogTestPolicy"
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">
<!-- This section describes fault conditions. Build more conditions with faultName, test and action -->
<conditions>
<!-- Fault if wsdlRuntimeLocation is not reachable -->
<faultname xmlns:bpelx="http://schemas.oracle.com/bpel/extension" name="bpelx:remoteFault">
<condition>
<action ref="ora-retry"/>
</condition>
<condition>
<action ref="ora-human-intervention"/>
</condition>
</faultname>
</conditions>
<actions>
<!-- This action will attempt 8 retries at increasing intervals of 2, 4, 8, 16, 32, 64, 128, and 256 seconds. -->
<action id="ora-retry">
<retry>
<retrycount>8</retrycount>
<retryinterval>2</retryinterval>
<exponentialbackoff />
</retry>
</action>
<!-- This is an action will cause a replay scope fault-->
<action id="ora-replay-scope">
<replayscope />
</action>
<!-- This is an action will bubble up the fault-->
<action id="ora-rethrow-fault">
<rethrowfault />
</action>
<!-- This is an action will mark the work item to be "pending recovery from console"-->
<action id="ora-human-intervention">
<humanintervention />
</action>
<!-- This action will cause the instance to terminate-->
<action id="ora-terminate">
<abort />
</action>
</actions>
</faultpolicy>
We defined a policy which will handle all remoteFaults. When a remoteFault occurs, the framework will be able to execute two actions. First it will do the “ora-retry” action, if the fault still occurs the next action will be executing the “ora-human-intervention” action. After creating the policy we restart the oc4j-container to make sure the policy will be active.
**update
To chain the actions, in this example we just added 2 actions after each other. This won’t work, and only the last action will get executed. The way to do this is to use the retryFailureAction-element in the action.
for example :
<action id="ora-retry">
<retry>
<retrycount>5</retrycount>
<retryinterval>10</retryinterval>
<retryfailureaction ref="ora-human-intervention"/>
</retry>
</action>
Before we start testing the framework we make sure we still use the same situation as in the beginning. We have undeployed the javawebservice which we will invoke in the bpel process. We left the catch in the process. On the server we defined the policy. This policy will now handle the remoteFault instead of the “catch” in the bpel.
Execute the process. When we look in the console at the instance of the process we see this :
The catch in the bpel itself isn’t getting fired. When we look in the audit trail, we notice the next message :
![]()
It looks like our policy is active. The framework applied the policy. So it first executed the ‘ora-retry’ action (no output on this) and after this it executed the ‘ora-human-intervention’ action. So at this point we should be able to apply some other actions on the faulted activity (the invoke of the webservice).
From here we have 2 options. The first is the activities-tab. On this tab we will find all activities executed, and which faulted with the faultname. On the left we select the ‘Pending’ state in the ‘Activity State’ checkbox. On the right we will see the faulted invoke of our webservice. If we select the checkbox on the left of the activities we can make use of the ‘bulk update’- functionality on more then 1 instance. We select the invoke activity and in the listbox we can select one of the following actions :
- Retry
- Abort
- Rethrow
- Replay
- Continue
The second option is the ‘interactions’-tab available in the view when we selected the faulted instance.
![]()
In here we will find all the activities from the current process-instance. Select the invoke-activity (sayHello). In the next screen we will see some sort of Error Hospital. Notice the new State of the current instance : open.pending.recovery.
![]()
We will be able to update all the payload of the variables of the activities in the process, execute different actions on them, chain the outcomes or just created new instances.
First select the variable in the “Available Variables”-listbox for which we want to update the payload. Click the get-button. In the textarea we’re now able to insert different payload. After inserting the correct values, click the set-button and go to the “Actions available”-listbox and select the appropriate action. The last step is to either choice to recover the current instance, or create a new one.
In our scenario we redeployed the webservice, so the wsdl is reachable again. We updated the sayHello inputvariable just to see some changes in the updated instance later on. After this we just click the Recover-button. Select the visual flow, and click on the invoke activity (sayHello).
![]()
As we can see in the output. The payload of the inputVariable of the sayHello has been updated and the framework executed the retry after it. We redeployed the webservice, so it was reachable again, and the invoke executed correct too.
I hope with the information in this article the functionality of the new fault policy framework is a bit clear.
