Migrating WebSphere Commerce search

You can migrate WebSphere Commerce search from an earlier feature pack version to a later feature pack version, according to your site requirements. Ensure that you are aware of the considerations before migrating WebSphere Commerce search.

Migration paths

In Feature Pack 2, 3, 4, 5, and 6, WebSphere Commerce search uses a BOD-based search runtime programming model that resides on the WebSphere Commerce server.

In Feature Pack 7, WebSphere Commerce search introduces a REST-based search runtime programming model that resides on both the WebSphere Commerce and search servers. It contains a new architecture, deployment strategy, and REST APIs to program against the search server. In Feature Pack 8, WebSphere Commerce search continues to use the new REST-based search runtime programming model.

Consult the following list to select the relevant task for migrating WebSphere Commerce search to a later feature pack version:

After you migrate to a later feature pack level, your previous implementation and customizations continue to function.

Compatibility path

The following diagram illustrates the WebSphere Commerce search compatibility path:
Search interaction diagram

Where:

Solr stack upgrade and indexing enhancements: The Solr stack will be updated as part of the feature pack installation. Any existing cores or indexes that are created in earlier feature pack versions must be set up again and rebuilt. These tasks are automated by using the migrateSolrSearch utility. Any custom changes made at the schema-level must be manually applied after migrating the search index.; There are some changes to the CatalogEntry and CatalogGroup indexes. To ensure compatibility with earlier versions, no index fields are being removed that were available in prior feature pack versions. Instead, some fields are new, and others are deprecated.
Search runtime: The BOD-based search runtime and programming model resides on the WebSphere Commerce server. The new lightweight REST-based search server runtime does not depend on BOD services and resides on the search server. The BOD-based path continues to function as intended. That is, there are no additional enhancements to the BOD-based code path. As a result, there are some shared common runtime artifacts between both code paths, for example, the search expression providers. Any runtime custom code that follows the BOD-based code path's best practices are preserved after installing the feature pack. However, you must replicate the runtime custom code to the search server.

Updating to Feature Pack 7 or later

WebSphere Commerce search contains several architectural changes, and must be treated with the typical considerations of a stack upgrade. For example, it contains a new architecture, deployment strategy, and REST APIs to program against the search server.

The REST-based search runtime programming model that is introduced uses POJO and raw data that is returned from the search server to perform simple name-value pair mapping. The following diagram shows an overview of the new search runtime programming model:
Search programming model

In addition, the storefront services, search profile names, search server artifacts such as expression providers, query preprocessors, and postprocessors are all changed and updated. Therefore, you must consider which new REST services, search profiles, and search artifacts can act as replacements to your existing BOD-based services.