WebSphere Commerce Enterprise

Store relationships for cached store pages

If your store is using data defined in another store through a store relationship, you must use the request attributes specified by the cache filter to define the relationships. The cache filter is a servlet filter that defines request attributes from the session and store relationship information that can be used by the WebSphere Application Server dynamic cache. The dynamic cache then uses this information to construct cache IDs and dependency IDs to be used for cache invalidation.

The cache filter creates the store relationships information by calling the getStorePath() and getStoresForRelatedStore() methods from the StoreAccessBean. The corresponding information is listed in the following table:

Store Relationship Type Store Relationship Identifier Request Attributes Name for getStorePath() Request Attributes Name for getStoresForRelatedStore()
IBM commerce businessPolicy -1 DC_bus_SP_N DC_bus_RS_N
IBM commerce business campaigns -3 DC_camp_SP_N DC_camp_RS_N
IBM commerce business catalog -4 DC_cat_SP_N DC_cat_RS_N
IBM commerce business command -5 DC_cmd_SP_N DC_cmd_RS_N
IBM commerce hosted store -6 DC_host_SP_N DC_host_RS_N
IBM commerce price -7 DC_prc_SP_N DC_prc_RS_N
IBM commerce referral -8 DC_ref_SP_N DC_ref_RS_N
IBM commerce segmentation -9 DC_seg_SP_N DC_seg_RS_N
IBM commerce URL -10 DC_url_SP_N DC_url_RS_N
IBM commerce view -11 DC_view_SP_N DC_view_RS_N
IBM commerce inventory -13 DC_inv_SP_N DC_inv_RS_N
IBM commerce base item -14 DC_baseItem_SP_N DC_baseItem_RS_N
IBM commerce channel store -15 DC_chs_SP_N DC_chs_RS_N
IBM commerce currency conversion -17 DC_currConv_SP_N DC_currConv_RS_N
IBM commerce currency format -18 DC_currFmt_SP_N DC_currFmt_RS_N
IBM commerce supported currency -19 DC_supCurr_SP_N DC_supCurr_RS_N
IBM commerce counter value currency -20 DC_cterCurr_SP_N DC_cterCurr_RS_N
IBM commerce measurement format -21 DC_meaFmt_SP_N DC_meaFmt_RS_X
IBM commerce contract -22 DC_contract_SP_N DC_contract_RS_N

Store relationship caching example

To understand how caching pages that use a store relationship works, consider the following example.

Publishing the sample composite store archive DemandChain.sar and then creating a store (for example, ResellerOne) in that site creates the following stores.

Store ID Directory Store Type
10001 CommercePlaza channel hub
10002 CommercePlazaCatalog catalog asset store
10003 CommercePlaza distributor proxy
10004 ConsumerDirectResellerProfile storefront asset store
10051 ResellerOne reseller store

ResellerOne (10051), the reseller store, uses the assets defined in the storefront asset store (10004) and the catalog asset store (1002).

In order to set up the caching relationship, the cache filter gets the following information:

Store ID Relationship Type getStorePath() getStoresForRelatedStore()
10001
  • -1 (business policy)
  • -4 (catalog)
  • -7 (price)
  • -17 (currency format)
  • -19 (currency supported)
 10002 not applicable
10001
  • -6 (hosted store)
 10051 not applicable
10051
  • -1 (business policy)
  • -14 (base item)
 10051, 10002, 10004 10051
10051
  • -3 (campaigns)
  • -5 (command)
  • -10 (URL)
  • -11 (view)
 10051, 10004 10051
10051
  • -4 (catalog)
  • -7 (price)
  • -17 (currency conversion)
  • -18 (currency format)
  • -19 (currency supported)
  • -20 (counter value currency)
  • -21 (measurement format)
 10051, 10002 10051

Then the cache filter sets up the following request attributes:

Store Relationship Store ID 10051 store ID 10051 store ID 10001
-1 (business policy) DC_bus_SP_0=10051 DC_bus_SP_1=10002 DC_bus_SP_2=10004 DC_bus_RS_0=10051 DC_bus_SP_0=10002
-2 (tax) DC_tax_SP_0=10051 DC_tax_SP_1=10004 DC_tax_RS_0=10051
-4 (catalog) DC_cat_SP_0=10051 DC_cat_SP_1=10002 DC_cat_RS_0=10051 DC_cat_SP_0=10002
-6 (hosted store) DC_host_SP_0=10051 DC_host_RS_0=10001 DC_host_SP_0=10051

Whenever the catalog of the catalog asset store (10002) is changed, the catalog pages of the ResellerOne store (10051) must also be invalidated before it can use the information from the catalog asset store (10002). In order for the pages in 10051 to be invalidated, extra dependency IDs must be set up for this store relationship. Setting up the extra dependency IDs for StoreCatalogDisplay is illustrated in the following example:

<!-- Start Store Relationship Dependency Ids -->
<!-- DC_cat1 is the catalog Profile Store ID -->
<dependency-id>storeId
        <component id="DC_cat_SP_" type="attribute">
                <required>true</required>
                <index>1</index>
        </component>
</dependency-id>

<dependency-id>storeId:catalogId
        <component id="DC_cat_SP_" type="attribute">
                <required>true</required>
                <index>1</index>
        </component>
        <component id="catalogId" type="attribute">
                <required>true</required>
        </component>
</dependency-id>

<dependency-id>StoreCatalogDisplay:storeId
        <component id="DC_cat_SP_" type="attribute">
                <required>true</required>
                <index>1</index>
        </component>
</dependency-id>
<!-- Ends Store Relationship Dependency Ids -->

The extra dependency IDs created are as follows:

  • storeId:10002
  • storeId:catalogId:10002:10051
  • StoreCatalogDisplay:storeId:10002

Once these extra dependency IDs are defined, where there are changes to the catalog asset store 10002 that cause the catalog asset store pages to be invalidated, the hosted store (10051) pages will also be invalidated.