Résoudre les échecs du pipeline AEM as a Cloud Service lors des mises à jour de l’index
Cet article explique comment résoudre les échecs du pipeline AEM as a Cloud Service Cloud Manager qui se produisent pendant l’étape de mise à jour de l’index après le déploiement de définitions d’index personnalisées ou étendues. Ces conseils couvrent les causes courantes et les étapes exploitables pour garantir la réussite des déploiements.
Description description
Environnement
Adobe Experience Manager as a Cloud Service (AEMaaCS)
Problème/Symptômes
- Échecs de pipeline avec des erreurs indiquant des problèmes lors de la récupération de nouvelles définitions d’index
- Avertissements de validation liés aux fichiers de configuration d’index
Cause
Les causes profondes incluent souvent des incohérences entre les définitions d’index personnalisé et les versions d’index prêtes à l’emploi dans l’environnement cible, des configurations Tika incomplètes ou non valides ou des pratiques incorrectes de dénomination et de contrôle de version des index.
Résolution resolution
Suivez les étapes ci-dessous pour résoudre le problème :
- Comparez vos définitions d’index personnalisé aux définitions d’index prêtes à l’emploi dans l’environnement cible. Obtenez la dernière définition d’index prête à l’emploi (par exemple, damAssetLucene-14) à partir d’un environnement AEM as a Cloud Service exécutant la même version ou une version plus récente que l’environnement cible.
- Fusionnez vos modifications personnalisées dans la dernière définition prête à l’emploi et attribuez un nom personnalisé avec version approprié (par exemple, damAssetLucene-14-custom-2). Ne supposez pas que la version prête à l’emploi dans l’environnement de développement correspond à la version dans d’autres environnements.
- Validez la configuration Tika dans la définition d’index personnalisé. Assurez-vous que la sous-arborescence Tika complète est présente et valide, y compris le dossier tika/ , config.xml, jcr:content, jcr:data et jcr:mimeType défini sur application/xml. Évitez les remplacements partiels ou les nœuds config.xml vides.
- Respectez les conventions de nommage d’AEM as a Cloud Service pour les index personnalisés. Pour les index entièrement personnalisés, utilisez un nom et une version personnalisés uniques (par exemple, -custom-1). Pour les extensions d’index prêts à l’emploi, utilisez le modèle de dénomination et de version prêts à l’emploi. Ne renommez pas et ne supprimez pas les nœuds d’index déployés directement dans l’environnement cloud.
- Vérifiez que toutes les définitions d’index se trouvent sous ui.apps/src/main/content/jcr_root/_oak_index et sont incluses dans le package de code de l’application, et non dans un package de contenu modifiable. Assurez-vous que les métadonnées du package incluent allowIndexDefinitions=true et noIntermediateSaves=true. Toutes les définitions d’index doivent utiliser une configuration Lucene compatible avec le cloud et des paramètres asynchrones pris en charge (tels que
[async],[async]nrt ou[fulltext-async]). - Déployez le package révisé dans un environnement inférieur et vérifiez que le déploiement s’est terminé correctement, que les définitions d’index attendues sont présentes et que les requêtes utilisent les index prévus.
- Pour supprimer d’anciennes définitions d’index, ne renommez pas ou ne supprimez pas directement les nœuds d’index. Au lieu de cela, gérez la suppression comme une modification de code distincte via Cloud Manager. La suppression d’entrées du fichier filter.xml seul ne supprime pas les données d’index déployées. Utilisez une définition d’index conforme suivante pour désactiver l’index précédent et le rendre éligible pour un nettoyage périodique.
Après avoir suivi ces étapes, réexécutez le pipeline et vérifiez que le déploiement réussit et que les index prévus sont actifs.