Migrating custom Java classes from BOD-based Search to REST-based Search

You can migrate custom Java classes either by reusing them where applicable, or reimplementing them in an alternative way.

Due to the use of containerization, all customizations must be built by WCB script and deployed by your CI/CD pipeline. By default, custom configuration assets can be added under the search-config-ext directory, and custom java assets can be added under search-logic-ext directory. Then, the default WCB script and CI/CD pipeline can build and deploy those assets to Search container.

Procedure

  1. You can reuse your custom expression providers.

    For BOD-based Search, all of the default expression providers are packaged under com.ibm.commerce.catalog.facade.server.services.search.expression.solr. For HCL Commerce Version 9, all expression providers are moved to package com.ibm.commerce.search.internal.expression.provider. The naming pattern was changed too. So your custom expression provider needs to be changed to override the new expression provider. The main logic should remain compatible with BOD search.

  2. You can reuse your custom expression preprocessors.

    BOD-based Search query preprocessors operated on the native physical SolrQuery object inherited from the following parent AbstractSolrSearchQueryPreprocessor, packaged in com.ibm.commerce.foundation.internal.server.services.search.query.solr.

    In HCL Commerce Version 9 Search, the parent is packaged in com.ibm.commerce.search.internal.expression.preprocessor.

  3. Reapply your custom query result postprocessors.

    If your customized postprocessors operate on the native Query, they can be reused by overriding related postprocessor. However, if the custom postprocessor operates on the SolrCatalogNavigationViewImpl, it cannot be reused.

    Alternatively, change your custom code to operate on the SearchResponse. For example, the following snippet shows how to use the SearchResponse:
    
List<Map<String, Object>> catalogEntryViews = (LinkedList<Map<String, Object>>)iSearchResponseObject.getResponse().get("external object name");
    Where the object name is the external object name. For more information about resolving external names, see the sample custom postprocessors in the wc-search.xml file.
  4. Reapply your custom search query result filters.

    Custom result filters that operate on the logical CatalogNavigationViewType noun are not supported in the HCL Commerce Version 9 Search server. All custom result filters must be reimplemented by using Search query postprocessors. For more information, see Creating a custom query postprocessor.

  5. Reapply your Business Object Mediators.

    In previous HCL Commerce versions, Business Object Mediators operated on the logical CatalogNavigationViewType noun. This is no longer supported on the Search server. Instead, you can use search query postprocessors. All custom mediators that extend the AbstractReadBusinessObjectPartMediatorImpl parent class must be reimplemented by using Search query postprocessors.