How to make a custom fault handling for a BPEL process
Every SOA application needs to establish a set of rules for handling faults. In this blog I will show you how to make a custom fault handling for a BPEL process. Usually in the BPEL processes this is possible thanks to the fault-policies.xml. In it are defined all the actions that can be done when […]
Every SOA application needs to establish a set of rules for handling faults. In this blog I will show you how to make a custom fault handling for a BPEL process.Usually in the BPEL processes this is possible thanks to the fault-policies.xml. In it are defined all the actions that can be done when an error occurs. The policies that can be used in the application are defined in the fault-bindings.xml. They can affect different scope of the SOA application - service components, BPEL process or even the whole SOA application.The basic construction of the fault-bindings.xml and fault-policies.xml documents represents a rule that is applied for all types of faults and for the whole SOA application. They are usually located in the same directory as the composite.xml of the SOA application.
But how should we construct our policy if we need a single different rule for a single BPEL?
First we should define a new policy that affects only the desired BPEL in
fault-bindings.xml
The whole fault-binding.xml document content should look like this:
After that we will define the rules for this policy inside the tag in the fault-policies.xml
Defined like this the default action for our policy will be for any type of fault to rethrow that fault. Remember, if we want to apply the rules only for a specific fault (runtime fault for example) we should define it inside the tag <Conditions> like this:
The human intervention action stops the current activity from processing and waits for manual recovery that can happen when the user logs in the Oracle Enterprise Manager.
Retry the setted number of times in the <retryCount>.
Exponential back off indicates the next retry attempt will increase double the retry delay starting with the <retryInterval> value.
If the activity has reached the maximum retry counts, retryFailureAction will be executed.
Sign up for our newsletter and never miss an article
[mc4wp_form id=8036]
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.