ESB 4

WSO2 ESB Tutorial:
Simple Message Content-Based
Routing using Filter Mediator

Index

1. Introduction

2. Message Mediation
a) Simple Content-Based Routing (Filter Mediator Example 1)
b) Testing the routing
AXIS2 Service
SOAPUI Service
3. Conclusion

1. Introduction
Continuing with the Synapse example catalogue, in today’s post, we will see how content-based message

routing works. In this case, we will focus on the significance of the TO property of the message header.
Its value indicates where messages are sent to.

2. Message Mediation

a. Simple Content-Based Routing (Filter Mediator Example 1)

In this example, the Client sends a message to the ESB. The latter acts as a gateway, accepting all
messages and routing those that have specific content in the TO property of the header. Routing may
also take place based on the content of the message’s payload.

This is what we will do:

To do this, first, you need to deploy the CAR file with all the sequences in WSO2 ESB. For further details,
check out my previous post, it will be really helpful! Now you will deploy a series of Web Services that
are exposed via SOAP, which redirect the requests to the endpoints in the Axis2 Server’s Backend or the
mock service in SOAPUI. In the ESB, the web services that will redirect the messages to the endpoints
of the backend appear expanded:

http://localhost:8280/services/StockQuote?wsdl

http://localhost:8280/services/mockSampleServiceSoapBinding?wsdl

As you can see in soap12: address location, for each of the wsdl files, the messages are forwarded to the
backend in AXIS2Server.

<soap12:address location="http://172.17.0.1:9000/services/SimpleStockQuoteService.SimpleStockQuoteServiceHttpSoap12Endpoint"/>

And in the second wsdl, to SOAPUI.

<soap:address location="http://trm-Dell-System-XPS-L702X:8088/mockSampleServiceSoapBinding"/>

In order to start the AXIS2Server server:

wso2esb-4.9.0/samples/axis2Server$ ./axis2server.sh

Now we need to implement a mock SOAP service in SOAPUI. In the following image, you will find the
entire configuration.

As shown in the Image, at the top you can see a symbol corresponding to a SOAP folder. 

Clicking on this folder you can create a mock SOAP web service. In the following squares, you can see
the name of the folder (‘sample-service’), the name of the sample service (‘SampleServiceSoapBinding’)
and lastly, the name of the mock service.

To the left of the screen, in the red square, you can see the definition of the request, and further down,
the response defined within the mock service. On the right side, you can see the sample XML request
and to the right, the XML response coming from the mock service.

When selecting Response 1, you can see the response XML sent by the mock service to Request 1.

If you double-click on the name of the mock service on the overview to the left, on the right you will see
the operations definitions for this Web Service. We will call the login operation. 

If you now click on the gear on top, as shown in the image, you will see the options for the Service,
including the path, port and hostname where it is deployed.

In order to execute the service, you need to click on the green triangle-shaped icon.

As shown in the screenshot, the service is now running on port 8088.

b. Testing the routing

• AXIS2 Service

Once the Axis2Service backend and the SOAPUI web service are running, we can send the requests 

through WSO2 ESB.

First, we can test the routing toward Axis2Service. In order to do this, we need to execute the command
below in the following path: wso2esb-4.9.0/samples/axis2Client

sudo ant stock quote -Dtrpurl=http://localhost:8280/services/StockQuote

As you can see, we sent the request to the WSO2ESB on port 8280. The response we get from the ESB,
which in turn is coming from the Axis2Service backend, is:

Now go back to the command console where the ESB is executed to see the request and response that
has been generated by the ESB’s log mediator. It is important to remember that there are two log
mediators: one in the In sequence, and another in the Out sequence.

The formatted request of the In sequence sent by AXIS2Client is as follows:

To: /services/StockQuote,

WSAction: urn:getQuote,

SOAPAction: urn:getQuote,

ReplyTo: http://www.w3.org/2005/08/addressing/anonymous,

MessageID: urn:uuid:36ddb3e7-9679-48b7-8d58-66c604860847,

Direction: request,

Envelope:

As can be seen in the header, the message is sent to the following service: /services/StockQuote. The
client is abstracted from the endpoint, it doesn’t even know where the service is; that routing task falls to
the ESB. Within the ESB, the first filter takes the value of the TO parameter. The regular expression is
true and sends the request to:

http://localhost:9000/services/SimpleStockQuoteService

This is content-based routing; in this case, the content is the TO parameter.

This request is forwarded to Axis2Server, and as shown in the image, the request is processed in the
backend:

The mediator’s log of the out sequence in the ESB shows the response that comes from the backend:

To: http://www.w3.org/2005/08/addressing/anonymous,

WSAction: ,

SOAPAction: ,

ReplyTo: http://www.w3.org/2005/08/addressing/anonymous,

MessageID: urn:uuid:a73ebbc0-ca82-4053-981c-e7cb1279c277,

Direction: response,

Envelope:

As you can see in the red square, this is the value that shows the client in the command line, as
previously seen.

• SOAPUI Service

Now we will send the SOAPUI request. To accomplish this, you need to run the following command:

curl --header "Content-Type: text/xml;charset=UTF-8" --header
"SOAPAction:http://www.example.org/sample/login" --data @request.xml
http://trm-Dell-System-XPS-L702X:8280/mockSampleServiceSoapBinding

The request is sent to the ESB on port 8280 and the requested operation is in the SOAPAction header
value.

The value of the request.xml file is the payload our mock service in SOAPUI is expecting.

The response received by the curl client is:

This is the response that was defined in SOAPUI’s mock for the /login SOAP action.

The ESB shows the request that is coming from the curl command.

To: /mockSampleServiceSoapBinding,

WSAction: http://www.example.org/sample/login,

SOAPAction: http://www.example.org/sample/login,

MessageID: urn:uuid:7b86babe-5349-4ec6-b960-dbecee0a7da8,

Direction: request,

Envelope:

As can be seen, the value of the TO parameter has changed; it is now:
mockSampleServiceSoapBinding , which coincides with the value of the regular expression of the
second filter in the ESB. Therefore, the request is routed toward SOAPUI’s mock service.

As you can see in the image, on the left side you can find the request that has been received, and on the
right, the response to the mock service.

The log mediator of the ESB’s out sequence shows the same response:

To: http://www.w3.org/2005/08/addressing/anonymous,

WSAction: ,

SOAPAction: ,

MessageID: urn:uuid:ef3596b7-e6eb-4349-aaa3-380e8c556ecc,

Direction: response,

Envelope:

3. Conclusion

Routing of the requests by the ESB is a very simple task. Header values, as well as those of request

payloads, can be used. In addition, the ESB detaches the endpoint from the Client, since it only needs to
know the name of the service, which is entered as a value in the TO header. Routing is part of the
Message Routing integration pattern, and of the Content-Based Router within it.

The ESB post section continues!