oracle.tip.adapter.api.exception.PCRetriableResourceException
The main thing to understand here is that this is a transient connection error and can be recovered easily once the listener or database is up properly but for this purpose we can let our process throw an exception.This situation can be handled by using the retry feature in your Process.
For this we will add the following two properties in our bpel.xml
<property name="retryInterval">10</property>
<property name="retryMaxCount">10</property>
These property will tell the process to retry 10 time for a time interval of 10 seconds before throwing an exception.Normally a linstener took less than 15 seconds to up and database one minute so by specifying this time duration you can get rid of those exception.
So if you BPEL.xml is looking something like this earlier
<BPELSuitcase>
<BPELProcess ...>
<partnerLinkBindings>
<partnerLinkBinding name="OutboundPartnerLink">
<property name="wsdlLocation">Outbound.wsdl</property>
</partnerLinkBinding>
</partnerLinkBindings>
</BPELProcess>
</BPELSuitcase>
You will change it to following
<BPELSuitcase>
<BPELProcess ...>
<partnerLinkBindings>
<partnerLinkBinding name="OutboundPartnerLink">
<property name="wsdlLocation">Outbound.wsdl</property>
<property name="retryInterval">10</property>
<property name="retryMaxCount">30</property>
</partnerLinkBinding>
</partnerLinkBindings>
</BPELProcess>
</BPELSuitcase>
Even after setting the retry feature there can be situation that database make take unexpected long time to up ,In that case you will get a Remote Fault from the adapter which is nothing but the resource exception.
So again to overcome this we can use a fault handling by defining a catch block to handle the remoteFalut.
Just call the Db adapter within a scope and attach a catch activity to catch the RemoteFault.May be then within this Catch block you can again put some wait and again try to write the data in to database.This is just a scenario you can design it as per your requirement.
Again Legacy and package application adapter do not throw these retriable exception they throw a resource exception which is converted to bindingFault exception in BPEL
so if you are using Legacy and package application adapter then you need to use a catch block for binding fault.
Both Remote fault and binding fault has been pre built with BPEL.
Other option is that you can define the retry feature in your fault-binding policy also for BPEL.
In ESB if you want to use the retry feature then you can specify the retry feature in following file
SOA_HOME\integration\esb\config\esb_config.ini
It contains following data
#Retry
InboundRetryCount = 3
InboundRetryInterval = 5
InboundRetryEnabled = true
OutboundRetryCount = 3
OutboundRetryInterval = 5
OutboundRetryEnabled = true
which you can modify as per your requirement or business process.
Or if you have your esb-dt and esb-rt in separate container
you can make the change in following file
SOA_HOME/j2ee/OC4J_SOA/applications/esb-rt/META-INF/orion-application.xml
there you will find the following lines commented,uncomment them and set the values as per your requirement
<property name="InboundRetryCount" value="3" />
<property name="InboundRetryInterval" value="5" />
<property name="InboundRetryEnabled" value="true" />
<property name="OutboundRetryCount" value="3" />
<property name="OutboundRetryInterval" value="5" />
<property name="OutboundRetryEnabled" value="true" />
<property name="PingCount" value="15" />
<property name="PingInterval" value="15" />
The values set at orion-application.xml gets a precedence over the values set at esb_config.ini
Again from ESB console also you can add these properties.
Log in to esb console.
Choose the process for which you want to set the retry interval.
Go to properties tab and click on add button to add the properties there as shown below.
No comments:
Post a Comment