Store relationships for cached store pages
If your store is using data defined in another store through a store relationship, 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 WAS 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_busN DC_bus_RS_N IBM commerce business campaigns -3 DC_campN DC_camp_RS_N IBM commerce business catalog -4 DC_catN DC_cat_RS_N IBM commerce business command -5 DC_cmdN DC_cmd_RS_N IBM commerce hosted store -6 DC_hostN DC_host_RS_N IBM commerce price -7 DC_prcN DC_prc_RS_N IBM commerce referral -8 DC_refN DC_ref_RS_N IBM commerce segmentation -9 DC_segN DC_seg_RS_N IBM commerce URL -10 DC_urlN DC_url_RS_N IBM commerce view -11 DC_viewN DC_view_RS_N IBM commerce inventory -13 DC_invN DC_inv_RS_N IBM commerce base item -14 DC_baseItemN DC_baseItem_RS_N IBM commerce channel store -15 DC_chsN DC_chs_RS_N IBM commerce currency conversion -17 DC_currConvN DC_currConv_RS_N IBM commerce currency format -18 DC_currFmtN DC_currFmt_RS_N IBM commerce supported currency -19 DC_supCurrN DC_supCurr_RS_N IBM commerce counter value currency -20 DC_cterCurrN DC_cterCurr_RS_N IBM commerce measurement format -21 DC_meaFmtN DC_meaFmt_RS_X IBM commerce contract -22 DC_contractN DC_contract_RS_N
Note: A new feature in WebSphere Commerce 6.0 is the support of
arrays. As a result, the request attributes above will be returned in an
array.
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_bus0=10051 DC_bus1=10002 DC_bus2=10004 | DC_bus_RS_0=10051 | DC_bus0=10002 |
| -2 (tax) | DC_tax0=10051 DC_tax1=10004 | DC_tax_RS_0=10051 | |
| -4 (catalog) | DC_cat0=10051 DC_cat1=10002 | DC_cat_RS_0=10051 | DC_cat0=10002 |
| -6 (hosted store) | DC_host0=10051 | DC_host_RS_0=10001 | DC_host0=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 type="attribute">
<required>true</required>
</component>
</dependency-id>
<dependency-id>storeId:catalogId
<component type="attribute">
<required>true</required>
</component>
<component type="attribute">
<required>true</required>
</component>
</dependency-id>
<dependency-id>StoreCatalogDisplay:storeId
<component type="attribute">
<required>true</required>
</component>
</dependency-id>
<!-- Ends Store Relationship Dependency Ids -->
The extra dependency IDs created are as follows:
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.
Related concepts