Enabling interim fix JR53113
If your site uses catalog filters created using
Data Load, and you have migrated from Feature Pack 1 to 6, to Feature
Pack 8; then set up and configure the search index.
Before you begin
- Install the interim fix for APAR JR53113.
For information about
how to install an interim fix, see
About this task
Starting in Feature Pack 7, browsing and searching as non-transactional requests were offloaded to the dedicated search server. As a result, the WebSphere Commerce server acts as a transaction server, and the search server acts as a non-transactional server that can be separately deployed and scaled. Entitlement was moved to the search server to apply entitlement checks before and after search results are returned in the storefront.
The EXPRESSSION table was created to separate entitlement.
It has the following characteristics and behavior:
- When catalog filters are created or imported using data-loaded, or assigned to a contract on the WebSphere Commerce server, the catalog filter service is called to precompile the Solr-based filter query expression into the table. The EXPRESSION table is cached in the search server runtime, with the key of the associated contract. As a result, the cached expression can be reused on the search server, instead of calculating filter query expressions by calling the catalog filter service. When an entitled contract is validated on the search server, the associated expression is retrieved from search server cache.
- The EXPRESSION table is regenerated when the final filter query expression changes. For example, when a catalog filter or the relationship to a contract changes. The data cache on the search server is invalidated to refresh the changes.
- The EXPRESSION table supports member group-level entitlement, to apply different entitlement levels to different member groups that qualify for the same contract.
- The EXPRESSION table supports staging, so that after you create a catalog filter in the staging environment and propagate to the production environment, the table will also be propagated to the production environment.
The following steps add a scheduled job that calls the catalog filter service, calculates the filter query expressions, and records them into the EXPRESSION table. The expression record is then used by the search server for entitlement.
Procedure
- Complete one of the following tasks:
Log on as a WebSphere Commerce non-root
user.
Log on with a user profile that has *SECOFR
authority.
Log on with a user ID that is a member of the
Windows Administration group.
- Go to the following directory:
- WC_installdir\components\foundation\subcomponents\search\bin
WCDE_installdir\components\foundation\subcomponents\search\bin
- Run the search index setup utility, additionally specifying
the configWCScheduleforCatalogFilter action:
- setupSearchIndex.bat -action configWCScheduleforCatalogFilter
[util-specific-params]
- setupSearchIndex.bat -action configWCScheduleforCatalogFilter
[util-specific-params]
- ./setupSearchIndex.sh
-action configWCScheduleforCatalogFilter [util-specific-params]
Where:- action
- Prepares the search index for certain scenarios. In this task, configWCScheduleforCatalogFilter is used to ensure that the EXPRESSION table is used for entitlement.
- util-specific-params
- For more information about utility-specific parameters and actions that are not related to the managed configuration, see setupSearchIndex utility.