Invalider des pages mises en cache depuis AEM invalidating-cached-pages-from-aem

Lors de l’utilisation de Dispatcher avec AEM, vous devez configurer l’interaction pour assurer une gestion efficace du cache. En fonction de votre environnement, la configuration peut également augmenter les performances.

Configuration des comptes d’utilisateur AEM setting-up-aem-user-accounts

Le compte d’utilisateur ou d’utilisatrice admin par défaut est utilisé pour authentifier les agents de réplication qui sont installés par défaut. Vous devez créer un compte d’utilisateur ou d’utilisatrice dédié à utiliser avec des agents de réplication.

Pour plus d’informations, consultez la section Configurer les utilisateurs et utilisatrices de réplication et de transferts de la Liste de contrôle de sécurité AEM.

Invalider le cache de Dispatcher depuis l’environnement de création invalidating-dispatcher-cache-from-the-authoring-environment

Un agent de réplication de l’instance de création AEM envoie une demande d’invalidation du cache à Dispatcher lorsqu’une page est publiée. Dispatcher actualise le fichier dans le cache, le cas échéant, lorsque du nouveau contenu est publié.

Procédez comme suit pour configurer un agent de réplication sur l’instance de création AEM. La configuration invalide le cache du Dispatcher lors de l’activation de la page :

Vous pouvez également accéder à l’agent de purge de Dispatcher et le configurer depuis l’interface utilisateur tactile d’AEM.

Pour plus d’informations sur l’activation d’accès aux URL de redirection, voir Activer un accès aux URL de redirection.

Cette approche présente deux problèmes potentiels :

Invalider le cache de Dispatcher à partir d’une instance de publication invalidating-dispatcher-cache-from-a-publishing-instance

Dans certains cas, vous pouvez améliorer les performances en transférant la gestion des caches de l’environnement de création à une instance de publication. C’est alors l’environnement de publication (et non l’environnement de création AEM) qui envoie une requête d’invalidation du cache à Dispatcher lorsqu’une page publiée est reçue.

Ces cas incluent ce qui suit :

Un agent de réplication opérant sur l’instance de publication contrôle le vidage du Dispatcher. Cependant, la configuration est effectuée dans l’environnement de création, puis transférée en activant l’agent :

Après configuration, lorsque vous activez une page de création à publier, cet agent lance une réplication standard. Le journal comprend des messages indiquant les requêtes provenant de votre serveur de publication, semblables à l’exemple suivant :

Invalider manuellement le cache de Dispatcher manually-invalidating-the-dispatcher-cache

Pour invalider (ou purger) le cache de Dispatcher sans activer de page, vous pouvez émettre une requête HTTP au Dispatcher. Par exemple, vous pouvez créer une application AEM qui permet aux administrateurs et administratrices ou à d’autres applications de vider le cache.

La requête HTTP entraîne la suppression de fichiers spécifiques du cache par le Dispatcher. Le Dispatcher actualise ensuite éventuellement le cache avec une nouvelle copie.

Suppression de fichiers mis en cache delete-cached-files

Cela produit une requête HTTP qui entraîne la suppression de fichiers du cache par le Dispatcher. Dispatcher met à nouveau les fichiers en cache uniquement lorsqu’il reçoit une requête client pour la page. Cette méthode de suppression de fichiers mis en cache convient aux sites web peu susceptibles de recevoir des requêtes simultanées pour la même page.

La requête HTTP se présente comme suit :

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
CQ-Handle: path-pattern
Content-Length: 0

Dispatcher vide (supprime) les fichiers et les dossiers mis en cache dont les noms correspondent à la valeur de l’en-tête CQ-Handler. Par exemple, un CQ-Handle de /content/geomtrixx-outdoors/en correspond aux éléments suivants :

Tous les autres fichiers du cache de Dispatcher (ou jusqu’à un niveau spécifique, en fonction du paramètre /statfileslevel) sont invalidés en modifiant le fichier .stat. La date de dernière modification de ce fichier est comparée à la date de la dernière modification du document mis en cache et le document est à nouveau récupéré si le fichier .stat est plus récent. Pour plus d’informations, voir Invalidation des fichiers par niveau de dossier.

L’invalidation (c’est-à-dire la modification des fichiers .stat) peut être évitée en envoyant un en-tête CQ-Action-Scope: ResourceOnly supplémentaire. Cette fonctionnalité peut être utilisée pour purger des ressources spécifiques. Tout cela sans invalider les autres parties du cache, telles que les données JSON. Ces données sont créées dynamiquement et nécessitent une purge régulière, indépendamment du cache. Par exemple, les données de représentation obtenues à partir d’un système tiers pour afficher des actualités, des titres boursiers, etc.

Supprimer et remettre en cache des fichiers delete-and-recache-files

Cela produit une requête HTTP qui entraîne la suppression de fichiers mis en cache par le Dispatcher, puis leur récupération et leur remise en cache immédiate. Supprimez et remettez immédiatement les fichiers en cache lorsque les sites web sont susceptibles de recevoir des requêtes client simultanées pour la même page. La remise en cache immédiate garantit que Dispatcher récupère et met en cache la page une seule fois, au lieu d’une fois pour chacune des requêtes client simultanées.

Note : la suppression et la remise en cache ne peuvent être exécutées que sur l’instance de publication. En cas d’exécution depuis l’instance de création, des conditions de concurrence se produisent lorsque les tentatives de remise en cache des ressources ont lieu avant leur publication.

La requête HTTP se présente comme suit :

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
`Content-Type: text/plain
CQ-Handle: path-pattern
Content-Length: numchars in bodypage_path0

page_path1
...
page_pathn

Les chemins d’accès des pages à remettre en cache immédiatement sont listés sur des lignes séparées dans le corps du message. La valeur de CQ-Handle est le chemin d’accès d’une page qui invalide les pages à remettre en cache. (Voir le paramètre /statfileslevel de l’élément de configuration Cache). L’exemple de message HTTP suivant supprime et recense les /content/geometrixx-outdoors/en.html page :

POST /dispatcher/invalidate.cache HTTP/1.1
CQ-Action: Activate
Content-Type: text/plain
CQ-Handle: /content/geometrixx-outdoors/en/men.html
Content-Length: 36

/content/geometrixx-outdoors/en.html

Exemple de servlet de purge example-flush-servlet

Le code suivant implémente un servlet qui envoie une requête d’invalidation à Dispatcher. Le servlet reçoit un message de requête contenant les paramètres handle et page. Ces paramètres fournissent la valeur de l’en-tête CQ-Handle et le chemin d’accès à la page à remettre en cache, respectivement. Le servlet utilise les valeurs pour construire la requête HTTP pour Dispatcher.

Lorsque le servlet est déployé sur l’instance de publication, l’URL suivante oblige le Dispatcher à supprimer la page /content/geometrixx-outdoors/en.html, puis à mettre en cache une nouvelle copie.

10.36.79.223:4503/bin/flushcache/html?page=/content/geometrixx-outdoors/en.html&handle=/content/geometrixx-outdoors/en/men.html

package com.adobe.example;

import org.apache.felix.scr.annotations.Component;
import org.apache.felix.scr.annotations.Service;
import org.apache.felix.scr.annotations.Property;

import org.apache.sling.api.SlingHttpServletRequest;
import org.apache.sling.api.SlingHttpServletResponse;
import org.apache.sling.api.servlets.SlingSafeMethodsServlet;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

import org.apache.commons.httpclient.*;
import org.apache.commons.httpclient.methods.PostMethod;
import org.apache.commons.httpclient.methods.StringRequestEntity;

@Component(metatype=true)
@Service
public class Flushcache extends SlingSafeMethodsServlet {

 @Property(value="/bin/flushcache")
 static final String SERVLET_PATH="sling.servlet.paths";

 private Logger logger = LoggerFactory.getLogger(this.getClass());

 public void doGet(SlingHttpServletRequest request, SlingHttpServletResponse response) {
  try{
      //retrieve the request parameters
      String handle = request.getParameter("handle");
      String page = request.getParameter("page");

      //hard-coding connection properties is a bad practice, but is done here to simplify the example
      String server = "localhost";
      String uri = "/dispatcher/invalidate.cache";

      HttpClient client = new HttpClient();

      PostMethod post = new PostMethod("https://"+host+uri);
      post.setRequestHeader("CQ-Action", "Activate");
      post.setRequestHeader("CQ-Handle",handle);

      StringRequestEntity body = new StringRequestEntity(page,null,null);
      post.setRequestEntity(body);
      post.setRequestHeader("Content-length", String.valueOf(body.getContentLength()));
      client.executeMethod(post);
      post.releaseConnection();
      //log the results
      logger.info("result: " + post.getResponseBodyAsString());
      }
  }catch(Exception e){
      logger.error("Flushcache servlet exception: " + e.getMessage());
  }
 }
}