Welcome! Sure you remember the previous post about simple routing based on the content of the message with Filter Mediator. Well, on this occasion we propose a new example but making the routing with Switch Mediator. This will be everything you can discover in our post:
Introduction
Continuing with the catalogue of Synapse examples, today 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?
Message Mediation
-
Simple Content-Based Routing (Switch Case Mediator).
The message is sent using Axis2’s Smart Client:
ant stock quote -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 good ol’ 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:
Axis2 server path: /wso2esb-4.9.0/samples/axis2Server/
Axis2 client path : /wso2esb-4.9.0/samples/axis2Client/
WSO2ESB path : /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.
-
Testing the routing.
Now we need to launch the request from the path where the Axis2 client is located.
ant stock quote -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.
-Did you miss the first post in the ESB saga? Discover “Apache Synapse ESB and WSO2”-
We suggest you try with the rest of the requests to see the outputs of the log mediator in the ESB as well:
ant stock quote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/ -Dsymbol=MSFT
In this case, the request message is processed by the second case of the switch mediator.
ant stock quote -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.
Conclusion
This new post 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!
