Indexation sans propagation de transfert
Alors que la propagation de transfert est recommandée pour HCL Commerce Search, un serveur d'assurance qualité (QA) peut être utilisé pour tester et prévisualiser des modifications apportées à un environnement autre qu'un environnement de transfert avant la propagation vers la production.
Le diagramme suivant décrit comment un utilisateur professionnel applique les modifications apportées à une configuration sans transfert à l'aide d'un serveur de QA :
Dans ce flux, un utilisateur professionnel applique des modifications à une zone du QA, qui sont ensuite propagées dans l'environnement de production par un administrateur informatique. Voici le processus de haut niveau de ce flux :
- Les modifications de catalogue sont apportées à HCL Commerce via le Centre de gestion ou l'utilitaire Chargement des données dans un environnement de transfert ou de création. Les utilisateurs professionnels testent et prévisualisent tous les changements de cet environnement de préproduction avant de les publier dans les environnements de production. Dans ce scénario, il existe un index de recherche dédié pour l'environnement de QA et la procédure de mise à jour delta pour synchroniser les modifications de catalogue est la même que dans un environnement non QA.
- Une fois que l'utilisateur professionnel est satisfait de ses modifications, les données sont ensuite publiées et envoyées en production par le biais de vos propres procédures internes. La table TI_DELTA_CATENTRY doit être mise à jour en conséquence pendant le chargement des données afin de refléter les produits créés, mis à jour ou supprimés. Cette étape est obligatoire et permet au moteur de recherche d'être informé des produits actualisés dans l'index de recherche.
- Lorsque les données de catalogue et les fichiers d'actifs sont publiés dans le système de production, une génération d'index delta ou complète est requise au niveau du répéteur d'index de recherche. Le répéteur d'index de recherche contient un instantané de la version actuelle de l'index en production. Une fois la première réplication terminée à partir du transfert, le répéteur communique les modifications apportées à ses nœuds subordonnés en production. Cette approche est similaire à l'approche Indexation avec propagation de transfert, sauf que l'index est regénéré en production plutôt que reproduit à partir du transfert. La regénération de l'index de recherche doit être lancée à partir du système de production à l'aide de la commande du planificateur UpdateSearchIndex, ou en invoquant directement le script buildSearchIndex à partir de la ligne de commande par un administrateur informatique.Les considérations suivantes doivent être prises en compte lorsque les données de catalogue et les fichiers d'actifs sont publiés en production :
- La prochaine fois que la commande du planificateur de réindexation est exécutée.
- Le temps approximatif que la réindexation pourrait prendre pour s'achever.
- La prochaine fois que la réplication se produit entre l'index de recherche de production et le répéteur.
- Le temps approximatif que la réplication de l'index pourrait prendre pour s'achever.
- L'invalidation du cache pour la vitrine doit être effectuée avant que les modifications mises à jour ne soient visibles en production. Une invalidation automatisée du cache peut être effectuée à l'aide de l'utilitaire indexprop et du travail du planificateur UpdateSearchIndex.
Apporter les modifications du catalogue directement sur l'environnement de production
Il est possible qu'une plateforme HCL Commerce puisse être déployée sans environnement de transfert et sans serveur de QA pour les tests et les aperçus, les modifications étant plutôt apportées directement dans un environnement de production. En règle générale, ce type de configuration de déploiement se trouve dans les sites Web de petite à moyenne taille. Cette configuration, bien que possible, n'est cependant pas recommandée.