Migración de clases Java personalizadas de búsqueda basada en BOD a la búsqueda basada en REST

Puede migrar clases Java personalizadas reutilizándolas cuando sea aplicable o reimplementándolas de una forma alternativa.

Debido al uso de contenedorización, todas las personalizaciones deben ser creadas por el script WCB e implementadas por su canalización CI/CD. De forma predeterminada, los activos de configuración personalizados se pueden agregar en el directorio search-config-ext y los activos de Java personalizados se pueden agregar en el directorio search-logic-ext. A continuación, la secuencia de comandos WCB predeterminada y la canalización CI/CD pueden crear e implementar esos activos en el contenedor de búsqueda.

Procedimiento

  1. Puede reutilizar proveedores de expresión personalizados.

    Para la búsqueda basada en BOD, todos los proveedores de expresiones predeterminados se empaquetan bajo com.ibm.commerce.catalog.facade.server.services.search.expression.solr. Para HCL Commerce Version 9, todos los proveedores de expresiones se mueven al paquete com.ibm.commerce.search.internal.expression.provider. El patrón de nombres también se cambió. Por lo tanto, su proveedor de expresiones personalizado debe cambiarse para anular el nuevo proveedor de expresiones. La lógica principal debe seguir siendo compatible con la búsqueda de BOD.

  2. Puede reutilizar preprocesadores de expresión personalizados.

    Los preprocesadores de consulta de búsqueda basados en BOD que funcionan en el objeto físico SolrQuery nativo heredado del siguiente padre AbstractSolrSearchQueryPreprocessor, empaquetado en com.ibm.commerce.foundation.internal.server.services.search.query.solr.

    En HCL Commerce Version 9 Search, el padre está empaquetado en com.ibm.commerce.search.internal.expression.preprocessor.

  3. Vuelva a aplicar los posprocesadores de resultados de consultas personalizados.

    Si sus posprocesadores personalizados operan en la consulta nativa, pueden reutilizarse anulando el posprocesador relacionado. Sin embargo, si el postprocesador personalizado opera en la SolrCatalogNavigationViewImpl, no se puede reutilizar.

    De forma alternativa, cambie el código personalizado para que opere en el SearchResponse. Por ejemplo, el fragmento de código siguiente muestra cómo usar SearchResponse:
    
List<Map<String, Object>> catalogEntryViews = (LinkedList<Map<String, Object>>)iSearchResponseObject.getResponse().get("external object name");
    Donde el nombre de objeto es el nombre de objeto externo. Para obtener más información sobre la resolución de nombres externos, consulte los posprocesadores personalizado de ejemplo en el archivo wc-search.xml.
  4. Reimplemente los filtros de resultado de consulta de búsqueda personalizados.

    Los filtros de resultados personalizados que operan en el nombre lógico CatalogNavigationViewType no son compatibles con el servidor de HCL Commerce Version 9 Search. Todos los filtros de resultados personalizados se deben reimplementar utilizando posprocesadores de consulta de búsqueda. Para obtener más información, consulte Crear un postprocesador de consulta personalizado.

  5. Reimplemente sus mediadores de objetos de negocio.

    En versiones anteriores de HCL Commerce, los mediadores de objetos de negocio operan en el nombre lógico CatalogNavigationViewType. Ya no es compatible con el servidor de búsqueda. En su lugar, puede utilizar posprocesadores de consultas de búsqueda. Todos los mediadores personalizados que amplían la clase padre de AbstractReadBusinessObjectPartMediatorImpl se deben reimplementar utilizando posprocesadores de consulta de búsqueda.