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, voir la section Configurer la réplication et le transport d’utilisateurs et d’utilisatrices 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. La demande entraîne Dispatcher à actualiser le fichier dans le cache lorsque du contenu nouveau est publié.

Procédez comme suit pour configurer un agent de réplication sur l’instance de création d’AEM afin d’invalider le cache de 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 vers les microsites, voir Activation de l’accès aux URL de redirection vers les microsites.

Cette approche présente deux problèmes potentiels :

Invalidation du cache de Dispatcher depuis 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 demande d’invalidation du cache à Dispatcher lorsqu’une page publiée est reçue.

Ces cas incluent :

Le vidage de Dispatcher est contrôlé par un agent de réplication fonctionnant sur l’instance de publication. Cependant, la configuration est effectuée sur 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 purger le cache.

La requête HTTP mène Dispatcher à supprimer des fichiers spécifique du cache. Le Dispatcher actualise ensuite éventuellement le cache avec une nouvelle copie.

Suppression de fichiers mis en cache delete-cached-files

Envoyez une requête HTTP qui entraîne Dispatcher à supprimer des fichiers du cache. 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 supplémentaire CQ-Action-Scope: ResourceOnly. Cela peut être utilisé pour purger des ressources particulières sans invalider d’autres parties du cache, comme les données JSON qui sont créées dynamiquement et nécessitent une purge standard indépendante du cache (par exemple, représenter des données obtenues à partir d’un système tiers pour afficher des actualités, des titres boursiers, etc.).

Suppression et nouvelle mise en cache de fichiers delete-and-recache-files

Émettez une requête HTTP qui mène Dispatcher à supprimer des fichiers mis en cache, puis à récupérer et à remettre immédiatement le fichier en cache. 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.

Remarque : La suppression et la remise en cache ne peuvent être exécutées que sur l’instance Publish. 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 aux pages à remettre en cache immédiatement sont répertoriés sur des lignes distinctes 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 met en œuvre un servlet qui envoie une demande 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 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());
  }
 }
}