Some Java, JEE and WebSphere stuffs | Something about JEE and WebSphere. Java, JEE and WebSphere tips and tutorials

WebSphere Commerce Developer Enterprise 6.0 installation – Part 1

RAD Installation
WebSphere Commerce Developer is an application that is running on top of Rapid Application Developer 6.0.0.1. The primary requirement for WebSphere Commerce Developer Enterprise installation is RAD 6.0.1.1. If your RAD is an older version, then you need to upgrade your Rapid Application Developer version to 6.0.1.1. Upgrading RAD to version 6.0.1.1 is very easy. Download the packages from http://www-1.ibm.com/support/docview.wss?uid=swg24010926. This page offers two downloads one is to upgrade the Rational Product Updater and another is to upgrade RAD to fix level 6.0.1.1. Follow the instructions mentioned in http://www3.software.ibm.com/ibmdl/pub/software/rationalsdp/rad/60/install_instruction/6011/install.html for upgrading Rational Product Updater and Rational Application Developer. (Don’t ask me what if you have higher version of RAD installed? I don’t know what needs to be done for that. For me my RAD version was below 6.0.1.1 and I followed all the above procedures. )

Upgrading WAS Test Client. Installing WAS Fix packs.
Once we have RAD 6.0.1.1, we need a WebSphere Application Server Test Environment version 6.0 updated to a minimum of WAS 6.0.2.5 level. To upgrade WAS 6.0.0 to 6.0.2.5 level, we need to apply three different fix packs. Download WAS Refresh Pack 2 from http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg24009813. The second fix pack we need to download is WAS 6.0.2 Fix pack 3 which is available at http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg24010724. Finally we need to have WAS 6.0.2 Fix Pack 5, available at http://www-1.ibm.com/support/docview.wss?rs=180&uid=swg24011099, to upgrade our WAS Test Environment version to 6.0.2.5.

Once we have our Fix packs downloaded, follow the following steps to install the above Fix packs.

1. Open your command prompt.
2. Navigate to your AppServer’s bin directory. If you have installed RAD to C:\RAD directory, your AppServer bin directory will be C:\RAD\runtimes\base_v6\bin.
3. Execute the command setupCmdLine.bat. This command sets all the required environment variables.
4. Extract the contents of WAS Refresh Pack 2 zip file. (Most probably the zip file name will be 6.0-WS-WAS-WinX32-RP0000002.zip).
5. Copy the contents of ‘updateinstaller’ directory to appserver root directory.
6. Navigate to this updateinstaller directory from your command prompt.
7. Execute the command update.exe. This will start the update installer wizard for WAS refresh pack 2.

8. Click on Next and from the page appeared, point to your AppServer root directory.

9. Click on Next. The page would ask us to select the maintenance operation. Select ‘Install maintenence package’ as the choice.

10. Click on Next. This window will ask us to select the location of maintenance package that we are installing. If we follow all the above steps without fail, it will populate the correct maintenance package location by default. If not the maintenance package will be inside updateinstaller\maintenance directory.

11. Click on Next. This will show you the pre installation summary.

12. Now click on Next. This will start the installation of WAS refresh pack 2.

13. Once the installation is over. We will be presented a screen confirming the installation.

14. Now click on Relaunch button.

15. Follow all the steps from 8 to 13. This wizard will install maintenance package RP6020 for WAS test client.

16. Once the wizard completes the installation exit the wizard by clicking on Finish button.

17. Now our WAS Test client will have 6.0.2.0 as its version.

18. Delete the updateinstaller directory from AppServer root directory.

19. Repeat steps 4 to 18 for installing the refresh pack 3 and 5.

Once you have installed all the required fixes, the WAS Test Client will be upgraded to version 6.0.2.5, the minimum required version for WCS installation. I will cover the installation of WebSphere Commerce Developer Enterprise 6.0. in the next post.

Most of the WCS developers are confused with the member subsystem and different types of users in WCS. Here is a small post on the different types of WCS users and their differences.

The member subsystem of WCS handles the users of a WebSphere Commerce site (Member subsystem also covers the organizations, member groups, roles and access control policies). Users of a WCS site are the business users or administrators that manage the store or end users who access the site for shopping.

A WebSphere Commerce site can have three types of users. Generic, Guest and Registered users. All the users of any WCS installation fall under any of these categories including business users and store administrators.

A generic user is a user who just accessed the site. Any user accesses a WCS website will have a userId associated. All the generic users share the same userId and for a default WCS installation the generic userId will be -2001 (At least in my case). The generic user does not have any user information.

When a generic user adds an item to the shopping cart, he/she becomes a guest user. All the guest users will have a unique userId associated. This guest user can have personal information stored in the database as they are having a unique userId. This userId is extremely important and is used for tracking their shopping cart.

A registered user is any user who signs up in a WCS system. They will have a username and password for logging into the application. They can have a permanent address in the system. Even the site/store administrators and business uses comes under this category. Any user can become a registered user by signing up or signing in to the system.

A new problem has been found in WebSphere Commerce Server sites. Because of a hard coded date in the product, customers will no longer be able to add items to their shopping carts. All WebSphere commerce sites are affected as all editions of the product has this hard coded date. When customer adds an item to the shopping cart, an error message “CMN2022E: The command is unable to determine an appropriate fulfillment center for an OrderItem.” will be displayed.

The solution to this problem is to check the SHPARRANGE table and verify that the ENDDATE field has not expired. If it is expired, update this field to a future date and restart the WebSphere Commerce Server.

For eg:

update shparrange set enddate = '2018-06-22-23.00.00.000000' where enddate = '2008-06-22-23.00.00.000000

To create a new view command in WCS 5.6 we need to make a couple of database entries. i.e., we need to make an entry in VIEWREG, ACACTION, ACACTDESC, ACACTACTGP tables. For e.g.: if we want to make a new view command ‘MyNewView’, the database entries for this view command to work will be.

INSERT INTO VIEWREG(VIEWNAME, DEVICEFMT_ID, STOREENT_ID, INTERFACENAME, CLASSNAME, PROPERTIES, DESCRIPTION, HTTPS, INTERNAL) VALUES ('MyNewView', -1, 1000, 'com.ibm.commerce.command.ForwardViewCommand', 'com.ibm.commerce.command.HttpForwardViewCommandImpl',  'docname=MyNewView.jsp' , 'My New view', 0, 0);
INSERT INTO ACACTION(ACACTION_ID, ACTION) VALUES ((SELECT MAX(ACACTION_ID)+1 FROM ACACTION), 'MyNewView');
INSERT INTO ACACTDESC(ACACTION_ID, DISPLAYNAME, DESCRIPTION, LANGUAGE_ID) VALUES ((SELECT ACACTION_ID FROM ACACTION WHERE ACTION='MyNewView'), 'MyNewView', 'MyNewView', -1 );
INSERT INTO ACACTACTGP(ACACTGRP_ID, ACACTION_ID) VALUES ((SELECT ACACTGRP_ID FROM ACACTGRP WHERE GROUPNAME='AllSiteUsersViews'), (SELECT ACACTION_ID FROM ACACTION WHERE ACTION='MyNewView'));

Here the storeId I used is 1000 and the viewname is ‘MyNewView’. This is the easiest way of creating a new view command in WebSphere Commerce Server 5.

To create a new controller command we need to make a couple of database entries. i.e., we need to make an entry in URLREG, CMDREG, ACACTION, ACACTDESC, ACACTACTGP, ACRESCGRY, ACRESCGRY, ACRESGPRES tables. For eg: if we want to make a new controller command ‘MyNewCommand’, the database entries for this command to work will be.

INSERT INTO URLREG (URL, STOREENT_ID, INTERFACENAME, HTTPS, DESCRIPTION, AUTHENTICATED, INTERNAL) VALUES ('MyNewCommand', 1000, 'com.mycomp.commands.MyNewCommandCmd', 0, 'My New controller command', 0, 0);
INSERT INTO CMDREG (STOREENT_ID, INTERFACENAME, DESCRIPTION, CLASSNAME, TARGET) VALUES (1000, 'com.mycomp.commands.MyNewCommandCmd', 'My new controller command', 'com.mycomp.commands.MyNewCommandCmdImpl', 'Local');
INSERT INTO ACACTION (ACACTION_ID, ACTION) VALUES ((SELECT MAX(ACACTION_ID)+1 FROM ACACTION), 'com.mycomp.commands.MyNewCommandCmd');
INSERT INTO ACACTDESC (ACACTION_ID, DISPLAYNAME, DESCRIPTION, LANGUAGE_ID) VALUES ((SELECT ACACTION_ID FROM ACACTION WHERE ACTION='com.mycomp.commands.MyNewCommandCmd'), 'MyNewCommand', 'My New controller command', -1);
INSERT INTO ACACTACTGP(ACACTGRP_ID, ACACTION_ID) VALUES ((SELECT ACACTGRP_ID FROM ACACTGRP WHERE GROUPNAME='AllSiteUsersViews'), (SELECT ACACTION_ID FROM ACACTION WHERE ACTION='com.mycomp.commands.MyNewCommandCmd'));
 
INSERT INTO ACRESCGRY(ACRESCGRY_ID, RESCLASSNAME) VALUES ((SELECT MAX (ACRESCGRY_ID) + 1 FROM ACRESCGRY), 'com.mycomp.commands.MyNewCommandCmd');
INSERT INTO ACRESGPRES(ACRESCGRY_ID, ACRESGRP_ID) VALUES ((SELECT ACRESCGRY_ID FROM ACRESCGRY WHERE RESCLASSNAME='com.mycomp.commands.MyNewCommandCmd'), 10119 );

Here the storeId I used is 1000 and the command interface is ‘com.mycomp.commands.MyNewCommandCmd’ and the implementation class is ‘com.mycomp.commands.MyNewCommandCmdImpl’. This is the easiest way of creating a new controller command.