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

Welcome back to the special section of our post dedicated to ESB! Here, we will be covering the WSO2 ESB.

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.

Message Mediation

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 our 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.

-Discover the first post of the ESB: Apache Synapse Enterprise Service Bus (ESB) and WSO2 saga-

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.

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:

 

-This post is sure to be interesting to you: WSO2 ESB Quick Start & Installation Guide –

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:

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.

If you missed our previous post about “Message Mediation: Catalog of Synapse Examples, WSO2 ESB”, don’t miss your chance and find it here!

This post section on ESB will continue; see you next time!