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

Commerce Accelerator Customization

I was customizing WebSphere Commerce Accelerator for that last couple of weeks. We are adding a new feature for configuring a product dynamically. WCS does not provide any product configurator OTB and hence no screen was available in Commerce Accelerator to manage the Product Configuration. Our business wants to manage the Product Configuration from commerce accelerator. So the only option available to us was to customize Commerce Accelerator. Customizing WebSphere Commerce Accelerator is a very difficult task. Commerce Accelerator uses a framework called Tools Framework which manages all the state using JavaScript. If someone wants to learn Object oriented JavaScript the best thing to do is to customize some of the Tools Framework components. The biggest issue with Commerce Accelerator customization is JavaScript debugging. CA works only in IE and there are no good debuggers available for JavaScript debugging in IE.

Every time I customize Tools Framework I will think to document how to do this customization. However unfortunately it never happens. So next time when I started customization I need to do the same research again and again. So this time I kept some notes on how to create Wizard, Notebook, Dialog, Tree etc.

I am thinking of some posts that contain these notes on customizing and debugging of commerce accelerator whenever I get some time.

Creating a new Key in WCS

In WebSphere Commerce, tables that need a unique primary key, the keys are not auto generated. They are coming from the KEYS table. The WCS table KEYS defines the range of key values for all tables that require a unique key. So always new key generated will be using values of KEYS table.

Any time if you need this value programmatically, you can get it using ECKeyManager class. So the code for getting the next keys table for a table is

com.ibm.commerce.key.ECKeyManager keyMgr = com.ibm.commerce.key.ECKeyManager.singleton();
Long key = keyMgr.getNextKey("tablename");

Where tablename is your table’s name. Table name is case sensitive. If your primary key is defined as long data type use getNextKeyAsLong instead of getNextKey method.

In order to work the above code, we need to have an entry in the KEYS table.

WebSphere Commerce Developer Enterprise 6.0 installation – Part 1 covers the installation of RAD and WAS Fix packs. Once we have done with all that installation we are ready for our WebSphere Commerce Developer 6.0 installation. If we are planning to install IBM Sales Center as part of our development environment, we need to install IBM Sales Center before installing WCS Toolkit.

To perform the WCS installation follow the below steps. I had already installed IBM Sales Center in my machine.

1. Double click on setup.exe from WCS Toolkit CD. This will bring the installation wizard.

2. Click on Next and from the page appears accept the license.

3. Click on Next and select the installation directory. Please select a directory with no spaces and no long file paths.

4. Click on Next. This screen would ask us to select the installation components. Select the components you want to install. (Select at least the WebSphere Commerce development environment ).

4. Click on Next. This page will be the installation summary page.

5. Now click on next. The installation of WCS Toolkit begins and you will be presented with a screen as shown below.

6. Once the installation is over. Click on Finish and exit the wizard.

We are done with our WCS 6 Toolkit installation. Go to Start -> Programs -> IBM WebSphere Commerce Developer Enterprise 6.0 -> WebSphere Commerce development environment and start your toolkit. Publish a store and start coding.

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.