Generating a simple response using WSO2 Enterprise Service Bus

Generating a simple response using WSO2 Enterprise Service Bus

This knowledge base article is aimed at exploring the possibilities of WSO2 Enterprise Service Bus configuration langauge.

Applies To

WSO2 Enterprise Service Bus version 2.1.1 or later

Introduction

WSO2 Enterprise Service Bus has the concept of proxy services. Proxy services are designed to be virtual services that expose an actual service to the outside world. Usually when a request comes to a proxy service it forwards it to an actual service. Response from the actual service is sent to the client. 

The above example is the normal behaviour of proxy services. A proxy service is created using an XML configuration. This configuration determines where to send the message, what are the transformations that need to be done prior to sending the message etc. Also a proxy service configuration specifies what needs to be done to the actual response message before sending to the client. We call this XML language Apache Synapse langauge.

The beauty of Apache Synapse language is such that you can create a proxy service that create the response on its own without forwarding the request to an actual service. Below is an explanation on how to do it.

Message mediation is the other way WSO2 Enterprise Service Bus handles messages. In message mediation all the messages are sent to the main sequence. Usually messages are filtered and transformed in the main sequence before sending to the actual endpoint. 

As with the proxy services, users can create a response and send it back from the main sequence. 

The configuration

Here is such a configuration.  

<?xml version="1.0" encoding="UTF-8"?>
<syn:definitions xmlns:syn="http://ws.apache.org/ns/synapse">
	<syn:registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
		<syn:parameter name="cachableDuration">15000</syn:parameter>
	</syn:registry>
	<syn:proxy name="EchoProxy" transports="https http" startOnLoad="true" trace="disable">
		<syn:target inSequence="response"/>
	</syn:proxy>
	<syn:sequence name="main">
		<syn:sequence key="response"/>
	</syn:sequence>
	<syn:sequence name="fault">
		<syn:log/>
	</syn:sequence>
	<syn:sequence name="response">
		<syn:script language="js">
			mc.setPayloadXML(
			&lt;greeting&gt;Hello World&lt;/greeting&gt;
			);
		</syn:script>
		<syn:header name="To" action="remove"/>
		<syn:property name="NO_ENTITY_BODY" scope="axis2" action="remove"/>
		<syn:property name="RESPONSE" value="true"/>
		<syn:send/>
		<syn:log level="full"/>
	</syn:sequence>
</syn:definitions>

In the above sample, we have a proxy service and main sequence. Both proxy service and main sequence uses a sequence called “response”. This sequence creates a response and sends it back to the client. 

Start WSO2 Enterprise Service Bus with this configuration. You can copy the above configuration into synapse.xml which is found in the conf directory and start WSO2 Enterprise Service Bus with –DuseSynapseXML parameter. Then send a GET or POST request to the proxy service or main sequence. 

For invoking the proxy service

https://localhost:8280/services/EchoProxy

For invoking the main sequence you need to use a URL which is not a proxy service.

https://localhost:8280/services/Response

Now lets look at what happens in this configuration. Both proxy service and the main sequence executes the “response” sequence when a message comes to them. The response sequence is in the request path. So we are transforming the request message to a response message.

Response sequence uses the script mediator to set a custom payload to the message. Then it removes the To header. Since we are sending the message back, To header is not required and not expected by WSO2 Enterprise Service Bus. Note all these changes are done to the incoming request message. 

Now it removes another property called NO_ENTITY_BODY. If this property is present and if it’s value is true WSO2 Enterprise Service Bus will not send the response body. Instead it will just send the headers. In case of a GET request this property is set. So we need to remove it, in order to send the response body.

Now the final property RESPONSE is set. This property indicates that this is a response message and it needs to be sent back to the client. At this point we are virtually turning the request back to a response. If you use a send mediator without setting this property you can see that our custom message is being sent to the service.

Finally we do a send. This send, sends back the created response message.

Summary

Author

Supun Kamburugamuva, Senior Software Engineer, WSO2, supun AT wso2 DOT com