HCL Commerce Search interacciones

La HCL Commerce Search incluye varias áreas de servicio de claves, incluidos la arquitectura de servidores y el modelo de programación.

Arquitectura de servidor de búsqueda

Existe una vía de acceso directo a la navegación de sitio y al servidor de búsqueda en el servidor de búsqueda Solr. Este servidor consta de un conjunto de servicios REST, una infraestructura de ejecución de búsqueda que reutiliza el modelo de programación de búsqueda actual y un conjunto de servicios de fundamentos de HCL Commerce que también proporcionan acceso a la base de datos de HCL Commerce.

El diagrama siguiente muestra una visión general de la arquitectura de servidor de búsqueda:
Diagrama de interacción de búsqueda
Donde:
  • El correlacionador de servicio REST es una implementación Jersey de JAX-RS 2.0 que utiliza configuraciones para correlacionar una URL REST con un recurso. Entonces este recurso llamará al tiempo de ejecución de búsqueda incorporado.
  • El tiempo de ejecución de búsqueda es una infraestructura de programación conectable que permite que se ejecuten expresiones de búsqueda utilizando propiedades que se definen en un perfil de búsqueda basado en la configuración. Una vez que se ha compuesto una expresión de búsqueda, el tiempo de ejecución reenvía entonces la solicitud al tiempo de ejecución de Solr incorporado para su proceso.
  • El servicio de fundamentos es el tiempo de ejecución de núcleo de HCL Commerce que puede proporcionar servicios de servidor básicos, como el servicio de consulta JDBC para acceder a la base de datos de HCL Commerce.

Ejemplo

Cuando los compradores especifican una consulta de búsqueda en el escaparate, la consulta se convierte en una llamada REST. La plantilla utilizada para crear la llamada se encuentra en el archivo SearchSetup.jspf. Esta plantilla, que se encuentra en el código <wcf:rest/>, crea la llamada como una serie.
<wcf:rest var="catalogNavigationView1" url="${searchHostNamePath}${searchContextPath}/store/${WCParam.storeId}/productview/${restType}">
La llamada REST se envía al servidor de búsqueda y la intercepta el manejador de peticiones especificado en la llamada (ProductViewHandler en el escenario anterior).El manejador de peticiones comprueba el archivo wc-rest-resourceconfig.xml para confirmar que el perfil que se está pasando está en la lista de perfiles de búsqueda definidos para el URI. Si el perfil no está en la lista definida para el URI, se generará un error HTTP 400.
Si no se especifica ningún perfil de búsqueda en la URL (&searchProfile=X), el manejador de peticiones utiliza el primer perfil de búsqueda definido en wc-rest-resourceconfig.xml. Por ejemplo, para una solicitud productview/bySearchTerm, ese perfil es IBM_findProductsBySearchTerm.
<GetUri uri="store/{storeId}/productview/bySearchTerm/{searchTerm}"
                description="Get products by search term based on below search profile."
                searchProfile="IBM_findProductsBySearchTerm,IBM_findProductsByNameOnly,IBM_findProductsByNameAndShortDescriptionOnly,IBM_findProductsByUnstructureOnly,IBM_findProductsBySearchTerm_Summary"/>
Si el controlador de solicitudes acepta la llamada, el servidor de búsqueda utiliza la implementación de Jersey de JAX-RS 2.0 para convertir los pares de nombre-valor en la URL en una forma más utilizable a través de la anotación de Java. Por ejemplo, en ProductViewResource:

@Path("store/{storeId}/productview")
@Description("This class provides RESTful services to get the ProductView details.")
@Encoded
public class ProductViewResource extends AbstractSearchResourceHandler {
Donde la URL store/{storeId}/productview/{partNumber} se correlaciona con el siguiente método en bold:
    @GET
    @Path(BY_PART_NUMBER)
    @Produces({ APPLICATION_JSON })
    @ApiOperation(value = "Gets products by part number.")
    @ApiImplicitParams({
            @ApiImplicitParam(name = PARAMETER_ASSOCIATION_TYPE, value = PARAMETER_ASSOCIATION_TYPE_DESCRIPTION, required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_ATTRIBUTE_KEYWORD, value = PARAMETER_ATTRIBUTE_KEYWORD_DESCRIPTION, required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_CATALOG_ID, value = PARAMETER_CATALOG_ID_DESCRIPTION, required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_CONTRACT_ID, value = PARAMETER_CONTRACT_ID_DESCRIPTION, required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_CURRENCY, value = PARAMETER_CURRENCY_DESCRIPTION, required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_LANG_ID, value = PARAMETER_LANG_ID_DESCRIPTION, required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_CHECK_ENTITLEMENT, value = PARAMETER_ENTITLEMENT_CHECK_DESCRIPTION, required = false, dataType = DATATYPE_BOOLEAN, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_ATTACHEMENT_FILTER, value = PARAMETER_ATTACHMENT_FILTER_DESCRIPTION, required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY),
            @ApiImplicitParam(name = PARAMETER_PROFILE_NAME, value = PARAMETER_PROFILE_NAME_DESCRIPTION,  required = false, dataType = DATATYPE_STRING, paramType = PARAMETER_TYPE_QUERY)})
    @ApiResponses(value = {
            @ApiResponse(code = 200, message = RESPONSE_200_DESCRIPTION),
            @ApiResponse(code = 400, message = RESPONSE_400_DESCRIPTION),
            @ApiResponse(code = 401, message = RESPONSE_401_DESCRIPTION),
            @ApiResponse(code = 403, message = RESPONSE_403_DESCRIPTION),
            @ApiResponse(code = 404, message = RESPONSE_404_DESCRIPTION),
            @ApiResponse(code = 500, message = RESPONSE_500_DESCRIPTION) })
    public Response findProductByPartNumber(
            @ApiParam(value = "The product part number.", required = true) @PathParam(PART_NUMBER) String partNumber) {

Entonces el recurso llama al código de tiempo de ejecución de búsqueda incorporado, que llama al archivo wc-search.xml utilizando los nombres de perfil de búsqueda para buscar el proveedor y los preprocesadores a llamar.wc-search.xml Este método es similar a una línea de ensamblaje de fábrica, donde cada componente de negocio puede aportar su propio fragmento de la expresión de búsqueda a la consulta principal. Después de que el tiempo de ejecución de búsqueda hay construido la consulta Solr final, llama a Solr y procesa la salida utilizando postprocesadores que están definidos en el perfil de búsqueda. A continuación, el manejador REST produce la respuesta.

La expresión de búsqueda está representada por el objeto SearchCriteria, que contiene un conjunto de parámetros de control en forma de correlaciones de parámetros de nombre-valor.

Por ejemplo, el siguiente fragmento de código del archivo trace.log muestra que SolrSearchEDismaxQueryPreProcessor procesa SearchCriteria:trace.log

SolrSearchEDi > com.ibm.commerce.foundation.internal.server.services.search.query.solr.SolrSearchEDismaxQueryPreProcessor 
invoke(SelectionCriteria, Object) ENTRY Search profile: 'IBM_findProductsBySearchTerm', Control parameters: 
'_wcf.search.exclude.type=[],' 'DynamicKitReturnPrice=[true],' '_wcf.search.currency=[USD],' '_wcf.search.manufacturer=[],
' '_wcf.search.runAsId=[-1002],' '_wcf.search.contract=[10001],' '_wcf.search.catalog=[10052],''_wcf.search.catalog=[10052],
''_wcf.search.catalog=[10052],' '_wcf.search.internal.response.format=[json],'

Una vez que se ha compuesto una expresión de búsqueda, el tiempo de ejecución reenvía la solicitud al tiempo de ejecución de Solr incorporado para su proceso.

Si hay parámetros que desea pasar del escaparate, pero no desea especificarlos en el método findProductByPartNumber por ejemplo, puede añadirlo al correlacionador de parámetro de control en el archivo wc-component.xml. Este archivo se correlaciona del par nombre-valor en el parámetro de control en el objeto SearchCriteria.

Modelo de programación de búsqueda

La infraestructura de tiempo de ejecución de búsqueda está controlada por un patrón de programación que es similar a una línea de ensamblaje de fábrica, donde cada componente de negocio puede aportar su propio fragmento de la expresión de búsqueda en la consulta principal, que se ejecuta en el motor de búsqueda de Solr.

El modelo de programación de ejecución de búsqueda utiliza POJO y datos en bruto que se devuelven del servidor de búsqueda para realizar la correlación de par nombre-valor simple:
Modelo de programación de búsqueda
El tiempo de ejecución de búsqueda contiene dos componentes principales: el proveedor de expresiones de búsqueda y el procesador de expresión de búsqueda:
Proveedor de expresión de búsqueda
En función de la naturaleza de la solicitud, es decir, el perfil de búsqueda, es posible que se impliquen otros componentes de negocio, tales como Marketing para reglas de comercialización basadas en búsquedas o contratos para la autorización. Cada componente de negocio es responsable de contribuir con una parte de la expresión de búsqueda, que se combina con la expresión de búsqueda principal generada por los servicios REST de búsqueda.
Como resultado de ello, la expresión de búsqueda consolidada la ejecuta el procesador de búsqueda.
El SolrRESTSearchExpressionProvider predeterminado realiza los siguientes pasos de alto nivel en este orden:
  1. Valida que se proporciona un perfil de búsqueda llamando a SolrSearchProfileNameValidator y se detiene inmediatamente si no se proporciona ninguno.
  2. Valida el nombre de índice correspondiente llamando a SolrSearchIndexNameValidator y se detiene inmediatamente si no es válido.
  3. Valida la información de espacio de trabajo correspondiente llamando a SolrSearchWorkSpaceValidator y establece la información para permitir que el procesador esté informado.
  4. Valida la expresión de búsqueda para asegurarse de que la expresión de consulta no está vacía y no contiene caracteres especiales llamando a SolrSearchExpressionValidator.
  5. Crea una lista de proveedores de expresiones de consulta de búsqueda que están definidos en el perfil de búsqueda donde cada proveedor contribuye con una parte de la expresión de búsqueda.
Procesador de expresiones de búsqueda
Un procesador de búsqueda es la unidad central de proceso para la integración con el motor de búsqueda. Su responsabilidad es ejecutar la expresión Solr, basándose en los atributos de perfil de búsqueda, y capturar la respuesta del motor de búsqueda.
El SolrRESTSearchExpressionProcessor es una implementación predeterminada del procesador de expresión que se define en el archivo SearchExpressionProcessorFactory.properties en el servidor de búsqueda.SearchExpressionProcessorFactory.properties
El SolrRESTSearchExpressionProcessor predeterminado compone la expresión Solr final y configura todos los valores de programa de arranque necesarios para ejecutarlos en el tiempo de ejecución de búsqueda de Solr. El conjunto de resultados se reformatea entonces en un objeto JSON que se debe devolver al llamante.
El procesador de expresión realiza los siguientes pasos de alto nivel en la siguiente secuencia:
  1. Inyecta una opción de parámetro de depuración en el objeto SolrQuery llamando a SolrSearchDebugQueryPreprocessor.
  2. Genera una lista de campos de índice que se incluirán en el conjunto de resultados de búsqueda llamando a SolrSearchResultFieldQueryPreprocessor.
  3. Incluye un grado de relevancia e información de rastreo adicional en el objeto SolrQuery llamando a SolrSearchPreviewQueryPreprocessor.
  4. Habilita la corrección ortográfica e incluye sus opciones de parámetro asociadas en el objeto SolrQuery llamando a SolrSearchSpellCorrectionQueryPreprocessor.
  5. Habilita el resaltado y incluye las opciones de parámetro asociadas en el objeto SolrQuery llamando a SolrSearchHighlighterQueryPreprocessor.
  6. Inyecta opciones de parámetro de paginación en el objeto SolrQuery llamando a SolrSearchPaginationQueryPreprocessor.
  7. Inyecta opciones de parámetro de ordenación en el objeto SolrQuery llamando a SolrSearchSortingQueryPreprocessor.
  8. Compone una lista de campos de faceta, junto con los valores adecuados, que se incluirán en el conjunto de resultados de búsqueda llamando a SolrSearchFacetQueryPreprocessor.
  9. Inyecta la expresión relacionada con consulta dismax llamando a SolrSearchEDismaxQueryPreProcessor porque el manejador eDismax debe producirse antes que la consulta principal porque es posible que sea necesario eliminar el parámetro de control de consulta de impulso.
  10. Inyecta la opción de parámetro de formato de respuesta llamando a SolrSearchResponseFormatQueryPreprocessor.
  11. Inyecta la serie de consulta de búsqueda principal en el objeto SolrQuery llamando a SolrSearchMainQueryPreprocessor.
  12. Inyecta parámetros SolrQuery personalizados adicionales en la expresión de consulta Solr final llamando a SolrSearchCustomQueryPreprocessor.
  13. Crea una lista de preprocesadores de consulta de búsqueda que están definidos en el perfil de búsqueda para permitir modificaciones en el objeto SolrQuery justo antes de que se envíe a Solr para su proceso.
  14. Emite una solicitud a Solr para que procese el objeto SolrQuery.
  15. Crea una lista de postprocesadores de consulta de búsqueda que están definidos en el perfil de búsqueda para permitir modificaciones en el objeto de datos físico, SearchResponse, justo después de que se devuelva QueryResponse desde el servidor Solr.

Se utiliza un preprocesador de consulta para modificar el objeto SolrQuery justo antes de que se envíe al servidor Solr para su proceso.

Se utiliza un posprocesador de consulta para modificar el objeto QueryResponse que se devuelve del servidor Solr.