Taking WCS to the edge with Akamai (Or other CDN solution)

First of all, you should be asking yourself what a CDN is?

CDN means Content delivery network, and it is a  is a large distributed system of servers deployed in multiple data centers across the internet. The goal of a CDN is to serve content to end-users with high availability and high performance.

This contents are all sort of static contents you may have in your store, like  .CSS, . HTML Files, .JS Scripts  all medias (Images, movies, flashes, documents) and etc.

Instead of having all users downloading these static files from your servers, in a CDN these files are propagated to servers across the globe, and users can download it from the best available server, granting  high availability and high performance to our store.

File:NCDN - CDN.png

The main benefits to our business are:

  • SEO – Since Google announced that site speed affects the page rank, have a fast site is mandatory to business. Better page rank means more exposition, more exposition means more conversion, and conversion means revenue.
  • Best Content Delivery – Since CDNs place servers as close to a group of users as possible, latency and packet loss are minimized due to a shorter distance traveled. Theoretically, the closer the content is to the user, the faster the delivery. Therefore, users will experience less jitter when streaming, fewer network spikes, and an overall improved streaming quality. Due to the reliability, operators can deliver high quality content with a high level of service, low network server loads, and thus, lower costs. Additionally, many CDN providers offer TCP acceleration technology which boosts performance, thus improving user experience. Since CDNs decrease latency, the acceleration working in conjunction with an already high-performing network results in explosive content.
  • 100% Availability – (For static assets on Akamai)Due to the distribution of assets across many regions, CDNs have automatic server availability sensing mechanisms with instant user redirection. As a result, CDN websites experience 100% availability, even during massive power outages, hardware issues or network problems.
  • Analytcs – Another beneficial feature of CDN technology is that more control of asset delivery and network load is awarded. Operators have the ability to deliver real-time load statistics, optimize capacity per customer, display active regions, indicate which assets are popular, and report viewing details to their customers. These details are extremely important, since usage logs are deactivated once the server source has been added to the CDN.
  • E-Commerce Overall performance booster – Our site will have best exposition in search engines, will open faster and have a better availability. All these items combined will reflect in more traffic and more orders.

Now that we know what CDN is, how do we setup and integrate a our Aurora Store with a  CDN service?

In this post, we will use as example Akamai, that is very popular CDN provider on the marketing.

Default Behavior:

As we know, by default, in Aurora Starter Store when a business user uploads an attachment asset file, the file is initially copied to the WebSphere Commerce database. When certain criteria are met, the attachment asset file is copied from the WebSphere Commerce database to the WebSphere Commerce EAR file.

Until the attachment asset is available in the WebSphere Commerce EAR file (Copied every 30 minutes)., you can view the attachment file only in a store page using the preview function in WebSphere Commerce Accelerator.

Expected Behavior:

To use Akamai, all assets should be stored in a  static HTTP server (IHS Prefered), and to do that, we have to:

 1 – Override the implementation in CMDREG table, to FileSystemCopy.

  • FileSystemCopy
     update cmdreg set className='com.ibm.commerce.wc.appmanagement.commands.UpdateStaticEARContentUsingFileSystemCmdImpl' where interfaceName='com.ibm.commerce.wc.appmanagement.commands.UpdateStaticEARContentCmd';

2 – FileSystem.xml – We have to edit this file, located in the “WC/xml/config” directory. In this file we have to pint where the assets will be copied.

  • proceedOnlyWhenAllServersAreWorkingSet –  Set this value to false. This attribute is only applicable to the root element of FTP servers.
  • FSLocation – A local directory on the WebSphere Commerce system which is mapped or mounted to a remote directory on the Web server system.
<FSLocations xmlns="http://www.ibm.com/xmlns/prod/WebSphereCommerce" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.ibm.com/xmlns/prod/WebSphereCommerce xsd/FileSystem.xsd" proceedOnlyWhenAllServersAreWorking="false">

<FSLocation dir="/temp/filehold"/>


3 – Schedule ScheduledContentManagedFileEarUpdate (Commerce Scheduled Job) to run every 15 minutes only on dedicated staging appserver.

4 – Schedule Shell scripts jobs to copy the  files and folders created by the business user, from this folder in the app server to our webserver. This script can use rsync or other technology. You may also allow the app to save the asset directly on the web server, mounting a folder with NFS, but I don’t like this solution.

*We can define type of files that will be copied in the UpdateEARFilter.properties file.


Reviewing, now, we have the following scenario.



  1. Business user uploads assets and have created specific folder structure in the asset toll, inside CMC.
  2. These assets and folder structure where created inside the database.
  3. A combination of jobs, Shell Scripts, XML Changes and updates in the CMDREG table copied these assets and folders to  our web server.


Lets assume that our webserver, has a Virtual Directory that answer to the following sub domain name:


If a user uploads a structure like:


Then, we should have:


But, our goal isn’t  allow the users to download the images from our webserver, then we have to:

  1. Create a subdomain, to point to Akamai servers. For example: images.aurora.com
  2. Create a rule, where if Akamai serves are hit, and don’t have the asset, get it from “localimages.aurora.com/*”.
  3. Change our store JSP’s to bring all assets from “images.aurora.com”

This way, we will have all shoppers downloading images from the CDN network, when visiting our store. This applies to all images, like, Marketing Assets, Catalog Assets and others.

It’s important to remember that WCS allows dynamic eSpots (“What the heck is an eSpot”  from my friend Bob Balfe), so the requests will still hit the APP server in these dynamic cases, but after receive the decision of what asset will be displayed, the browser will download the asset from the CDN.

At the end, this will be the scenario:



  1. Shopper access the store
  2. Browser queries application server to know what assets shoud be displayed on the eSpots.
  3. Browser downloads all assets from the Akamai CDN. (images.aurora.com)
  4. If Akamai does not have this asset cached yet (normal situation for first time requests), it will be query the local image repository we  set in our HTTP Server (localimages.aurora.com).

The concepts of using Akamai are very easy, but setting all these things is not so trivial. If you need any help about how to make this set up, in terms of JSPs, shell scripts and others, please, fell free to contact me.



Changing managed file WebSphere Commerce EAR updater parameters


Updating static Web assets to a remote Web server


Configuring the scheduler to run a job on an instance or cluster member