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.