Des mises à jour du service Query ont été effectuées pour HCL Commerce versions 9.1.7 et 9.1.8. Consultez ce document pour effectuer une mise à niveau à partir des versions précédentes.
Version 9.1.7 - Modifications du service Query
- i. Profil de recherche
- Les profils de recherche ne sont applicables que lorsque le regroupement est activé. Auparavant, il y avait des références de code de nom de profil de recherche codées en dur. Le remplacement de ces profils de recherche a entraîné l'expression du comportement personnalisé dans tous les scénarios référençant le profil.
- Par exemple, auparavant, HCL_findCatalogEntryById était codé en dur pour les scénarios de recherche de termes et de navigation. Si ce profil de recherche a été remplacé, le nouveau comportement a été exprimé à la fois dans les scénarios de recherche de termes et de navigation sans aucun moyen d'isoler la personnalisation. Le profil de recherche a été introduit pour permettre un remplacement du profil par n'importe quel nom. Le code recherche d'abord le profil de recherche, au lieu d'utiliser le profil codé en dur.
- Cette amélioration fonctionnelle introduit un nouvel attribut lookupProfileName facultatif dans le profil de recherche. Les profils de remplacement personnalisés fonctionneront toujours tels quels. Voir l'exemple de profil de recherche personnalisé suivant qui fait référence à un profil de recherche :
- Créer un profil personnalisé
Si vous souhaitez trouver un article de stock spécifique, ajoutez une zone de réponse dans le profil personnalisé qui spécifie le numéro de stock en tant que
inventories.10501.quantity.
{
"parentProfileName": "HCL_findProductsBySearchTerm",
"profileName": "X_findProductsBySearchTerm",
"lookupProfileName": "X_findCatalogEntryById",
"query": {
"responseFields": [
"inventories.10501.quantity",
“workspaceName”
]
}
}
- Créer un profil de recherche
{
"parentProfileName": "HCL_findCatalogEntryById",
"profileName": "X_findCatalogEntryById",
"query": {
"responseFields": [
"inventories.10501.quantity"
]
}
}
Pour plus d'informations sur les profils de recherche, voir Zones de stock et personnalisées dans un profil de recherche personnalisé.
- ii. Profils de recherche V2
- Dans les versions précédentes, Search utilisait les mêmes profils de recherche pour les vitrines Aurora et React (Emerald/Sapphire). Cela a entraîné le même comportement pour les vitrines Aurora et React lorsqu'un profil était remplacé. Dans la version 9.1.7, les profils de recherche ont été séparés en profils V1 et V2 pour s'aligner sur l'API REST du service Query V1 et V2. Les profils de recherche V2 sont destinés à être utilisés avec les vitrines React, qui nécessitent l'API REST V2. Les profils de recherche V1 sont utilisés avec l'API REST V1.
- Si vous utilisez l'API REST V2, il est recommandé d'utiliser des profils de recherche V2 afin de rester aligné avec l'évolution de l'API REST V2.
- Vous pouvez trouver des exemples de profils V2 dans Rechercher dans les profils.
- iii. Contrôle d'accès pour les nœuds finaux de configuration du service Query
- L'authentification a été introduite pour protéger les nœuds finaux de configuration (admin) data-query. Le service data-query possède des nœuds finaux de configuration, alors que les requêtes auth-query et live-query servent uniquement les nœuds finaux de l'API REST de vitrine. Auth-query et live-query servent les API REST de vitrine pour la navigation pour les clients et ces nœuds finaux d'API ne nécessitent pas de contrôle d'accès.
-
Note: Lorsque vous accédez aux nœuds finaux via auth-query et live-query, il n'y a pas d'impact du point de vue de la migration. Toutefois, l'accès aux nœuds finaux de l'API de configuration via data-query nécessite désormais un en-tête d'authentification avec SPIUSER et un mot de passe dans la requête.
Version 9.1.8 - Modifications du service Query
- Profil de traitement du langage naturel (NLP)
- Une nouvelle fonction de profil NLP a été introduite dans la version 9.1.8 pour fournir une méthode de contrôle du flux de prétraitement des termes de recherche avant l'exécution d'une requête Elasticsearch. Ces profils NLP peuvent être créés au niveau du magasin.
- Avant la version 9.1.8, une logique complète pour NLP, telle que PartNumber, CurrencySymbol, DMM, Color Matchmaker, etc., était présente dans la classe com.hcl.commerce.search.internal.expression.provider.SearchNLPSupportProvider. Cette logique a été déplacée vers des classes auxiliaires distinctes et externalisée sous la forme de profils NLP afin de faciliter la personnalisation dans la structure d'extension.
Note: Cette amélioration fonctionnelle n'a aucun impact sur la migration, car il s'agit d'une restructuration interne du code. Elle ne modifie pas le comportement existant de NLP.
Pour plus d'informations sur les profils de NLP, voir Profil du processeur de langage naturel.
Mise à niveau vers le service Query version 9.1.12
Lors de la mise à niveau vers HCL Commerce Search version 9.1.12.0, effectuez une réindexation complète afin que la nouvelle fonction d'association de termes de recherche (STA) analyse à nouveau correctement les termes STA.
