This documentation is work in progress and will be released with the next WSO2 EI version.
Sample 420: Simple Response Cache in the ESB for an Actual Service - WSO2 Enterprise Integrator 6.x.x - WSO2 Documentation

All docs This doc
||
Skip to end of metadata
Go to start of metadata

Note that WSO2 EI is shipped with the following changes to what is mentioned in this documentation:

  • <PRODUCT_HOME>/repository/samples/ directory that includes all Integration profile samples is changed to <EI_HOME>/samples/service-bus/.
  • <PRODUCT_HOME>/repository/samples/resources/ directory that includes all artifacts related to the Integration profile samples is changed to <EI_HOME>/samples/service-bus/resources/.

Introduction

This sample demonstrates how to use the Cache mediator to cache a response, and then use that cached response as the response to another identical xml request.

In this sample, you send a request to the ESB and check whether a cached response exists by calculating the hash value. If there is a cache hit in ESB, the request is not forwarded to the actual service, rather the ESB responds to the client with the cached response. If it is a cache miss, the message is forwarded to the actual service and the response is cached in the out path so that it can be used for consecutive requests of the same type.

Prerequisites

For a list of prerequisites, see Prerequisites to Start the ESB Samples.

Building the sample

The XML configuration for this sample is as follows: 


<definitions xmlns="http://ws.apache.org/ns/synapse">

	<sequence name="main">
    	<in>
        	<cache collector="false" maxMessageSize="10000" timeout="20">
            	<protocol type="HTTP">
                	<methods>POST</methods>
                	<headersToExcludeInHash/>
                	<responseCodes>2[0-9][0-9]</responseCodes>
                	<hashGenerator>org.wso2.carbon.mediator.cache.digest.HttpRequestHashGenerator</hashGenerator>
            	</protocol>
            	<implementation maxSize="100"/>
        	</cache>
        	<send>
            	<endpoint name="inlined">
                	<address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
            	</endpoint>
        	</send>
    	</in>
    	<out>
        	<cache collector="true"/>
        	<send/>
    	</out>
	</sequence>
</definitions>

This configuration file  synapse_sample_420.xml is available in the <EI_HOME>/samples directory.

To build the sample

  1. Start the ESB with the sample 420 configuration. For instructions on starting a sample ESB configuration, see Starting the ESB with a sample configuration.

    The operation log keeps running until the server starts, which usually takes several seconds. Wait until the server has fully booted up and displays a message similar to "WSO2 Carbon started in n seconds."

  2. Start the Axis2 server. For instructions on starting the Axis2 server, see Starting the Axis2 server.

  3. Deploy the back-end service SimpleStockQuoteService. For instructions on deploying sample back-end services, see Deploying sample back-end services.

    Now you have a running ESB instance and a back-end service deployed. In the next section, we will send a message to the back-end service through the ESB using a sample client.

Executing the sample

The sample client used here is the Stock Quote Client, which can operate in several modes. For further details on this sample client and its operation modes, see Stock Quote Client.

To execute the sample client

  • Run the following commands from the <EI_HOME>/samples/axis2Client directory:

    ant stockquote -Dtrpurl=http://localhost:8280/

Analyzing the output

If you send more than one request within 20 seconds, you will see that only the first request is forwarded to the actual service. The rest of the requests are served by the cache inside the ESB. You can observe this by analyzing the line printed on the axis2 server, as well as by the constant response rate to the client that takes place instead of a random rate that changes every 20 seconds.

Synchronizing web service invocations with the Callout mediator

The Callout mediator calls the given service URL with the request message that is specified via the source attribute. Then it waits for the response, and attaches the received response to the destination that is specified via the target attribute. Both the source and the target can be a key or an XPath. In the case of the source, the key refers to either a message context property or to a local entry. For the target, the key refers to a message context property on

  • No labels