ESB 5

WSO2 ESB Tutorial:
Simple Message Content-Based
Routing with Switch Mediator

Index

1. Introduction

2. Message Mediation

a) Simple Content-Based Routing (Switch Case Mediator)
b) Testing the routing

3. Conclusion

1. Introduction

Continuing with the catalogue of Synapse examples, now we will see how content-based routing works, but implementing this integration through the Switch mediator. If you recall, in the previous post we implemented the Filter mediator. In today’s post, we will focus on the value of the message’s payload.

Messages are routed in this example to the same endpoint. We will use Switch to add properties to the
message depending on the value of its payload. Ready?

2. Message Mediation

a. Simple Content-Based Routing (Switch Case Mediator)

The message is sent using Axis2’s Smart Client:

ant stockquote -Daddurl=<addressingEPR> -Dtrpurl=<synapse>

The addurl property selects the endpoint resource using the WS-Addressing specification in order to
store this value.

In our example, this property points to Axis2’s backend. The services in the backend is exposed using the
SOAP protocol. It is clear that this property of the stockquote command will also be contained in the
value of the TO header of the message, indicating where the message is being sent to, while the trpurl
property points to our ESB.

The way in which ESB’s mediation works is as follows: When a message is sent to the ESB, the
payload’s symbol value is read (getQuote/request/symbol).

Depending on this value, a Switch mediator changes the message’s mediation flow, adding a property to
the message and showing this value in the log mediator, in such a way that the message is redirected to
the endpoint with the value of the TO property.

The following diagram shows the entire process:

As stated in the previous article, we will first start the Axis2 backend and then the ESB. If you are in
doubt, you can read how to do this in the previous posts.

As a reminder, we show you where each component is located:

Ruta del servidor Axis2: /wso2esb-4.9.0/samples/axis2Server/

Ruta del cliente Axis2   : /wso2esb-4.9.0/samples/axis2Client/

Ruta de WSO2ESB      : /wso2esb-4.9.0/bin

Beware! It is very important that you don’t forget to use Eclipse to generate the CAR file with the
sequences and deploy this file in the ESB.

b. Testing the routing

Now we need to launch the request from the path where the Axis2 client is located.

ant stockquote
-Daddurl=http://localhost:9000/services/SimpleStockQuoteService
-Dtrpurl=http://localhost:8280/ -Dsymbol=IBM

The log mediator in the inSequence shows the incoming message/request:

As can be seen in the message, the action that is selected is getQuote, which is forwarded to the
endpoint To: http://localhost:9000/services/SimpleStockQuoteService, which is the Axis2 backend; the
payload’s symbol is IBM.

Within the ESB, switch mediator seeks the value of symbol:

This symbol matches the value of the first regular expression of the switch mediator:

This leads the processing of the request, or the message, to go through this case, and adds a new
property into the message context under the name symbol.

The following log mediator, after the switch mediator, prints the value of the To header and the symbol
value that has just been added in the switch.

The information shown for this log mediator by the command line is:

symbol = Great stock - IBM,

epr = http://localhost:9000/services/SimpleStockQuoteService

Lastly, there is the send mediator:

What it does is sending the message to the endpoint contained in the TO header.

The backend receives the message and displays this notification in the command console:

The response sent by the backend is shown in the log mediator of the outSequence in the ESB:

In the red square, you can see the value of the latest quotation for the IBM symbol, while the blue square
shows that the message is a response.

The message ID is different from that of the request message, given that it refers to a different
communication between the backend and the client. In this case, it is a response, another message and
another identifier. However, it fully matches the incoming message (request) that we have just processed
in the ESB.

Now, the resulting message shown in the Axis2 client is:

This, therefore, completes the request-response circuit.

We suggest you try with the rest of the requests to see the outputs of the log mediator in the ESB as well:

ant stockquote
-Daddurl=http://localhost:9000/services/SimpleStockQuoteService
-Dtrpurl=http://localhost:8280/ -Dsymbol=SUN

In this case, the request message is processed by the second case of the switch mediator.

ant stockquote
-Daddurl=http://localhost:9000/services/SimpleStockQuoteService
-Dtrpurl=http://localhost:8280/ -Dsymbol=SUN

Lastly, since there is no regular expression that matches the SUN symbol, the message will be
processed by the default case.

3. Conclusion

This new chapter is a continuation of the previous one, where we study the same use case,
content-based routing, but implementing the Filter mediator. This time around it is implementing the
Switch mediator and inputs the values of the message’s payload.

As shown, the behaviour is identical. In today’s example, properties are added to the message context
depending on the symbol, so that it matches the regular expression of the case of the Switch mediator,
through the message could have been sent to different endpoints depending on the value of each symbol.

This example, therefore, meets the Message Routing -> Content-Based Router integration pattern, as it
did in the previous article.

See you in the next instalment of ESB WSO2!