Transforming the Message

In this scenario, we will look at how WSO2 ESB handles message transformation. This scenario contains the following sections:

About transformation

Transformation is necessary when the message format sent by the client is different from the message format expected by the back-end service. The Message Translator architectural pattern in WSO2 ESB describes how to translate from one data format to another.

For example, let’s assume this is the format of the request sent by the client:

<m:getQuote xmlns:m="http://services.samples/">
  <m:CheckPriceRequest>
      <m:Code>WSO2</m:Code>
   </m:CheckPriceRequest>
</m:getQuote>

However, the format of the message must be as follows to be compatible with SimpleStockQuoteService:

<m:getQuote xmlns:m="http://services.samples">
   <m:request>
      <m:symbol>WSO2</m:symbol>
   </m:request>
</m:getQuote>

Furthermore, following is the format of the response expected by the client:

<m:CheckPriceResponse xmlns:m="http://services.samples/xsd">
   <m:Code>WSO2</m:Code>
   <m:Price>62.976571995113986</m:Price>
</m:CheckPriceResponse>

Transformation is required for both the request and response messages. The client message format must be transformed to the back-end service message format within the In sequence, and the opposite must be done within the Out sequence.

Updating the deployable artifacts

We will use the PayloadFactory mediator to transform the message within the In and Out sequences. The PayloadFactory mediator transforms or replaces the contents of the request message so that it is in the format expected by the back-end service. Let’s take a look at how this is done in WSO2 Developer Studio.

1. First we need to update the Log mediators that are within the Switch mediator so that they are able to extract the log values from the new request format. In the Log mediators, update the XPath expression on the Properties tab as follows:

   1. For the French Message Log mediator in Case, update the XPath expression to:

      fn:concat('Bonjour ',//m0:CheckPriceRequest/m0:Code)

   2. For the Welcome Message Log mediator in Default, update the XPath expression to:
      

      fn:concat('Welcome ',//m0:CheckPriceRequest/m0:Code)
      
      Notice that we are not using the m1 namespace in the new expressions, so you can remove the m1 namespace definitions in both of these Log mediators.

2. Add a PayloadFactory mediator just after the Switch mediator in the In sequence of the proxy service.
   

3. Go to the properties of this PayloadFactory mediator and fill in the details as follows:

   • Payload Format: Inline

   • Payload (the XML format for the message payload):
     <m:getQuote xmlns:m="http://services.samples">
<m:request>
<m:symbol>$1</m:symbol>
</m:request>
</m:getQuote>
     We are using the PayloadFactory mediator to specify the transformed format for the incoming message. In the Payload property, we have indicated that we need to add a variable to this message format by using $1 in the above XML.
   • Args:

     • Type: Expression

     • Value:
       Click the ... button and enter the expression:
       //m0:Code
       Here we are defining the value of the variable in the format definition. This value is obtained from the request message using the above expression. Because we're using a namespace in the expression, add the following namespace:

     • Prefix: m0

     • URI: http://services.samples


     • Evaluator: xml

     • The properties for the PayloadFactory mediator should now look like this:
       

4. Add another PayloadFactory mediator to the Out sequence of the proxy service, just before the Send mediator, to transform the response message to the format expected by the client.
   

5. Go to the properties of this second PayloadFactory mediator and fill in the details as follows:

   • Payload Format: Inline

   • Payload:
<m:CheckPriceResponse xmlns:m="http://services.samples/xsd">
<m:Code>$1</m:Code>
<m:Price>$2</m:Price>
</m:CheckPriceResponse>

   • Args (note that you are creating two arguments here):

     • Type (for both arguments): Expression

     • Value for the first argument: //m0:symbol
     • Value for the second argument: //m0:last
     • Evaluator (for both arguments): xml
     • Namespaces (for both arguments):

       • Prefix: m0

       • URI: http://services.samples/xsd

     • Ensure the arguments look like the following and click OK.

6. Keep the rest of the fields as they are and save the proxy service.

We are now ready to redeploy the C-App and send the request.

Redeploying and sending the request in SoapUI

1. Redeploy SampleCApp in your server as you did in the previous lessons.

2. In SoapUI, go to Request 1, delete the default content of the request, and then copy and paste the following request there.

   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:m="http://services.samples">
   <soapenv:Header/>
     <soapenv:Body>
       <m:getQuote xmlns:m="http://services.samples">
         <m:CheckPriceRequest>
           <m:Code>wso2</m:Code>
         </m:CheckPriceRequest>
       </m:getQuote>
     </soapenv:Body>
   </soapenv:Envelope>

3. Send the request. You will get a response similar to the following:

   <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
     <soapenv:Body>
        <m:CheckPriceResponse xmlns:m="http://services.samples/xsd">
           <m:Code>wso2</m:Code>
           <m:Price>62.976571995113986</m:Price>
        </m:CheckPriceResponse>
     </soapenv:Body>
   </soapenv:Envelope>

We have now explored how WSO2 ESB can take a message in one format, transform it into the format expected by the back-end service, and then transform the response back to the client’s required format. In the next scenario, you will learn how to monitor the ESB and debug using the management console.