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)
- Commerce 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:
Where:
- 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.
- 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.
- 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:
- Following the recommended programming pattern with WebSphere
Commerce search, or
- 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:
- The tooling provided by the alternative search engine
must be used to perform influencing of search results in the storefront.
- The search engine must contain its own indexing process,
as those build into WebSphere Commerce search are used to integrate
with Apache Solr.
- 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.
- 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.