WebSphere Commerce search interactions

WebSphere Commerce search includes several key interaction areas, including the Presentation layer, WebSphere Commerce server, and the search service façade.

The following diagram illustrates the interaction between the various areas of WebSphere Commerce search:

Search interaction diagram

Where:

The CatalogNavigationView noun is used with the storefront Catalog service to perform searches and search-based navigation in the storefront. This noun represents a business response of a catalog browsing request, containing a list of sub-products, called CatalogEntryView, and a list of subcategories, called CatalogGroupView.
The main running path involves the Catalog component, where the Catalog navigation service is provided. Depending on the nature of the request, that is, the given search profile, other business components might get involved, such as Marketing for search-based merchandising rules, or contracts for entitlement. Each business component is responsible to contribute a portion of the search expression, which get combined with the main search expression generated by the Catalog navigation service. As a result, the consolidated search expression is run by the Data Service Layer (DSL) against the search engine for processing.
The response of the search request is in the form of a native search response object, that is, the physical SDO, which is then mediated by the Catalog navigation business object mediator (CatalogNavigationView Read BOM) in the DSL into the Catalog navigation noun (the logical SDO) for use by the caller, such as the search interface.

Search Service Facade

In addition to the existing Data Service Facade, which typically works with database-related requests, the Search Service Facade handles all the search engine-specific requests. The decision between which facade to use is contained in the search profile parameter. If a search profile parameter, for example, _wcf.search.profile, is passed in as part of the control parameter in the XPath expression, the request is run as a search expression that requires a search engine for processing.

The following diagram illustrates the Search Service Facade:
Feature Pack 4

Where:

Information gathered through the expression builder from the storefront interface includes keywords, paging and sorting parameters, category ID, and search profile. For example:


{_wcf.ap='$accessProfile$';_wcf.search.profile='$searchProfile$';_wcf.search.term='$searchTerm$'
;_wcf.search.sort='$orderBy$';_wcf.search.meta='$metaData$'}/CatalogNavigationView

When the search Get request hits the BOD controller command in the Catalog component, it is mapped down to the Fetch command. The runtime determines which facade to forward the search request by inspecting whether a search profile, _wcf.search.profile, has been provided with the XPath. If it is provided, the request is run as requiring a search engine for processing and therefore routed to the Search Service Facade.
There are two main search engine-specific components in the Search Service Facade: the search provider and the search processor.

SearchExpressionProvider

Depending on the nature of the request, that is, the given search profile, other business components might get involved, such as Marketing for search-based merchandising rules, or contracts for entitlement. Each business component is responsible to contribute a portion of the search expression, which get combined with the main search expression generated by the Catalog navigation service. As a result, the consolidated search expression is run by the search processor.

A factory class, SolrSearchExpressionProvider, manages all of these expression providers at runtime. The implementation of this search expression provider factory class is defined in the SearchExpressionProviderFactory.properties file.

SearchExpressionProcessor

A search processor is the central processing unit for integrating with the external search engine. Its responsibility is to run the given Solr expression, based on the given search profile attributes, and capture the response from the search engine.

SolrSearchExpressionProcessor is a default implementation of the expression processor that is defined in the SearchExpressionProcessorFactory.properties file.

A query preprocessor is used to modify the SolrQuery object right before sending to 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.

See the query section of WebSphere Commerce search configuration file (wc-search.xml) (WC EAR) for more information.
The default SolrSearchExpressionProvider performs the following high-level steps in this given order:
1. Validates that a search profile is provided by calling SolrSearchProfileNameValidator and immediately stops if none is provided.
2. Validates the corresponding index name by calling SolrSearchIndexNameValidator and immediately stops if invalid.
3. Validates the corresponding workspace information by calling SolrSearchWorkSpaceValidator.
4. Decodes _wcf.search.meta (if provided) and expands into _wcf.search.internal.meta by calling SolrSearchDecodeMetaTokenExpressionProvider. The value in this control parameter can be considered the breadcrumb trail.
5. Calls each of the given expression providers defined in the search profile. For example, the keyword search request involves using the IBM_findCatalogEntryByNameAndShortDescription search profile.
  The following expression providers are run in the following sequence:
  1. SolrSearchBasedMerchandisingExpressionProvider calls the marketing component to run search rules.
  2. SolrSearchTermAssociationExpressionProvider gets synonyms and replaces the search term to fetch the final result.
  3. SolrSearchByKeywordRelevancyExpressionProvider handles the search by keyword request.
  4. SolrSearchByCategoryExpressionProvider handles the search by category, considering the sales catalog in the current business context.
  5. SolrSearchByManufacturerExpressionProvider handles the search by brand name requests.
  6. SolrSearchByPriceExpressionProvider handles the search by price range request generated from the Advanced Search page.
  7. SolrSearchByFacetExpressionProvider handles the search by facet request.
  8. SolrSearchByStorePathExpressionProvider generates conditions to handle the store path.
  9. SolrSearchByPublishedEntryOnlyExpressionProvider generates conditions for restricting search results to only published entries.
  10. SolrSearchByCustomExpressionProvider includes custom expressions stored in _wcf.search.expr.
  11. SolrSearchFacetConditionExpressionProvider generates a list of attribute-related facets and currency-specific price range facets for the current search request.
  12. SolrSearchTypeExpressionProvider handles the match type for keyword search requests, such as Any and Exclude SKU.
  13. SolrSearchSequencingExpressionProvider arranges product entries in the search result by ranking.
  14. SolrSearchProductEntitlementExpressionProvider performs product entitlement.
  15. SolrSearchInventoryExpressionProvider handles searching related to the Inventory index.
6. Validates the search expression to ensure the query expression is not empty and does not contain special characters by calling SolrSearchExpressionValidator;
7. Reconstructs and encodes the new meta string in _wcf.search.meta by calling SolrSearchEncodeMetaTokenExpressionProvider so that it can be reused later to represent the current navigation state.
The default SearchExpressionProcessor then composes the final Solr expression and sets up all the required bootstrap settings for communicating to the Solr search server. The result set is then mediated into an EntityContainer object to be returned to the caller.
The expression processor performs the following high-level steps in the following sequence:
1. Injects a debug parameter option into the SolrQuery object by calling SolrSearchDebugQueryPreprocessor.
2. Includes a relevancy score and additional tracing information into the SolrQuery object by calling SolrSearchPreviewQueryPreprocessor.
3. Enables spell correction and includes its associated parameter options into the SolrQuery object by calling SolrSearchSpellCorrectionQueryPreprocessor.
4. Enables highlighting and includes its associated parameter options into the SolrQuery object by calling SolrSearchHighlighterQueryPreprocessor.
5. Injects pagination parameter options into the SolrQuery object by calling SolrSearchPaginationQueryPreprocessor.
6. Injects sorting parameter options into the SolrQuery object by calling SolrSearchSortingQueryPreprocessor.
7. Injects result grouping parameter options into the SolrQuery object by calling SolrSearchResultGroupingQueryPreprocessor.
8. Generates a list of index fields to be included in the search result set by calling SolrSearchResultFieldQueryPreprocessor.
9. Composes a list of facet fields, with the proper settings, to be included in the search result set by calling SolrSearchFacetQueryPreprocessor.
10. Injects the main search query string into the SolrQuery object by calling SolrSearchMainQueryPreprocessor.
11. Launches a list of search query preprocessors defined in the given search profile to allow modifying of the SolrQuery object immediately before sending it to the Solr server for processing.
12. Attempts to connect to the Solr server, with retry logic enabled upon connection failures, to process the SolrQuery object.
13. Launches a list of search query postprocessors defined in the given search profile to allow modifying of the physical data object, SolrEntityContainerImpl, immediately after the QueryResponse is returned from the Solr server.
The response of the search request is a native search response object, the physical SDO com.ibm.commerce.catalog.facade.server.services.search.metadata.solr.SolrCatalogNavigationViewImpl, which is mediated by the Catalog navigation business object mediator (defined in wc-business-object-mediator.xml) into the Catalog navigation noun (CatalogNavigationView). This message transformation is implemented by the following mediators:

SolrReadCatalogNavigationViewMediator

The top-level mediator for processing the facets and metadata, such as spelling correction and meta strings.

SolrReadCatalogEntryViewPartMediator

The CatalogEntryView noun part mediator for processing all required CatalogEntryView nouns in the list in the CatalogNavigationView noun.

SolrReadCatalogGroupViewPartMediator

The CatalogGroupView noun part mediator for processing all required CatalogGroupView nouns in the list in the CatalogNavigationView noun.

SolrReadAttachmentAssetViewPartMediator

Constructs the AttachmentAssetViewType from the search result document list and puts those attachments into the CatalogEntryViewType container. If the catentry_id is found in the noun container, it puts the attachment object in it. If the catentry_id is not found in the noun container, it creates a new CatalogEntryViewType and puts the attachment into it.

SolrReadBreadCrumbTrailViewPartMediator

Converts the result set data from Solr into its logical manifestations in the logical CatalogNavigationViewType noun. This mediator handles the /CatalogNavigationView/BreadCrumbTrailView portion of the noun.

SolrReadFacetViewPartMediator

Converts the result set data from Solr into its logical manifestations in the logical CatalogNavigationViewType noun. This mediator handles the /CatalogNavigationView/FacetView portion of the noun.

SolrReadWebContentViewPartMediator

Converts the result set data from Solr into its logical manifestations in the logical CatalogNavigationViewType noun. This mediator handles the /CatalogNavigationView/CatalogEntryView portion of the noun.

SolrReadCatalogNavigationViewPostMediator

Performs any post mediation logic to the logical CatalogNavigationViewType noun.
Important: This mediator must be declared as the last entry in the wc-business-object-mediator.xml file.

Note: A list of mediator properties are defined under the mediator section to provide a runtime mapping from the search index field name to an XPath in the logical noun.