- Mediator provides sophisticated error handling capabilities that enable you to configure a Mediator service component for error occurrences and corresponding corrective actions.
- Error handling enables a Mediator to handle errors that occur during the processing of messages and also the exceptions returned by outside web services.
- You can handle both business faults and system faults with Mediator.
System faults occur because of some problem in the underlying system such as a network not being available. Mediator provides fault policy-based error handling for system faults. Fault policies enable you to handle errors automatically or through human intervention.
Mediator fault policy-based error handling consists of the following three components:
• Fault policies
• Fault bindings
• Error groups
Fault Policies:
A fault policy defines error conditions and corresponding actions. Fault policies are defined in the fault-policies.xml file.
Fault policies for sequential routing rules are handled differently than for parallel routing rules. Due to the single threading of sequential routing rules, only three actions (Abort, Rethrow, and Java) are supported for handling errors, and the specified actions areexecuted immediately in the caller's thread.
Fault policies are not supported for the following:Fault policies for sequential routing rules are handled differently than for parallel routing rules. Due to the single threading of sequential routing rules, only three actions (Abort, Rethrow, and Java) are supported for handling errors, and the specified actions areexecuted immediately in the caller's thread.
• Callback execution failures
• Fault Handler action failures
• Resequencer failures
Fault Bindings:
Fault bindings associate fault policies with composites or components, and are defined
in the fault-bindings.xml file.
Fault policies can be created at the following levels:
Composite: You can define one fault policy for all Mediator components in a composite.
<composite faultPolicy="ConnectionFaults"/>
Component: You can define a fault policy exclusively for a Mediator service component. A component-level fault policy overrides the composite-level fault policy.
<component faultPolicy="ConnectionFaults">
<name>Component1</name>
<name>Component2</name>
</component>
Reference: You can define a fault policy for the references of a Mediator component.
<reference faultPolicy="policy1">
<name>DBAdapter3</name>
</reference>
Note:
- The level of precedence for fault policies is Reference -> Component -> Composite.
- Human intervention is the default action for errors that do not have a fault policy defined.
You can specify an action for an error type or error group while defining the conditions in a fault policy. medns:mediatorFault indicates that the error is a Mediator error, whereas medns:TYPE_FATAL_MESH refers to an error group. An error group consists of one or more child error types. TYPE_ALL is an error group that contains all Mediator errors.
Error handling with Fault policy and Fault binding:
User case 1: Notify an email to the desired recipient when there is any error in the mediator.
Right click on project⇾New⇾From Gallery
Search with Policy and select Fault Policy Documnent
Select the fault. here I selected mediator faults,
Select the default action. here I selected the default-termination
Creates condition to have a TYPE ALL group error.
Open the Expression builder and put contains($fault.mediatorErrorCode, "TYPE_ALL")
Create Alert
Here we are selecting email.
Provide the email properties like To and CC field. Property set is not mandatory for email.
Select the created email alert.
Go the composite flow and click the Edit Composite Fault Polices option
Bind the policy to the composite or component or reference section as required.
Test and receive the error over mail.
fault-policies.xml
<?xml version="1.0" encoding="UTF-8"?>
<faultPolicies
xmlns="http://schemas.oracle.com/bpel/faultpolicy"
xmlns:bpelx="http://schemas.oracle.com/bpel/extension"
xmlns:bpel1="http://schemas.xmlsoap.org/ws/2003/03/business-process/"
xmlns:bpel2="http://docs.oasis-open.org/wsbpel/2.0/process/executable"
xmlns:medns="http://schemas.oracle.com/mediator/faults"
xmlns:rjm="http://schemas.oracle.com/sca/rejectedmessages">
<faultPolicy id="policySet">
<Conditions>
<faultName name="medns:mediatorFault" xmlns:medns="http://schemas.oracle.com/mediator/faults"
description="All Mediator faults">
<condition>
<test>contains($fault.mediatorErrorCode, "TYPE_ALL")</test>
<action ref="default-termination"/>
<alert ref="emailProperties"/>
</condition>
<condition>
<action ref="default-termination"/>
</condition>
</faultName>
</Conditions>
<Alerts>
<Alert id="emailProperties">
<email>
<To>test1@test.com</To>
<CC></CC>
</email>
</Alert>
</Alerts>
<Actions>
<Action id="default-termination">
<abort/>
</Action>
<Action id="default-human">
<humanIntervention/>
</Action>
<Action id="default-java">
<javaAction className="oracle.integration.platform.faultpolicy.IFaultRecoveryJavaClass" defaultAction="default-termination"/>
</Action>
<Action id="default-replay">
<replayScope/>
</Action>
<Action id="default-rethrow">
<rethrowFault/>
</Action>
<Action id="default-ws">
<invokeWS uri="WebServiceURI"/><!-- format - <Absolute wsdl path>|service name|port name -->
</Action>
<Action id="default-enqueue">
<enqueue uri="QueueURI"/> <!-- QueueURI format - jdbc:oracle:thin:@<host>:<port>:<sid>#<un>/<pw>#queue -->
</Action>
<Action id="default-file">
<fileAction>
<location>FOLDER_LOCATION</location>
<fileName>FILE_NAME</fileName><!-- FILE_NAME will support %ID%(rejected message instance id) or %TIMESTAMP% wildcards -->
</fileAction>
</Action>
<Action id="default-retry">
<retry>
<retryCount>3</retryCount>
<retryInterval>2</retryInterval>
</retry>
</Action>
</Actions>
<Properties>
</Properties>
</faultPolicy>
</faultPolicies>
Use Case2 : When there is any mediator error, Using fault policy and fault binding, publish the error details into a JMS Queue.
Click here 12c-soa-oracle-mediator-part5-error-handling-usecase2.html
No comments:
Post a Comment