Testing mobile stores for WebSphere Commerce

Unit testing solutions for mobile stores

This article discusses different ways to test WebSphere® Commerce stores with mobile devices. It also covers methods to emulate the mobile environment, which is often better because the debugging tools on the mobile device itself are limited.


James W. Barnes (jwbarnes@us.ibm.com), Software Engineer, IBM China

Photo of James BarnesJames Barnes is currently a Level 2 Support Engineer for the WebSphere Commerce team. He joined IBM in 1999, first working at the Lucent outsourcing account and then moving to Level 2 Support in 2003, where he focused on development-related issues. Other works include the WebSphere Portal 5.1 Handbook and extensive articles for the Support site on migration and development. He holds certifications for WebSphere Portal development (5.1, 6.0, 6.1, 7.0) and WebSphere Portal Administrator (5.0, 5.1, 6.0). Jim has a B.Sc. degree in Agriculture and Applied Economics from Virginia Tech University. He is based at IBM's Research Triangle Park in North Carolina.

developerWorks Contributing author

14 March 2012

Also available in Chinese


Before we discuss the tools that are available for mobile stores, let's first look at what a mobile store is, why it is important, and common considerations. Additionally, we will cover common mistakes and items that are not well-known, such as browser detection, JSP selection, and device mapping. The article assumes that most users will not have access to all of the devices available.

A mobile store is any store that you are planning to be accessible via a mobile device. In reality, this includes all B2C commerce sites because, in the current market with the proliferation of smartphones and tablets, customers will access your store via a mobile client whether you plan for it or not. To that end, it is smart to include at least unit testing of your site with some mobile devices to ensure your site provides a pleasant shopping experience. Because if they can find it when they want it on their phone, they are more likely to buy it then, rather than trying to remember it later.

So what differentiates a mobile store from just a store that is capable of being viewed on a mobile browser? The distinction lies in setting up your store so that you provide a different markup based on the device making the request. The goal is to provide a richer customer experience to entice them to buy from you. This means that the markup provided is better suited to viewing on a smaller screen and for user interaction than a traditional Web site. Keep these things in mind as you customize the store for your mobile site.

When making your store into a mobile store, there are few options. First off, you can use the mobile starter store that comes with WebSphere Commerce, or you can grow your own by using the mappings in the various tables, such as DISPCGREL and DISPENTREL, to control what JSPs are displayed for mobile requests. With Feature Pack 4 and later, there are also reference native and hybrid applications available. These native and hybrid applications require your customers to install something instead of just using the mobile Web application. These reference applications show how they work with the rest of the services to provide a richer experience for the mobile device user.

Next, let us look at a few items to understand the common points of failure and flow of the request once it reaches the server. The starter store chooses the JSPs to render based from the mappings in the Struts configuration files, as shown below:

<forward className="com.ibm.commerce.struts.ECActionForward" 
  <set-property property="implClassName"                
value="com.ibm.commerce.messaging.viewcommands.MessagingViewCommandImpl" />
  <set-property property="interfaceName"                

The syntax of the name attribute of the forward element is a "docname/storeID/deviceFormatID" triplet, where the third constituent defaults to "-1". However, in this case, you can see it is a "-3". Keep this in mind when it appears that the request is going to be a different JSP than you planned on. This can happen because the request bypassed the device detection, the user agent string does not map to the one you have defined, or a mapping is missing for the view being requested.

If you decide to grow your own mobile store and use the DISPCGREL and DISPENTREL tables to control which pages are displayed, be aware of how the mapping actually works. Let's say you have sample entries like the ones shown in Table 1.

Table 1. Sample DISPENTREL table
0 10001 -1 -11 10001 mobile/ShoppingArea/CatalogSecion/CatalogEntrySubsection/PackageDisplay.jsp PackageBean 0
0 10002 -1 -1 10001 ShoppingArea/CatalogSecion/CatalogEntrySubsection/PackageDisplay.jsp 1

The rank attribute is ascending, so that zero (0) is the highest rank for an item. Additionally, you need to set the rank on your mobile page to be higher than the default because the default view is always selected as well. To illustrate this further, when a request is made to the table for the views for that device, (-11) in this case, the query also includes the default device ID (-1). If a separate view is not defined for the device (-11), then a view will be returned. Therefore, if both ranks are zero(0), then the default view is returned.

Finally, if you are working with your own custom native or hybrid applications, you need to test on the emulators or on the device itself. These require installation, which is more than a browser emulator can do by itself. If you use an emulator, even though it tries to mimic the device, it may not match the rendering of the device itself. Additionally, when accessing a mobile store, you need to first come in via the storeview URL. The servlet filter that is running determines which device you are running and redirects appropriately. If you bypass this URL, then the browser detection does not happen. The storeview URL looks like this:


For more information about the limitations, see the Information Center.

For this article, we used the following products and browsers:

  • IBM® WebSphere Commerce V7.0.0.3 Toolkit with Feature Pack 3
  • IBM Rational® Application Developer V7.5.5.4
  • IBM Rational Application Developer V8.0.3
  • Fiddler2 V2.3.9.3
  • Mozilla® Firefox® 10.0.2
  • Internet Explorer® 9.0.8112.16421
  • UserAgent Switcher V0.7.3
  • Firebug® V1.9.1
  • WebDeveloper Toolbar V1.1.9
  • Android® SDK Tools Revision 16
  • Android 4.0.3
  • Android 3.1
  • Android 2.3.3

Debugging tools

When doing any kind of Web development, there are certain tools that help you to see what is going on in the wire between the browser or device and the application. These tools help you examine the request and response from the Web applications, inspect the HTML and Javascript more closely, and help examine the server side. Let's look at these tools and how you can use them before discussing methods for testing the mobile sites. These tools can help you troubleshoot display and page rendering issues.

Viewing the request and response

First, inspect the request and responses flowing to and from the server. This is helpful to see things like cookies and other header information that are usually only seen by the browser engine when viewing a Web site.

The first of these tools is called Fiddler. This tool is a proxy that sits between the running browser or device and the network stack for your machine. You can use it when you are using emulators or user agent switchers on your workstation to emulate or simulate your mobile browsing experience. With this tool, you can see requests for every resource going to the server and the response, as shown in Figure 1.

Figure 1. Example requests in Fiddler
Example requests in Fiddler

With these requests, you can examine each response via the tool as shown in Figure 2.

Figure 2. Examining the request
Examining the request

In examining them, you can see cookies, headers, referrers, response code, user-agent, and more. You see information that is helpful to debug your application. You can also view the HTML that was sent before Dojo or other JavaScript code altered the HTML on the page.

Another request or response viewer is the "Live HTTP Headers". This is a plugin for the browsers and FireFox. This tool shows a little less, but it can still be helpful. Figure 3 shows an example of the items that you can see. You can still see items such as cookies and responses, but it is just a little harder to read and parse.

Figure 3. Example of Live HTTP Headers
Example of Live HTTP Headers

All this information allows you to see what the application is telling to the browser to do, not just what you are seeing. When you match this up with the tracing from the server, you get a complete picture of what is going on between the browser and the server.

Inspecting the HTML

Now that you can see the requests and responses on the page, there is often a need to inspect parts of the HTML, CSS, and Javascript. It is also helpful to make changes on the fly. These tools are browser-dependent and we will cover Firefox and Internet Explorer because those are the two most popular browsers used by customers.

First off, let's look at what is available for Firefox. We use a combination of two tools, Firebug and WebDeveloper toolbar. With these two add-ons, you can easily manipulate the markup by disabling styles, inspecting styles, and changing them. See Figure 4 on how you can inspect the HTML and CSS for an item.

Figure 4. Example of Firebug
Example of Firebug

This tool lets you see the HTML, the Javascript, and the style applied. You can also review the request and responses here as well.

Looking at some of the tools available in Internet Explorer, you have Firebug lite, which has many of the features you have in Firefox that allows you to use them in other browsers. Then starting with Internet Explorer 8, you have the option of the built-in developer tools. These tools are helpful, but we have found them to be much slower than Firebug, causing whole page refreshes and long parse times.

Server side investigation

Finally, there is the server side tooling, which is mostly tracing. This tracing gives you details on how the server is processing the request and what items are sent to the server. You need to enable the following trace string:

com.ibm.websphere.commerce.WC_SERVER=all: org.apache.struts.*=all

With this trace string, as shown below, you can see the device ID that it is mapping to as well as the specific JSP it is going to load.

Entry Request
[2/21/12 14:04:02:382 EST] 0000007d WC_SERVER     3 
 com.ibm.commerce.webcontroller.RuntimeServletFilter doFilterAction URLINFO -
Method = GET
ServletPath = /servlet
PathTranslated = C:\IBM\WCDE_ENT70\workspace\Stores\WebContent\StoreView
RequestURI = /webapp/wcs/stores/servlet/StoreView

Device ID resolution
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     3 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 storeId = 10051
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     > 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 findForwardConfig(ViewCommandCOntext,String,ServletContext) Entry
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     3 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 findForwardConfig(ViewCommandCOntext,String,ServletContext) context.device= -11
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     3 
 52e3019f:135a13f532e:-7ff6 LRUDynamicHashtable.get Cache misses: 5 
 The missing key: StoreView&10051&-11 hits: 1 evictions: 0
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     3 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 findForwardConfig(ViewCommandCOntext,String,ServletContext) context device=-11 
 defaultDevice= -1

Finally, this section of the tracing shows the engine finding the forward for a specific device.

[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     > 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 findForwardConfigForDevice Entry
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     > 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 findStoreSpecificForwardConfig Entry
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     3 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 findStoreSpecificForwardConfig look for view StoreView/10051/-11
[2/21/12 14:04:02:407 EST] 0000007d WC_SERVER     < 
 52e3019f:135a13f532e:-7ff6 com.ibm.commerce.struts.StrutsActionHelper.
 findStoreSpecificForwardConfig Exit

This tracing determines why you are getting one view, versus the view you expected. It can determine if the device ID is resolving to something besides what you expect, or if the JSPs are mapped incorrectly in your Struts files. If you are not getting what you expect, enable this trace first, then see what device ID it is mapping to, what view it is looking for, and what view it finds.

Switching the user agent string

The first scenario is using a tool to switch the user agent string. The user agent string is what your browsing device actually sends to the server to tell the server about itself. An example of a user agent from Firefox 10 is:

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:10.0) Gecko/20100101 Firefox/10.0

You can tell a good bit about the machine and the user agent from this line. It is Firefox 10, it is on a 64-bit operating system, and it is Windows® 7. To get an add-on that lets you switch the user-agent, see the Firefox add-ons page. You need to apply the add-on, then load the add-on with a list of user agents. If you so choose, you can also type them in by hand. In the following steps, we have loaded the user agents into the add-on, then chose to emulate an Apple® iPad®.

  1. Download the useragent list.
  2. Go to Tools > Default User Agent > User Agent Switcher > Options.
  3. Click the Import button.
  4. Select the file from Step 1.
  5. Click OK.
  6. Go back to Tools > Default UserAgent > Mobile Devices > Devices > Tablets, as shown in Figure 5.
    Figure 5. Changing the user agent
    Changing the user agent
  7. Now choose the correct iPad that you want to test. We chose "iPad 2".

While doing this testing, start Fiddler to capture the traffic. If you refresh the page, you see this as the user string in Fiddler as shown below:

User-Agent: Mozilla/5.0 (iPad; U; CPU OS 4_3 like Mac OS X; en-us) AppleWebKit/533.17.9 
 (KHTML, like Gecko) Version/5.0.2 Mobile/8F190 Safari/6533.18.5

The tracing described above is enabled on the server. Look on the server and see the following in the trace log. You can see the request coming in for the stores here.

[2/10/12 14:32:40:176 EST] 00000072 WC_SERVER     3 
 com.ibm.commerce.webcontroller.RuntimeServletFilter doFilterAction
 (HttpServletRequest,HttpServletResponse,FilterChain,Integer) URLINFO -
Method = GET
ServletPath = /servlet

Then under that string, you see:

HeaderNames: User-Agent
	Header = Mozilla/5.0 (iPad; U; CPU OS 4_3 like Mac OS X; en-us) 
    AppleWebKit/533.17.9 (KHTML, like Gecko) Version/5.0.2 Mobile/8F190 Safari/6533.18.5

You can see in this base store that it has mapped the user agent to the mobile devices by looking at the following trace string:

[2/10/12 14:32:41:346 EST] 00000072 WC_SERVER     3 
 -7f9224f7:13568b8e136:-7ffc com.ibm.commerce.struts.StrutsActionHelper.
 findForwardConfig(ViewCommandCOntext,String,ServletContext) device!=servletContext.
 defaultDevice, set viewDevice=-11

This ID matches what is in the wc-devices.xml file. Next, it tries to find the view for that device.

2/10/12 14:32:41:347 EST] 00000072 WC_SERVER     3 -7f9224f7:13568b8e136:-7ffc 
 String,ServletContext) call findForwardConfig with: baseName,storeId,device,
[2/10/12 14:32:41:347 EST] 00000072 WC_SERVER     3 -7f9224f7:13568b8e136:-7ffc 
 Integer,Integer,Integer) storeId= 10101

It then looks for a view in the Struts config, such as TopCategoriesDisplayView/10101/-11. If one is not defined for the device, it looks for a specific mapping for the store. If there is no mapping for the store, it looks for the general view mapping. Looking for these traces will help you to see what is being looked up, what is being found, and the view that was found. You can then troubleshoot if the wrong device was mapped, or if the wrong JSPs were loaded.

Device emulation with Rational Application Developer V8.0.3

In Rational Developer V8.0.3 and later, you can use the mobile browser simulator. This requires you to have two installations of Rational Application Developer, given the current requirements for WebSphere Commerce if you are testing it against your local Developer install. This simulator is designed to test items running on the sample server included with that version of the Developer. However, it allows you to easily point to other hosts and test with them as well so you can run this against other systems.

This simulator is a powerful tool for debugging mobile applications. One of the features is allowing you to rotate the device, so that you can see how it works when flipped, and to change devices on the fly without having to open another browser or another device emulator (see Figure 6).

Figure 6. Mobile Browser Simulator
Mobile Browser Simulator

Setting up your Rational Application Developer environment

  1. To set this up, first install Rational Application Developer V8.0.3 or later. Then create a generic Web project to use to launch the tool. Create a static Web project similar to the one shown in Figure 7.
    Figure 7. Creating a new project
    Creating a new project
  2. Once the static Web project is created, create a simple HTML file to use as your test bed. Right-click on WebContent > New > WebPage, as shown in Figure 8.
    Figure 8. Creating a new HTML file
    Creating a new HTML file
  3. Now insert the generic "Hello World" in to the HTML as shown in Figure 9 to verify it is loading the right file and working correctly.
    Figure 9. HTML with text
    HTML with text
  4. With the scratch project created, now change the Web browser that Rational Application Developer uses to launch the application because it is better to use the external browser for this than the default internal one. To change that, go to Window > Web Browser > FireFox as shown in Figure 10.
    Figure 10. Changing the browser to display
    Changing the browser to display

Running the simulator

  1. Once you have done this, right-click on the sample HTML file you created above and choose Run As > Run On Mobile Browser Simulator as shown in Figure 11. We have the Mobile Browser Simulator set up for the AJAX test server that comes with Rational Developer Developer V8.0 to keep things lightweight.
    Figure 11. Running the dummy file in the simulator
    Running the dummy file in the simulator
  2. This then opens a browser as shown in Figure 12.
    Figure 12. Sample file in the simulator
    Sample file in the simulator
  3. After verifying that all is working, change the Web page URL to the URL of your WebSphere Commerce store. Ensure that you are pointing to the storeview URL as discussed previously. You receive a message that items are limited since it is not running on the same server as the store, and it is safe to ignore that for our purposes.
  4. Now that you are pointing to your store, change the device by clicking on the blue icon to the left of the browser simulator. This lets you choose other devices like "Apple iPad2" shown in Figure 13.
    Figure 13. Switching devices in the simulator
    Switching devices in the simulator
  5. One of the nice features of using an external browser is that you can use the previously discussed tools in the browser to help review the mark up returned and using Fiddler to inspect the request and response sent from the browser. This is helpful for content that is changed dynamically. We use Firebug to inspect an element inside the mobile browser as shown in Figure 14.
    Figure 14. Using add-ons within the simulator
    Using add-ons within the simulator

Device emulators

Next, let's look at using a device emulator to test the store. This provides a lighterweight testing environment compared to using Rational Application Developer V8.0.3. Additionally, this provides an environment to test native and hybrid applications instead of just using the mobile browser. The device emulators we will explore are the Android device emulators that come with the Android SDK. There is also an emulator for iOS devices, but those require more specific environments than we are able to test with here.

Installation and setup

Follow these steps to download and setup the Android SDK:

  1. Download the SDK.
  2. Unpack or install the SDK starter packager.

    In this example, we are using the installer_r16-windows.exe file and installing the SDK. While installing, we took the defaults.

  3. Next, decide what to download with the Android SDK Manager. We chose the following:
    1. Android SDK Platform-tools
    2. 4.0.3 Android package
    3. 3.1 Android package
    4. 2.3.3 Android package (This is what we have on our personal phone.)
    5. USB driver package
    6. WebDriver Package
  4. When it is done, close the Manager.
  5. Download and install the ADT plugin for the Rational Application Developer 8.0.3 environment:
    1. Select Help > Install New Software.
    2. Click Add in the top right corner.
    3. Give it a name, and use this as the address: https://dl-ssl.google.com/android/eclipse/.
    4. Click OK.

      Note: It may take a few seconds for this to resolve and get the tools back.

    5. Click the check box beside "Developer Tools".
    6. Click Next.
    7. Click Next when it displays "Install Details".
    8. Accept the License Terms.
    9. Click Finish.

      Note: You may receive a message that you are installing unsigned content. Click OK to continue.

    10. Wait for it to install and when done and restart Eclipse.
    11. When it restarts, it asks you to install an SDK, but you already did that in Steps 2 and 3. Instead, select the already installed SDK, and point it to where you unpacked or uninstalled the SDK before.

Using the device emulator

Before you can start using the emulator, you have to create a profile or an AVD so that you can set up the emulator with the various settings. Follow these next steps to do that:

  1. Open the Android Virtual Device Manager.
  2. Click on New. Fill out your information as shown in the AVD creation screen in Figure 15.
    Figure 15. AVD creation screen
    AVD creation screenNote: Our computer became unresponsive during this time and took a while to finish this.
  3. Now that you have your AVD created, select it, and then click Start. It then gives you a few options to change, then click Launch. This brings up a device with a phone and a browser. Next click on the browser icon(Globe). This opens a browser that you can enter your site's URL to test against, as shown in Figure 16.
    Figure 16. Testing your mobile store
    Testing your mobile store


This article explored the different tools that you can use to unit test a custom store. These tools are helpful to reproduce problems seen on production without the need for adding expensive hardware for all the developers. Additionally, you can use all of these tools together to ensure everything is working as designed. Often times, you use the emulator to enable tracing on the server and to debug the problem yourself.

The biggest challenge with many of these tools is replicating the Javascript engine that they all use. They have a different engine than what is in the emulating browser. These tools usually rely on the browser they are running in to power the Javascript engine, so things may not always behave as expected. Remember to keep this in mind when working with emulators and trying to test all use cases. A smoke test with a specific device may be needed before final release, but these tools will help you through unit testing.





developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into WebSphere on developerWorks

ArticleTitle=Testing mobile stores for WebSphere Commerce