Introduced in Feature Pack 2

Integrating WebSphere Commerce with third-party search engines

Integrating WebSphere Commerce search with third-party search engines other than Apache Solr can be accomplished by modifying default interfaces and performing other customizations to meet your business requirements. However, it is important to note that this process is an advanced task, as WebSphere Commerce search is a core runtime component in WebSphere Commerce. Many features are tightly integrated with the search component. Therefore, replacing WebSphere Commerce search with a third-party search engine is an in-depth customization.

That is, there are many existing (and future) features that are tightly integrated with the search component. Therefore, replacing WebSphere Commerce search with a third-party search engine can cause malfunctions, requiring in-depth customization to recover and replicate WebSphere Commerce search functionality.

The following features require WebSphere Commerce search in order to function correctly:
  • All Management Center functionality related to WebSphere Commerce search, such as search term associations, search rules, search rule based e-Marketing Spot product recommendation, search statistics, and search facets.
  • Rule-based catalog entitlement (catalog filtering)
  • Feature Pack 7 or laterCommerce Composer
  • Price rules that use catalog filtering
  • Configurator
  • Workspace preview
  • Lifecycle management on the search index
  • Caching and invalidation

Procedure

  • The following diagram highlights the integration strategy with an additional third-party search service provider:

    Third-party integration components

    Where:

    1. Across the top is a layer of business components, such as Catalog, Contract, and Marketing. Each of these components is responsible for contributing a portion of the search expression and later combined by runtime to form a master execution instruction for the search engine.
    2. WebSphere Commerce search is the search implementation provided by default. Its advantage is that it engages tighter integration with other existing WebSphere Commerce business components and optimizes the processing logic to gain better overall performance throughput at runtime.
    3. A search interface is provided for search integration. Using this search interface, it is possible to reuse similar XPath expressions against a different third-party search service provider, and display the search result directly on the presentation layer.
  • Custom logic can be implemented:
    1. Following the recommended programming pattern with WebSphere Commerce search, or
    2. Code directly against other search service providers and aggregate the search result at the storefront user interface.
    Note:
    • Both of these approaches can use the same search interface to maintain consistency in the user interface.
    • The Management Center cannot be used to manage other custom third-party search implementations.
  • The following key considerations must be understood when using other third-party search engines:
    1. The tooling provided by the alternative search engine must be used to perform influencing of search results in the storefront.
    2. The search engine must contain its own indexing process, as those build into WebSphere Commerce search are used to integrate with Apache Solr.
    3. When implementing the search engine into your store, you must write custom JSP files to call out to third party search engines. For example, using the faceted navigation JSP files calling the search engine, or serving the JSP files directly from the search engine. For product display pages, product information must come either from WebSphere Commerce or from the third-party search engine.
    4. CAUTION: While performing customization and overriding the default search logic, do not delete the binaries that are included with WebSphere Commerce search by default. Doing so prevents you from performing future maintenance.