Troubleshooting Websphere Commerce Developer Startup issue

If the following exception occurs starting up the websphere application server test environment in your websphere commerce toolkit 6 then

Caused by: com.ibm.ws.exception.ConfigurationWarning: 

com.ibm.etools.j2ee.commonarchivecore.exception.NoModuleFileException: 

A file does not exist for module element having uri: 

WebSphereCommerceServerExtensionsData.jar.

Do the following

1. Navigate to WC Folder in your projects explorer view
2. Right clik on WC project and select close project. 
3. Once the build completes, right click again and open the project. 
4. This will again trigger a build and updated the WC enterprise application

Then restart the websphere application server test environment. If this doesn't work then restart the workspace itself.

Enabling Log and Trace for IBM Websphere Commerce Debugging

WCS logs can be configured using Websphere Application Servers’ Administration Console.

1. Login to the WAS admin console. Generally, the link for the admin console is

http://<<hostname>>:<<portnumber>>/ibm/console/

2. Select  Troubleshooting > Logs and Trace option from the left menu items in the admin console and then click Logs and Trace and select <<server1>> from the screen.

3. The above step will display general properties for logging and tracing for WAS.

Diagnostic Trace

JVM Logs

Process Logs

IBM Service Logs

Change Log Detail Levels

4. Select Diagnostic Trace for enabling / disabling log levels and setting the trace output formats (Simple, Advanced or Log Analyzer)

5. Selecting Change Log Detail Levels  from step 4 above will display all the Components  of Websphere commerce. Trace level can be enabled for a specific  components or for a whole set of components. Various trace levels available are

Off

Fatal

Severe

Warning

Audit

Info

Config

Detail

Fine

All

6. For example, to enable trace logs for specific components related to webservices, you might want to enable the logs for the following components

com.ibm.commerce.wc.messaging.adapters.jcahttp.JCAHTTPManagedConnectionImpl

com.ibm.commerce.wc.messaging.adapters.jcahttp.ws.JCAHTTPWSManagedConnectionFactoryImpl

com.ibm.websphere.commerce.WC_SERVER

com.ibm.websphere.commerce.adapters.jcahttp

com.ibm.ws.webservices.*

com.ibm.websphere.commerce.WC_MESSAGING

com.ibm.websphere.commerce.WC_TRANSPORT_ADAPTER

com.ibm.websphere.commerce.WC_SENSITIVE_INFO

Once the log levels are changed as per requirement, bounce the application server by issuing stopServer <<server1>>  from the <<AppServerHome>>/bin directory. Before starting the server, ensure that logs folder is cleared so that fresh logs are created.

The above details are valid for IBM Websphere Commerce 6.0 Fix Pack 9, Feature pack 1,2, 4 and 5 and WAS version 6.0.2.27

Overview of Websphere Commerce eMarketing Spots (emspot)

ESpots are specific defined areas on a JSP page whose content can be dynamically configured based on rules. Since websphere commerce version 6.0 and Feature pack 3 onwards, management centre feature can be used to manage ESpots, activities, catalog, and other marketing activities.

Introduced in feature pack 3, eSpot is created in management centre and the websphere commerce tables which are affected are as below

Emarketing Spots are stored in a table named EMSPOT with EMSPOT_ID (system generated), STOREENT_ID (store for which emarketing spot is created) and NAME (name of the emarketing spot) being the unique keys for the table.

There is a field SUPPORTEDTYPES which defines, as the name implies, supported types of things that can be displayed on an emarketing spot. In version 6.0 of wcs,

The types of things that this e-Marketing Spot can display:

A = Awareness ad

P = Product

C = Category

S = Cross-sell or Up-sell on product.

G = General content, which corresponds to a content spot. This value should only be used by the system.

Web activities are defined as rules to display targeted marketing content to customers in predefined e-Marketing Spots. If multiple web activities are configured to display different content on the same marketing spot, then the priority of the web-activity comes into picture.

DMACTIVITY is the table which holds the activity data. DMACTTYPE_ID defines the type of the activity. 0 is default for a web-activity. STOREENT_ID is the store with which activity is associated. STARTDATE and ENDDATE specifies dates between which the web activity is active. STATE field defines whether an activity is active or not.

DMELEMENT holds the details of the campaign elements associated with a marketing activity.

DMELEMENTNVP holds the name value pairs for each of the direct marketing element.

DMELEMENT_ID                 NAME                                                             VALUE                                    TRIGGERMATCH

10,512             collateralIdList             10463              0         

10,513             name                           rootPath          0

10,514             emsId                          10414              1

The collateralIdList specifies what the actual collateral to display is. This is contained in a table COLLATERAL

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.

dbclean utility in IBM Websphere Commerce

Websphere commerce provides dbclean utility to clean up the database tables that have lots of obsolete data. For example, the STAGLOG table contains data of changes that needs to be propagated to the production. In a typical architecture, all changes are made to the staging environment and then they are propagated to the production using the stage prop utility. However, over a period of time, the STAGLOG table is filled up with lots of records and could become a performance issue.

The following is the syntax of the dbclean command.

dbclean.sh / dbclean.bat

-object obj –type s  -instancexml s  -db s  -dbuser s   -dbschema s  -dbpassword s  -dbtype s

-check_object_only s  -comming n –max s   -log s  -loglevel s  -script s  -days s –name s

-jdbcDriver s  -jdbcUrlPrefix s  -jdbcCustomizer s  -sqlmode n

Where

object is the name of the object to be deleted. Websphere commerce defines various objects in the following URL http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm.commerce.admin.doc/refs/rduobjects.htm

type of an object is also specified for each object in the above URL.

instancexml is the absolute path of the commerce instance xml file. Usually this can be found at WebSphere/CommerceServer60/instances/<<instance_name>>/xml/<<instance_name>>.xml 

db – Optional - is the name of the database. For oracle type in as host:port:sid

dbuser – Optional – is the owner of the schema or the administrator of the database. If not specified id of user invoking dbclean command is used

dbschema – Optional – is the database schema name

dbpassword – Optional – is the password for the login ID specified by dbuser parameter

dbtype – Optional – specifies the dbtype. Default is DB2.

check_object_only – Optional – checks dependencies between tables if specified as “yes”. For example, an OrderItem might have an owner (user).

Loglevel – Optional - NONE, ERROR, WARNING, NORMAL, INFO/VERBOSE, or DEBUG (Default)

As an example, to delete obsolete objects from STAGLOG table, the following is the command

dbclean.sh  -object staglog –type obsolete –instancexml <<Commerce_Server_path>>/CommerceServer60/instances/<<instance_name>>/xml/<<instance_name>>.xml  -db host:port:sid  -check_object_only yes   –dbtype oracle    -dbuser <<dbuser>>  -dbpassword  <<dbpwd>>

 This will delete all STAGLOG entries with type=obsolete, which means that all records that have STGPROCESSED=1 (already processed) in the STAGLOG table.

I just realized that the attribute "days" is a mandatory attribute for STAGLOG object. Specifying -days 1 means that remove all objects of STAGLOG which are atleast 1 day older.