Use Swagger version 2 declarations to import and test WebSphere Commerce v7 REST services

It’s actually quite common to use Swagger JSON v2 declarations to import REST services and start interacting with them.

For example to start testing Oracle Commerce Cloud v16.1 REST services, you just have to download this JSON from the public documentation and start playing with your OCC instance.

OCC Swagger import on SoapUI

OCC Swagger import on SoapUI

Unfortunately for WebSphere Commerce is not so easy.

You can use the  standard Swagger interface available with WebSphere Commerce developer (remember to access it on http only and pushing the Explore button – Thanks Kevin Dillard for helping me)

WebSphere Commerce Swagger 1.2 UI on Commerce Developer

WebSphere Commerce Swagger 1.2 UI on Commerce Developer

to download JSON declarations for every service one by one (not so friendly).

A quick tip about Swagger UI: if you want to get Search API declarations instead of Commerce runtime API, please change the base URL to http://localhost/search/resources/api and press Explore

WebSphere Commerce v7 Search API declarations

WebSphere Commerce v7 Search API declarations

If you’re just specifying Swagger UI URL and hit Enter, a https redirection will be forced and Swagger UI cannot be accessed with recent Chrome or Firefox versions because of a missing CORS configuration on WebSphere Commerce (CORS issues will be solved soon with JR55289 fix, a back port for v7 of v8 CORS mentioned by Bob Balfe in his post)

CORS configuration error accessing Swagger interface

CORS configuration error accessing Swagger interface

In summary there isn’t a swagger.json file publicly available for download and the Swagger version used by WebSphere Commerce v7 is still 1.2 (please vote for my RFE to upgrade it to v2).

Then I had to open a PMR (25672,756,000: thank you Steve Boggs) and ask to the support for the procedure to create a Swagger file and upgrade it to v2. After some back and forth where our Commerce Technology Advocate helped too, we finally generated a valid v2 Swagger JSON file for runtime and search server

Swagger.json for WebSphere Commerce v7 FEP8 runtime

Swagger.json for WebSphere Commerce v7 FEP8 search

You just have load it on your preferred tool and start testing WebSphere Commerce REST interface

WebSphere Commerce v7 Swagger JSON imported on SoapUI

WebSphere Commerce v7 Swagger JSON imported on SoapUI

Tagged with: , , ,
Posted in oracle, REST services, websphere commerce

WebSphere Commerce custom tables queries and performance implications: goodbye ServerJDBCHelperAccessBean

Executing custom queries against custom tables is an historical problem affecting a lot of ecommerce projects implemented  with several big ecommerce frameworks (Oracle, IBM, SAP).

On WebSphere Commerce the developers have used during a lot of years (and they are still using) an undocumented API (ServerJDBCHelperAccessBean) to access custom tables data and IBM it self suggests to use it on developerworks.

This widely used API has another important inconvenient: it cannot be used to manage custom results caching.

But starting from the cumulative fix #2 for v7 Fixpack 9 (JR53438), we can finally use an optimized and documented API to query our Commerce tables: WCDataCache.

IBM extended the existing Commerce data cache API with a very powerful new method: executeParametrizedQuery.

This method should replace the correspondent ServerJDBCHelperAccessBean call allowing the developers to cache custom query results and associate them a specific dependencyId or a TTL to invalidate them when needed.

This new API has to be used in conjunction with the new data cache settings coming with FixPack 9: maxTimeToLiveForAutoCacheEntries and autoCacheableTableNames.

It’s time to refactor your code then and cache without fears your custom queries.

Tagged with: ,
Posted in cache, commerce frameworks, websphere commerce

Oracle JDBC performance: how to exploit defaultRowPrefetch in a WebSphere environment

A lot of WebSphere Commerce customers are using an Oracle database as backend.

From the performance point of view there are several specific parameters to work with to improve WebSphere Commerce performance on the database layer (DB2 or Oracle)

But in the WebSphere Application Server layer there are only a few, grouped on JDBC settings.

And the most important is probably the “Prepared Statement Cache“: Commerce support suggest to starting multipling x3 the default value.

[Overview of WebSphere Commerce performance and stability configurations]

Prepared Statement Cache 50 Specifies the number of statements that can be cached per connection. 150

Unfortunately this parameter doesn’t work with Oracle datasources created on WAS because you should switch to Oracle Universal Connection Pool and enable the implicit statement cache.

Then there is no way to improve Oracle datasource performance on WAS?

Yes, there is.

Using a specific datasource custom property, “connectionProperties”

[Using Oracle JDBC driver specific properties through a datasource]

you can access to several connection properties (“setConnectionProperties” list) through Oracle Datasource API and improve the overall datasource performance.

One of the most interesting connection properties you can change from the performance point of view is “defaultRowPrefetch”.

To setup it, you just need to create a custom datasource property using WAS console.

Oracle Datasource custom property

Oracle Datasource custom property

To check the performance impact for your environment, you need a load test.

Tagged with: , ,
Posted in JDBC, oracle, was

My top 15 hidden features in Commerce Fix Packs (FP9 and previous)

For the CSE blog fans who read my post there, I’d like to add the complete map with all hidden features available on FixPack 9


The original XMind map can be downloaded here with all links available. I hope you enjoyed the contents.

Posted in Uncategorized

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}”/>

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


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 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

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

Tagged with: , , ,
Posted in cache, frontend, search

Manage a custom servlet cache instance: configuration and invalidation

Most of the times in your baseCache instance falls several different types of cache entries: full pages, fragments, marketing command objects, policies.

Based on the “Best practices for caching design and decisions“, those entries could be moved to a different (or differents) servlet cache instances placed “in the default traditional DynaCache provider for the WebSphere Application Server provider or the WebSphere eXtreme Scale DynaCache provider”.

In general depending on the invalidation volume, you can evaluate moving the most frequent invalidated cache entries to a different instance (an high invalidation rate is not good for WXS) and create a replication domain to associate it.

But how to create a new servlet cache instance and use it in Websphere Commerce?

First you have to create a new servlet cache instance through WAS console

Custom Servlet Cache Instance

and follow the Knowledge center indications about his configuration adding all needed custom properties.

Restarting the server, these message on sysout will tell you the new servlet cache instance is up and running

CacheServiceI I   DYNA0015I: Dynamic Servlet Caching encountered an error: Error type=config warning. cacheName=services/cache/AuroraESpots CacheConfig.disableTemplateInvalidation=true. Template invalidations are disabled for JSP reload.
ResourceMgrIm I   WSVR0049I: Binding AuroraESpots as services/cache/AuroraESpots
ServerCache   I   DYNA1001I: WebSphere Dynamic Cache instance named services/cache/AuroraESpots initialized successfully.

Now services/cache/AuroraESpots instance has to be configured on cachespec.xml

On this sample we will move espot JSP snippets from baseCache to the new services/cache/AuroraESpots cache instance.

This is quite simple: all marketing cache entries has to be placed into this tag

<cache-instance name=”services/cache/AuroraESpots”>


I copied marketing cache entries from the sample cachespec.xml file in WCDE_installdir\components\foundation\samples\dynacache\marketing\cachespec.xml

To check this cache configuration we will simply load Aurora home page.

This page view will generate a cache entry for every espot in the page.

This is not the OOB behavior: I added a cache entry for JSP snippet caching based on activity behavior on



and I changed ContentRecommendation.jsp as explained on Knowledge Center.

With this configuration, loading Aurora home page

Aurora Home Page espots

9 cache entries are created

Espot cache entries

All those entries are associated to the JSP snippet caching

Espot cache entries detail

as you can see opening one of the entries

Espot JSP snipping detail cache

One thing to specify: the 9 espots are cached with specific cache entries because there is no cache entry for TopCategoriesDisplay in the sample cachespec.xml file I used in this post.

[Setting up JSP snippet caching based on activity behavior]

“Optional: Some optional parameters for an e-Marketing Spot can be configured as follows:
If the e-Marketing Spot JSP is included in a servlet cached page, then a static e-Marketing Spot has the JSP consumed by the parent page. If you want to always cache the e-Marketing Spot JSP separately, then define a cacheWithParent parameter with a value of false.”

And now the second part: invalidate the generated cache entries in our custom servlet cache instance.

First of all you need to apply an APAR if Commerce FixPack 7 is not installed (or request a build for your environment)


Then you have to add a special cache entry in your cachespec.xml

<component type=”method” id=”getString”>

This will allow to DynacacheInvalidation job to identify the custom servlet cache instance and send them the correspondent invalidations inserting a specific string (“cmd:”) in TEMPLATE column on CACHEIVL table.

“If the scheduler job locates a value in the TEMPLATE column that starts with cmd: prefix for a new row, the job uses the rest of the value that follows the prefix as a Java class name…”

To understand the whole process we are invalidating the JSP snippet corresponding to the HomeLeft_Content espot (the image with Shirt Sale 15% off men’s dress shirts)

DependencyIds espot home page

Webactivity associated to espot

The EMarketingSpotMetaDataGenerator associated to this entry generates 4 dependencyIds: emsId:10752,contentId:10156,contentId:10157 and contentId:10158.

We can invalidate that content using one of them: let’s use the emsId.

To invalidate that content we will use DynacacheInvalidation scheduled job inserting a specific record con CACHEIVL table

INSERT INTO cacheivl (template, dataid, inserttime) values (‘’, ’emsId:10752′, CURRENT TIMESTAMP);

As explained in Knowledge center (it could be explained better ;-)), we have to use the pattern “cmd:”+java class on TEMPLATE column and then indicate on DATAID column the dependencyId to invalidate.

After waiting for DynacacheInvalidation execution, the cache entries on our custom servlet are 8 now

Cache entries after invalidation

Tagged with: , ,
Posted in cache, websphere application server, websphere commerce

Precision Marketing basics: Customer abandon shopping cart trigger

In this second article about Websphere Commerce Precision marketing we will create another very common dialog activity using the “Customer abandon shopping cart” trigger.

We’ll use as a guide the example “3.2.2 Abandoned shopping carts” explained in the Precision Marketing redbook.

First of all the requirements as indicated in my last precision marketing post

1) Enable personalization ID
[Enabling personalization ID]

Modify wc-server.xml adding (or modifying) this tag

<PersonalizationId display=”false” enable=”true“/>

2) Enabling persistent sessions
[Enabling persistent sessions globally]

To activate the personalization ID you need to activate persistent sessions too (globally or at store level)
Modify wc-server.xml adding (or modifying) this tag

<PersistentSession cookieExpiry=”7″
delayNewPersistentGuestSession=”true” display=”false” enable=”true“/>

Remember to check dynacache implications when persistent sessions are enabled
[Dynamic caching considerations for persistent session]

3) User had to give his consent to receive emails

Quite simple to check

select * from emlusrrecv where users_id = XXXXX;

3) Configure outbound accounts to send emails at store level
[Configuring email activity accounts]

Remember to check “Time to start delivery”: it has to be 1 hour (or less) later than the “SendMarketingTriggers” scheduled job execution.

After verifying all the requirements, you can start create the dialog activity.

This will be the final result

Dialog activity for abandoned carts

You should start creating the coupon promotions

Coupon promotion for abandoned carts

and then the email template

Email template for abandoned carts



Tagged with: ,
Posted in precision marketing, websphere commerce
%d bloggers like this: