IBM HTTP Server Load Balancing Configuration

IBM HTTP server can be configured to perform basic load balancing to redirect requests to the websphere commerce server in the server cluster.

For setting up an IBM HTTP server with websphere commerce, you need to install a plugin which creates a plugin-cfg.xml.  This file contains configurations for virtual hosts, server cluster and other configurations.

So to define a load balance configuration for an application server cluster of 2 servers, the following sample settings are shown

<ServerCluster CloneSeparatorChange="false" GetDWLMTable="false" LoadBalance="Round Robin" Name="CommerceCluster" PostBufferSize="64" PostSizeLimit="-1" RemoveSpecialHeaders="true" RetryInterval="60">

     

<Server CloneID="15148o4st" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="server1" ServerIOTimeout="0" WaitForContinue="false">

         <Transport Hostname="wcsas01.domain.com" Port="9060" Protocol="http"/>

         <Transport Hostname="wcsas01.domain.com" Port="9062" Protocol="https">

         </Transport>

</Server>

<Server CloneID="15148o50q" ConnectTimeout="0" ExtendedHandshake="false" LoadBalanceWeight="2" MaxConnections="-1" Name="server2" ServerIOTimeout="0" WaitForContinue="false">

         <Transport Hostname="wcsas02.domain.com" Port="9060" Protocol="http"/>

         <Transport Hostname="wcsas02.domain.com " Port="9062" Protocol="https">

         </Transport>

</Server>

<PrimaryServers>

         <Server Name="server1"/>

         <Server Name="server2"/>

</PrimaryServers>

</ServerCluster>

The ServerCluster tag in the above XML snippet defines the servers in the cluster and also specifies the algorithm used for load balancing (in this case “Round Robin”). Each server in the cluster is defined in the Server tag. One of the important attributes of the “Server” xml tag is the “LoadBalanceWeight”.

The value assigned to this attribute will be the starting value for the server weight. The server weight is lowered by the HTTP server dynamically whenever a request is allocated to that server. This will result in the value getting to 0 or lower sooner or later. So setting a lower value like 2 (default is 2) means the LoadBalanceWeight will get to 0 or less very quickly and the HTTP server will readjust the weights when all the LoadBalanceWeight goes to 0 or less very quickly for all the servers defined in the cluster.  Hence, it is recommended to put a larger weight value like 99 in this attribute.

Also, one more point to note is that at runtime, the HTTP server normalizes all the LoadBalanceWeight of all servers defined in the cluster by their highest common factor. For example, assume you have 2 application servers in the cluster and you have set the weight as 100 100. This will result in a weight of 1 after normalization (highest common factor 100). Hence it is advised to keep the weight of at least one of the servers off by a value 1 with others. For example keeping the weights as 100 and 99 for server1 and server2 respectively will not change the starting weights after normalization.

Getting to know Schedulers and Jobs in Websphere Commerce

The scheduler is a background server (runs as a low priority thread) which schedules and runs jobs at the site and store levels.

Some of the key tables are

SCHACTIVE – This contains an active list of jobs that needs to be executed. The scheduler polls this table to find the jobs to run.

SCHCONFIG – This table contains the configuration information for a particular job. The configuration may be an INTERFACENAME of a command to be executed, STOREENT_ID if the job has to run for a specific store (0 for all stores) and you can also specify which node of your application server cluster will run this job by specifying the SCCHOST field in this table.

SCHSTATUS – For each job that is executed, this table contains the status of the job. This table might have huge number of records after a certain amount of time which might impact performance of WCS.

There are three kinds of jobs namely Regular, Store Level and Broadcast jobs. Regular jobs run at site level and are generally Commands that are automatically scheduled to execute at a particular interval. When a regular job is created (using websphere commerce administration console), an entry is made to the SCHACTIVE table with status as I (Has to run at preferred start time). Once the job runs and completes, an entry is made to the SCHSTATUS table.

Store Level Jobs contain a task command that check if the job needs to be run based on certain conditions. When created, an entry to SCHACTIVE table is made with status as W (Waiting for execution).

Broadcast jobs are run by all the websphere commerce servers / nodes connecting to the same database.

To remove job status records from SCHSTATUS table, either login to websphere commerce administration console and delete the status by selecting them or click “Remove All” to delete all records from the scheduler status table.

Preventing some URL parameters from encryption in websphere commerce

There are some situations where you would want to prevent certain URL parameters to be encrypted by Websphere Commerce. For example, there was a situation I faced wherein the product detail page displayed the ratings and reviews (BazaarVoice integration). The requirement was that only registered users be able to write a review for a product. Hence, when a guest user clicked on "Write a review" from product detail page, there was a redirect to a secure login page (https). 

This was encrypting the URL parameters required by BazaarVoice into a "krypto" parameter. And when after login, the page redirects back to ProductDetail page, the BazaarVoice section on the page just wouldn't display.

To overcome this, certain parameters required by BazaarVoice had to be unencrypted and part of the URL parameter.

To achieve this, open the wc-server.xml file which is generally found at C:\WCToolkitEE60\xml\config where C:\WCToolkitEE60 is the websphere commerce toolkit installation path. Search for NonEncryptedParameters XML attribute in the file. In this section of the xml, we define all the parameters that should not be encrypted by WCS over a secure connection.

<NonEncryptedParameters>

    <Parameter display="true" name="user"/>
    <Parameter display="true" name="bvpage"/>
    <Parameter display="true" name="return"/>

</NonEncryptedParameters>

Having this will ensure that WCS doesn't encrypt the listed parameters. All the NonEncryptedParameters are appended to the beginning of the URL.

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.