12c SOA - Oracle Mediator part3 - Echo

• Mediator can echo source messages back to the initial caller without routing the message to another target.
• Echo option is used when we don’t have target service available ,we expose Mediator functionality as target service and Echo a response to initial caller . Suppose we are doing query from target service but that target service is down due to some reason , in this case to test our Mediator we use Echo, we will create sample query response message and pass that to calling service as a Echo.
• This is typically used in use cases where a certain message has to be enriched, or some filtering to be done, etc.

I will show you how we can create one sample Mediator project to show Echo functionality.

Implementation:
Create one project and add Mediator to it. Name it as “MediatorEcho” and made it as Synchronous.

 Note: we can also use custom xsd for the echo mediator.

 Go to Mediator mplan file and open one static routing rule.

 Choose “Echo Reply” from available options.

 Do the required mapping and map all the fields which we want to send to initial caller as Echo.

 Deploy and test.

12c SOA - Oracle Mediator part2 - Resequencer

"The Resequencer in Mediator rearranges a stream of related but out-of-sequence messages into a sequential order. When incoming messages arrive, they may be in a random order. The resequencer orders the messages based on sequential or chronological information, and then sends the messages to the target services in an orderly manner. The sequencing is performed based on the sequencing strategy selected."

Mediator can resequence the incoming messages in a user-specified order. This implementation enables you to specify three types of resequencing orders:

• Standard Resequencer
• FIFO Resequencer
• Best Effort Resequencer

Mediator Processing without Resequencing:

Standard – Processes transactions contiguously within a Group, based on a defined Group and Sequence ID.  Groups are processed in parallel.

FIFO (First-In-First-Out) – Processes transactions based on the time they are received by the Resequencer.

Best Effort – Processes transactions based on Sequence ID in increasing order at predefined intervals. Best Effort transaction processing is not always contiguous.

Implementation using Standard type:

• When using the standard resequencer in Mediator, you must always specify a group XPath expression and a sequence ID XPath expression. These specify where theMediator resequencer can find the group and the sequence ID in the messages. 
• You must also supply the sequence numbering in terms of the start sequence ID and the sequence ID incremental delta. This numbering is used to form each group. 
• In addition to the group, sequence ID, and increment properties, you can also specify a timeout period, in seconds, to wait for the expected messages.

The Mediator standard resequencer holds back messages in the Mediator resequencer database until it can produce the right sequence for different groups. This situation means that if for a given group, the message with a particular sequence ID does not arrive within the timeout period, the subsequent messages for that group are held back forever. In such a case, you must manually unlock the group through Oracle Enterprise Manager Fusion Middleware Control and go to the next available message,
skipping the pending message.

Schema used:

<?xml version="1.0" encoding="windows-1252" ?>

<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.emp.poc" targetNamespace="http://www.emp.poc"

            elementFormDefault="qualified">

  <xsd:element name="process">

    <xsd:complexType>

      <xsd:sequence>

        <xsd:element name="empID" type="xsd:string"/>

        <xsd:element name="empType" type="xsd:string"/>

        <xsd:element name="empName" type="xsd:string"/>

      </xsd:sequence>

    </xsd:complexType>

  </xsd:element>

</xsd:schema>

Create a SOA project and above schema file and drag and drop mediator

 Use One way Interface and use the schema.

 Choose Re-sequence level as Component.

 Choose Resequence mode as Standard.

 Select the Xpaths for Group and ID. Here we use empType as Group and empID and ID.

For the Resequence Level we can select ‘operations’ or ‘component’.

For Mediator components which only have 1 operation it doesn’t matter which one we select. For a Mediator component which consists of more then 1 operation and selecting the ‘component’ option means resequencing is applied to all operations in it. For this test we selected the ‘component’ option and used the ‘Standard’ mode.

About options to configure the re-sequencer.

Group – xpath expression to the field in the payload which the resequencer will use to group our incoming messages

ID – xpath expression to the field which will uniquely identify our message

Start – Start value of the ID in the incoming message

Increment – Value which will be used for the increment of the id field in the upcoming messages

Timeout – Time to wait before a following expected message arrives at the Mediator component

 Create a file adapter to write the files in a local directory.

 Now wire it

 Do the transformation

 Deploy to the server and test

test with ID= 1 and Group = TMP

 test with ID= 3 and Group = TMP

 Observed that the transaction (id=3) went to running state and waiting for the ID=2 which is not processed yet.

 Test with ID=2 and group=TMP

 Now 1st process ID=2 and then ID=3.

Implementation using FIFO Resequencer:

• The FIFO resequencer supports a standard first in, first out (FIFO) pattern.The FIFO resequencer receives a stream of messages that are in order and processes them in sequence for each group based on the arrival time of the messages.
• When using the FIFO resequencer, you must always specify a group XPath expression. However, you do not need to specify a sequence ID because the messages are processed according to the time of arrival to the Mediator service component that isconfigured for FIFO resequencing. The group XPath expression specifies where the FIFO resequencer should find the group information in the message to group the messages. No further configuration is needed for a FIFO pattern.

Test with ID=1 and group=PERM

 Test with ID=3 and group=PERM

 Test with ID=2 and group=PERM

 Its processed 1,3 and 2 in FIFO manner.

Implementation using Best Effort Resequencer:

• The best effort pattern is useful for applications that produce a large number of messages in a short period and cannot provide information to the resequencer about the identifier to use for sequencing. Typically, the identifier used for sequencing in Resequencing Order such scenarios is of a dateTime type or numeric type. Using the dateTime field as the sequence ID XPath enables you to control the sequencing. The messages are expected to be sent in sequence by the applications, thus the date and time the messages are sent can be used for sequencing. The Mediator makes the best effort to ensure that the messages are delivered in sequence.

• The best effort resequencer can reorder messages based on no knowledge about the increment of the sequence ID. This situation means that unlike the standard resequencer, you do not need to define the increment of the sequence ID for the best effort resequencer in advance. When the messages are processed, they are processed in sequence based on the specified sequence ID and the messages that have arrived, whether a true sequence is received. The sequence IDs are either numeric or dateTime. Therefore, sequencing occurs on the numeric order or the dateTime order of the sequence IDs.

When using the best effort resequencer, you must specify a group XPath expression, a sequence ID XPath expression, and the data type of the sequence ID (numeric or dateTime). These specify where the resequencer should find the group and the sequence ID in the messages and how to handle the sequence ID. In addition, you must specify either a maximum number of rows to select for each resequencing batch or a time window during which the messages included in one batch arrive. Unlike the standard resequencer, the best effort resequencer has no knowledge about how the sequence is built. No further information

Example of Best Effort Resequencing Based on Maximum Rows
In this example, msgX(Y,Z) indicates that the message arrives as message number X to the Mediator service component and the message contains sequenceID Y and group Z.

Group C 
msg03(1,c)
msg06(2,c)
msg10(3,c)
msg12(4,c)

Sequenced Messages
msg12(4,c),msg10(3,c),msg06(2,c),msg03(1,c)

Example of Best Effort Resequencing Based on a Time Window
In this example, the time window is 10 minutes, the buffer is 10% (one minute), and msgX(Y) indicates that the message arrives as message number X to the Mediator service component and the message contains the sequence ID Y. The first message arrives at 2:00:00, which starts the time window. The time window lasts until 2:10:00, but with the addition of the buffer time, messages that arrived until 2:11:00 are processed.

Group C
Message/Time
msg01(04)/2:00:00
msg02(05)/2:00:20
msg03(01)/2:00:30
msg04(03)/2:00:50
msg05(07)/2:04:20
msg06(02)/2:04:45
msg07(13)/2:05:10
msg08(08)/2:05:40
msg09(06)/2:08:40
msg10(12)/2:09:20
msg11(10)/2:10:30
msg12(09)/2:10:40
msg13(14)/2:10:50
msg14(11)/2:13:00

Sequenced Messages
msg03(01), msg06(02), msg04(03), msg01(04), msg02(05),
msg09(06), msg05(07), msg08(08), msg12(09), msg11(10),
msg10(12), msg07(13)

Note:
In the above example, the resequencer identified the maximum sequence ID for the time window as 13 (from message 7). Message 13 arrived within the buffer time, but has a sequence ID of 14. It is not processed with the original group, but instead begins a new time window at its arrival time of 2:10:50. Message 14 arrived too late and is included in the second time window.

12c SOA - Oracle Mediator part1 - Introduction

Introduction to Oracle Mediator:

• Oracle Mediator provides a lightweight framework to mediate between various components within a composite application such as business processes, human workflows, and so on, using a Web Services Description Language (WSDL) document as the interface.
• Oracle Mediator facilitates integration between events and services, where service invocations and events can be mixed and matched. You can use a Mediator component to consume a business event or to receive a service invocation. A Mediator component can evaluate routing rules, perform transformations, validate, and either invoke another service or raise another business event. You can use a Mediator component to handle returned responses, callbacks, faults, and timeouts.
• Mediator follows V-E-T-R-O pattern.(where V=validation, E=Enrichment, T=Transformation, R=Routing and O=Operation).

This section provides an overview of Oracle Mediator features:

• Content-Based and Header-Based Routing
• Synchronous and Asynchronous Interactions
• Sequential and Parallel Routing of Messages
• Message re-sequencing
• Data Transformations
• Payload Validations
• Java Callouts
• Event Handling
• Dynamic Routing
• Error Handling
• Multiple Part Message Support
• Mediator Echo Support

Content-Based and Header-Based Routing
Mediator enables you to define rules based on the message payload or message
headers. You can select elements or attributes from the message payload or the
message header and, based on the values in those elements or attributes, you can
specify an action. For example, Mediator receives a file from an application or service
containing data about new customers. Based on the country mentioned in the
customer's address, you can route and deliver data to the database storing data for
that particular country. Similarly, you can route a message based on the message
header.

Synchronous and Asynchronous Interactions
Mediator supports both synchronous and asynchronous request and response
interactions. In a synchronous interaction, the client requests a service and then waits
for a response to the request. In an asynchronous interaction, the client invokes the
service, but does not wait for the response. You can specify a timeout period for an
asynchronous interaction and you can specify an action to perform after the timeout
period, such as to raise an event or start a process.
Mediator also supports event-based interactions. Events are one-way (fire-and-forget)
asynchronous interactions.

Sequential and Parallel Routing of Messages
Mediator lets you specify that a routing rule be executed either in parallel or in
sequence. You can configure the execution type from the Routing Rules section of the
Mediator Editor.
Click here 12c-soa-oracle-mediator-Sequential-vs-Parallel to know more details on sequential vs parallel routing rules.

Message Re-sequencing
When you use the Mediator resequencer, it rearranges streams of related but out-of sequence
messages into their sequential order based on the type of resequencer used
and the rules you define. When incoming messages arrive in a random order, the
resequencer orders the messages based on sequential or chronological information,
and then sends the messages to the target services in the correct order based on the
resequencing configuration.
Click here mediator-resequencer-implementation to know about Mediator resequencer implementation.

Data Transformation
Mediator lets you define data transformation from one XML schema to another. This
feature enables data interchange among applications using different schemas. For
example, you can transform a comma-delimited file to an XML schema that is
compatible with a database.

Payload Validation
You can configure Mediators to validate the incoming message payload using a
Schematron or an XSD file. You can specify Schematron files for each inbound
message part and Mediator executes Schematron file validations for those parts.
Click here for implementation details 12c-soa-oracle-mediator-schematron

Java Callout
Oracle Mediator provides support for Java callout. Java callouts enable the use of Java code, together with regular expressions.
Check for implementation 12c-soa-oracle-mediator-java-callout

Event Handling
An event is message data sent because of an occurrence of an activity in a business environment. Oracle Mediator provides support for subscribing to business events or raising business events. You can subscribe to a business event that is raised when a situation of interest occurs. For example, you can subscribe to an event that is raised when a new customer is created and then use this event to start a business process such as sending confirmation email. Similarly, you can raise business events when a situation of interest occurs. For example, raise a customer created event after completing the customer creation process.
click here 12c-soa-event-delivery-network-edn to know about Mediator and BPEL EDN implementation.

Dynamic Routing
Dynamic Routing separates the control logic, which determines the path taken by the process, from the execution of the process. You can create a dynamic routing rule from the Mediator Editor.
Click here for implementation 12c-soa-oracle-mediator-part6-dynamicrouting-Using-DVM

Error Handling
Oracle Mediator supports both fault policy-based and manual error handling. A fault policy consists of conditions and actions. Conditions specify the action to be carried out for a particular error condition.
Click here for implementation 12c-soa-oracle-mediator-part4-error-handling

Mediator Echo Support
Oracle Mediator supports echoing source messages back to the initial caller after any transforms, validations, assignments, or sequencing are performed.
Click here 12c-soa-oracle-mediator-part3-echo to know about Mediator Echo implementation.

Multiple Part Message Support
Mediator can process messages that consist of multiple parts. Some Remote Procedure
Call (RPC) web services contain multiple parts in the SOAP message.


Difference between Mediator and BPEL:
Mediator is particularly useful for content based routing of events, and as a listener for events. BPEL of course offers more possibilities for business logic and would generally be suited to defining process logic. A more complex SOA composite likely includes both components and others as well.

Mediator serves the purpose of a bus. It can be best utilized when used for routing. It can do routing based on many parameters and the best part is, the routing rules can be modified at runtime, thus giving the flexibility to choose the target at any point in time.
BPEL
1) Complex Logic
2) Good Support language in form of”activities”
3) Performance wise very slow
4) Support of Dehydration and Instance Monitoring
5) For Long Running process BPEL is the Right Solution
6) To implement the controlled Transactions
Integration of Rules Engine and Human Workflow
7) To implement the service virtualization BPEL is not the right approach

Mediator
1) Less Complex Logic
2) Less Support
3) Three times faster than BPEL
4) No support of dehydration
 5) For Long Running process not a proper solution
6) You cannot control the transactions in Mediator.
7) Mediator is the right approach for the service virtualization

Mediator vs. Oracle Service Bus (OSB)
Mediator
The “tiny”, “light weight” service bus
Limited to simple Mediator functionality for the implementation of the VETRO pattern
V alidade
E nrich
T ransform
R oute
O perate
Value Mapping and Cross-Reference Table for supporting the canonical datamodel
Development through JDeveloper IDE
Event Delivery Network for Publish-Subscribe semantic
Message Transformation with XSLT
Can be used and deployed as a SCA component
Oracle Service Bus (OSB)
The large, powerful service bus
Extended functionality important for enterprise-wide Integration, like
Message Throttling
Service Pooling
Reliable Messaging
Development through Eclipse IDE or Web Console(in 11g).
Message Transformation over XQuery and XSLT
OSB specific deployment
In 12c, its integrated with SCA.