Implementing mobile WebSphere Commerce

	Page 5 of 11

Document options

		PDF - Fits A4 and Letter 1259 KB (49 pages)
		Get Adobe® Reader®
		Sample code

My developerWorks needs you!

Connect to your technical community

Rate this tutorial

Help us improve this content

Caching the configuration for mobile WebSphere Commerce

You now have view implementations specific to a mobile device browser and a standard browser. In this section, you will explore the caching considerations involved with these new implementations. First, you will explore the behavior of using a standard way of caching the TopCategoriesDisplay, highlighting the problems encountered. Then you will see how to cache based on the device from the command context.

Cache the TopCategoriesDisplay

First, you will add a cache-entry for the TopCategoriesDisplay using the common approach of servlet caching, along with typical components as part of the cache-id. At the end of this section, you will see that this introduces a problem when using the same Struts action-mapping (for example, TopCategoriesDisplay) for multiple global-forwards, which is differentiated based on device format.

From the J2EE perspective of Rational Application Developer, expand Stores > WebContent > WEB-INF.
Double-click cachespec.xml to open it for editing.

Between the <cache> and </cache> tags, insert the following cache-entry into the cachespec.xml:

	<cache-entry>
		<class>servlet</class>
		<name>com.ibm.commerce.struts.ECActionServlet.class</name>
		<property name="consume-subfragments">true</property>
		<property name="save-attributes">
			false
			<exclude>jspStoreDir</exclude>
		</property>
		<!-- TopCategoriesDisplay?langId=-1&storeId=10001&catalogId=10001 -->
		<cache-id>
			<component id="" type="pathinfo">
				<required>true</required>
				<value>/TopCategoriesDisplay</value>
			</component>
			<component id="storeId" type="parameter">
				<required>true</required>
			</component>
			<component id="catalogId" type="parameter">
				<required>true</required>
			</component>
			<component id="langId" type="parameter">
				<required>true</required>
			</component>
		</cache-id>
	</cache-entry>

Note that an updated cachespec.xml is also available under MobileCommerceCode\Part5\5.2\cachespec.xml for you to compare the modifications.
Save the changes, but leave the cachespec.xml open for further changes.

Back to top

Test the cached TopCategoriesDisplay in both browsers

Now that you are caching the TopCategoriesDisplay, you will access this page in a standard browser first and then open it in the mobile device simulator.

Open a standard Web browser and enter the following URL in the Address field:
http://localhost/webapp/wcs/stores/servlet/ConsumerDirect/index.jsp
The ConsumerDirect language selection page appears. Click United States English.
The TopCategoriesDisplay appears.
In a separate browser, access the Dynamic Cache Monitor via the following URL:
http://localhost/cachemonitor
In the Cache Monitor, click Cache Contents in the left navigation menu.
Search for "Template" in /webapp/wcs/stores/com.ibm.commerce.struts.ECActionServlet.class.
Scroll to the right and observe the stored cache ID, which looks similar to the following:
/webapp/wcs/stores/com.ibm.commerce.struts.ECActionServlet.class: pathinfo=/TopCategoriesDisplay:storeId=10001:catalogId=10001: langId=-1:UTF-8:requestType=GET
Notice this corresponds to the cache-id and cache-entry you just placed in cachespec.xml.
Open the mobile device simulator by clicking the "Apple Safari" icon in the Quick Launch menu.
In the simulator, enter the following URL in the Address field:
http://localhost/webapp/wcs/stores/servlet/ConsumerDirect/index.jsp
The ConsumerDirect language selection page appears. Click United States English.
The TopCategoriesDisplay appears.
Notice that the view displayed does not look like the mobile implementation any more, but looks like the standard browser implementation.
To understand why, again refer back to the browser that has the Dynamic Cache Monitor open.
In the Cache Monitor, click Cache Contents in the left navigation menu.
Search for "Template" in /webapp/wcs/stores/com.ibm.commerce.struts.ECActionServlet.class.

Scroll to the right and observe the stored Cache ID, which looks similar to the following:

/webapp/wcs/stores/com.ibm.commerce.struts.ECActionServlet.class:
 pathinfo=/TopCategoriesDisplay:storeId=10001:catalogId=10001:
 langId=-1:UTF-8:requestType=GET

This is the same entry as before. It was retrieved as a cache-hit during the second request, which came from the mobile device simulator after caching on the first request from the standard browser.

You then see a problem where the second device displays the view in the same format as the first device. The reason is that you are using the same action-mapping (TopCategoriesDisplay, in this case) for two different JSPs referenced by the global-forwards. Remember, you defined one global-forward for each device type.

Back to top

Cache the entry based on DeviceFormatId

Based on this, a new cache-id component is introduced to differentiate cached pages based on the device format, if you are using the same action-mapping.

From the J2EE perspective of Rational Application Developer, expand Stores > WebContent > WEB-INF.
Double-click cachespec.xml to open it for editing, if not already open.

Locate this section:

		<component id="langId" type="parameter">
			<required>true</required>
		</component>
	</cache-id>

In between the </component> and </cache-id> tags, insert the following new component for this cache-id. You can also find this snippet in MobileCommerceCode\Part5\5.4\snippet.xml:
 <component id="CommandContext" type="attribute"> <required>true</required> <method> getDeviceFormatId </method> </component>
Note that you are retrieving the DeviceFormatId from the CommandContext object and adding this as a required component for the cache-id. This ensures that you are caching based on the specific device format to avoid the issue that was demonstrated in the previous section.
For reference, an updated version of the cachespec.xml is in MobileCommerceCode\Part5\5.3\cachespec.xml.
Save the changes and close the cachespec.xml.

Back to top

Test the device-specific caching of TopCategoriesDisplay

Now that you have an updated caching policy to cache the TopCategoriesDisplay per the device format, you will repeat the test to see if you get two separate cache entries in the Dynamic Cache Monitor and to see the different device format IDs as part of the cache-id for each.

From the Dynamic Cache Monitor, clear the cache by clicking Cache Contents, then the Clear Cache button.
Repeat section Test the cached TopCategoriesDisplay in both browsers to test the cached TopCategoriesDisplay in the standard browser and the mobile device simulator.

Note that the views are displayed as expected, rather than getting the same display for both devices. In the Cache Contents of the Cache Monitor this time, observe that there are two different cache IDs for the template /webapp/wcs/stores/com.ibm.commerce.struts.ECActionServlet.class.

The two Cache IDs look similar to the following:

/webapp/wcs/stores/com.ibm.commerce.struts.ECActionServlet.class:
 pathinfo=/TopCategoriesDisplay:storeId=10001:catalogId=10001:
 langId=-1:CommandContext:-1:UTF-8:requestType=GET
/webapp/wcs/stores/com.ibm.commerce.struts.ECActionServlet.class:            
 pathinfo=/TopCategoriesDisplay:storeId=10001:catalogId=10001:
 langId=-1:CommandContext:-2:UTF-8:requestType=GET

Notice the CommandContext component within each cache ID. This reflects the caching specific to the getDeviceFormatId value from the CommandContext you added, referencing the standard device (CommandContext:-1) and mobile device (CommandContext:-2).

Back to top

	Page 5 of 11