(Enterprise)

Store relationships for cached store pages

If the store is using data defined in another store through a store relationship, we 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.