Migration des personnalisations du service Query

Si vous avez examiné les modifications récentes apportées à l'édition du service Query comme décrit dans Mise à jour de vos services Ingest et Query, vous pouvez procéder à la migration de vos personnalisations. Utilisez le guide suivant.

Rechercher dans les profils

Les profils de recherche personnalisés avec le même nom de profil ont une priorité plus élevée que les profils par défaut. Par conséquent, les profils personnalisés sont chargés en premier s'ils sont trouvés dans ZooKeeper, sinon les profils de service Query par défaut sont chargés. Il s'agit de fournir une fonctionnalité de remplacement des profils de recherche.

Les profils par défaut sont présents à l'emplacement ci-dessous dans le conteneur query-service : /opt/WebSphere/Liberty/usr/servers/default/apps/search-query.ear/search-query.war/WEB-INF/classes/profiles

Pour fournir la fonctionnalité d'héritage avec les profils de recherche, le profil défini par rapport à l'attribut parentProfileName est extrait et ses zones sont fusionnées avec le profil actuel. Lors de l'extraction du profil parent, la règle de priorité ZooKeeper mentionnée ci-dessus s'applique toujours.

Pour plus d'informations, voir Configuration de votre profil de recherche personnalisé.

Configurations

La structure (format/notation) de la configuration Matchmaker de couleur a changé dans HCL Commerce version 9.1.7.0. Toutefois, la structure de tous les autres nœuds finaux de configuration (composant, uoms, filtre, etc.) reste la même. Si vous avez ajouté des configurations personnalisées au nœud de configuration couleurs, procédez comme suit pour sauvegarder et fusionner les modifications personnalisées et réappliquer ces configurations :

Pour sauvegarder la configuration de couleurs avant la migration, utilisez le nœud final de configuration de l'API data-query du service Query pour le nœud couleurs.
```
GET http://QUERY_HOSTNAME:
              QUERY_PORT/api/v2/configuration?nodeName=colors&envType=auth&locale=en_US 
```
Vous pouvez enregistrer la réponse de cet appel GET en tant que colors_v916.json.
Après la migration, utilisez le même nœud final de configuration d'API data-query du service Query pour le nœud couleurs afin d'obtenir la dernière configuration de couleurs.
```
GET http://QUERY_HOSTNAME:
              QUERY_PORT/api/v2/configuration?nodeName=colors&envType=auth&locale=en_US 
```
Vous pouvez enregistrer la réponse de cet appel GET en tant que colors_v918.json.
Comparez les deux noms JSON pour fusionner manuellement les modifications. Appliquez-les à nouveau à l'aide de la méthode PATCH sur le nœud final de configuration de l'API data-query pour le nœud couleurs, en fournissant le JSON fusionné final dans le corps.
```
PATCH http://QUERY_HOSTNAME:
              QUERY_PORT/api/v2/configuration?nodeName=colors&envType=auth&locale=en_US 
```
Redémarrez le conteneur query-service.

Note: La version 9.1.6 de la configuration des couleurs sera au format de "light salmon": "red_255", qui a fourni la valeur la plus significative du spectre RVB. Dans la version 9.1.7, le format/la notation a changé pour "light salmon": "[[red],[255,160,122]]" afin de fournir la valeur complète du spectre RVB, et ainsi améliorer la précision de la correspondance des couleurs. Par conséquent, lors de la fusion des modifications de configuration de couleurs personnalisées, les valeurs de spectre de trio RVB complètes doivent être fournies.

Pour plus d'informations, consultez la rubrique Configuration du service Query

Note: Lors de la migration de la version 9.1.8 vers des versions ultérieures, les nœuds finaux d'importation/exportation peuvent être utilisés pour exporter toutes les configurations query-service à importer dans de nouveaux environnements.

Fournisseurs d'expressions personnalisées et processeurs de requête

Si vous avez étendu le service Query en créant des fournisseurs d'expression personnalisés ou des pré ou post-processeurs, assurez-vous de sauvegarder le fichier JAR d'extension avant la migration. Réappliquez les expressions après la migration dans le répertoire d'extension query-service comme décrit dans Extension du service Query.

Note: Les modifications du schéma Elasticsearch ne doivent pas affecter l'API REST V2, mais les modifications du schéma d'index peuvent affecter les pré/post-processeurs de requête personnalisés. Elles doivent être évaluées en fonction des modifications de schéma spécifiques et peuvent nécessiter une restructuration.

Attributs

Pour mettre à niveau les attributs, procédez comme suit :

Dans votre profil personnalisé, remplacez la valeur responseField par attributes.* à attribute.source.
Lors du post-traitement, analysez la chaîne source et affectez les valeurs obtenues aux zones de réponse d'API respectives.

En outre, lors de la recherche ou de l'agrégation, vous pouvez utiliser des zones autres que la source à partir de la zone d'attribut et de facette au niveau de base.