Introduced in Feature Pack 2

WebSphere Commerce search configuration file (wc-search.xml) (WC EAR)

The WebSphere Commerce search configuration file (wc-search.xml) contains properties that are related to configuring WebSphere Commerce search features. You can change the properties to suit your site's needs by creating a custom wc-search.xml file that contains the changed properties only.
The WebSphere Commerce search configuration file is stored in the following location:
  • WC_eardir/xml/config/com.ibm.commerce.catalog-fep/wc-search.xml

    The default WebSphere Commerce search configuration file.

  • WC_eardir/xml/config/com.ibm.commerce.catalog-ext/wc-search.xml

    The extended WebSphere Commerce search configuration file. This customized version of the file contains only the changed properties.

It consists of sections that can be classified into the following categories:
Server
This section defines how to connect to the search server:
AdvancedConfiguration
This setting uses the Apache Commons HTTP Client to connect to a remote search server.
The following is a list of configurable settings:
URL
The HTTP URL location of the remote Solr server context root.
soTimeout
The HTTP client default socket timeout in milliseconds for waiting for data. The default value is 0, which is interpreted as an infinite timeout.
connectionTimeout
The HTTP client connection timeout is the number of milliseconds to wait until a connection is established. The default value is 0, which means a timeout is not used.
defaultMaxConnectionsPerHost
The default maximum number of connections that are allowed per host. The default value is 32.
maxTotalConnections
The maximum number of overall connections allowed.
maxRetries
The maximum number of times to reconnect.
retryTimeInterval
The amount of time in milliseconds to wait between each connection retry.
followRedirects
Indicates whether HTTP redirects are automatically followed.
allowCompression
When enabled, the HTTP client is able to make better use of available bandwidth and provide faster transmission speeds between both servers.
Note: Avoid using values that are too long for the two timeout values, as it causes the storefront page to hang for a prolonged period in an event where the search server is not available. The search run time retries for the maxRetries number of times and there are retryTimeInterval milliseconds before each retry attempt. This timeout setting should only be used as the HTTP connection timeout. For the search request timeout, use the maxTimeAllowed parameter inside of each search profile.
BasicConfiguration
This setting provides the same interface to a locally embedded search server without requiring an HTTP connection.
Index
This section defines the associated properties of the search index:
object
The Java object type that is used to represent the native search response object.
deltaUpdate, fullBuild
There are two switches in the CatalogEntry index that can be used to control the index synchronization trigger at the storefront:
  • deltaUpdate: Indicate if the storefront can trigger a delta index build.
  • fullBuild: Indicate if the storefront can trigger a full index build.
For example, if deltaUpdate is true while fullBuild is false, then only delta reindexing can be triggered through storefront search operations. To perform a full reindexing in this example, the indexing command utility must be used instead.
Cores
A list of internally used search runtime core server settings.
Profiles
Groups sets of search runtime parameters such as search index name, search index fields, expression providers, paging and sorting, and search feature configurations such as text highlighting, facets, and spelling correction. It is therefore possible to control the storefront search experience at a page-level by using different search profiles.

Search profile properties

The following table summarizes the configurable profile properties in the file. For more information about the properties within the search profile, open the wc-search.xml file and browse to your section of interest.
Important: The following properties rely on the default operator that is configured in the solrconfig.xml file to remain set as OR to function correctly. That is, changing the default OR operator in the solrconfig.xml file is not supported.
wc-search.xml configurable properties
Property Description
Profile The IBM_Global search profile is the base search profile. It contains all common settings and properties that are reusable for most search scenarios. Each of these settings can be individually overridden for additional customization.
Other search profiles that are provided in the wc-search.xml file include:
  • AutoComplete
  • SearchTermAssociation
  • IBM_findCatalogEntryByName
  • IBM_findCatalogEntryByNameAndShortDescription
  • IBM_findCatalogEntryByNameAndShortDescriptionInDetail
  • IBM_findCatalogEntryByUnstructureField
  • Introduced in Feature Pack 3IBM_findNavigationSuggestions
  • IBM_Global_Unstructured
  • Introduced in Feature Pack 3IBM_Global_WebContent
  • IBM_findAttachmentByCatentryId
  • IBM_findAttachmentByContent
  • IBM_FilteredCatalogEntry
  • IBM_CatalogEntryEntitlement
Query Declares properties that influence how the query expression gets executed against the search server at run time.

Feature Pack 6 or laterDefault parameters can be defined in the wc-component.xml file. For more information, see Search properties in the component configuration file (wc-component.xml) (WebSphere Commerce EAR).

It contains the following parameters:
maxRows
Restricts the maximum number of search results per page. The default value is:
  • Feature Pack 2500
  • Introduced in Feature Pack 350
maxTimeAllowed
Restricts the maximum amount of time allowed (in milliseconds) for any query to run. If the query takes more time than specified, a timeout occurs and partial (or no) results might be returned. If the value is null, the parameter is removed from the request. The default value is:
  • Feature Pack 23000
  • Feature Pack 4Feature Pack 35000
  • Feature Pack 5 or later15000
debug
Requests the search server to generate additional debug messages. The default value is false.
preview
Determines the level of details for the store preview:
  • 0 = Minimal, which includes marketing rules.
  • 1 = Summary, which includes marketing rules, and index status.
  • 2 = Detailed, which includes marketing rules, index status, and query explanations.

Feature Pack 2The default value is 2.

Introduced in Feature Pack 3The default value is 1.

price
Determines the display mode for showing prices in the storefront:
  • 0 = Computed, which includes:
    • Summary: prices only for the current page are calculated at run time.
    • Hide price facets.
    • Show computed price in each result.
    • Hide price range search in Advanced Search page.
    • Usage: prices are not populated in the search index.
  • 1: Indexed, which includes:
    • Summary: all prices are retrieved from the search index.
    • Show price facets with price range configured in facet configuration table.
    • Show indexed price in each result.
    • Show price range search in Advanced Search page.
    • Usage: prices are populated in the search index.
  • 2: Mixed, which includes:
    • Summary: search result contains computed prices, while price facets use indexed prices.
    • Show price facets with price range configured in facet configuration table.
    • Show computed price in each result.
    • Show price range search in Advanced Search page.
    • Usage: prices for all supported currencies are populated in the search index.
The default value is 1.
Note: standard offer price is indexed, with price value set to 1, search returns with product's standard offer price, any adjustment from price rule or contract price is not reflected.
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.
Introduced in Feature Pack 3statistics
Introduced in Feature Pack 3Requests the search server to capture search-related statistics. When this option is enabled, statistical data is cached in memory until the batch size (defined as SearchStatisticsBatchInsertSize in wc-component.xml under ExtendedConfiguration) is reached. This is done to minimize the amount of traffic caused as a result of search statistics gathering. The default value is false.
A list of mandatory expression providers is called upon each search request.
Note: These providers cannot be customized or reconfigured.
SolrSearchProfileNameValidator
This expression provider is for validating the search profile name from _wcf.search.profile.
SolrSearchIndexNameValidator
This expression provider is for validating the index core name. It can also determine the name if not specified by:
  1. Checking if _wcf.search.index is passed in as part of the expression
  2. If not, then look up the core name from the given search profile
  3. Otherwise, try to derive the core name by making use of the store ID to determine the master catalog ID and the locale name.
The resulting index name is added back into the SelectionCriteria object (_wcf.search.index) for other downstream processing.
SolrSearchDecodeMetaTokenExpressionProvider
A Solr specific implementation of the search expression provider for decoding the meta string by calling SolrSearchMetaTokenDecoder. The meta string is used for representing the search context, such as the breadcrumb trail.
SolrSearchEncodeMetaTokenExpressionProvider
This is a Solr specific implementation of the search expression provider for encoding the meta string. This provider encodes the meta string stored in _wcf.search.meta so that it can be reused later to represent the current facet state.
SolrSearchExpressionValidator
This search expression provider ensures the query expression is not empty. If so, it generates a default all inclusive condition (*:*) and adds it back to the SelectionCriteria object (_wcf.search.internal.optional.query). It also ensures all special characters are escaped properly before passing down to the search engine.

An optional list of expression providers can be specified. A search provider is used for compiling a business expression from the caller to an executable search engine expression. Depending on the given search profile, other business components might also get involved, such as marketing for rule-based merchandising, or contract for entitlement. Each business component is responsible for contributing a portion of the search expression, which gets combined with the main search expression. The consolidated search expression is executed by the search processor.

The following is a list of predefined expression providers provided by default:
Introduced in Feature Pack 3SolrSearchNoSearchResultsExpressionProvider
Introduced in Feature Pack 3This expression provider generates a search that returns no results. This is necessary when using the Data Service Layer and search profile capabilities, without having a full mediation occur for the entire CatalogNavigationView noun. A search results filter is used to populate the new area of the noun.
SolrSearchBasedMerchandisingExpressionProvider
This is a Solr specific implementation of the search-based merchandising expression provider. This provider calls the marketing component to run search rules. Search rules can apply to all searches or target specific search keywords. They might add additional constraints to the search request to influence the order of the results, and add new conditions to the search query with the intention of adding new products to search results.

For example, search rules might scope search results to contain only products that are in stock. They can also elevate products that meet a specific criteria (such as brand, profit margin or customer ranking) to the top of the search result.

The query fragments produced by search rules are added back into the SelectionCriteria object for other downstream processing:
  • _wcf.search.internal.filterquery
  • _wcf.search.internal.optional.query
  • _wcf.search.internal.mandatory.query
  • _wcf.search.internal.boostquery
  • _wcf.search.internal.sort
  • _wcf.search.term
Note: This provider should run before SolrSearchByKeywordExpressionProvider to ensure that search terms can be replaced successfully by the Add or Replace Search Criteria marketing action.
SolrSearchByKeywordExpressionProvider
This search expression provider is for handling the search by keyword request. This provider helps convert an XPath expression into a Solr specific expression. The following is the description of its behavior:
  • If EXACT match type is specified, the expression is considered to include keywords that use the EXACT match pattern +(f1:"t1 t2" f2:"t1 t2")
  • If NONE match type is specified, the expression is considered to include keywords that use the NONE match pattern -(f1:(t1 t2) f2:(t1 t2))
  • If ALL match type is specified, the expression is considered to include keywords that use the ALL match pattern +(f1:(+t1 +t2) f2:(+t1 +t2))
  • Otherwise, as is the default behavior for the storefront Quick Search, the expression is considered to include keywords that use the ANY match pattern +(f1:(t1 t2) f2:(t1 t2))
  • If exclude term and EXACT match type is specified, the expression is considered to exclude keywords that use the EXACT match pattern -f1:"t1 t2" -f2:"t1 t2"
  • Otherwise, the expression is considered to exclude keywords that use the ANY or ALL match pattern -f1:(t1 t2) -f2:(t1 t2)
The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.optional.query) for other downstream processing.
Feature Pack 5SolrSearchByAlternateKeywordExpressionProvider
Feature Pack 5An alternate expression provider that improves performance by simplifying synonym expansion logic for AND type searches in the storefront.
Note: The interim fix for JR46771 is required to use this expression provider.
SolrSearchByCategoryExpressionProvider
This search expression provider is for handling the search by category, and considers the sales catalog in the current business context.

The resulting Solr expression is added back into the SelectionCriteria object (category into _wcf.search.internal.mandatory.query and catalog into _wcf.search.internal.filterquery) for other downstream processing.

SolrSearchByManufacturerExpressionProvider
This search expression provider is for handling the search by brand name requests.

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.meta) and to be encoded into the meta string later.

SolrSearchByPriceExpressionProvider
This search expression provider is for handling the search by price range request that is generated from the Advanced Search page.

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.meta) and to be encoded into the meta string later.

SolrSearchByFacetExpressionProvider
This search expression provider is for handling the search by facet request. This provider helps convert an XPath expression into a Solr specific expression.

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.meta) and to be encoded into the meta string later.

SolrSearchByStorePathExpressionProvider
This search expression provider is for generating conditions to handle the store path.

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.filterquery) for other downstream processing.

SolrSearchByPublishedEntryOnlyExpressionProvider
This search expression provider is for restricting search results to only published entries.

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.filterquery) for other downstream processing.

SolrSearchByCustomExpressionProvider
This search expression provider is for handling the search by custom expression that is stored in _wcf.search.expr.

This custom expression is added to the SelectionCriteria object (_wcf.search.internal.optional.query) for other downstream processing.

SolrSearchFacetConditionExpressionProvider
This search expression provider is used to generate a list of attribute related facets and currency-specific price range facets for the current search request.

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.facet.field) for other downstream processing.

Introduced in Feature Pack 3SolrSearchSequencingExpressionProvider
Introduced in Feature Pack 3This search expression provider is for ordering product entries in the search result by ranking. The result is added back into the SelectionCriteria object (_wcf.search.internal.boostquery) for other downstream processing.

Feature Pack 4 or laterThis search expression provider also supports ordering for categories.

Introduced in Feature Pack 3SolrSearchTermAssociationExpressionProvider
Introduced in Feature Pack 3This search expression provider is for handling the search term association (STA) expansion. This provider helps get synonyms and replace the search term to fetch the final result.

The synonyms fetched by the STA service is added back into the SelectionCriteria object for other downstream processing: _wcf.search.internal.synonyms.

SolrSearchTypeExpressionProvider
This search expression provider is for handling the match type for keyword search requests. The following list is the pseudo logic of how the match type (_wcf.search.type) can be converted into a search criteria:
  • Match type is defaulted: ANY, exclude SKU
  • Exclude SKU expression is represented as -catenttype_id_ntk_cs:ItemBean
  • Only SKU expression is represented as - +catenttype_id_ntk_cs:ItemBean
  • Include SKU expression does not need to be qualified

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.filterquery) for other downstream processing.

SolrSearchProductEntitlementExpressionProvider
This search expression provider is for performing product entitlement. It is performed by calling ProductEntitlementExpressionHelper to build search engine specific query expressions for contracts that contain CatalogFilter Term Conditions and ProductSet Term Conditions. If a contract list is passed in, ProductEntitlementExpressionHelper builds the search expression against those contracts, instead of fetching contract from context. Otherwise, if there are no contracts that are passed as a parameter, this helper class fetches the current eligible contracts and builds search expressions against them.

The resulting Solr expression is added back into the SelectionCriteria object (_wcf.search.internal.filterquery) for other downstream processing.

Feature Pack 6 or laterSolrSearchByKeywordRelevancyExpressionProvider
Feature Pack 6 or laterThis search expression provider is for handling the search by keyword relevancy.
Feature Pack 6 or laterSolrSearchInventoryExpressionProvider
Feature Pack 6 or laterThis search expression provider is for handling searches for the inventory search index.
Sort The sort section is for defining sorting options and their corresponding values that can be used directly from the storefront.
For example:

<_config:sort>
<_config:field name="1" value="mfName_ntk_cs asc" />
<_config:field name="2" value="name_ntk asc,price_* asc" />
</_config:sort> 
Where, when a value of 2 is passed in through a control parameter _wcf.search.sort, the following two parameters is added to the final Solr expression:

sort=name_ntk+asc,price_USD+asc 
Note: price_* contains a * operator that is substituted with the shopper's currency at run time. In the example, the shopper's currency is USD.
Result Declares a list of search index fields to be returned in the search result set. Additional data filtering can applied.
The following predefined result filters are provided by default:
Introduced in Feature Pack 3SearchCatalogNavigationViewDynamicKitResultFilter
Introduced in Feature Pack 3This CatalogNavigationView search result filter is used to populate a Dynamic Kit response BOD with its configuration data. This data includes the Model name, Model configuration, and whether the Dynamic Kit has a predefined configuration. If a predefined configuration is defined, the response includes details about the pre-configured components of the Dynamic Kit and the total price of the Dynamic Kit.
Note:
  • Components and price information is returned only when all components of the Dynamic Kit are displayable and when the shopper has entitlement to the components.
  • You can use the IBM_findCatalogEntryDynamicKitSummary search profile for a response with price information.
SearchCatalogEntryViewPriceResultFilter
The CatalogNavigationView search result filter for modifying prices in each CatalogEntryView object. Its purpose is to determine the suitable calculated contract price to be displayed to the shopper.
SearchCatalogEntryViewSingleSKUResultFilter
The CatalogNavigationView search result filter for determining whether each CatalogEntryView object is a single SKU.
SearchCatalogNavigationViewPreviewResultFilter
The CatalogNavigationView search result filter for setting up all required metadata for previewing search operations in the store preview. This includes the indexing status and search query string.
Introduced in Feature Pack 3SearchNavigationSuggestionsResultFilter
Introduced in Feature Pack 3This search result filter enables the population of the NavigationSuggestion area of the CatalogNavigationViewNoun. This filter class checks the search configuration for any registered "navigation suggestion handlers", with each handler that populates a navigation suggestion displayed in the drop-down box.
Feature Pack 5 or laterSearchCatalogNavigationViewDynamicKitResultFilter
Feature Pack 5 or laterThis CatalogNavigationView search result filter is used to populate a Dynamic Kit response BOD with its configuration data. This data include the Model name, Model configuration, and whether the Dynamic Kit has a predefined configuration. If a predefined configuration is defined, the response includes details about the preconfigured components of the Dynamic Kit and the total price of the Dynamic Kit.
Note:
  • Components and price information is returned only when all components of the Dynamic Kit are displayable and when the shopper has entitlement to the components.
  • You can use the IBM_findCatalogEntryDynamicKitSummary search profile for a response with price information.
Feature Pack 5 or laterSearchCatalogGroupEntitlementResultFilter
Feature Pack 5 or laterThis search result filter determines whether the current user is entitled to the returned CatalogGroupView objects in the response.
Feature Pack 5 or laterSearchCatalogEntryViewDescriptionResultFilter
Feature Pack 5 or laterThis CatalogNavigationView search result filter is used to populate catalog entries override for an eSite store. The fields include name, short description, long description, thumbnail, full image, and keyword.
Feature Pack 5 or laterSearchCatalogNavigationViewDynamicKitResultFilter
Feature Pack 5 or laterThis CatalogNavigationView search result filter is used to populate a Dynamic Kit response BOD with its configuration data. This data includes the Model name, Model configuration, and whether the Dynamic Kit has a predefined configuration. If a predefined configuration is defined, the response includes details about the pre-configured components of the Dynamic Kit and the total price of the Dynamic Kit.
Note:
  • Components and price information are returned only when all components of the Dynamic Kit are displayable and when the shopper has entitlement to the components.
  • You can use the IBM_findCatalogEntryDynamicKitSummary search profile for a response with price information.
Feature Pack 5 or laterFacetEntryViewImageAndSequenceResultFilter
Feature Pack 5 or laterThis CatalogNavigationView search result filter is used to populate additional information for facet entries. If the facet is attribute dictionary attribute-based, the sequence and image from the ATTRVALDESC table is respected for the facet entry values returned. Use this filter when you sort facet values by attribute value sequence.
Note: The naming convention for some of the preceding result filters might contain a Solr prefix.
Highlight Declares a list of search index fields to be used for highlighting and their associated highlighting behavior at run time.
Facets Declares a list of search index fields to be used for faceting and their associated faceting behavior at run time.
It contains the following parameters:
sort
Determines the ordering of the facet field constraints:
  • count = sort the constraints by count (highest count first).
  • index = return the constraints sorted in their index order (lexicographic by indexed term). For terms in the ASCII range, this is alphabetically sorted.
The default value is count.
minCount
Indicates the minimum counts for facet fields that should be included in the response.
The default value is 1.
limit
Indicates the maximum number of constraint counts that should be returned for the facet fields. A negative value denotes unlimited.
The default value is 200.
Note: The MAX_DISPLAY column of the FACET table overrides this limit by default in the storefront.
Spellcheck Defines the spell checking behavior at run time.
It contains the following parameter:
limit
Indicates the maximum number of suggestions to return.
The default value is 5.
navigationSuggestion Defines the suggested brands, categories, and articles behavior at run time.
Articles contains the following parameter:
totalNumber
The number of cached web content articles to return.
The default value is 100.

Inheritance

Similar to Java inheritance, search profile properties are inheritable. Parent properties can be either overridden or extended by its child:
Overridden
All associated elements within a given property of its parent are discarded and only the properties that are specified by the child are used instead. For example, <_config:query> or <_config:query inherits="false">.
Extended
All associated elements within a given property of its parent are passed down to its child, along with other additional properties specified by the child. For example, <_config:query inherits="true"> .
Note: Properties from the child are always processed last and therefore achieve the behavior of inheritance. In situations where sequencing of properties is necessary, properties of the parent always come before the child. If this behavior is not desired, the child can override this behavior by specifying all of its parent properties along with its own, in an order that is needed.