Oracle Service Bus, how to verify Result Caching is active

Oracle Service Bus has a feature now for a while which gives us the option to switch on Result Caching on services.
Result Caching is based on Oracle Coherence, an in-memory data grid.

Basically what it does is cache the results from the calls to the business services. Which means on a second call to the service, OSB will first verify if the data, identified by a xpath-expression is in the cache. If it is, i will be retrieved from the cache, if it isn’t the call to the physical endpoint of the service will be made.

To be able to identify the data in the cache you need to configure the result caching on the business service, add the identifying ‘Cache Token Expression (XPath)’ and configure the expiration of the data item in the cache. This one can be handled by the default of the OSB, based on a duration or based on a XPath expression on the request/response message.
For a good overview read this part of the Administrators Guide.


For this scenario we re-used the almighty Hello World Webservice again.

  1. imported the wsdl + xsd resources in your osb project
  2. Create a new http business service based on the wsdl
  3. Create a new proxy service based on the business service

Our testscenario is ready, let’s get on.

To be able to verify if the result cache is getting used or not we need to enable Monitoring on our proxy and business service.
Either open them in the plain text editor and look for
[sourcecode language=”xml”]



Switch isEnabled to true.
Or enable the monitoring after deployment in the SBConsole.

Deploy the service.

By default we haven’t enabled the Result Cache. So when we would call the proxy service it will passthrough to the business service and do the ‘real’ call to the webservice.
When we repeat this, every time again, the proxy service will just do the ‘real’ call to the webservice over and over again.

Let’s setup a testcase in SoapUI to do a little loadtest against the proxy service interface


Create a new SoapUI project, based on the wsdl endpoint of our OSB proxy service. Enable the creating of the TestSuite too.

Create a new TestSuite and enable the ‘Generate LoadTest’ option.

Double click the LoadTest 1, and check a few settings.

  • Threads => 1
  • Limit => 20 Total Runs

Our simple loadtest is ready. Based on 1 thread it will fire off 20 requests to our proxy service which eventually will invoke our Hello World business service.

Oracle Service Bus service statistics.
By enabling the Monitoring on our services Oracle Service Bus will collect and and gives us a Statistics overview in the console of the service.
Go to the Service Bus Console > Operations. Select the ‘Service Health’ tab at the top.
By default it will look a bit like this :


Go back to SoapUI and change the request payload of our sayHello teststep.

Start the loadtest

.. and the results of the loadtest, 20 calls to the proxy service.

Now go back to the SBConsole and look at the statistics again.

Both the proxy service and the business service received 20 messages, like we expected since we haven’t done anything yet with result caching.


Enabling Result Caching.
Go to the SBConsole > Operations > Global Settings and enable Result Caching

We can enable the Result Caching on the business service either in Eclipse or in the Console.
Since we need to add some XPath expressions it’s easier to do it in Eclipse itself.
Open the business service and go to the ‘Message Handling’ tab.

  1. Enable Result Caching
  2. Add a ‘Cache Token Expression’ (used to see if the data is already in the cache)
  3. And optional add an Expiration Time

By enabling this configuration we setup the next situation.
Result Caching is active, when ever a request arrives through a proxy service to the business service result caching will get triggered. It retrieves that data by use of the XPath expression and check if it’s already or still availabe in the cache.
If the data isn’t available in the cache, the data will get stored in the cache and the real call to the webservice will be done.
If the data is available in the cache, the data will get retrieved from the cache and there won’t be any call to the webservice.

Eventually the retrieved data will be returned to the response pipe of the proxy service, back to the client caller.

Deploy the osb project and go back the SBConsole, to the Statistics.
First we need to reset the statistics to see the difference on the numbers between the situation in which we didn’t use the result caching.

Go back to the SoapUI project and start the loadtest again.

And for the last time go back the SBConsole to the statistics.

Again 20 messages arrived at the proxy service. On the first call the data won’t be in the cache so the ‘real’ call to the webservice will be done.
The next call will contain the same message payload (since we’re using the same message in our SoapUI test), so the XPath expression will evaluate to true, which means the data can be retrieved from the cache. And this continues till message #20.

So eventually from the 20 calls we made to the proxy service, only 1 will really do the webservice call at the backend, and the other 19 calls will retrieve data from the cache.

I hope it’s a bit clear now how the result caching works in the Oracle Service Bus, how to configure it and eventually how to be able to see if the cache is really active.

Share this Post:
Digg Google Bookmarks reddit Mixx StumbleUpon Technorati Yahoo! Buzz DesignFloat Delicious BlinkList Furl

8 Responses to “Oracle Service Bus, how to verify Result Caching is active”



It is a very complicated topic and very confusing. I just stepped into the Computer Science world and I am just getting used to the terminology. I really appreciate the blog, it was really well written.



Hello, One question. Is possible improve service resoult caching with composite application with bpels in oracle soa suite 11g?


I don’t think there is something out-of-the-box to supply you this functionality.

You could have a look at the next two links, maybe they will supply you something for a possible solution


Very nice article. At the same time, what should be done to refresh the cache when needed. How to trigger the cache to be executed at the service level.????



Nice Article Eric

Karibasavanagoud | April 12th, 2013 at 5:09 am

The result cache enabled Business service (called from Proxy service)load testing is showing the Overall response time as a huge compared to result caching disabled scenario.

Ideally Result caching enabled AVG response time should be less than result caching disabled scenario.


Nice Article Eric.
what should be done to refresh the cache when needed. How to trigger the cache to be executed at the service level (Java Service)?

Leave a Reply:

Name (required):
Mail (will not be published) (required):
Comment (required):
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>