12c SOA - Oracle Mediator part6 - Dynamic routing - Override a Static Routing Rule using DVM

"The basic idea behind dynamic routing is to separate the control logic, which determines the path taken by the process, from the execution of the process. Dynamic routing enables you to dynamically route messages at runtime from a mediator to multiple target services, based on the message content. You can use Domain Value Maps (DVMs) or Decision Components (Business Rules) to override static routes at runtime."

Dynamic Routing using DVM:

Use Case: There are two providers viz. Provider1 and Provider2 both of which are based on the same abstract WSDL. The Mediator has to invoke Provider1 or Provider2 based on the input. The logic for this mapping is:

If the input is Provider1 then invoke Provider1
If the input is Provider2, invoke Provider2

Create the composite where we will implement the Dynamic Routing via mediator. The composite contains a mediator(based on the Abstract WSDL we created earlier), a Service client and a Reference which points to the Provider1.

Open the mediator and click on Assign Values and map the input

 Now, click on Override. This will allow you to define a DVM that will be used for the routing. Enter the Name and Location of the DVM and then Set the values as shown in the screenshot below

Here we basically do two things:
Set the Value Expression and Key Domain: This allows the request input to be used as a key in the DVM
Set the feature we want to override: For this case, we override only the EndpointURI. For values that are not to be overidden, set it to <<Not Override>>.
When we chose DVM for the routing, JDeveloper creates the DVM and auto-populates the rows. For our use case, we require only the Keys and the endpointURIs (which we have mentioned as the value to be overridden) .

 Assign the sync reply part.

Deploy and Test
Input is provider1 and provider1 service invoked.

 Input is provider2 and provider2 service invoked.

12c SOA - Oracle Mediator part5 - Error Handling

Use Case : When there is any mediator error, Using fault policy and fault binding, publish the error details into a JMS Queue.

Read Previous blog 12c-soa-oracle-mediator-part4-error-handling for more details.

Create a Distributed Queue and connection factory.

 Add  JMS Alert action

 Add a Header value.

 Create required Properties

 Provide Destination and CF details.

 Press ok.

 Select the created JMS Alert.

 Deploy and test. The mediator failed and stored into the Queue.

Error message:

<commonfault xmlns="http://schemas.oracle.com/soa/fault">

<faultID>1560021</faultID>

<flowID>1730097</flowID>

<compositeDN>POC/MediatorFaultPolicyProject!1.0</compositeDN>

<componentName>MediatorFaultpolicyCheck</componentName>

<errorCode> 3302</errorCode>

<engineType> mediator</engineType>

<faultName> {http://schemas.oracle.com/mediator/faults}mediatorFault</faultName>

<faultType> SYSTEM</faultType>

<message>ORAMED-03302:[Exception in oneway execution]Unexpected exception in one-way operation &quot;execute&quot; on reference &quot;MediatorResequencerProject&quot;.Possible Fix:Check whether the reference service is properly configured and running or look at exception for analyzing the reason or contact Oracle Support Services. Cause: oracle.j2ee.ws.client.jaxws.JRFSOAPFaultException: Client received SOAP Fault from server : The composite &quot;POC/MediatorResequencerProject!1.0*soa_0ad97452-27c1-4e45-afa0-6993a0abc094&quot; is retired. New instances cannot be initiated.</message>

</commonfault>

Fault policy:

<?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="jmsProperties"/>

                </condition>

                <condition>

                    <action ref="default-termination"/>

                </condition>

            </faultName>

        </Conditions>

        <Alerts>

            <Alert id="jmsProperties">

                <JMS propertySet="jmsPropertySet">

                    <Headers>

                        <property name="MSG_ID">1</property>

                    </Headers>

                </JMS>

            </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>

            <propertySet name="jmsPropertySet">

                <property name="jmsDestination">jms/SOAErrorQueue</property>

                <property name="connectionFactory">jms/SOAErrorQueueConnectionFactory</property>

            </propertySet>

        </Properties>

    </faultPolicy>

</faultPolicies>

12c SOA - Oracle Mediator part4 - Error Handling

• 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.

Business faults are application-specific and are explicitly defined in the service WSDL file. You can handle business faults by defining the fault handlers in Oracle JDeveloper at design time.
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:
• 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.

Error Groups in Mediator:
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