WCS Extended Site Model Concepts

Extended Site architecture diagram & solution outline

In WCS Extended site model Multiple stores can exist in a single Stores Web module. If so, the store assets are separated using the following methods:

Storefront Assets

Storefront assets for each store in the Stores Web module are stored in a separate store directory (storedir). For example, all storefront assets for Mystore1.com (for QC 57) are in the Mystore1 directory & all shared storefront assets are in SharedStorefrontAssetStore directory.

Storefront asset includes jsp, html, css, javascript, images & properties files.

Business logic

The store ID is used to select the command implementation for each store, as specified in the command registry.

Struts Mapping

The configurations for actions and forwards for the Extended-Sites model work the same general way as the ConsumerDirect (B2C) or AdvancedB2BDirect (B2B) models, with one important difference.
For the B2C and B2B direct models, actions and forwards will be looked up for the STORE_ID matching the parameter of the Web request. If no entry exists, it defaults to the default "STORE_ID = 0" and performs another lookup.
In the case of Extended-Sites, you also need to consider the StorePath, which is defined by the relationships between the extended site customer facing stores and the asset stores. These are defined in STOREREL. The relevant relationships for Struts are:

 NAME                                     STRELTYP_ID        

com.ibm.commerce.URL            -10         

com.ibm.commerce.view           -11        

The lookups for actions and forwards first check the Extended-site STORE_ID (as passed in from the Web request). If no entry exists it then looks up based on the related STORE_ID's from STOREREL (for example, asset stores), and then reverts to the default STORE_ID = 0, performing another lookup.
Examples of mapping: Same view name but different storeId
Struts forward mapping to display Mystore1.com specific view (e.g. storIed: 10002)
<forward className="com.ibm.commerce.struts.ECActionForward" name="MyStore1CategoryOnlyResultsDisplayView/10002" path="/Snippets/Catalog/CategoryDisplay/MyStore1CategoryOnlyResultsDisplay.jsp"/>
Struts forward mapping to display shared view ,right now it is shared between mystore1.com & mystore2.com (e.g. shared storIed: 10101, STORETYPE is BMP – Hosted B2B storefront asset store)
<forward className="com.ibm.commerce.struts.ECActionForward" name="MyStore1CategoryOnlyResultsDisplayView/10101" path="/Snippets/Catalog/CategoryDisplay/MyStore1CategoryOnlyResultsDisplay.jsp"/>

Commerce Database tables

Commerce Database tables database tables that are used to define the store path & relationship type are:

STRELTYP

The store relationship type defines all the assets that can be shared.

STOREREL

Defines a relationship between an asset store and an Extended Site store in extended site model

STORE

Stores the directory path for hosted as well as storefront asset store

Commonly used JSTL variables in Elite starter store pages

Infocenter Ref:      http://publib.boulder.ibm.com/infocenter/wchelp/v7r0m0/topic/com.ibm.commerce.elite-starterstore.doc/refs/rsmelitejstlvars.htm

Store directory variables

jspStoreDir

Web Asset directory of the shared file directory. This directory can contain common Web file formats such as JSP files, HTML, and images.

storeDir

Web Asset directory of the hosted store. This directory can contain common Web file formats such as JSP files, HTML, and images.

Utility Class

There is a simple utility class we can use to pull all the related store identifiers for a given store relationship type and store identifier, use com.ibm.commerce.common.helpers.StoreUtil.getStorePath(storeId,storePathType ). An array of store identifier values is returned. The index of the array is congruent with the sequence value from the STOREREL table. The way we use that data is up to us, either use all values to find corresponding assets by the foreign key store identifier, or use a specific index from the array based on some conditional rule.

Customized Extended site model where we don’t need separate struts view mapping for each store separated by /storied

Business Requirement:

As a developer we don’t want to create separate entry in struts-config file for each store in case we have different view implementation for different stores. We can still have the same view name & same storeId which is related store storeId(e.g. 10101 )  in the struts config file for all hosted sites in an extended site model of WCS.

Solution:

To implement this functionality we need to extend the OOB BaseAction class & override the execute() method & below is the solution outline & request processing flow of commerce:

 

(1) Extended MyBaseAction class execute() method will first call the OOB BaseAction class execute method which will do all the processing & will return a ActionForward. At this point all the processing has been done by the OOB BaseAction.

(2) Check for the LOOK_UP_AT_HOSTED_STORE property value from store specific WHRConfig.properties file inside the MyBaseAction execute() method. If it is true then execute the logic written in step # 3 otherwise ignore it & return the ActionForward from step #1 to RequestProcessor.

(3) Inside MyBaseAction execute() method we have ActionForward object from step #1 i.e. super class & from this object we will get the relative path of the resource (jsp) which will be returned to the struts RequestProcessor & in turn it will be returned to the browser for display.

In this step we will use the store path concept of the extended site model & will retrieve all the store paths i.e. related stores directory stored in the STOREREL database table.

Now we will check for requested resource in the related stores directory in the sequence maintained in the STOREREL database table in a for loop.Once it finds the requested resource in a store directory then set this path in the ActionForward object which we got from BaseAction & it break the for loop & return the updated ActionForward to the RequestProcessor & remaining things will be taken care by the OOB Request Processor & ECActionServlet classes as usual.

(4) Use this extended MyBaseAction in place of OOB BaseAction in the struts-config file action mapping section for the views shared between more than hosted sites.

In short, if we have same jsp in the store specific directory then it will be displayed to the user & if it is not there in the store specific directory then it will be displayed from the shared/related store directory.

We will get following advantage if we will go with this approach:

1. We can have views name same for all the stores so small size of struts config file, easy to maintain.

2. Since views name are same so need to create separate access control policies

3. No need to change the existing jspf paths in the already existing jsp(s) since those will work as usual unless those are not overridden in the specific store directory.

4. No changes required in the SEO URL since views name are still same.

5. In future it will help us to make changes/add new features in different sites without impacting other existing sites very easily.