All docs This doc
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 10 Next »

Introduction to Message Translator

Translator will basically change the context of a message from one interface to the other so that the message passed will adhere to the message context rules of the back end service. When communicating in between several applications each of the application might use a different standard of a data type. Therefore, to successfully maintain the communication, the messages should be intermediately be translated to a data format which will be compatible to the receiving application.

Message Translator is responsible to translate a message to ensure compatibility between two applications supporting two different data types. For more information please refer    






Figure 1: Message Translator EIP

Example Scenario for the EIP

The rest of this document explains, through a typical example scenario, how the Content-Based Router EIP can be simulated using the WSO2 ESB.

The example scenario depicts an inventory for stocks and illustrates how the sender sends a request in a different format which will be transformed into a format which will be compatible through the receiver. In the given scenario the sender sends a request which contains the following format,

<soapenv:Envelope xmlns:soapenv="" xmlns:ser="http://services.samples" xmlns:xsd="http://services.samples/xsd">

 The format which is expected by the receiver is in the following format,

<soapenv:Envelope xmlns:soapenv="" xmlns:ser="http://services.samples" xmlns:xsd="http://services.samples/xsd">

The scenario explains on how the message can be translated through the WSO2 ESB to a format which is compatible by the receiving application. 

Implementing the Example Scenario in WSO2 ESB

Getting Started

The diagram below depicts how to simulate the example scenario using the WSO2 ESB.






Before digging into implementation details, let's take a look at the co-relation of the example scenario and the Content-Based Router EIP by comparing their core components.

Figure 1: Content-Based Router EIPFigure 2: Content-Based Router Example Scenario

Incoming Message

Stock Quote Request



The translation is done through the Payload Factory Mediator

Environment Setup

1. Download an install the WSO2 ESB from For a list of prerequisites and step-by-step installation instructions, refer to Installation Guide in the WSO2 ESB documentation.

2. Start an instance of Axis2 server. For instructions, refer to section ESB Samples Setup - Starting Sample Back-End Services in the WSO2 ESB Documentation.

ESB Configuration

3. Start the WSO2 ESB and copy the following configuration to the "Source View" in the management console (Main Menu -> Service Bus -> Source View), using which the example scenario can be explored.


<?xml version="1.0" encoding="UTF-8"?>
<definitions xmlns="">
   <sequence name="fault">
      <log level="full">
         <property name="MESSAGE" value="Executing default &#34;fault&#34; sequence"/>
         <property name="ERROR_CODE" expression="get-property('ERROR_CODE')"/>
         <property name="ERROR_MESSAGE" expression="get-property('ERROR_MESSAGE')"/>
   <!-- Will trigger when a request is sent to the ESB --> 
   <sequence name="main">
		 <!-- Will transform the incoming message to the format specified below --> 
               <m:getQuote xmlns:m="http://services.samples">
               <arg xmlns:m0="http://services.samples" expression="//m0:Code"/>
               <address uri="http://localhost:9000/services/SimpleStockQuoteService"/>

Simulating the Sample Scenario

4. Send a request using a SOAP  request client (ex :- SOAP UI) to WSO2 ESB in the following manner,

<soapenv:Envelope xmlns:soapenv="" xmlns:ser="http://services.samples" xmlns:xsd="http://services.samples/xsd">

When the above request was sent to the ESB through the client. the client will be able to notice that the request was successfully generated in the stock quote server.

How the Implementation Works

Let's investigate the elements of the ESB configuration in detail. The line numbers below are mapped with the ESB configuration illustrated in step 3 above.

  • main sequence - The default sequence which will trigger when the user invokes the ESB server
  • in - Once the message is hit in the main sequence the message will be diverted into the 'in'
  • out - Will be triggered after execution of steps defined through the 'in'
  • payload factory - Will transform the message to a format denoted within the mediator 














  • No labels