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
- 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 paquetecom.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. - 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.
- 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 elSearchResponse
. Por ejemplo, el fragmento de código siguiente muestra cómo usarSearchResponse
:
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.List<Map<String, Object>> catalogEntryViews = (LinkedList<Map<String, Object>>)iSearchResponseObject.getResponse().get("external object name");
- 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. - 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 deAbstractReadBusinessObjectPartMediatorImpl
se deben reimplementar utilizando posprocesadores de consulta de búsqueda.