Configuration de l'invalidation du cache pour HCL Commerce Search

HCL Commerce fait appel au service de cache dynamique de WebSphere Application Server pour mettre en cache les servlets ou les fichiers JSP ainsi que les instructions provenant de l'interface de WebSphere Application Server, CacheableCommand. Le service de cache dynamique, la mise en cache de servlet et le déchargement sur le disque sont activés par défaut, pendant la création d'une instance de HCL Commerce.

Le service de mise en mémoire cache dynamique comprend les fonctions suivantes :
  • Mémoire cache de résultat de page JSP et de servlet : pour mettre en cache l'intégralité des pages ou des fragments générés par un servlet ou une page JSP.
  • Mémoire cache de commande : pour mettre en cache des objets de commande.
  • Mémoire cache ESI (Edge Side Include) : pour mettre en cache, assembler et fournir des pages Web dynamiques à la frontière d'un réseau d'entreprise.
  • Prise en charge d'invalidation : pour s'assurer que le contenu de la mémoire cache est correct. L'invalidation peut être basée sur les règles, sur le temps, sur un groupe ou programmée.
  • Fonction de déchargement sur le disque : Pour activer la mise en cache de grandes quantités de données.

Vous pouvez automatiser l'invalidation du cache de vitrine pour le contenu mis en cache HCL Commerce à l'aide d'un cache dynamique pendant le processus de réindexation de recherche.

Le comportement du service de cache dynamique de WebSphere Application Server est spécifié par les règles de mise en cache définies par les éléments <cache-entry> dans les fichiers XML (cachespec.xml) de configuration de spécification de mémoire cache.

Procédure

  1. Définissez une stratégie de cache dans cachespec.xml pour un fichier JSP avec l'identificateur de dépendance approprié pour les mises à jour d'index (delta) de recherche d'urgence.
    Par exemple :
    • Pour invalider la page ProductDisplay avec un identificateur d'entrée de catalogue :
      
<dependency-id>ProductDisplay:productId:langId
<component id="" ignore-value="true" type="pathinfo">
<required>true</required>
<value>/ProductDisplay</value>
</component>
<component id="productId" type="parameter">
<required>true</required>
</component>
<component id="DC_lang" type="attribute">
<required>true</required>
</component>
</dependency-id>
    • Pour invalider la page CategoryDisplay avec un identificateur de groupe de catalogues :
      
<dependency-id>CategoryDisplay:categoryId:langId
<component id="" ignore-value="true" type="pathinfo">
<required>true</required>
<value>/CategoryDisplay</value>
<value>/SearchDisplay</value>
</component>
<component id="categoryId" type="parameter">
<required>true</required>
	</component>
<component id="DC_lang" type="attribute">
	<required>true</required>
</component>
</dependency-id>
    • Pour invalider la page TopCategoriesDisplay :
      
<dependency-id>TopCategoriesDisplay:langId
<component id="" ignore-value="true" type="pathinfo">
<required>true</required>
<value>/TopCategoriesDisplay</value>
</component>
<component id="DC_lang" type="attribute">
<required>true</required>
</component>
</dependency-id>
  2. Définissez un identificateur d'invalidation correspondant à générer en fournissant un modèle pour les deux propriétés suivantes dans le fichier wc-component.xml :
    CacheInvalidationForCatalogEntry

    Deux modèles d'invalidation sont fournis avec cette propriété. Le premier modèle consiste à invalider la page ProductDisplay. Le deuxième modèle est utilisé pour invalider ses catégories parent immédiates dans tous les catalogues.

    Les variables de contexte prédéfinies qui peuvent être utilisées dans ce modèle d'identificateur d'invalidation incluent les éléments suivants :
    catEntryId
    Identificateur interne de l'entrée de catalogue modifiée.
    catGroupId
    Identificateur interne de sa catégorie parent immédiate dans tous les catalogues.
    langId
    Identificateur de langue interne pour l'entrée du modificateur.
    storeId
    Identificateur de magasin interne pour l'entrée du modificateur.
    catalogId
    Identificateur de catalogue interne pour l'entrée du modificateur.
    La condition d'invalidation totale :
    
if (cacheInvalidationForCatalogEntry != null
&& cacheInvalidationForCatalogEntry.length() > 0) {
try {
if (ibFullBuild) {
// Full cache invalidation
if (cacheInvalidationForAll != null
&& cacheInvalidationForAll.length() > 0) {
    CacheInvalidationForCatalogGroup
    Deux modèles d'invalidation sont fournis avec cette propriété. Le premier modèle consiste à invalider la page CategoryDisplay pour la catégorie actuelle et toutes ses catégories parent immédiates dans tous les catalogues. Le deuxième modèle est utilisé pour invalider TopCategoriesDisplay, utilisé dans la page Accueil où les catégories concernées peuvent être présentes.
    Les variables de contexte prédéfinies qui peuvent être utilisées dans ce modèle d'identificateur d'invalidation incluent :
    catGroupId
    Identificateur interne du groupe de catalogues modifié et de sa catégorie parent immédiate dans tous les catalogues.
    langId
    Identificateur de langue interne pour l'entrée du modificateur.
    storeId
    Identificateur de magasin interne pour l'entrée du modificateur.
    catalogId
    Identificateur de catalogue interne pour l'entrée du modificateur.
    CacheInvalidationForAll
    Un opérateur spécial d'invalidation de cache pour l'invalidation complète du cache. Lorsque le temps d'exécution de la recherche détermine qu'une invalidation complète du cache est nécessaire et que CacheInvalidationForAll est défini (la valeur par défaut est définie sur clearall), cette valeur est définie dans CACHEIVL.DATA_ID pour demander que tout le cache soit effacé.
    Si cette valeur n'est pas définie ou est laissée comme une chaîne vide ("", aucune invalidation complète du cache n'est effectuée).
    Remarque : Pour permettre l'invalidation complète du cache via la commande du planificateur DynaCacheInvalidationCmd, assurez-vous que enableRefreshRegistry=false est transmis comme l'un des paramètres de travail.
    CacheInvalidationDelay
    Le délai approprié, en millisecondes, avant que l'invalidation du cache ne se produise après chaque réindexation de recherche :
    Pour déterminer un délai raisonnable, il faut tenir compte des facteurs suivants :
    • L'heure de la prochaine exécution de commande du planificateur de réindexation. Par exemple, 5 minutes.
    • Le temps approximatif que la réindexation pourrait prendre pour s'achever. Par exemple, 2 minutes.
    • Le temps de réplication suivant entre l'index de recherche de production et le répéteur. Par exemple, 1 minute.
    • Le temps approximatif que la réplication de l'index pourrait prendre pour s'achever. Par exemple, 3 minutes.
    Dans cet exemple, le délai d'invalidation estimé est le total de 5, 2, 1 et 3 minutes. Cela équivaut à 11 minutes, ou 660 000 millisecondes.
    La valeur par défaut est 0.
    CacheInvalidationForStoreHeader
    Le modèle d'invalidation StoreHeader est utilisé pour automatiser l'invalidation du cache pour le contenu mis en cache en magasin à l'aide de DynaCache dans le cadre de la procédure de réindexation de recherche.
    Les variables de contexte prédéfinies qui peuvent être utilisées dans ce modèle d'identificateur d'invalidation incluent :
    storeId
    Identificateur de magasin interne pour l'entrée du modificateur.
    catalogId
    Identificateur de catalogue interne pour l'entrée du modificateur.
    langId
    Identificateur de langue interne pour l'entrée du modificateur.
    Par exemple :
    Remplacez le fragment par défaut suivant :
    
<_config:property name="CacheInvalidationForCatalogEntry" value="" />
<_config:property name="CacheInvalidationForCatalogGroup" value="" />
    Par le fragment suivant :
    
<_config:property name="CacheInvalidationForCatalogEntry" value="ProductDisplay:productId:langId:$catEntryId$:$langId$" />
<_config:property name="CacheInvalidationForCatalogGroup" value="CategoryDisplay:categoryId:langId:$catGroupId$:$langId$" />

Que faire ensuite

Pour plus d'informations sur la mise en cache dynamique, voir Mise en mémoire cache dynamique.

Après avoir configuré l'invalidation du cache pour HCL Commerce Search, vous pouvez démarrer le processus de réindexation via Génération de l'index de recherche.