HCL Commerce Search interactions

HCL Commerce Search comprend plusieurs domaines de service clés, y compris l'architecture du serveur et le modèle de programmation.

Architecture du serveur de recherche

Un chemin d'accès direct à la navigation du site et au serveur de recherche existe sur le serveur de recherche Solr. Ce serveur se compose d'un ensemble de services REST, d'une structure d'exécution de recherche qui réutilise le modèle de programmation de recherche actuel et d'un ensemble de services de base HCL Commerce qui donnent également accès à la base de données HCL Commerce.

Le diagramme suivant montre un aperçu de l'architecture du serveur de recherche :
Diagramme d'interaction de recherche
Où :
  • Le mappeur de service REST est une implémentation Jersey de JAX-RS 2.0 qui utilise des configurations pour mapper une URL REST à une ressource. Cette ressource appelle alors le temps d'exécution de la recherche intégrée.
  • Le temps d'exécution de recherche est une structure de programmation enfichable qui permet d'exécuter des expressions de recherche à l'aide de propriétés définies dans un profil de recherche basé sur la configuration. Une fois qu'une expression de recherche est composée, l'exécution transmet ensuite la requête à l'exécution Solr intégrée pour traitement.
  • Le service de base est le temps d'exécution HCL Commerce principal qui peut fournir des services de serveur de base, tels que le service Query JDBC pour accéder à la base de données HCL Commerce.

Exemple

Lorsque les clients saisissent une requête de recherche dans la vitrine, la requête est traduite en un appel REST. Le modèle utilisé pour générer l'appel se trouve dans le fichier SearchSetup.jspf. Ce modèle, disponible dans la balise <wcf:rest/>, génère l'appel sous forme de chaîne.
<wcf:rest var="catalogNavigationView1" url="${searchHostNamePath}${searchContextPath}/store/${WCParam.storeId}/productview/${restType}">
L'appel REST est soumis au serveur de recherche et intercepté par le gestionnaire de requêtes spécifié dans l'appel (gestionnaire ProductView dans le scénario ci-dessus).  Le gestionnaire de requêtes vérifie le fichier wc-rest-resourceconfig.xml pour confirmer que le profil transmis se trouve dans la liste des profils de recherche définis pour l'URI. Si le profil ne se trouve pas dans la liste définie pour l'URI, une erreur HTTP 400 sera générée.
Si aucun profil de recherche n'est spécifié dans l'URL (&searchProfile=X, le gestionnaire de requêtes utilise le premier profil de recherche défini dans wc-rest-resourceconfig.xml. Par exemple, pour une requête productview/bySearchTerm, ce profil est 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 l'appel est accepté par le gestionnaire de requêtes, le serveur de recherche utilise l'implémentation Jersey de JAX-RS 2.0 pour convertir les paires nom-valeur dans l'URL en une forme plus utilisable via l'annotation Java. Par exemple, dans productViewResource :

@Path("store/{storeId}/productview")
@Description("This class provides RESTful services to get the ProductView details.")
@Encoded
public class ProductViewResource extends AbstractSearchResourceHandler {
Lorsque l'URL store/{storeId}/productview/{partNumber} est mappée à la méthode suivante en gras :
    @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) {

La ressource appelle ensuite le code d'exécution de la recherche intégrée, qui appelle le fichier wc-search.xml en utilisant les noms de profil de recherche pour rechercher le fournisseur et les pré-processeurs à appeler. Cette méthode est similaire à une chaîne de montage d'usine, où chaque composant de l'entreprise peut apporter sa propre partie de l'expression de recherche dans la requête principale. Une fois que le temps d'exécution de recherche construit la requête Solr finale, il appelle Solr et traite la sortie à l'aide de post-processeurs définis dans le profil de recherche. Ensuite, le gestionnaire REST produit la réponse.

L'expression de recherche est représentée par l'objet SearchCriteria, qui contient un ensemble de paramètres de contrôle sous forme de mappes de paramètres de nom-valeur.

Par exemple, le fragment suivant du fichier trace.log montre que la SearchCriteria est traitée par SolrSearchEDismaxQueryPreProcessor :

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],'

Une fois qu'une expression de recherche est composée, l'exécution transmet la requête au temps d'exécution Solr intégré pour traitement.

S'il y a des paramètres que vous souhaitez transmettre à partir de la vitrine, mais que vous ne souhaitez pas les spécifier dans la méthode findProductByPartNumber par exemple, vous pouvez les ajouter au mappeur de paramètres de contrôle dans le fichier wc-component.xml. Ce fichier mappe la paire nom-valeur dans le paramètre de contrôle de l'objet SearchCriteria.

Modèle de programmation de recherche

Cette méthode est similaire à une chaîne de montage d'usine, où chaque composant de l'entreprise peut apporter sa propre partie de l'expression de recherche dans la requête principale, qui est ensuite exécutée au niveau du moteur de recherche Solr.

Le modèle de programmation d'exécution de recherche utilise POJO et des données brutes qui sont renvoyées à partir du serveur de recherche pour effectuer un simple mappage de paires nom-valeur :
Modèle de programmation de recherche
Le temps d'exécution de la recherche contient deux composants principaux : le fournisseur d'expressions de recherche et le processeur d'expressions de recherche :
Fournisseurs d'expressions de recherche
Selon la nature de la requête, c'est-à-dire du profil de recherche, d'autres composants commerciaux peuvent être impliqués, tels que le marketing pour les règles de marchandisage basées sur la recherche ou les contrats d'autorisation. Chaque composant métier est responsable de la contribution d'une partie de l'expression de recherche, qui est combinée avec l'expression de recherche principale générée par les services REST de recherche.
Par conséquent, l'expression de recherche consolidée est exécutée par le processeur de recherches.
La classe SolrRESTSearchExpressionProvider par défaut effectue les étapes de haut niveau suivantes dans l'ordre suivant :
  1. Vérifie qu'un profil de recherche est fourni en appelant SolrSearchProfileNameValidator et s'arrête immédiatement si aucun n'est fourni.
  2. Valide le nom d'index correspondant en appelant SolrSearchIndexNameValidator et s'arrête immédiatement en cas d'invalidation.
  3. Valide les informations correspondantes de l'espace de travail en appelant SolrSearchWorkSpaceValidator et définit les informations pour en informer le processeur.
  4. Valide l'expression de recherche pour s'assurer que l'expression de la requête n'est pas vide et ne contient pas de caractères spéciaux en appelant SolrSearchExpressionValidator.
  5. Crée une liste de fournisseurs d'expressions de requête de recherche définis dans le profil de recherche où chaque fournisseur apporte sa propre partie de l'expression de recherche.
Processeur d'expressions de recherche
Un processeur de recherche est l'unité de traitement centrale pour l'intégration au moteur de recherche. Sa responsabilité est d'exécuter l'expression Solr, basée sur les attributs du profil de recherche, et de capturer la réponse à partir du moteur de recherche.
SolrRESTSearchExpressionProcessor est une implémentation par défaut du processeur d'expression défini dans le fichier SearchExpressionProcessorFactory.properties du serveur de recherche.
La classe SolrRESTSearchExpressionProcessor par défaut compose l'expression Solr finale et définit tous les paramètres d'amorçage nécessaires à l'exécution de la recherche Solr. Le jeu de résultats est ensuite reformaté en un objet JSON pour être renvoyé à l'appelant.
Le processeur d'expressions effectue les étapes de haut niveau suivantes dans la séquence suivante :
  1. Injecte une option de paramètre de débogage dans l'objet SolrQuery en appelant SolrSearchDebugQueryPreprocessor.
  2. Génère une liste de zones d'index à inclure dans le résultat de recherche défini en appelant SolrSearchResultFieldQueryPreprocessor.
  3. Inclut un score de pertinence et des informations de traçage supplémentaires dans l'objet SolrQuery en appelant SolrSearchPreviewQueryPreprocessor.
  4. Active la correction orthographique et inclut les options de paramètres associées dans l'objet SolrQuery en appelant SolrSearchSpellCorrectionQueryPreprocessor.
  5. Active le surligneur et inclut les options de paramètres associées dans l'objet SolrQuery en appelant SolrSearchHighlighterQueryPreprocessor.
  6. Injecte des options de paramètre de pagination dans l'objet SolrQuery en appelant SolrSearchPaginationQueryPreprocessor.
  7. Injecte des options de paramètres de tri dans l'objet SolrQuery en appelant SolrSearchSortingQueryPreprocessor.
  8. Compose une liste de zones de facettes, ainsi que les paramètres appropriés, à inclure dans le jeu de résultats de recherche défini en appelant SolrSearchFacetQueryPreprocessor.
  9. Injecte l'expression dismax liée à la requête en appelant SolrSearchEDismaxQueryPreProcessor car le gestionnaire eDismax doit se produire avant la requête principale. En effet, le paramètre de contrôle de requête de stimulation peut devoir être supprimé.
  10. Injecte l'option de paramètre de format de réponse en appelant SolrSearchResponseFormatQueryPreprocessor.
  11. Injecte la chaîne de requête de recherche principale dans l'objet SolrQuery en appelant SolrSearchMainQueryPreprocessor.
  12. Injecte des paramètres SolrQuery personnalisés supplémentaires dans l'expression de requête Solr finale en appelant SolrSearchCustomQueryPreprocessor.
  13. Crée une liste de pré-processeurs de requêtes de recherche définis dans le profil de recherche pour permettre des modifications au niveau de l'objet SolrQuery juste avant qu'il ne soit envoyé à Solr pour traitement.
  14. Emet une requête au niveau de Solr pour traiter l'objet SolrQuery.
  15. Crée une liste de post-processeurs de requêtes de recherche définis dans le profil de recherche pour permettre d'apporter des modifications à l'objet de données physiques, SearchResponse, juste après le retour de QueryResponse du serveur Solr.

Un pré-processeur de requêtes est utilisé pour modifier l'objet SolrQuery juste avant qu'il ne soit envoyé au serveur Solr pour traitement.

Un post-processeur de requêtes est utilisé pour modifier l'objet QueryResponse qui est renvoyé à partir du serveur Solr.