Title Script
Hi, my name is Swarnapriya Shridhar and I will be presenting Oracle SOA Suite
11g:Mediator Component Overview. This course will introduce you to the Oracle
Mediator component and provide an insight on how to create an Oracle Mediator service
component . Enjoy!
Using The Player Script
Before we begin, now might be a good time to take a look at some of the features of this
Flash-based course player. Feel free to skip this slide and start the lecture if you’ve
attended similar Oracle eStudy courses in the past.
To your left, you will find a hierarchical course outline. This course enables and even
encourages you to go at your own pace, which means you are free to skip over topics you
already feel confident on, or jump right to a feature that really interests you, or go back
and review topics that were already covered. Simply click on a course section to expand
its contents and then select an individual slide. However, note that by default we will
automatically walk you through the entire course without requiring you to use the outline.
Standard Flash player controls are also found at the bottom of the player, including pause,
previous, and next buttons. There is also an interactive progress bar to fast forward or
rewind the current slide. Interactive slides may have additional controls and buttons along
with instructions on how to use them.
Also found at the bottom of the player is a panel containing any additional reference
notes for the current slide. Feel free to read these reference notes at the conclusion of the
course, in which case you can minimize this panel and restore it later. Or if you prefer
you can pause and read them as we go along.
Various handouts may be available from the Attachments button, including the audio
narration scripts for this course.
The course will now pause, so feel free to take some time and explore the interface. Then
when you’re ready to continue, click the next button below or alternatively click the
Lesson 1 slide in the course outline at left.
Course Roadmap
This course introduces the features of the Oracle Mediator component. It describes the
various functionalities of the Mediator component, which facilitates communication
between different interfaces exposed by different components, which are wired together
to build a SOA composite application.
In this course the topics that you will be introduced are:
 Introduction to the Mediator Component
 Creating Routing Rules
 Data Transformation
 Domain Value Mapping
 Testing Transformation Maps
Lesson 1
Welcome to Lesson 1: Introduction to the Mediator Component
Now let’s meet Sheila who is working as a Technical Architect in a fictitious company.
She has been working in the client-server technology area for a while and is keen in
understanding the Services Oriented Architectural Style as a possible solution to
integrating applications. She has an understanding of the Oracle SOA Suite 10g and
would now like to know the working of the various service components of the Oracle
SOA Suite 11g.
As a first step, this lesson introduces the Mediator component and its features to Sheila.
Introduction to the Mediator Component
First let us understand what a Mediator component is.
A Mediator component routes data between a service client and target services within a
composite application. Oracle Mediator provides a lightweight mediation framework to
mediate between various producers and consumers of services and events. The challenge
of integrating data from disparate sources (including business partners, legacy
applications, enterprise applications, databases, and custom applications) can be met by
using Oracle Mediator to deliver appropriate real-time data access to all applications that
update or have a common interest in the same data.
Oracle Enterprise Bus and Mediator
In SOA Suite 11g, Run-time ESB in not present. Instead, there is a modular architecture
that consists of a common service infrastructure (shared with the other components of the
SOA Suite) and a routing engine (called the Mediator). The service infrastructure is the
common normalized transport into which are plugged the service components, such as
the BPEL service components or the Mediator service components.
Features of Mediator Component (an Articulate Interaction)
Event Handling
Now let us delve a little deeper into each of the features.
Talking about event handling, the mediator component provides support for subscribing
to or raising business events delivered through the Oracle SOA Suite 11g Event Delivery
Network.
If you look at the example that has been graphically represented, you will notice that an
event is raised when a new customer is created. This event is then used to initiate a
business process such as sending an email confirmation to the customer. One could
subscribe to this event.
Content – Based and Header – Based Routing
Having talked about event – handling, let us have a look at another feature of the
mediator component which is Content – Based and Header – Based Routing.
Mediator routing rules provide a filter mechanism that defines conditions based on
message content and message header. In the example that has been shown, a customer
updates her profile and changes the name of the country. The mediator component
evaluates the condition, raises an event to figure out the data store where this information
needs to be routed to and routes the information appropriately.
Synchronous and Asynchronous Interactions
A mediator component supports synchronous as well as asynchronous interactions with a
target service. An synchronous interaction could be one- way or two way. In the example
that has been graphically represented, a customer places an order for couple of items.
Tracking the order related information based on the postal code would be an
asynchronous interaction. But trying to validate the credit card status of the customer who
place the order and then letting the customer know if the order is fulfilled or not would be
a synchronous interaction.
Service Virtualization
One of the most important feature of a mediator component is Service Virtualization
The mediator component provides service virtualization within a composite application
that enables separating the client from the physical implementation. The example shows
initial implementation that contains a Mediator component whose interface is exposed to
the client. The Mediator component routes the message to a BPEL component in this
example.
In the modified implementation, the Mediator interface remains exposed and unchanged
from the client application perspective. However, the Mediator Routing Rule is modified
to route messages to another composite application instead of a BPEL component. In this
case, the main composite application implementation has changed without impact on the
interface used by the client application.
Validations
A mediator component provides support for validating the incoming message payload
using either a schematon or an XSD file. You can use an XSD file for structural
validation and for a semantic validation you can use a schematron file.
Transformations
One of the key features of the mediator component is converting data from one XML
schema format to another. This enables data interchange and enrichment between
applications using different schemas. For example, the initial XML schema may have the
City and the zipcode as separate values while the other XML schema may have both the
city and zipcode stored as one value. Through transformations, you can concatenate the
city and zipcode from the initial schema before it reaches the resultant XML schema.
Error Handling
The mediator component supports fault-policy based error handling. A fault policy
consists of conditions and actions. A condition specifies the action to be carried out for a
particular error condition. We shall look into this in closer detail as we move on.
Now that we have seen the various features of a mediator component we shall now see
how to create a mediator component and the various options available to do so.
Creating a Mediator component
You can create an Oracle Mediator component any time that you want to consume a
business event or receive a service invocation. Oracle Mediator components can be
created in Oracle JDeveloper by using a service invocation or an event subscription as the
entry point. In order to create a mediator component you can:
Drag and drop a Mediator component from the Component palette or
Select “Composite with Mediator” in the Create SOA Composite dialog box or the Create
SOA Project dialog box
Select Service Components from Categories and Mediator from the Items in the New
Gallery dialog box
Mediator Component Creation Options
When you first create the Mediator component, a dialog box appears where you need to
specify the name of the mediator component and choose one of the options from the list
of templates available for creating the mediator. The different options available are:
• The Define Interface Later option which enables you to create a Mediator first, and
later define the interface for the services or subscribing to events.
• The Asynchronous Interface option which enables you to create a Mediator
component for asynchronous interaction.
• The Synchronous Interface option which enables you to create a Mediator
component for synchronous interaction.
• The One-Way Interface option which enables you to create a Mediator component
for a one-way interaction process. In this case, the client sends a message to the
service, and the service does not need to reply or even acknowledge the receipt of the
message.
• The Interface Definition from WSDL option which enables you to define services
for the Mediator component from a WSDL file. A WSDL file describes the interface
of a Mediator such as schemas and operations.
• The Subscribe to Events option which enables you to subscribe to a business event
that is raised when a situation of interest occurs.
Creation of a Mediator without Interface Definition (Articulate Interaction)
Creating a Mediator based on WSDL Interface (Articulate Interaction)
Effects of Creating a Mediator component
When a Mediator component is added to a composite application the Composite Editor
creates a <component> element in the composite.xml file (which is a SCA descriptor)
that references the component implementation file. The file that are added to the project
are:
•
•
•
A .componentType file that describes the services and references for each service
component. This file tracks the wiring created between components and ensures
that the wires work as designed.
A .mplan file that contains the Mediator implementation details, such as routing
rules, links to transformations, filters, validations, and references to target
services.
A .wsdl file, that is created if you specified interface definition for the
component.
Deleting a Mediator component
The mediator component can be deleted either by right – clicking on the mediator
component and selecting delete or by selecting the Delete Selected Items icon in the SOA
Composite Editor tabbed page toolbar. After doing so confirm that you want to delete the
selected component and save your changes.
Modifying a Mediator component
You can modify a mediator component explicitly or implicitly. To explicitly modify the
mediator component you need to double click the mediator component icon in the
composite editor window and then make the changes in the Mediator Editor.
To implicitly modify the mediator component you can wire the mediator components to
other components in the composite editor window.
Lesson Review
In this lesson, we covered:





The features of the Mediator component
Creating a Mediator component
The different options available for creating a mediator component
The effects of creating a mediator component and
Modifying and Deleting a mediator component
Next, answer a series of simple questions to make sure you are ready to move on. (Quiz)
Lesson 2: Creating the Mediator Routing Rule
The objective of this lesson is to introduce
 The different types of routing rules
 How to define a routing rule
 Adding a routing rule for various options
 Creating a static or dynamic routing rule
 Configuring a routing rules and message filters and
 Configuring validations
Introducing Routing Rules
The routing rule determines how a message processed by a mediator component reaches
its next destination. The routing rules specify where a mediator component sends the
message, how it sends it and what changes should be made to the message structure
before sending it to the target service. The details that can be specified when configuring
routing rules are:
 The target service to which the message should be sent
 The filter expression that needs to be applied. For example, you may apply a filter
expression that specifies that a service needs to be invoked only if the message
includes a customer ID.
 The execution type which specifies the way in which routing rules will be
executed
 The schematron files for validating different parts of an inbound message
 Transformations that need to be applied and
 How the reply, callback and fault handlers need to be handled.
Types of Routing Rules
The mediator component enables you to create two types of routing rules - Static and
Dynamic.
Static routing can be created for an event subscription, an incoming operation for an
synchronous and asynchronous service interaction.
Dynamic Routing Rules can only be created for asynchronous interactions. A Dynamic
Routing Rule configures a Business Rules component that uses a decision table to
determine the target endpoint to which a message is routed through a dynamic external
service interface.
A Dynamic Routing Rule cannot be added to an operation that has Static Routing Rules
configured
Defining Routing Rules (Articulate Interaction)
Using the Routing Panel
The Routing Rules Panel of the mediator editor can be used to define the routing rules.
The Mediator Editor can be accesses either from the SOA Composite Editor or from the
Applications Navigator.
Adding a Routing Rule for an Echo option (Articulate Interaction)
Adding a Routing Rule to a Published Event (Articulate Interaction)
Creating the Published Event
When creating a Routing Rules to publish an event, when you click Event on the Target
Type window, the Event Chooser window is displayed first. To create a new event
definition for the event to be published in the Event Chooser window performs the
following steps:

On the Event Chooser window, click the “Create new event definition (edl) file”
(lightning) icon. The Event Definition Creation window is displayed.

On the Event Definition Creation window, you can enter a name for the event
definition (edl) file and the XML namespace to be associated with the event
definition.

On the Event Definition Creation window, to add the new event definition click
the “Add an Event” (green plus) icon. The “Add an Event” window is displayed.

On the “Add an Event” window, enter a name for the event. This name is the
published event name, and click the Browse (searchlight) icon to locate a XML
element from an XSD file in the project or that you can import into the project.
Click OK. This adds the new event definition into the Event Definition Creation
window, and associated edl file.

On the Event Definition Creation window, you can add additional events using
the preceding steps before you click OK to complete event definitions. You are
returned to the Event Chooser window, where you select the specific event to be
published and click OK. The example shows only one event in the Event Chooser
window.
Adding a Dynamic Routing Rule [Articulate Interaction]
Configuring a Routing Rule
Depending on the interaction type (synchronous or asynchronous, one or two way) you
can defined how synchronous reply, asynchronous callback, and fault messages are to be
handled for each Routing Rule.
The different properties that can be configured are:
 Target Service
 Filter Expression
 Execution Type
 Validation and
 Transformations
Setting the Target Service
There are different ways to set the target service for a Mediator component Routing Rule.
One of the ways is by wiring a mediator component to another component or service
reference. The other way is by adding a routing rule and selecting the Target Type.
Clicking the “Browse for target service operations” icon for an existing Routing Rule,
and selecting a new Target Type, is yet another way of setting a target service for a
routing rule.
Handling Synchronous and Asynchronous Responses and Faults
Handling response and fault messages depends on whether the interactions are
synchronous or asynchronous.
For a synchronous interaction, you can:
• Specify the transformations and assignments for the response and the fault message or
• Forward the response and the fault message to another service or event. Alternatively,
you can send them to the initial caller, if it expects responses and faults.
For a asynchronous interactions, you can:
• Specify a timeout period, in seconds, hours, days, months, or years, for receiving the
response. By default, there is no timeout. If a callback response does not arrive before
the timeout period expires, then a timeout response can be forwarded to another
service, event, or returned to the initial caller.
Configuring Message Filter
In order to create a message filter firstly click on the filter icon. On the expression builder
window, you need to build the conditional expression.
For example, if you want notices of new product launches to be routed to three different
stores: one in New York, one in Houston, and another in San Francisco you need to
create a Routing Rule for each target store and use a filter expression based on the
content element containing an value on which a suitable expression can be built.
Configuring Validation
Inbound messages to a Mediator component can be validated in the following two ways –
 One of the ways is by selecting the Validate Syntax (XSD) option for an
operation. The Mediator Engine validates the XML inbound payload syntactic
structure for all messages, such as incorrect element names, or invalid data type
values.
 The other way is by supplying a Schematron file in the Validate Semantic field of
a Routing Rule for an operation. Schematron validation enables validation of the
data within the payload, such as checking a value is non-zero, is between a range
of values, and more complex assertions.
Sequential and Parallel
Sequential and parallel execution enables you to manage transactional semantics.
A Mediator component always enlists itself into a global transaction propagated from a
thread processing the incoming message. For example, if an inbound JCA Adapter
invokes a Mediator component, then a transaction that the JCA Adapter initiated is
joined. A Mediator component does not commit or roll back transactions propagated by
external entities.
Sequential Routing Rules are processed sequentially in the same thread and transaction as
the caller. A transaction propagates through the same thread as the target components.
Parallel Routing Rules are queued and processed in parallel within different threads. A
new transaction is initiated in each parallel thread, in which a message is read from the
Database store and sent to the invoked target component. A transaction is propagated to
the target component, and commits or rolls back within its own thread.
For an operation or event with both sequential and parallel execution, sequential Routing
Rules are performed first, and then parallel rules queued for executed.
Lesson Review
In this lesson, we covered:


The different types of routing rules
How to define a routing rule and how you can add a routing rule to publish an
event or for the echo option
We also delved into configuring routing rules and validations and lastly
We also covered the concept of sequential and parallel routing rules



Next, answer a series of simple questions to make sure you are ready to move on. (Quiz)
Lesson 3: Transformations
The objective of this lesson is to introduce
 How to create and Configure Transformations
 Using the XSLT Mapper to define simple and complex mapping, mapping
repeated element and conditional mapping and
 Adding a dictionary for Auto mapping
Transformations
Now that Sheila understands how to create routing rules, she would like to go a step
further and understand how to transform data from one XML schema to another.
Creating Transformations in Mediator Routing Rule
Transformations in Mediator are implemented via routing rules you create for the
Mediator component. The XSLT Mapper tool enables transformations in the routing rules
that you create for a Mediator component. For example, you can map incoming source
purchase order schema to an outgoing invoice schema.
Configuring Transformations (Articulate Interactions)
Editing with XSLT Mapper (Articulate Interactions)
Mapping Types and Tools
The XSLT mapper enables defining simple mapping where a source element maps oneto-one directly to a target. You can also define complex mapping using built-in and user
defined functions. Using the XSLT Mapper you can map repeated elements with the for –
each operation as well as define conditional mapping by either applying the if operation
or the choose operation. The Automap tool also enables the XSLT Mapper to apply rules
to map source to their respective target elements.
We shall now see how to add a function to a transformation
Adding a Function to a Transformation (Articulate Interaction)
Modifying a Function Parameter
To modify the parameters of a function usage:
1.
Double-click the function icon in the XSLT Mapper window to open the Edit
Function window for that function.
2.
On the Edit Function - <function name> window, enter or select appropriate
values for parameters.
In addition, the Edit Function window provides help text to describe the function
parameters and its usage. Some Edit Function fields provide flashlight icons that are used
to browse for values in the context of the function.
Chaining Functions
The result of one function can be linked to the input of another function, and so on,
enable building complex functional expression to compute a desired result. For example,
the screen shot shows the source input element being linked as the parameter to the
upper-case function, whose result is linked to the first input parameter of the concat
function. The “Edit Function – concat” window, shows a second parameter containing a
literal string concatenated to the uppercase result of the first parameter. The result of the
concat function is linked to the input element of the target structure.
Mapping Nodes Automatically
The Automap preference window appears when mapping non-leaf (parent) nodes, and
based the Auot Map Preferences settings you select it attempts to map all relevant nodes
under the selected source and target nodes.
The settings that can be changed to control how the auto mapping is applied in the Auto
Map Preferences window are
• Confirm Auto Map Results which if selected displays a window of mappings
discovered prior to applying them
•
•
Prompt for Preferences before Auto Map which when selected causes the Auto
Map Preferences window to display when needed; otherwise the last saved
preferences are used.
The Show Dictionaries option which enables you to add one or more dictionary
files that specify matching words that should be automatically mapped.
Adding a For-Each Mapping Rule (Articulate Interaction)
Adding an IF mapping rule (Articulate Interaction)
Adding a Dictionary for Auto Mapping
A dictionary is an XML file that captures the synonyms for mapping element names. The
XSLT Mapper considers the rules defined in a dictionary when attempting to
automatically map source and target elements. You can reuse these mapping definitions
in other transformation maps by including the dictionary in the Auto Map Preferences.
To include a dictionary in your Automap Preferences first
1.
Click Show Dictionaries on Automap Preferences window
2.
Under the dictionaries field, click Add and browse for and open a XML file
containing the dictionary definitions
Creating a Dictionary for Auto Mapping
To create a new dictionary file first:
Manually create the desired mapping between source and target elements.
After creating the desire mappings, right-click the middle column of the XSLT Mapper
for your mapping diagram and click Generate Dictionary.
On the Generate Dictionary window, enter a File name for your dictionary and specify
the directory in which to place the file..
Lesson Review
In this lesson, we covered:


The different types of routing rules
How to define a routing rule and how you can add a routing rule to publish an
event or for the echo option
 We also delved into configuring routing rules and validations and lastly
 We also covered the concept of sequential and parallel routing rules
Next, answer a series of simple questions to make sure you are ready to move on. (Quiz)
The next lesson that we will be looking into is Domain Value Map
Lesson 4: Domain Value Map (Let us have a look at the objectives of this lesson)
Objectives
The objective of this lesson is to:
Introduce Domain Value Map
How you can create and populate a domain value map and
How you can use a Domain Value Map in Transformations
Introducing Domain Value Maps
A domain value map enables mapping of vocabulary in one domain to another, when
different domains represent the same data in different ways. In the example that has been
shown, you can see that we have a domain where the city name has been represented with
a long name whereas in another domain the city name has been represented with a short
name. In cases like these you can use a Domain-Value Map to directly map values
between multiple domains.
Creating a Domain Value Map (Articulate Interaction)
Populating a Domain Value Map (Articulate Interaction)
Using a Domain Value Map in Transformation
After creating a DVM you can use the DVM file in XSLT Mapper by including one of
the DVM functions. The DVM function is found under the DVM Functions menu under
the Advanced tab in the Component Palette.
In the example that has been shown graphically, in order to use the LookupValue
function, drag the lookup Value function onto the line connecting the source and the
target. In order to configure the DVM mapping rules, double click the lookup-dvm
function icon. This displays the Edit Function – lookupValue window. You need to
provide values for the following parameters:
 The dvmLocation which would be the path and name of the domain-value map
 The sourceColumnname which is the name of the domain that is used to lookup
and compare against the source Value
 sourceValue which is an Xpath expression identifying a source element, in the
source document of the XSLT transformation, whose value is compared to the
DVM sourceColumnName for a matching value.
 targetColumnName which is the domain name for the target value copied to the
target element in the XSLT mapper file.
 defaultValue which is an optional default value, if no match is found in the DVM
Once done, click OK to accept the values and apply your selection.
Lesson Review
In this lesson, we :


Introduced Domain Value Map and how one can create and populate a domain
value map
We also saw how you can use a Domain Value Map in Transformations.
Next, answer a series of simple questions to make sure you are ready to move on. (Quiz)
Lesson 4 : Testing Transformation Maps
[Course Roadmap slide]
Having learnt how to create Transformation Maps we shall now see how to test the same.
In this lesson you will see how to test transformation maps.
[Lesson Slide]
Let us have a look at the objectives of this lesson
Objectives
The objective of this lesson is to introduce the process of testing transformation maps.
Transformations
Sheila is now familiar with creating data transformations and would like to understand
how she can test these transformation maps.
In this lesson, Sheila will be familiarized with the process of testing transformation maps.
Testing Transformation Maps
Oracle JDeveloper provides a test utility to test the XML style sheet map created by the
XSLT Mapper. The test utility generates a sample source document based on the XML
Schema for the source structure. It also provides several choices of layout to view the
source XML document instance along with the XSL map used to generate the target
XML document instance, and the resulting XML document instance. The test utility also
enables you to modify and reuse a generated source XML document and the XSL
transformation file to perform additional tests.
Initiating an XSL Transformation Test
The test tool can be used to initiate the test either by right clicking in the midde column
of the XSLT Mapper or by right-clicking rthe XSL file in the application navigator and
then selecting test. Either of this approach results in the display of the Test XSL Map
window. In the Test XSL Map window you can specify the source and target XML file
name and with the Enable Auto Layout option selected , you can specify any of the
several layouts for displaying the generated or selected source XML file, the XSL map
and the XML result.
Viewing the Test Result
The screen shot shows the default auto layout option with the source XML document and
the result XML document shown side by side and above the XSL map file used to
transform the source into the target.
By default, you can retest the same XSL file with an existing generated source, even if it
has been modified.The Test XSL Map window will have cleared the Generate Source
XML File option. In this case, your saved modifications to the source file are used. You
can regenerate and overwrite the source document if required by setting the Generate
Source XML File option again.
Lesson Review
In this lesson, the process of testing transformation maps was discussed.
Next, answer a series of simple questions to make sure you are ready to move on. (Quiz)
Lesson 6 : Handling Faults in Mediator Now
[Course Roadmap slide]
Having learnt how to test transformation maps let us see how to handle faults in a
mediator component
[Lesson Slide]
Let us have a look at the objectives of this lesson
Objectives
The objectives of this lesson are:
 To understand the different types of faults
 Managing and Configuring faults in a mediator
 Understanding the fault policy file structure
Fault Handling Concepts
The two parts to designing and managing faults with service-oriented applications are
identifying and creating the fault and managing and handling the fault. Faults are returned
by Web Services instead of a response data to indicate an error condition. They can be
handled and managed using fault handlers and fault policies.
Types of Service Faults [Articulate Interaction]
Defining Business Fault
To define a business faults you can create a message structure in an XML Schema
document that stores the error information, so that the service that detects the fault
populates a message structure with the data that describes the fault condition.
The screenshot shows the following components of fault design for synchronous services:
•
In the XSD a processFault element is defined containing a simple error string
element for the fault information
• In the WSDL the process operation defines two faults, in addition to the input and
output elements. Each fault element appears visually to be the same. However,
when you add the fault elements to an operation a unique fault name must be
specified. In the example, one fault name is called fault1 and the other is called
fault2.
Managing Faults in Mediator [Articulate Interaction]
Configuring a Target Service for a Mediator Fault [Articulate Interaction]
Considering Faults with Asynchronous Mediator Components
When a Mediator component is used with asynchronous interaction, the Mediator
component can receive and route a callback response. A callback response could contain
a fault message if a service is designed in that way.
However, a Mediator component cannot handle multiple callbacks in a defined manner.
The example that has been illustrated shows one such scenario where the AsyncMediator
component returns the callback response from the AsyncEchoMediator1 and
AsyncEchoMediator2 components to the client. In such a flow, the AsyncMediator may
return the callback from the AsyncEchoMediator1 and AsyncEchoMediator2, or from
either one of them. The exact behaviour is stochastic and cannot be predicted.
Overview of the Fault Management Framework
Oracle SOA Suite 11g provides a generic fault management framework for handling
faults in composite applications containing Mediator and BPEL components. If a fault
occurs during run-time when a service is invoked, the fault management framework can
be configured to catch the fault and performs a user-specified action.
The Oracle SOA Suite 11g Fault Management Framework Defines fault policies in a file,
called fault-policy.xml and Associates fault policies with a composite application,
component, or service reference by using a fault bindings file, called fault-bindings.xml
Introducing Policy Driven Fault Handling
Fault management files, by default, are located in the same folder as the composite.xml
file.The policy file defines one or more faultPolicy’s with Conditions, and Actions. The
binding file associates a policy with an composite application, a component, or a
reference.The fault policies can replace component fault actions
Policy and binding files can be in a location specified by the
oracle.composite.faultPolicyFile property and oracle.composite.faultBindingFile property
added to the composite.xml file.
Fault Policy File Structure
The fault-policies.xml file contains one or more <faultPolicy> elements, with an id
attribute that defines a unique name for the policy. The <faultPolicy> element contains
One <Conditions> element, which is the parent for one or more <faultName> elements.
Each <faultName> element can have one or more <condition> element with an optional
<test> element and An <action> element . Besides the condition element the fault poliy
element also contains One <Actions> element, which is the parent for one or more
<Action> elements. Each <Action> element must have a unique “id” and either the Retry,
, humanintervention , rethrow fault,replay scope, javaaction or abort action.
Creating Fault Policy
The fault-policies.xml file is manually created and added to the composite application
project directory, or placed in central location for shared access.
The slide example shows how to handle all remote faults that occur in a composite
application. The bplex:remoteFault is specified (fully qualified) in the faultName
element, which contains a catch all condition that references a pre-seeded Action
identified as ora-human-intervention. The Action uses built-in humanInvention element
that causes the process to stop at the point of failure, enabling you to examine and
possibly perform recovery in Enterprise Manager Fusion Middleware Control.
Creating Fault Conditions
• Conditions can be used to categorize fault types for:
– Mediator-specific faults
– Business and SOAP faults
– Adapter-specific faults, for example a DB Adapter fault:
• Action elements contained in the Actions section define how faults are managed
Configuring a Retry Action for a Fault Condition
The Retry Action provides the following configurable options:
• retryCount which specifies the number of times to retry the operation
• retryInterval, which specifies the delay in seconds between retries
• exponentialBackoff, which is used to increase interval exponentially
• retryFailureAction, chain to action when all retries fail
• retrySuccessAction, chain to action on successful retry
Configuring a Java Action
A javaAction type:
• Enables executing an external Java class
• Returns a value (returnValue) that must be a String type
• Chains to a new action based on the return value
When using the javaAction fault policy the Java class specified must implement the
IFaultRecoveryJavaClass interface, which returns a String from its handleFault() method.
The handleRetrySuccess() method is invoked upon a successful retry attempt. The retry
policy can be chained to a Java action by using a retrySuccessAction.
The handleFault() method is invoked to execute the javaAction policy type.
Multiple return values enable you apply to another action depending on the result
returned by executing the Java code. The returnValue enables you to map (chain) to
another fault policy for additional actions.
If there are no returnValue elements included in the javaAction, the specified action in
the defaultAction value is executed
Fault Binding File Structure
Fault bindings associate fault policies with composites or components and are defined in
the fault-bindings.xml file.
You can define one fault policy for all Mediator components in a composite.
You can define a fault policy for a Mediator component exclusively. A component-level
fault policy overrides the composite-level fault policy
You can define a fault policy for the references of a Mediator or BPEL component. If you
specify the name only the policy applies to all reference portTypes (operations). To apply
the policy to a specific operation include the portType information.
Default Fault Binding
Fault bindings associate fault policies with composites or components and are defined in
the fault-bindings.xml file. Fault bindings can be defined for compocite, component and
refernce.
Lesson Review
This lesson covered
 The different types of faults
 Managing and Configuring faults in a mediator
 Understanding the fault policy file structure
Course Summary
In this course, we learned about:
•
•
•
•
•
•
Mediator Component and its Features
Difference between Enterprise Service Bus and Mediator
Mediator Routing Rules
Data Transformation
Testing Transformation Maps
Handling Faults in Mediator
How can I learn more ?
So where can you find more information of these or other Oracle SOA Suite 11g topics?
Many online resources are available including he sites shown here.
From these locations, you can download the product installers, access the online product
documentation, find additional instructor-led and self paced training course on this
product and browse and participate in product-specific customer discussion forums.
This concludes our self – paced estudy course. We at Oracle know that your time and
attention is valuable and limited, so we sincerely hope this training has met your
expectations and learning objectives.