wc.search.priceMode |
This property determines the display mode for showing prices in the
storefront.You can set the following values for this property:
- 0
- Computed:
- Summary: Prices only for the current page are calculated at runtime.
- Hide price facets.
- Show computed price and offer price ranges in the product display page.
- Show computed price in each search result.
- Show computed price and price ranges on the category display page.
- Hide price range search in the Advanced Search page.
- Usage: Prices are not populated in the search index.
- 1
- Indexed:
- Summary: All prices are retrieved from the search index.
- Show price facets with price ranges configured in the facet configuration table.
- Show indexed price in product display page.
- Show indexed price in each search result.
- Show price range search in the Advanced Search page.
- Usage: Prices are populated in the search index.
- 2
- Mixed:
- Summary: Search results contain computed prices, while price facets use indexed prices.
- Show price facets with price ranges configured in the facet configuration table.
- Show computed price and offer price ranges in the product display page.
- Show computed price in each search result.
- Show computed price and price ranges on the category display page.
- Show price range search in the Advanced Search page.
- Usage: Prices for all supported currencies are populated in the search index.
Note:
 If you are using price mode as
1:When the indexed price mode is set
(wc.search.priceMode=1 in the STORECONF table), all the catalog
search and browsing pages, including the product display page use the indexed price. If the contract
price is indexed, these pages use the indexed contract price. However, all the checkout pages,
including the shopping cart pages, use the price commands to calculate real time pricing. - If you are changing the price mode to 0 or 2:
- Update your extended wc-search.xml file to include the following changes to
enable the calculated prices features. The first configuration changes the category search
profile.
<_config:profile name="IBM_findProductsByCategory" indexName="CatalogEntry">
<_config:query inherits="true">
<_config:postprocessor classname="com.ibm.commerce.foundation.server.services.rest.search.postprocessor.solr.SolrRESTSearchCatalogEntryViewSKUQueryPostprocessor"/>
<_config:postprocessor classname="com.ibm.commerce.foundation.server.services.rest.search.postprocessor.solr.SolrRESTSearchCatalogEntryViewComponentsQueryPostprocessor"/>
</_config:query>
<_config:result inherits="true">
<_config:field name="components"/>
</_config:result>
</_config:profile>
In
order for correct price ranges to appear in the results, also change the search result profile,
using the same
code.<_config:profile name="IBM_findProductsBySearchTerm" indexName="CatalogEntry">
<_config:query inherits="true">
<_config:postprocessor classname="com.ibm.commerce.foundation.server.services.rest.search.postprocessor.solr.SolrRESTSearchCatalogEntryViewSKUQueryPostprocessor"/>
<_config:postprocessor classname="com.ibm.commerce.foundation.server.services.rest.search.postprocessor.solr.SolrRESTSearchCatalogEntryViewComponentsQueryPostprocessor"/>
</_config:query>
<_config:result inherits="true">
<_config:field name="components"/>
</_config:result>
</_config:profile>
These
postprocessors are disabled by default for performance considerations. The following describes why
they are needed for calculated price modes: The
SolrRESTSearchCatalogEntryViewSKUQueryPostprocessor is required so that SKUs are
retrieved from Solr in the same request as products in search results. For
example, when viewing search results in grid mode, this enables price ranges to be displayed for all
SKus and contracts. When viewing search results in list mode, this enables products with a single
SKU the ability to be added to the shopping cart. The
SolrRESTSearchCatalogEntryViewComponentsQueryPostprocessor is required so that
components of a dynamic kit are retrieved from Solr in the same request as dynamic kits in search
results. For example, when viewing search results for components, the price is displayed. With
the postprocessor disabled, the price will be pending.
- Deploy the changes to the search
server.
- Restart the WebSphere Commerce search server.
 If you are changing the price mode to 2:Set up a
dedicated threadpool to manage communications between the WebSphere Commerce server and
the Search server. Without a dedicated threadpool, browser sessions may hang due to communications
deadlocks between the servers.
Important: When the price mode is set to 0 or 2, REST calls to the storefront
will not automatically return price information. Even if set as the default, price modes 0 or 2 must
also be declared in the REST call in order to retrieve price information. Use the GET query
parameter priceMode={priceMode} in RESt calls, where {priceMode}
is {0} or {2}, when using these modes. The default value is 1
(Indexed). |
wc.search.priceMode.compatiblePriceIndex |
This property determines the indexed price mode
when prices are indexed.You can set the following values for this
property:
- 1.0
- The price column is indexed from the contract price using the
following naming convention:
price_#currency_#contractId.
- 1.1
- The price column is indexed from the standard offer price using
the following naming convention:
price_#currency.
Note: Only the store-level setting applies for the compatiblePriceIndex property
when the store prioritizes price mode settings. |
wc.search.entitlement |
This property determines the entitlement check
for the B2B and B2C business models.You can set the following values
for this property:
- 0
- Entitlement is disabled.
- 1
- Entitlement is enabled.
The default value is 0 (Entitlement
is disabled). Note: To enable your store to use catalog filters
that are created with the Catalog Filter and Pricing tool, the value
for the wc.search.entitlement property must be set
to 1. |