Bonnes pratiques relatives à l’indexation dans AEM

Comprenez les exigences de recherche et vérifiez si les index prêts à l’emploi peuvent répondre à vos besoins de recherche. Utilisez l’outil de performances des requêtes, disponible sur le SDK local et AEMCS via la Developer Console ou https://author-pXXXX-eYYYY.adobeaemcloud.com/ui#/aem/libs/granite/operations/content/diagnosistools/queryPerformance.html?appId=aemshell.

Définissez une requête optimale, utilisez le graphique de flux optimisation des requêtes et l’aide-mémoire pour les requêtes JCR à titre de référence.

Si les index prêts à l’emploi ne répondent pas aux besoins de recherche, vous disposez de deux options. Toutefois, passez en revue les Conseils pour créer des index efficaces.

• Personnaliser l’index prêt à l’emploi : option préférée, car il est facile de le gérer et de le mettre à niveau.
• Index entièrement personnalisé : uniquement si l’option ci-dessus ne fonctionne pas.

Dans AEMCS, lors de la personnalisation de l’index prêt à l’emploi, utilisez la convention de nommage <OOTBIndexName>-<productVersion>-custom-<customVersion>. Par exemple, cqPageLucene-custom-1 ou damAssetLucene-8-custom-1. Cela permet de fusionner la définition d’index personnalisée chaque fois que l’index prêt à l’emploi est mis à jour. Consultez Modifications apportées aux index prêts à l’emploi pour plus d’informations.

Dans AEM 6.X, la convention de nommage ci-dessus ne fonctionne pas, mais il vous suffit de mettre à jour l’index prêt à l’emploi avec les propriétés nécessaires dans le nœud indexRules.

Copiez toujours la dernière définition d’index prêt à l’emploi de l’instance AEM à l’aide du gestionnaire de packages CRX DE (https://experienceleague.adobe.com/crx/packmgr/?lang=fr), renommez-la et ajoutez des personnalisations dans le fichier XML.

Stockez la définition d’index dans le projet AEM à l’adresse ui.apps/src/main/content/jcr_root/_oak_index et déployez-la à l’aide des pipelines CI/CD Cloud Manager. Consultez Déploiement de définitions d’index personnalisé pour plus d’informations.

Lors de la création d’un index entièrement personnalisé, utilisez la convention de nommage <prefix>.<customIndexName>-<version>-custom-<customVersion>. Par exemple, wknd.adventures-1-custom-1. Cela permet d’éviter les conflits de nommage. Ici, wknd est le préfixe et adventures est le nom d’index personnalisé. Cette convention s’applique à AEM 6.X et AEMCS et permet de préparer une migration future vers AEMCS.

AEMCS ne prend en charge que les index Lucene. Pour préparer une migration ultérieure vers AEMCS, utilisez toujours les index Lucene. Consultez Index Lucene par rapport aux index de propriété pour plus d’informations.

Évitez de créer un index personnalisé sur le même type de nœud que l’index prêt à l’emploi. À la place, personnalisez l’index prêt à l’emploi avec des propriétés nécessaires dans le nœud indexRules. Par exemple, ne créez pas d’index personnalisé sur le type de nœud dam:Asset, mais personnalisez l’index damAssetLucene prêt à l’emploi. Il s’agit d’une cause courante des problèmes de performances et de fonctionnement..

Évitez également d’ajouter plusieurs types de nœud, par exemple cq:Page et cq:Tag, sous le nœud des règles d’indexation (indexRules). Créez plutôt des index distincts pour chaque type de nœud.

Comme mentionné dans la section ci-dessus, stockez la définition d’index dans le projet AEM à l’adresse ui.apps/src/main/content/jcr_root/_oak_index et déployez-la à l’aide des pipelines CI/CD Cloud Manager. Consultez Déploiement de définitions d’index personnalisés pour plus d’informations.

Les directives de définition d’index sont les suivantes :

• Le type de nœud (jcr:primaryType) doit être oak:QueryIndexDefinition.
• Le type d’index (type) doit être lucene.
• La propriété async (async) doit être async,nrt.
• Utilisez includedPaths et évitez la propriété excludedPaths. La valeur queryPaths doit toujours être identique à la valeur includedPaths.
• Pour appliquer la restriction de chemin, utilisez la propriété evaluatePathRestrictions et définissez-la sur true.
• Utilisez la propriété tags pour baliser l’index et, lors de l’interrogation, spécifiez la valeur de ces balises pour utiliser l’index. La syntaxe de requête générale est la suivante : <query> option(index tag <tagName>).

/oak:index/wknd.adventures-1-custom-1
    - jcr:primaryType = "oak:QueryIndexDefinition"
    - type = "lucene"
    - compatVersion = 2
    - async = ["async", "nrt"]
    - includedPaths = ["/content/wknd"]
    - queryPaths = ["/content/wknd"]
    - evaluatePathRestrictions = true
    - tags = ["customAdvSearch"]
...

Gestionnaire d’index disponible à l’adresse http://host:port/libs/granite/operations/content/diagnosistools/indexManager.html pour obtenir des informations d’index telles que le type, la dernière mise à jour, la taille.

Journalisation détaillée des packages Java™ liés à la requête Oak et à l’indexation, comme org.apache.jackrabbit.oak.plugins.index, org.apache.jackrabbit.oak.query et com.day.cq.search via http://host:port/system/console/slinglog pour la résolution des problèmes.

JMX MBean de type IndexStats disponible à l’adresse http://host:port/system/console/jmx pour obtenir des informations d’index telles que le statut, la progression ou les statistiques liées à l’indexation asynchrone. Il fournit également les statistiques FailingIndexStats. En cas d’absence de résultat ici, cela signifie qu’aucun index n’est corrompu. AsyncIndexerService désigne comme corrompu tout index qui ne parvient pas à se mettre à jour pendant 30 minutes (configurable) et arrête son indexation. Si une requête ne donne pas les résultats attendus, l’équipe de développement doit la vérifier avant de poursuivre la réindexation, car cette opération est coûteuse en calcul et prend du temps.

JMX MBean de type LuceneIndex disponible à l’adresse http://host:port/system/console/jmx pour les statistiques de l’index Lucene telles que la taille ou le nombre de documents par définition d’index.

JMX MBean de type QueryStat disponible à l’adresse http://host:port/system/console/jmx pour Oak Query Statistics, y compris les requêtes lentes et populaires avec des détails comme la requête ou le temps d’exécution.