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.
