Pages

Monday, December 13, 2010

Problem with Websphere Commerce Server Marketing Spots

Marketing spots are space on a page that are used by the business and marketing team to display the featured products on the website.

I am working on Websphere Commerce v 6.0 with fix pack 9. There are a total of 16 marketing spots on the home page displaying featured products. Every week or so, marketing people use websphere commerce management centre on our staging environment to update marketing spots with new catalog entry items.

There is a stagprop utility batch that runs and propagates all espot associations to our production environment. However, the new product associations with eSpots didn’t show up on our production site. We logged in to commerce administration console and updated the “CampaignInitiativeCache” registry and then cleared the dynamic cache for the eSpots. This should have cleared and updated the eSpots. However, to our surprise, even after updating the registry and clearing the dynamic cache on the server, we couldn’t see the latest eSpot associations on the site. We finally had to restart the complete application server to get the latest eSpot displayed on the page.

We enabled the marketing and cache trace logs and looked at the resulting logs

com.ibm.websphere.commerce.WC_CACHE=all: com.ibm.websphere.commerce.WC_MARKETING=all: com.ibm.websphere.commerce.WC_SCHEDULER=all: com.ibm.commerce.marketing.*=all

We have a cluster of two application servers on our production environment. The logs below indicated that the application server 2 had a stale web-activity cache and server 1 had up to date web-activity cache.

Server 1 Logs
[22/11/10 11:06:00:369 EST] 000013a9 engine        1 com.ibm.commerce.marketing.internal.runtime.engine.RemoteCall remoteCall    activity: id= 14501 name= MAI_MainProduct1 description= null storeId= 10601 campaignId= null campaignName= null state= 1 createdDate= 2010-06-30 16:00:24.931 lastUpdate= 2010-11-16 11:28:08.242 lastUpdatedBy=

Server 2 Logs
22/11/10 11:04:46:506 EST] 000034ff engine        1 com.ibm.commerce.marketing.internal.runtime.engine.RemoteCall remoteCall    activity: id= 14501 name= MAI_MainProduct1 description= null storeId= 10601 campaignId= null campaignName= null state= 1 createdDate= 2010-06-30 16:00:24.931 lastUpdate= 2010-11-08 15:58:18.723 lastUpdatedBy=

On server 2, the webactivity cache for the espot was stale, ie., had an older activity in cache.

With the basic cachemonitor application that was installed, we could only clear the dynamic espot jsp cache. This would only clear the jsp’s associated with the espot. On the other hand the web activities were cached in a separate instance called the DM_CACHE. To view and work with this instance, we had to upgrade our cache monitor to an extended cache monitor.

IBM Extended Cache Monitor for IBM WebSphere Application Server technology preview
http://www.ibm.com/developerworks/websphere/downloads/cache_monitor.html

To upgrade the cachemonitor on WAS 6.0, login to the ibm websphere application server console and select as below


 


Note: Select the cachemonitor602_update.zip which is available in the cachemonitor602_package.zip archive for application server 6.0 versions

Once updated, save the settings to master configuration. Now you shall be able to see the upgraded dynamic cache monitor.



The DM_Cache caches the marketing elements and activities


Invalidating the DM_ACTV_XXXXX and DM_ELEM_XXXXX updated the eSpots with latest content / catalog entry.

We investigated why updating the registry and clearing the JSP cache didn’t work at the first place and found that the commerce management centre feature was not enabled properly. In the wc-server.xml file, we found that the element “Marketing Version” was set to “Classic”. This should be set to “Dialog” instead. This wc-server.xml setting should look like

<Marketing Version = “Dialog” />

As per IBM infocenter – “This value tells WebSphere Commerce which marketing runtime to use. There are two marketing versions: Classic refers to the pre-Feature Pack 3 marketing runtime; Dialog refers the marketing runtime required for Feature Pack 3 and later feature packs. When you set this value to Dialog, you must use the Management Center Marketing tool for any functions that it supports (campaigns, content, Web activities, e-mail activities, and e-mail templates).”

Following link specifies how and why you need to enable this
http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm.commerce.management-center.doc/tasks/tsbenable.htm

Once set to “Dialog”, refreshing the “CampaignInitiativeCache” registry did clear the activities and element cache and updated the espot with new content

But I really wonder why enabling management centre feature didn’t just update the “Marketing Version” to “Dialog” while installation of WCS.

No comments:

Post a Comment