Determining whether a product is “Web-Ready” in Websphere Commerce (WCS) or not

Websphere commerce catalog sub system stores catalog related information in various tables. One such table is the CATGPENREL. This table holds the relationship between a catalog group (which is actually a group of catalog items or category at the store level) and an entity (which is a product from the CATENTRY table).

When there is an association between a category group and a catentry, it means that the catentry (product / SKU) is associated with a catalog group.

Before displaying a product on the frontend Websphere commerce checks if the product is associated with any category for a particular store or not.

There are three mandatory fields in this database table which also form the complex primary key for the table. These are

1. CATGROUP_ID – This is the unique id of the catalog group (Category)
2. CATALOG_ID – This is the unique id of the catalog for a particular store. This can be found from STORECAT table
3. CATENTRY_ID – This is the unique id of the actual produc / sku which is a foreign key on CATENTRY table

The query to check if a product is web-ready or not is

select * from catgpenrel where catalog_id=(select catalog_id from storecat where storeent_id=<<store_id>>) and catentry_id=<<catentry_id>>

<<store_id>> is the unique id of the store in question

<<catentry_id>> is the unique catalog entry (product / SKU) id from CATENTRY table

Encoding websphere commerce or websphere commerce build and deploy properties files with sensitive information like userId and password

Encoding websphere commerce or websphere commerce build and deploy properties files with sensitive information like userId and password

Generally, Websphere Commerce Build and Deploy (WCBD) have many properties files containing information about the build and deployment. Usually you would store userId and Password for configuration manager like an svn or a cvs.

To encode properties in a file, follow the steps below

1. Open a command window and change directory to the application server bin directory.

For example,

C:\RAD601\runtimes\base_v6\profiles\default\bin assuming C:\RAD601 is my RAD installation directory and base_v6 is the websphere 6 installation directory.

2. Execute the following command

PropFilePasswordEncoder.bat  <<source_file path>> <<properties_to_encode>> [-Backup/-noBackup]

Provide the source properties file path followed by comma separated properties to encode and optionally specify whether the original file has to be backed up or not.

PropFilePasswordEncoder.bat "C:\Documents and Settings\chetanr\Desktop\extract-svn.private.properties" svn.user,svn.password -Backup

In the above example, I have properties file containing svn login information for my websphere commerce build. I need to encode the login information to secure it from being viewable to other users of the system.

This is not a fool proof way for the userid and password to be stored since it is a basic Base64 encoding done by websphere.

How to achieve near to zero downtime deployment for WCS in ND mode

Today I will walk through as to how we can achieve a near-to-zero downtime deployment of Websphere Commerce application on production environment with deployment manager (a.k.a node manager).

In my previous posts, I mentioned that the deployment manager holds the master copy of the websphere commerce EAR artefacts.  The deployment manager is responsible for keeping all the nodes, configured with it, synchronized. Any deployments to be done on the production should be done to the deployment manager itself (using the script deploy.sh usually a script that calls an ant task).

Note: Never deploy directly on the node as this may corrupt the EAR.

To achieve a near-to-zero downtime deployment, follow the steps below. The purpose is to make the site available most of the time to the end-users with minimal interruption. For the purpose of simplicity I am assuming here that there are two nodes namely “Node A” for “Server A” and “Node B” for “Server B” and a deployment manager in my environment. Also, I am assuming two webservers “Web 1” and “Web 2” which use round robin method to redirect requests to application server.

1. Build the websphere commerce zip/ear file using the websphere commerce build and deploy (WCBD) instance.

2. Before starting the deployment, ensure that webservers are configured to route the requests always to one of the servers, in this case “Server B”.

3. Stop the node agent on “Node B” so that the deployment manager does not have the status availability for this node. To stop à login to the server (Node B) and issue stopNode.sh / stopNode.bat command. This will not stop the request processing coming through from the web server because the server is still running.

4. Now use the deployment script to deploy websphere commerce. This script will first deploy on to the deployment manager and then propagate the changes to “Node A” (Node agent on Node B is currently inactive). When the changes are being propagated, the WC application on the server restarts.

5. Ensure that the propagation is complete. This can be done by looking at the server and application status on the node manager console and also by monitoring the EAR size on the application server. Stop and start the application server A.

6. Once deployment to “Node A” is complete, configure webservers to redirect all requests to Server A.

7. Now start the node agent on “Node B”. This can be done using startNode.sh / startNode.bat. Once the node is started, the deployment manager synchronizes “Node B” with the new deployed EAR.

8. Once the deployment is complete on “Node B”, then configure the webservers to route requests to both application servers in a round-robin way (or whatever is the load balancing algorithm)

Note that the webservers need to be restarted 3 times for the configuration to take effect in step 2, 6 and 8. But this is much faster than restarting the application servers.

Websphere Commerce Deployment Architecture

A.    The deployment manager is a separate independent node that contains the master copy of the Websphere commerce application EAR file

B.    The deployment manager basically is a node manager which manages multiple nodes. In this way, horizontal scalability can be achieved by adding new nodes to the architecture and configuring the node manager to manage the newly added nodes.

C.   For each application server, a node agent is available. The node manager interacts with this node agent to monitor the node and propagate changes to keep the nodes in synch.

D.   All the application servers in the architecture connect to a single Websphere Commerce Database.

Installing Dynacache monitor and enabling servlet caching on websphere application server

Installing DynaCache Monitor and enabling servlet chaching on WCToolkit

Cachemonitor is an EAR application provided by IBM for managing the dynacache of the websphere application server.

Follow the link below which guides how to install cache monitor on Websphere Application Server. The cachemonitor.ear must be part of the installableApps of the websphere application server.

http://publib.boulder.ibm.com/infocenter/wchelp/v6r0m0/index.jsp?topic=/com.ibm.commerce.admin.doc/tutorial/tdcperf1b.htm

How to enable servlet caching

Once cachemonitor is installed, open the ibm websphere application server console.

The URL is generally http://localhost:9060/ibm/console

Click the servers => application servers option

Select the server (generally server1)

Expand the container settings section and then select web container

Now select the checkbox named “Enable Servlet Caching” to enable servlet caching.

How to expand or collapse EAR on Websphere Application Server

EARExpander

This command is used to either expand the Enterprise Archive in to a file system or collapse the application files into a single EAR file.

The syntax is

EarExpander -ear earName -operationDir dirName –operation <expand | collapse> 

[-expansionFlags <all|war>]

Where

-       earName specifies the source EAR file name if it is a expand operation or output EAR file name for collapse operation

-       operationDir specifies the directory where EAR needs to be expanded or a directory from where EAR needs to be collapsed in to a file.

-       expand or collapse option to either expand an EAR or collapse a directory to a EAR

-       an optional expansionFlags

o   all - expand war’s, rar’s.

o   war – to expand only .war

Adding a certificate to server trusted store

Setting up digital certificates for Websphere Commerce

There is almost always going to be situations where your websphere commerce instance would need to interact with various external systems like payments, fulfilment, inventory systems. The interactions between external systems would almost always be through a secure channel (https, sftp, etc).

For example, to set up websphere commerce as a webservice consumer, we need to trust the certificate presented by the server hosting the webservice else you will get a SSLHandshakeException.

There are two ways to do this.  One way is to update the cacerts in the websphere application server path. The cacerts file is the trusted store for the websphere application server and is available at the path C:\RAD601\runtimes\base_v6\java\jre\lib\security assuming that C:\RAD601 is your RAD installation.

To update the cacerts, follow the steps below:

1. Copy the certificate file (usually .pem or .cer) file to a temporary directory in your local drive

2. Change directory to C:\RAD601\runtimes\base_v6\java\jre\bin

3. Run the following command

keytool –import –v –keystore C:\RAD601\runtimes\base_v6\java\jre\lib\security\cacert –alias AliasName –file c:\file.pem

Assuming that C:\RAD601 is the RAD installation directory and base_v6 is the websphere application server instance directory.

AliasName is the name for the certificate in the trusted store.

C:\file.pem is my certificate file.

4. Enter default password as “changeit” when prompted

5. Type “yes” if you are prompted whether to trust the certificate or not

6. You will see a message like “Certificate was added to keystore” if it was successful.

The second way, and the preferred way, to trust the certificate is as given below

1. Change directory to C:\RAD601\runtimes\base_v6\java\jre\bin and execute ikeyman.exe

2. The IBM key manager window opens as shown above. 

3. Select Open (2^nd Icon) and the open window appears. Now click on browse and traverse to the wasprofile\etc directory in websphere commerce toolkit path. Assuming C:\WCToolkitEE60 is the websphere commerce toolkit installation directory.

C:\WCToolkitEE60\wasprofile\etc

4. Select the DummyServerTrustFile.jks and then select Open

5. Enter default password as “WebAS”

6. Click on Add to add a new certificate to the trust store. Select Browse and traverse to the certificate path and then select the certificate and click OK

7. Now the certificate is added to the Dummy certificate trust file in websphere commerce.

8. Now we need to tell websphere application server about the DummyServerTrustFile.jks. This can be done by opening the websphere application server console on the browser and login

          Usually http://localhost:9060/ibm/console

9. Select Servers à Application Servers and then select the server (default is server1).

10. Once the server configuration properties are displayed, select Java & Process Management option. Under that select the Process Definition option and then Java Virtual Machine from the Additional properties

11. Enter the following in the Generic JVM arguments space and then restart the application server

-Djavax.net.ssl.keyStore=C:\WCToolkitEE60\wasprofile\etc\DummyServerTrustFile.jks -Djavax.net.ssl.keyStorePassword=WebAS -Djavax.net.ssl.trustStore=C:\WCToolkitEE60\wasprofile\etc\DummyServerTrustFile.jks -Djavax.net.ssl.trustStorePassword=WebAS

This will enable the websphere commerce trust store to be established in websphere application server.

WCS 6 Installation primer

• Install RAD 6.0 from disk1 of the installation folder. Ensure that you install it to a folder which has a short path. For example C:\RAD6

• Once RAD 6.0 is installed, update the Rational Product Updater from v6.0 to 6.0.1 or 6.0.2 (rpu_602.zip).

• Install Rational Application Developer Fix Pack 6.0.1.2 (http://www.ibm.com/support/docview.wss?rs=2042&uid=swg24016331) which is a cumulative fix pack. There are three packages for this - rad60_6011_for_6012.zip, radpre60_6012.zip and rad60_6012.zip. It is recommended that you can choose to install from IBM update server automatically rather than downloading the fix.

• Once the update is done, download and unzip WAS refresh pack 2 - 6.0-WS-WAS-WinX32-RP0000002.zip which can be found at http://www-01.ibm.com/support/docview.wss?uid=swg24009813&rs=0&cs=utf-8&context=SSEQTP&dc=D400&q1=refreshpack&loc=en_US&lang=en&cc=US. Unzip to location where RAD is installed. For eg:- C:\IBM\Rational\SDP\6.0\runtimes\base_v6. This will create a updateinstaller folder.

• Run update.exe from the updateinstaller folder. This will backup java and relaunch the update installer to install the refresh pack v6.0.2.

• Now from the updateinstaller for WAS, select Optional Features and select “IBM WebSphere Application Server V6.0 Integrated Test Environment Update Version 6.0.2.5” and “Java SDK Update for IBM WebSphere Application Server V6.0.2.5 Integrated Test Environment” and install the selected features.

From this point, there can be two paths/ways to continue installation of Websphere Commerce.

  

Commerce Installation path1

• (a) Download and install the UpdateInstaller 7.0.0.11 7.0.0.11-WS-UPDI-WinIA32.zip for websphere application server.

• (b) Using the above UpdateInstaller, install the following three maintenance packs:- 6.0.2-WS-WAS-WinX32-FP00000043.pak, 6.0.2-WS-WASJavaSDK-WinX32-FP00000043.pak and 6.0.2.5-WS-WAS-IFWC-file-permission3.pak.

• (c) Install the Websphere commerce using the following command line

a.     setup.exe -cp:p C:\MyData\chetan\Environment_Setup\LI71397_devinstall.jar

This is required as WCS expects WAS version to be 6.0.2.5. However, we have updated the WAS server to version 6.0.2.43 and hence the above fix while installing WCS.

• (d) Once WCS is installed, install the Websphere Commerce update installer download.updii.61011.windows.ia32.zip and install it to a folder on the file system. This is required to apply fix packs to WCS

• (e) Download and install the latest fix pack for WCS (Fix Pack 10 (6.0.0.10)) from the URL http://www-01.ibm.com/support/docview.wss?uid=swg21414685.

• (f) Using the Websphere Commerce update installer (61011), apply fix pack downloaded in the above step.

• (g) Download Feature packs 1, 2 and 4 sequentially in that order and then install by unzipping the feature packs and executing install.windows.ia32.exe from the unzipped folder.

• (h) Download couple of coremetrics fixes for Websphere Commerce from the same location (LATEST - 4.0.0.0-WS-WCFeaturePack4-IFSI32088) and (SI32088 - 1.0.0.0-WS-WCFeaturePack1-IFIZ18527) and install them using the websphere commerce update installer.

• (i) Download and install Feature pack 5 by unzipping the feature packs and executing install.windows.ia32.exe from the unzipped folder.

• (j) Enable the services in Websphere commerce by executing the following commands from c:\WCToolkitEE60\bin

a.     enableFeature.bat -DfeatureName=component-services

b.    enableFeature.bat -DfeatureName=jca4webservices

c.     enableFeature.bat -DfeatureName=management-center

d.    enableFeature.bat -DfeatureName=madisons-starterstore

  

Commerce Installation path 2 (After WAS level is at 6.0.2.5)

• (a)  Install websphere commerce using setup.exe from the installation folder. Install to C:\WCToolkitEE60\

• (b) Once WCS is installed, follow steps d to f from the path 1 described above.

• (c)  Then follow step g above. However, for installing FEP1, FEP2, FEP4 and FEP5 for WCS, it requires the application server to be at a level of 6.0.1.27. Update the websphere application server to the level by applying the fix 6.0.2-WS-WASJavaSDK-WinX32-FP00000027.pak and 6.0.2-WS-WAS-WinX32-FP00000027.pak and then continue with step g through j above.