WebSphere Commerce FEP7: Caching search REST requests (updated FEP8)

With FEP7 a new REST service layer is deployed with WebSphere Commerce in a different EAR application

WebSphere Commerce Search interaction diagram

Search interaction diagram

to point to SOLR infrastructure directly without involve the BOD layer

This architectural change allow us to start developing a different presentation layer using the new search REST services

Advanced deployment cluster

Advanced deployment cluster

The new Aurora FEP7 has started to implement that change in his JSPs using an specific custom tag, wcf:rest and that tag is massively used on Aurora FEP8.

There is an interesting example in the infocenter

Defining storefront assets for a Commerce Composer widget

<wcf:rest var=”catGroupDetailsView” url=”${searchHostNamePath}${searchContextPath}/store/${WCParam.storeId}/categoryview/byId/${categoryId}” >    
                <wcf:param name=”langId” value=”${langId}”/>
                <wcf:param name=”currency” value=”${env_currencyCode}”/>
                <wcf:param name=”responseFormat” value=”json”/>        
                <wcf:param name=”catalogId” value=”${WCParam.catalogId}”/>
</wcf:rest>

I’ll use this sample to explain how to cache the underlying search REST request

CategoryViewHandler (Search)

against the new search infrastructure.

Navigating the sample catalog in Aurora FEP7

Aurora FEP7 category

the new wcf:rest tag is used and a GET request like

http://localhost/search/resources/store/10152/categoryview/byId/10028?langId=-1&catalogId=10001&currency=USD&responseFormat=json

is executed on the new search EAR.

How to cache this?

Using the same mechanism available from FEP4: dynacache.

As explained in the infocenter, you can take the sample cachespec.xml file in WCDE_installdir\components\foundation\samples\dynacache\REST to cache not only “old” REST requests but also “new” search REST requests.

To cache the categoryViewHandler request byId you just need to add this cachespec.xml to the Search-REST module: the com.ibm.commerce.rest.caching.RESTCacheFilter and the dynacache engine will do the rest.

A specific sample cachespec.xml for Search server is now available on FEP8

Caching strategies for REST services

“Search server
WCDE_installdir\components\foundation\samples\dynacache\Search-Rest”

You have to request a specific APAR to IBM support to have this sample available

JR52222: Create sample cachespec.xml for Search server for FEP7 and FEP8

When the cachespec will be loaded and navigating the Electronics-Accessories category for example, the cache monitor will show you two new entries

Search REST entries in cachemonitor

generated by the search REST requests fired by wcf:rest custom tag containing the returned JSON for the category

JSON coming from Search REST category request

The CACHED_RESPONSE header confirms us the JSON is coming from dynacache

JSON response cached by dynacache

By default client caching is enabled too and the returned JSON will be also cached at client side for one hour (default value)

JSON cached on browser

Websphere Commerce and Portal Architect ✔ Motivated IT professional with more than ten years of experience, combining Java and JEE developer skills with systems and IBM products installation knowledge. ✔ Strong experience and skills on planning, architecting and implementing complex commerce and portal solutions based on IBM middleware products. ✔ Reliable with a strong network attitude, experience on leading developer's teams and manage international relationships. Specialties ✔ Pleasant manner, reliable. ✔ Ability to consider issues from different point of views. ✔ End-oriented work capacity and problem-solving attitude. ✔ Ability to work with deadlines and under pressure. ✔ Ability to prioritise tasks and manage people. ✔ Ability to increase the whole team skills. ✔ Ability to generate commercial leads

Tagged with: , , ,
Posted in cache, frontend, search
2 comments on “WebSphere Commerce FEP7: Caching search REST requests (updated FEP8)
  1. Diego Ballve says:

    Nice tip Marco! Thanks for the cachespec pointer. Just a heads up: the sample is really a sample. To start with, it does not consider the important profileName parameter, or the widely used productview/byIds URL. Then if you start looking closer, a lot more parameters are not considered. You will start getting funny results from cache unless you go through the file (and through the invocations from WCS side) carefully.

    • Marco Fabbri says:

      Hi Diego, remember that now you have an official cachespec sample available starting from FP9 CF2. And yes my sample was really a sample… ;-)

Leave a comment