Feature Pack 4Feature Pack 2Feature Pack 5Feature Pack 3Feature Pack 6

Customizing WebSphere Commerce search in the storefront

You can customize WebSphere Commerce search in the storefront to suit your business needs. You can customize WebSphere Commerce search according to your role within the WebSphere Commerce site.


The following list highlights the search-related areas in the storefront that business users can configure with the Management Center:

  • Catalog filtering

    Filtering against the entire master catalog can be done with catalog filters. You can explicitly include or exclude by category, catalog entry, or filter by attribute value or other catalog-related properties.

    For more information, see Working with catalog filters.

  • Entitlement

    Entitlement assigns price rules base contracts and customer contracts in the B2B direct business model, including extended sites. After you assign price rules to contracts, customers that are shopping under the contract are entitled to prices set by the price rule.

    For more information, see Working with price rules.

  • Storefront navigation

    The display sequence of categories and products for each sales catalog can be controlled with the Catalogs tool. In addition, facet management such as how facets are displayed, and facet properties such as multi-selectable, size, and display order can all be specified.

    For more information, see Creating attributes in the attribute dictionary and Managing faceted navigation attributes in categories.

  • Search engine optimization (SEO)

    Manage SEO URLs without getting your IT administrators involved. WebSphere Commerce remembers the change history for SEO URLs so that external search engines can redirect previously indexed URLs (301) to the latest SEO URL.

    For more information, see SEO for Version 7 Feature Pack 3 or later.

  • Landing pages

    Landing pages provide a better brand and categorization experience to shoppers in your store, and support SEO-friendly URLs.

    For more information, see Constructing SEO-friendly URLs by using pattern files and Linking and unlinking search terms with landing pages.

  • Keyword search relevancy

    Business users use search rules to influence shopper search results in the storefront. Search rules can be triggered by one or more keywords that are entered by the shopper. Based on certain conditions such as purchase history, browsing patterns, or the date and time, business users can define a set of actions. Actions such as promoting certain products up or down the search results based on a certain attribute value or property are supported.

    For more information, see Working with search rules.

    You can use store preview to test and tune the search rule boost factor. You can use AB testing to experiment with search rules in a production environment.

    For more information, see Working with search rule experiments.

  • Search result scoping

    Search term associations control the scope of search results. Synonyms increase the search scope and therefore return more relevant results, while replacement terms reduce the search scope to avoid returning too many unrelated results.

    For more information, see Creating search term associations using synonyms and replacements.

  • e-Marketing Spot product recommendations

    e-Marketing Spots can be configured so that the recommended content can be sensitive to keywords provided by the shopper.

    For more information, see Trigger: Customer Searches.

  • Bulk loading catalog data

    Several preceding configurations can be imported in the Management Center using Catalog upload.

    For more information, see Catalog Upload operations in WebSphere Commerce search.

The following list highlights the search-related areas in the runtime that IT administrators and developers can use to customize WebSphere Commerce search:

  • WebSphere Commerce search and indexing runtime architecture
    The following diagram illustrates the overall WebSphere Commerce search and indexing runtime architecture:
    WebSphere Commerce search and indexing runtime architecture
  • Scoping

    Use the appropriate match type to define the search scope with keywords specified by the shopper. Match types are defined in the SearchSetup.jspf file.

    For more information, see WebSphere Commerce search interface: Match Type (_wcf.search.type).

  • Expression providers

    Expression providers can be used to implement custom business logic for customizing the search expression. Each expression provider can be separately registered to any search profile query section so that it can be reused for other search operations. Each expression provider must extend from com.ibm.commerce.foundation.server.services.search.expression.solr.AbstractSolrSearchExpressionProvider and must implement the com.ibm.commerce.foundation.server.services.search.expression.SearchExpressionProvider interface.

    For more information, see WebSphere Commerce search configuration file (wc-search.xml) (WC EAR).

  • Search query preprocessors and postprocessors

    A query preprocessor is used to modify the SolrQuery object right before the object is sent to the Solr server for processing.

    A query postprocessor is used to modify the physical data object, SolrEntityContainerImpl, immediately after the QueryResponse is returned from the Solr server.

    For more information, see WebSphere Commerce search configuration file (wc-search.xml) (WC EAR).

  • Index schema preprocessor and indexer/parser

    You can customize the WebSphere Commerce search index schema, where in general, it affects the WebSphere Commerce runtime and index-building utilities. In addition, you can enable searching on additional unstructured content types.

    For more information, see Example: Customizing the search index schema and Enabling search on additional unstructured content types.

  • Search rules

    You can index data from a source external to the WebSphere Commerce database. Newly added search fields can be used to sort the search results when you create search rules.

    For more information, see Tutorial: Indexing external data in WebSphere Commerce search.

  • Result Filters

    A result filter can be used to modify the logical object (noun) before the search result is returned to the storefront. The filter has full access to the CatalogNavigationView noun and therefore additional data can be inserted or updated to any parts of this noun. A result filter must extend from the com.ibm.commerce.catalog.facade.server.services.search.metadata.AbstractSearchResultFilter and must implement the com.ibm.commerce.foundation.server.services.search.metadata.SearchResultFilter interface.

  • UserData mapper

    A UserData mapper can be used to map any element in the CatalognavigationView noun into a name-value pair. The name-value pair can be quickly accessed using the CatalogNavigationView/UserData type. The mapping configuration is defined in the mediator-property found in the wc-business-object-mediator.xml file.

    For more information, see Customizing the Business Object Mediator to include custom data.
    Feature Pack 6 or laterNote: Multi-value field support for a UserData mapper is available. All values that belong to the same field are returned in the value of the name-value pair that is defined in the wc-business-object-mediator.xml file. Each of the values that return is separated by a semi-colon.
  • Search profile

    Search requests are typically initiated from the storefront. The most important parameter that is specified when initiating a search request is the search profile. A search profile can be passed to the WebSphere Commerce search runtime by adding it as a parameter in the getData tag.

    Depending on where the custom search profile is called in the storefront, different JSP widgets must be updated.

    For example, to call the custom search profile that is created in WebSphere Commerce search programming model, extension points, and customization tasks, when performing a simple keyword search:
    1. Update the SearchSetup.jspf file in the common directory of your store:
      • WC_installdir\workspace\Stores\WebContent\AuroraStorefrontAssetStore\Common
    2. Replace IBM_findCatalogEntryWithoutDescriptionByNameAndShortDescription by the custom search profile X_findCatalogEntryByfield1.
      Important: The custom profile should extend the profile that is being replaced in this step to avoid losing any settings from the previous profile.

    Index fields that are mapped to the CatalogEntryView user data fields can be displayed in the storefront by modifying the JSP file where it should be displayed.

    To display the CatalogEntry customizable fields, field3, and field5, they can be displayed in the CatalogEtnry widget:
    <c:out value="Custom field3: ${catalogEntryView.UserData.UserDataField.field3}" />
    <c:out value="Custom field5: ${catalogEntryView.UserData.UserDataField.field5}" />