Vous consultez actuellement l'aide de la version:

Présentation

Dans les versions antérieures à AEM 6.4, le code client était déployé dans des zones imprévisibles du référentiel JCR, lesquelles pouvaient donc varier lors des mises à niveau.C’est pourquoi il n’était pas rare que les versions formelles d’AEM (Versions majeures, Feature Packs, Service Packs ou Correctifs logiciels) écrasent le contenu, la configuration ou le code personnalisé. En outre, il arrivait parfois que les modifications utilisateurs écrasent le contenu ou le code de produit AEM, empêchant le fonctionnement du produit.

Ces conflits ne pouvaient pas toujours être résolus automatiquement. Leur signalement demandait un temps considérable et leur résolution (qui n’était pas toujours simple) nécessitait une intervention humaine. Il est possible d’éviter ces conflits en définissant clairement les hiérarchies applicables au code du produit AEM et au code client. 

À cette fin, à compter d’AEM 6.4, le contenu, qui se trouvait jusqu’alors dans /etc, sera placé dans d’autres dossiers du référentiel, et des directives relatives à la destination des différentscontenus seront appliquées,conformément aux règles de haut niveau suivantes :

  • Le code de produit AEM sera toujours placé dans /libs, qui ne peut pas être écrasé par du code personnalisé.
  • Le codepersonnalisé doit être placé dans /apps, /content et /conf.

Cet article est composé de trois sections qui représentent le type de contenu qui a été déplacé hors de /etc :

  1. Configuration
  2. Bibliothèques côté client
  3. Divers

Chaque section comprend les éléments suivants :

  • Un tableau avec les emplacements restructurés et du contenu supplémentaire. Il est prévu, à court terme, de formater les tableaux avec une structure plus aplatie afin d’en améliorer la lisibilité.
  • Une stratégie d’extensibilité permettant au code personnalisé d’étendre le code d’application AEM résidant sous /libs.

Compatibilité descendante

Dans la plupart des cas,la compatibilité descendanteavec les emplacements précédents est conservée après la mise à niveau vers AEM 6.4.Pour y parvenir, les emplacements précédents sont conservés et respectés par le code de produit, en plus de l’ajout des nouveaux emplacements. Dans la plupart des cas, la logique conditionnelle est utilisée pour vérifier l’existence du dossier hérité et pour lire à partir de cet emplacement plutôt que du nouvel emplacement.

Après avoir effectué la mise à niveau vers la version 6.4, les utilisateurs sont invités, selon leur propre calendrier, à supprimer les emplacements précédents, de sorte que le contenu des nouveaux emplacements soit utilisé. Le tableau ci-dessousprésenteles instructions à suivre pour respecter la nouvelle structure de contenu par emplacement.

Remarque :

Une instance mise à niveau statique comprend les anciens emplacements de contenu en plus des nouveaux emplacements. Une nouvelle installation développeur ne contient que les nouveaux emplacements.

Comment lire les tableaux

Dans chaque section, le tableau se compose des éléments suivants :
  • La solution AEM (Sites, Assets, Forms, etc.) pour laquelle ce contenu est pertinent.
  • L’ancien emplacement (versions 6.3 et antérieures).
  • Le nouvel emplacement 6.4.
  • Instructions à suivre pour s’aligner sur la nouvelle structure de contenu. Par exemple, il peut s’avérer nécessaire d’exécuter un script ou de déplacer des fichiers manuellement dans les semaines ou les mois qui suivent une mise à niveau vers la version 6.4.
  • La méthode utilisée par AEM pour garantir la rétrocompatibilité des anciens emplacements de contenu pour les clients qui mettent à niveau une version antérieure vers la version AEM 6.4.

Configuration

Les emplacements de contenu de cette section font généralement référence au contenu résidant dans un dossier /settings sous /libs, /apps ou /conf.

Stratégie d’extensibilité

À quelques exceptions près, le contenu de cette section peut être étendu à l’aide de la fonctionnalité Context-AwareConfiguration d’Apache Sling.

En résumé,Context-AwareConfiguration permet de recouvrir plusieurs fois le contenu d’une partie du référentiel par le contenu d’autres parties du référentiel. Par exemple, le contenu de /libs peut être recouvert par lecontenude /apps qui peut, à son tour, être recouvert par lecontenude /conf. De plus, le contenu d’un dossier global sous /conf peut être recouvert par un « locataire » ou « site » spécifique (par exemple : /conf/we-retail/settings). 

En règle générale, la fonctionnalitéContext-AwareConfiguration est utilisée comme une stratégie d’extension des configurations de fonctionnalité. Cependant, il est des cas où elle est utilisée par d’autres types de contenu.

Le tableau ci-dessous contient une colonne supplémentaire, intitulée « Type de configuration », qui explique dans quelle mesure uneconfigurationpeut être recouverte. Voici quelques informations supplémentaires sur ces types de configuration :

not context-aware

  • Il se trouve que les ressources résident dans des structures de dossiers basées sur le contexte (comme /libs/settings), mais elles sont toujours référencées par le biais d’un chemin d’accès absolu, de sorte que la sensibilité au contexte ne soit pas appliquée.
  • Les ressources peuvent se trouver n’importe où. Les licences DRM Assets, par exemple, peuvent se trouver à l’emplacement suivant : /content/my-customer/licenses/creative-commons.html.
  • Exemples :
    • Scripts de workflow -> /apps/settings/workflow/scripts/noop.ecma
    • Licences DRM Assets -> /apps/settings/dam/drm/my-license

only global

  • Fonctionnalité avec la configuration only global
  • Comme point de référence, appliquez la priorité des paramètres de l’exemple suivant: /libs/settings < /apps/settings < /conf/global
  • AEM prend en charge la configuration only global, et non les configurations basées sur le locataire.
  • AEM commence toujours par rechercher les configurations au niveau /conf/global.
  • Exemples :
    • Lanceurs de workflow -> /libs/settings/workflow/launcher
    • Modèles de workflow -> /conf/global/settings/workflow/models

tenant-aware

  • Pour les configurations basées sur le locataire (tenant-aware), reportez-vous à cet exemple pour connaître la priorité des chemins de configuration : /libs/settings < /apps/settings < /conf/global < /conf/we-retail, où we-retail est le nom du locataire. Les configurations basées sur le locataire prennent également en charge les sous-locataires.
  • AEM prend en charge les configurations basées sur le locataire. Il respecte la propriété cq:conf sur la hiérarchie.
  • Exemples :
    • Modèles modifiables -> /conf/we-retail/settings/wcm/templates
    • Configurations cloud -> /conf/we-retail/settings/cloudsettings
Solution Emplacement précédent
Nouvel emplacement Type de configuration Context-Aware
Méthode de compatibilité descendante Conditions requises pour s’aligner sur le modèle le plus récent
AEM Sites / AEM Forms

/etc/cloudservices/typekit

/etc/cloudservices/recaptcha

/etc/cloudservices/echosign

/conf/<tenant>/settings/cloudconfigs/typekit

/conf/<tenant>/settings/cloudconfigs/recaptcha

/conf/<tenant>/settings/cloudconfigs/echosign

tenant-aware

Services cloud hérités.

Conservés lors d’une mise à niveau statique. Le code permettant de les lister et de les lire est toujours présent dans AEM comme solution de secours.

L’utilitaire de migration différée du contenu peut être déclenché par l’interface de migration de Forms afin d’effectuer une conversion automatique vers le nouveau chemin d’accès.
AEM Forms /etc/cloudservices/fdm /conf/<tenant>/settings/cloudconfigs/fdm tenant-aware

Services cloud hérités.

Conservés sur une configuration mise à niveau statique. Le code permettant de les lister et de les lire est toujours présent dans AEM comme solution de secours.

L’utilitaire de migration différée du contenu peut être déclenché par l’interface de migration de Forms afin d’effectuer une conversion automatique vers le nouveau chemin d’accès.
AEM Assets /etc/dam/adhocassetshare /libs/settings/dam/adhocassetshare tenant-aware Les structures de contenu héritées se voient accorder une priorité plus élevée que les nouvelles structures prêtes à l’emploi. Les personnalisations au niveau du projet doivent être coupées et collées dans les emplacements /apps ou /conf équivalents, suivant le cas.
AEM Assets /etc/dam/workflow/notification/email/downloadasset /libs/settings/dam/workflow tenant-aware Les structures de contenu héritées se voient accorder une priorité plus élevée que les nouvelles structures prêtes à l’emploi. Les personnalisations au niveau du projet doivent être coupées et collées dans les emplacements /apps ou /conf équivalents, suivant le cas.
AEM Assets /etc/dam/drm/licenses/ /libs/settings/dam/drm not context-aware Les structures de contenu héritées se voient accorder une priorité plus élevée que les nouvelles structures prêtes à l’emploi. Les personnalisations au niveau du projet doivent être coupées et collées dans les emplacements /apps ou /conf équivalents, suivant le cas.
AEM Assets /etc/dam/indesign/scripts /libs/settings/dam/indesign tenant-aware Les structures de contenu héritées se voient accorder une priorité plus élevée que les nouvelles structures prêtes à l’emploi.

Les personnalisations au niveau du projet doivent être coupées et collées dans les emplacements /apps ou /conf équivalents, suivant le cas.

Lors de l’exécution du workflow d’assimilation des ressources personnalisé, les références à l’ancien emplacement sous /etc subsistent dans la configuration du processus d’extraction des médias. Parallèlement au déplacement des scripts du dossier /etc vers les emplacements /apps et /conf équivalents, il convient de modifier les arguments du processus d’extraction des médias personnalisé (en définissant des chemins d’accès relatifs au lieu des chemins absolus), afin de tenir compte des modifications.

Pour plus d’informations, consultez cette page.

 

AEM Assets /etc/dam/video /libs/settings/dam/video tenant-aware Les structures de contenu héritées se voient accorder une priorité plus élevée que les nouvelles structures prêtes à l’emploi. Les personnalisations au niveau du projet doivent être coupées et collées dans les emplacements /apps ou /conf équivalents, suivant le cas.
Tous /etc/notification/email/default /libs/settings/dam/notification tenant-aware Les structures de contenu héritées se voient accorder une priorité plus élevée que les nouvelles structures prêtes à l’emploi. Les personnalisations au niveau du projet doivent être coupées et collées dans les emplacements /apps ou /conf équivalents, suivant le cas.
AEM Sites / AEM Assets /etc/designs
/libs/settings/wcm/designs not context-aware

Les Consuming Services ont connaissance de l’emplacement précédent.

Les configurations de l’emplacement hérité sont prises en compte.


Déplacez le contenu personnalisé de /etc/design vers /apps/settings/wcm/design pour vous aligner sur la nouvelle structure du référentiel. Par la suite, pensez à mettre à niveau vos sites afin d’utiliser la fonctionnalité des modèles modifiables, laquelle rend inutiles le mode de conception et donc ce contenu.
AEM Sites /etc/scaffolding

/libs/settings/wcm/template-types/scaffolding/scaffolding

/apps/settings/wcm/template-types/scaffolding/scaffolding

not context-aware Les composants résidant à l’emplacement précédent sous /etc/scaffolding continueront de fonctionner, bien qu’ils soient désormais obsolètes. Adobe vous recommande d’utiliser les nouveaux composants de structure (scaffolding) sous le nouvel emplacement.
AEM Sites /etc/blueprints

/libs/msm pour les configurations de plans directeurs Screens et Commerce prêtes à l’emploi.

 

not context-aware

Les Consuming Services ont connaissance de l’emplacement précédent.

Les configurations de l’emplacement hérité sont prises en compte.

Les configurations doivent être copiées sur les nouveaux emplacements.
AEM Sites /etc/mobile /libs/settings/mobile tenant-aware La fonctionnalité tire parti du Gestionnaire de configuration et prend toujours en charge l’ancien emplacement comme solution de secours.
  1. Transférez les configurations de /etc vers /conf/<tenant>/settings/mobile.
  2. Ensuite, mettez à jour la référence dans le contenu comme suit :

/content/<tenant>/jcr:content/cq:deviceGroups{String[]}=mobile/groups/responsive

AEM Sites /etc/msm/rolloutConfigs /libs/msm/wcm/rolloutconfigs N/D

Les Consuming Services ont connaissance de l’emplacement précédent.

Si des configurations sont détectées dans l’emplacement hérité, elles sont utilisées.

Pour se conformer au nouveau modèle, des configurations doivent être créées aux nouveaux emplacements, tandis que les anciennes configurations sous /etc doivent être supprimées.
AEM Sites /etc/segmentation/contexthub /conf/we-retail/settings/wcm/segments tenant-aware

Les segments issus de l’ancien emplacement :

  • restent en mode lecture seule dans la console Audiences ;
  • sont toujours chargés sur la page (si le chemin d’accès donné est sélectionné dans Propriétés de page > Personnalisation > Chemin d’accès de segments) ;
  • peuvent être utilisés pour le ciblage de contenu.
Vous pouvez utiliser l’outil de migration de segments pour effectuer une migration vers le nouvel emplacement.
AEM Communities /etc/social/config/languageOpts /libs/social/translation/languageOpts N/D    
AEM Communities /etc/community/templates /libs/settings/community/templates  

Le code connaît l’emplacement de l’ancien modèle. Les modèles existants continueront à être référencés et lus/écrits à partir de /etc.


S’agissant des modèles de courrier électronique, si le client avait déjà défini ses modèles personnalisés à un autre emplacement en configurant le chemin d’accès Racine des modèles dans la Configuration de réponse électronique d’AEM Communities, aucun changement n’est à signaler.

Un utilitaire de migration peut s’aligner sur le modèle AEM Communities le plus récent.

AEM Communities /etc/community/badging

Règles de badge :

/libs/settings/community/badging

Images de badge :

Les images prêtes à l’emploi situées à l’ancien emplacement /etc/community/badging/images sont transférées vers /libs/community/badging/images

 

Les images personnalisées sont transférées vers /content/community/badging/images.

 

tenant-aware

Le code connaît les anciens chemins d’attribution de badges.


Il vérifie d’abord l’existence de chemins plus anciens.
S’il n’en existe pas, il utilise les nouveaux.

Une migration manuelle est requise pour une mise en conformité avec le modèle le plus récent. Pour ce faire, procédez comme suit :

  1. Créez un compartiment contextuel de site à l’aide de l’explorateur de configuration sous Outils.
  2. Accédez à la racine du site.
  3. Définissez la propriété cq:conf sur le chemin d’accès du compartiment où vous souhaitez stocker toutes les configurations. Vous pouvez obtenir le même résultat en utilisant Assistant d’édition de site - Définir l’entrée de configuration cloud, puis en enregistrant les modifications.
  4. Déplacez les règles de notation et d’attribution de badges appropriées depuis etc/community/* vers le compartiment contextuel de site approprié créé à l’étape précédente.
  5. Modifiez les propriétés badgingRules et scoringRules à la racine du site pour qu’elles présentent des références relatives vers les nouveaux emplacements de règles. À titre d’exemple, si cq:conf est défini sur /conf/we-retail, la valeur de badgingRules sera community/badging/rules si les règles sont transférées vers ce nouveau compartiment.
  6. De même, configurez les références aux règles de notation dans un nœud de règle d’attribution de badges pour qu’elles aient un chemin d’accès relatif.
AEM Sites

/etc/cloudservices/facebookconnect

/etc/cloudservices/twitterconnect

/etc/cloudservices/pinterestconnect

/conf/<tenant>/settings/cloudconfigs/facebookconnect

/conf/<tenant>/settings/cloudconfigs/twitterconnect

/conf/<tenant>/settings/cloudconfigs/pinterestconnect

tenant-aware    
AEM Communities /etc/community/scoring /libs/settings/community/scoring  

Le code connaît les anciens chemins d’attribution de badges.


Il vérifie d’abord l’existence de chemins plus anciens
. S’il n’en existe pas, il utilise les nouveaux.

Des étapes de migration manuelle doivent être exécutées pour une mise en conformité avec le modèle le plus récent.

Elles sont identiques à celles des règles d’attribution de badges ci-dessus.

AEM Communities /etc/community/notifications /libs/settings/community/notifications not context-aware

Ces configurations ne sont pas rétrocompatibles. Reportez-vous à la colonne « Conditions requises pour une mise en conformité avec le modèle le plus récent » pour connaître la procédure de migration vers les nouveaux emplacements.


Une migration manuelle est requise pour une mise en conformité avec le modèle le plus récent. Vous pouvez utiliser le Gestionnaire de configuration Granite pour déplacer les configurations vers le nouvel emplacement sous /apps/settings.

Vous devez donc définir la propriété mergeList sur true sur le nœud /libs/settings/community/subscriptions, puis ajouter un nœud enfant nt:unstructured.

AEM Communities /etc/community/subscriptions /libs/settings/community/subscriptions not context-aware Ces configurations ne sont pas rétrocompatibles. Reportez-vous à la colonne « Conditions requises pour une mise en conformité avec le modèle le plus récent » pour connaître la procédure de migration vers les nouveaux emplacements.

Une migration manuelle est requise pour une mise en conformité avec le modèle le plus récent. Vous pouvez utiliser le Gestionnaire de configuration Granite pour déplacer les configurations vers le nouvel emplacement sous /apps/settings.

Vous devez donc définir la propriété mergeList sur true sur le nœud /libs/settings/community/subscriptions, puis ajouter un nœud enfant nt:unstructured.

AEM Communities /etc/socialconfig/srpc/defaultconfiguration /conf/global/settings/community/srpc/defaultconfiguration global Ces configurations sont rétrocompatibles. Si les anciens chemins d’accès sont détectés, ils sont utilisés. Dans le cas contraire, les nouveaux chemins d’accès sont prioritaires.

La tâche de migration différée du contenu est disponible sous la forme CQ64CommunitiesConfigsCleanupTask.

Pour plus d’informations, consultez la documentation de la migration différée.

AEM Communities /etc/watchwords /libs/community/watchwords N/D Ces configurations sont rétrocompatibles. Si les anciens chemins d’accès sont détectés, ils sont utilisés. Dans le cas contraire, les nouveaux chemins d’accès sont prioritaires.

La tâche de migration différée du contenu est disponible sous la forme CQ64CommunitiesConfigsCleanupTask.

Les mots-clés devront être déplacés manuellement de /etc/watchwords vers /conf/global/settings/community/watchwords.

Tous /etc/workflow/models

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

global

L’emplacement hérité est utilisé s’il est présent et s’il n’existe aucune configuration dans /libs ni dans /conf.

Lors de la modification de modèles de workflow prêts à l’emploi, des incrustations basées sur le contexte doivent être créées sous /conf pour les rendre modifiables.

Une exportation de module doit inclure le modèle dans /libs ou /conf, et le modèle d’exécution dans /var/workflow/models.

De nouveaux modèles seront créés à l’emplacement /conf/global/settings.

Avant d’effectuer une quelconque modification dans /etc ou /libs, vous devez créer explicitement un remplacement dans /conf/global/settings. Le bouton Modifier doit être sélectionné. Cela entraînera la création du remplacement dans /conf et permettra la modification.

Tous /etc/workflow/launcher

/libs/settings/workflow/launcher

/conf/global/settings/workflow/launcher

global L’emplacement hérité est utilisé s’il est présent et s’il n’existe aucune configuration
dans /libs ni dans /conf. De cette manière, les lanceurs personnalisés sont conservés.

Les configurations de lanceur qui viennent d’être créées ou modifiées se trouvent sous /conf.

Tous les lanceurs doivent être transférés de l’emplacement /etc hérité vers /conf/global/settings/workflow/launcher.

Tous /etc/workflow/models

/libs/settings/workflow/models

/conf/global/settings/workflow/models

global L’emplacement hérité est utilisé s’il est présent et s’il n’existe aucune configuration
dans /libs ni dans /conf. De cette manière, les modèles de workflow personnalisés sont conservés.

Tous les modèles de workflow doivent être transférés de l’emplacement /etc hérité vers/conf/global/settings/workflow/models.

 

Tous /etc/workflow/notification

/libs/settings/workflow/notification

/conf/global/settings/workflow/notification

not context-aware

S’il est présent, l’emplacement hérité est utilisé à des fins de compatibilité descendante.

Auparavant, les modèles prêts à l’emploi devaient être écrasés par le biais d’une modification dans /etc. Désormais, le remplacement doit être stocké dans /conf/global.

Pour plus d’informations, consultez la documentation des workflows.
Tous /etc/cloudservices/translation

/libs/settings/cloudconfigs/translation/translationcfg

/conf/<tenant>/settings/cloudconfigs/translation/translationcfg

 

tenant-aware Services cloud hérités. Seront conservés sur une configuration mise à niveau statique. Le code permettant de les lister et de les lire est toujours présent dans le produit comme solution de secours.

Pour déplacer des configurations de cloud vers /conf, vous pouvez effectuer l’une des opérations suivantes :

  • Créer des configurations à l’aide de la nouvelle interface utilisateur tactile
    ou
  • Copier les configurations depuis /etc/cloudservices/translation vers le ou les nouveaux emplacements appropriés

Une fois cette opération effectuée, les configurations doivent être associées à AEM Sites en sélectionnant Sites → Propriétés dans l’interface utilisateur.

Remarque : Pour que cela fonctionne, les connecteurs de traduction doivent être compatibles avec AEM 6.4.

Tous /etc/cloudservices/msft-translation

/libs/settings/cloudconfigs/translation/msft-translation

/conf/<tenant>/settings/cloudconfigs/translation/msft-translation

tenant-aware Services cloud hérités. Seront conservés sur une configuration mise à niveau statique. Le code permettant de les lister et de les lire est toujours présent dans le produit comme solution de secours.

Pour déplacer des configurations de cloud vers /conf, vous pouvez effectuer l’une des opérations suivantes :

  • Créer des configurations à l’aide de la nouvelle interface utilisateur tactile ou
  • Copier les configurations précédentes depuis /etc/cloudservices/translation vers le ou les nouveaux emplacements appropriés

Une fois cette opération effectuée, les configurations doivent être associées à AEM Sites en sélectionnant Sites → Propriétés dans l’interface utilisateur.

Tous /etc/cloudsettings

/libs/settings/cloudsettings

/conf/<tenant>/settings/cloudsettings

tenant-aware

Les entrées existantes sous /etc restent en place lors de la mise à niveau de l’instance.

Si vous accédez à l’interface utilisateur des paramètres de cloud après la mise à niveau, les paramètres de cloud existants sont copiés dans la nouvelle structure de référentiel, tout en conservant le contenu existant à des fins de compatibilité descendante.

Les modèles de contenu sont les mêmes. Seul l’emplacement a été modifié pour s’aligner sur les configurations sensibles au contexte (Context-Aware).

La tâche de migration différée portant sur ces paramètres de cloud effectue les opérations suivantes :

  • Copier les paramètres de cloud existants situés sous /etc/cloudsettings vers /conf/global/settings/cloudsettings.
  • Supprimez tous les enfants sous /etc/cloudsettings.

Quelques étapes manuelles doivent toutefois être effectuées après la mise à niveau et avant d’exécuter les tâches de migration différée :

  • Toutes les références pointant vers /etc/cloudsettings/* doivent être mises à jour pour pointer vers /conf/global.

Avertissement :

  • Le conteneur /etc/cloudsettings doit être conservé.
AEM Assets /etc/cloudservices/dmscene7 /conf/global/settings/cloudservices/dmscene7 only global

La configuration cloud pour l’installation Dynamic Media - Scene7 (mode d’exécution dynamicmedia_scene7) reste au même emplacement. Le processus fonctionne en l’état. Si vous devez modifier la valeur de configuration du cloud, deux options s’offrent à vous :

  1. Mettre à jour la configuration existante au moyen de l’ancienne interface utilisateur de configuration cloud.
  2. Créer une configuration cloud au moyen de la nouvelle interface utilisateur tactile. Cette interface est prioritaire.

Pour vous aligner sur le modèle le plus récent, vous devez télécharger le script situé à l’adresse suivante :

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json
AEM Assets /etc/dam/presets/viewer

/libs/settings/dam/dm/presets/viewer

/conf/global/settings/dam/dm/presets/viewer

only global

Les paramètres prédéfinis par défaut de la visionneuse ne seront disponibles que dans le nouvel emplacement, tandis que les paramètres prédéfinis personnalisés resteront accessibles sous /etc jusqu’à ce qu’une modification soit effectuée.

Une fois la modification effectuée, ces paramètres prédéfinis seront enregistrés dans le nouvel emplacement par le biais d’une migration différée. Lors de la réception d’une demande, le serveur d’images incorporé regardera à l’emplacement hérité et au nouvel emplacement. Il n’est donc pas nécessaire de modifier l’URL, ni le code intégré.

Les paramètres prédéfinis par défaut de la visionneuse ne seront disponibles que dans le nouvel emplacement. Dans le cas des paramètres prédéfinis personnalisés, vous devez exécuter le script de migration à cet emplacement :

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

Comme c’est le cas pour le scénario de rétrocompatibilité, vous ne devez pas modifier la fonction copyURL ni le code intégré pour qu’il pointe vers /conf. La requête existante vers /etc sera réacheminée vers le contenu correct à partir de /conf.

AEM Assets /etc/dam/imageserver/macros /conf/global/settings/dam/dm/presets/macro only global La macro disponible sous /etc reste valide. Si vous la modifiez, le nœud modifié sera déplacé vers le nouvel emplacement sous /conf au moyen d’une tâche de migration différée.

Vous devez exécuter le script de migration à cet emplacement :

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

 

AEM Assets /etc/dam/video/dynamicmedia/Adaptive Video Encoding /libs/settings/dam/dm/presets/video/jcr:content/Adaptive Video Encoding N/D

Le profil vidéo prêt à l’emploi sera supprimé sans mettre à jour la propriété des dossiers de ressources pour qu’elle pointe vers le profil.

Le processus de codage intègre un mécanisme de conversion qui transforme l’ancien chemin d’accès pour qu’il pointe vers le nouveau chemin d’accès au profil.

Aucune modification n’est requise.
AEM Assets /etc/dam/video/dynamicmedia /conf/global/settings/dam/dm/presets/video/jcr:content only global

Le profil vidéo personnalisé est conservé en l’état jusqu’à ce que vous le modifiiez.

Il est ensuite transféré vers le nouvel emplacement par le biais d’une tâche de migration différée. Ceci est semblable à la vidéo prête à l’emploi prédéfinie lors de la recherche d’encodage. Le processus de codage s’accompagne d’un convertisseur de chemin d’accès intégré qui recherche le profil vidéo dans l’ancien emplacement, puis dans le nouvel emplacement.

Pour vous aligner sur le modèle le plus récent, vous pouvez exécuter le script situé à l’adresse suivante :

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

 

AEM Assets /etc/cloudservices/dynamicmediaservices /conf/global/settings/dam/dm/cloudservices/dynamicmediaservices only global

Cette configuration cloud pour l’installation hybride Dynamic Media (mode d’exécution dynamicmedia) reste au même emplacement. Le processus fonctionne en l’état. Si vous devez modifier la valeur de configuration, deux options s’offrent à vous :

  1. Mettre à jour une configuration existante au moyen de l’ancienne interface utilisateur de configuration cloud.
  2. Créer une configuration cloud au moyen de la nouvelle interface utilisateur tactile. Cette interface est prioritaire.

Vous devez exécuter le script de migration pour une mise en conformité avec le modèle le plus récent. Le script est accessible à l’adresse suivante :

  • http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json
AEM Assets /etc/cloudservices/youtube /libs/settings/dam/dm/youtube only global

La configuration cloud pour l’installation DM-Youtube reste au même emplacement. Le processus fonctionne en l’état. Si vous devez modifier la valeur de configuration cloud, deux options s’offrent à vous :

  1. Mettre à jour une configuration existante au moyen de l’ancienne interface utilisateur de configuration cloud.
  2. Créer une configuration cloud au moyen de la nouvelle interface utilisateur tactile. Cette interface est prioritaire.

Vous pouvez exécuter un script de migration pour vous aligner sur le modèle le plus récent. Ce script est accessible à l’adresse suivante :

http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

 

 

AEM Assets /etc/dam/presets/analytics /libs/settings/dam/dm/analytics only global Aucune action requise.

Vous pouvez exécuter un script de migration pour vous aligner sur le modèle le plus récent. Ce script est accessible à l’adresse suivante :

http://serveraddress:serverport/libs/settings/dam/dm/presets.migratedmcontent.json

Tous

/etc/notification/email/default/com.day.cq.replication

/etc/notification/email/default/com.day.cq.wcm.core.page

/libs/settings/notification-templates only global Les modèles situés dans /etc/notification/email/default/ sont prioritaires sur ceux résidant dans /libs/settings/notification-templates. Pour vous aligner sur le modèle le plus récent, vous pouvez créer des modèles sous /apps/settings/notification-templates et y effectuer des modifications.
AEM Sites

/etc/msm/rolloutconfigs/launch

/etc/msm/rolloutconfigs/pushonmodifyshallow

/libs/msm/launches/rolloutconfigs/launch

/libs/msm/launches/rolloutconfigs/pushonmodifyshallow

N/D

Les Consuming Services ont connaissance de l’emplacement précédent.

Si des configurations sont détectées dans l’emplacement hérité, elles sont utilisées.

Pour se conformer au nouveau modèle, des configurations doivent être créées aux nouveaux emplacements, tandis que les anciennes configurations sous /etc doivent être supprimées.
Tous /etc/translation/supportedLanguages

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages

not context-aware Veuillez tenir compte du fait que les langues personnalisées doivent être ajoutées à la liste.
Superposez et mettez à jour la nouvelle liste avec des langues supplémentaires, le cas échéant. Vous pouvez également copier l’ancienne liste sous /apps.
Tous /etc/workflow/models/translation/translation_rules.xml

/libs/settings/translation/rules/translation_rules.xml

/apps/settings/translation/rules/translation_rules.xml

/conf/global/settings/translation/rules/translation_rules.xml

only global Elles seront conservées sur une configuration mise à niveau statique. Le code permettant de les lister et de les lire est toujours présent dans le produit. Pour rendre persistantes les modifications, copiez le fichier XML depuis /etc vers /libs ou /conf. Sinon, supprimez le fichier de l’emplacement /etc.

Bibliothèques côté client

Les bibliothèques côté client sont constituées de code JavaScript et CSS traités dans le navigateur.

Stratégie d’extensibilité

AEM fournit une structure d’extensibilité permettant d’ajouter plusieurs fichiers JavaScript. Tout fichier ayant la même propriété « categories » sera ajouté, ce qui permettra au code personnalisé d’étendre le code AEM résidant sous /libs.

Solution Emplacement précédent


Nouvel emplacement Méthode de compatibilité descendante Conditions requises pour s’aligner sur le modèle le plus récent
AEM Forms /etc/clientlibs/fd/fp /libs/fd/fp/components

La clientlib héritée sera conservée sur une instance mise à niveau de manière statique.

Les nouvelles clientlibs portent les mêmes noms de catégorie, accompagnés de la propriété « replaces », pour éviter d’être fusionnées avec les anciennes clientlibs.

Aucune action requise.
AEM Forms /etc/clientlibs/fd/rte /libs/fd/rte

Les clientlibs héritées seront conservées sur une instance mise à niveau de manière statique.

Les nouvelles clientlibs portent les mêmes noms de catégorie, accompagnés de la propriété « replaces », pour éviter d’être fusionnées avec les anciennes clientlibs.

Aucune action requise.
AEM Forms /etc/clientlibs/fd/af /libs/fd/af/authoring/clientlibs Clientlibs héritées. Elles seront conservées sur une instance mise à niveau de manière statique. Les nouvelles clientlibs portent les mêmes noms de catégorie, accompagnés de la propriété « replaces », pour éviter d’être fusionnées avec les anciennes clientlibs. Aucune action requise.
AEM Forms /etc/clientlibs/fd/themes/themeLibrary N’est plus proposé dans le cadre du package par défaut d’AEM 6.4.

Thèmes prêts à l’emploi dans des formulaires adaptatifs.

Ils seront conservés sur une configuration mise à niveau statique.

Il s’agit d’un contenu généré en partie par l’utilisateur. Il sera fourni sous la forme d’un module de contenu de référence avec le nom aem-forms-reference-themes.
AEM Forms /etc/clientlibs/fd/expeditor /libs/fd/expeditor/clientlibs Clientlibs héritées. Elles seront conservées sur une instance mise à niveau de manière statique. Les nouvelles clientlibs portent les mêmes noms de catégorie, accompagnés de la propriété « replaces », pour éviter d’être fusionnées avec les anciennes clientlibs. Aucune action requise.

 

AEM Forms /etc/clientlibs/fd/fmaddon /libs/fd/fmaddon Clientlibs Analytics et Target héritées qui ne sont pas censées être exploitées directement.  Effacement effectué après la mise à niveau à l’aide d’un filtre de nettoyage.
AEM Assets

/etc/clientlibs/foundation/asseteditor

/etc/clientlibs/foundation/assetshare

/etc/clientlibs/foundation/assetinsights

/libs/dam/clientlibs Les clientlibs héritées ont des noms de catégorie différents. Aucune action requise.
  /etc/clientlibs/ckeditor /libs/clientlibs/ckeditor Il s’agit de clientlibs héritées. Elles seront conservées sur une configuration mise à niveau statique. Les nouvelles clientlibs portent les mêmes noms de catégorie, accompagnés de la propriété « replaces », pour éviter d’être fusionnées avec les anciennes clientlibs. Aucune action requise.
AEM Sites /etc/clientlibs/foundation/sitecatalyst /libs/cq/analytics/clientlibs/analytics

Il s’agit de clientlibs héritées. Elles seront conservées sur une configuration mise à niveau statique.

Les nouvelles clientlibs ont les mêmes noms de catégorie.

Aucune action requise.
AEM Sites /etc/clientlibs/foundation/personalization /libs/cq/personalization/clientlibs/personalization

Il s’agit de clientlibs héritées. Elles seront conservées sur une configuration mise à niveau statique.

Les nouvelles clientlibs ont les mêmes noms de catégorie.

Aucune action requise.
AEM Sites /etc/clientlibs/foundation/searchpromote /libs/cq/searchpromote/clientlibs/searchpromote

Il s’agit de clientlibs héritées. Elles seront conservées sur une configuration mise à niveau statique.

Les nouvelles clientlibs ont les mêmes noms de catégorie.

Aucune action requise.
AEM Sites /etc/clientlibs/foundation/target /libs/cq/target/clientlibs/target

Il s’agit de clientlibs héritées. Elles seront conservées sur une configuration mise à niveau statique.

Les nouvelles clientlibs ont les mêmes noms de catégorie.

Aucune action requise.
AEM Sites /etc/clientlibs/address /libs/cq/address/clientlibs Les nouvelles clientlibs ont les mêmes noms de catégorie. Aucune action requise.
AEM Sites /etc/clientlibs/wcm/foundation /libs/wcm/foundation/clientlibs Clientlibs héritées. Elles seront conservées sur une configuration mise à niveau statique. Les nouvelles clientlibs portent les mêmes noms de catégorie, accompagnés de la propriété « replaces », pour éviter d’être fusionnées avec les anciennes clientlibs. Aucune action requise.
AEM Sites /etc/clientlibs/wcm/foundation/grid/grid_base.less

/libs/wcm/foundation/clientlibs/grid/grid_base.less

Sur une mise à niveau statique, le fichier hérité (/etc/clientlibs/wcm/…_) n’est pas supprimé automatiquement. Par conséquent, les références au fichier hérité /etc/clientlibs/wcm/foundation/grid/grid_base.less continuent d’être opérationnelles.

Notez qu’il s’agit d’un cas extrême dans lequel ce fichier LESS est référencé par un chemin d’accès absolu via des instructions LESS @import, et non par la catégorie clientlib.

Si l’instruction LESS du client qui fait référence à « grid_base.less » pointe vers un fichier inexistant, le mode Mise en page de modèles modifiables échouera et les éventuelles modifications effectuées avec celui-ci seront ignorées (en d’autres termes, tous les composants occuperont toute la largeur de la page).

Mettez à jour les références dans le code personnalisé (c’est-à-dire dans tous les fichiers LESS faisant référence au fichier grid_base.less déplacé) pour qu’elles pointent vers le nouvel emplacement et supprimez ensuite l’emplacement hérité.

Il s’agit là de tâches de restructuration qui ne sont pas couvertes dans les sections précédentes.

Stratégie d’extensibilité

Parcourez chaque ligne du tableau ci-dessous pour en savoir plus sur les modèles d’extensibilité pris en charge. En règle générale, le contenu de cette section n’est pas étendu.

Divers

Solution Emplacement précédent
Nouvel emplacement Méthode de compatibilité descendante Conditions requises pour s’aligner sur le modèle le plus récent
AEM Forms /etc/designs/fd/fp /libs/fd/fp

Modèles prêts à l’emploi AEM Forms Portal hérités. Ces modèles restent dans /etc après une configuration mise à niveau statique.

Le mot « deprecated » (obsolète) est ajouté au titre du modèle dans la liste des modèles pour le différencier des modèles plus récents.

Aucune action requise.
AEM Forms /etc/aep /var/fd/content/annotations Fichiers d’annotation Correspondence Management hérités. Ces fichiers ne sont pas censés être exploités directement. Ils seront effacés après la mise à niveau à l’aide d’un filtre de nettoyage. Effacement de l’emplacement hérité après la mise à niveau à l’aide d’un filtre de nettoyage.
Tous /etc/tags /content/cq:tags L’API Tag Manager prend en charge l’emplacement hérité et le nouvel emplacement. Lorsque le composant Factory OSGi de JCR Tag démarre, il détecte s’il s’exécute sur une instance mise à niveau ou une instance héritée, et utilise l’emplacement approprié en conséquence.

Pour vous aligner correctement sur le nouveau modèle, procédez comme suit :

  1. Remplacez les références à l’ancien modèle (/etc/tags) par le nouveau (/content/cq:tags) en utilisant le tagID.
  2. Connectez-vous à CRXDE Lite.
  3. Transférez les balises de /etc/tags vers /content/cq:tags.
  4. Redémarrez le composant OSGi com.day.cq.tagging.impl.JcrTagManagerFactoryImpl.

 

Tous /etc/workflow/instances /var/workflow/instances Emplacement hérité utilisé dans le cadre du traitement des
workflows en transit. Les nouveaux workflows utilisent le nouvel emplacement sous /var.
Aucune action requise.
Tous /etc/workflow/scripts

/libs/workflow/scripts

/apps/workflow/scripts

Les étapes du modèle de workflow qui font référence aux scripts de workflow dans l’emplacement hérité (/etc/workflow/scripts) pointent toujours vers ces scripts après la mise à niveau et continuent de s’exécuter correctement.

Nous attirons votre attention sur le fait que l’interface utilisateur d’AEM destinée à la création des étapes de workflow (Processus, Divisions, etc.) ne répertorie plus les scripts situés sous /etc/workflow/scripts dans le menu déroulant utilisé pour sélectionner les scripts de workflow.

Les workflows qui exploitent ces scripts continueront de fonctionner comme prévu si l’étape de workflow associée n’est pas modifiée dans AEM.

Cependant, pour bénéficier d’une parfaite rétrocompatibilité, y compris lors de la modification des étapes, une intervention manuelle de l’utilisateur sera nécessaire après la mise à niveau :

  • Les scripts doivent être transférés depuis /etc/workflow/scripts vers /apps/workflow/scripts.
  • Toute référence à /etc/workflow/scripts dans les étapes du modèle de workflow doit être mise à jour afin de pointer vers le nouvel emplacement /apps/workflow/scripts.
Tous /etc/replication/treeactivation /libs/replication/treeactivation La page de l’utilitaire Interface utilisateur classique reste au même endroit lors de la mise à niveau. Aucune action requise.
AEM Assets /etc/dam/jobs /var/dam/jobs

Emplacement de stockage temporaire des fichiers ZIP générés pour l’appel de l’opération de téléchargement d’AEM Assets.

Aucune mise à jour n’est nécessaire puisque, lorsque le client demande de télécharger la ressource, le fichier est généré dans le nouvel emplacement.

Aucune action requise.
AEM Commerce /etc/commerce/products /var/commerce/products

L’ancien contenu n’est pas transféré et reste utilisable après la mise à niveau.

Une tâche de migration différée est fournie pour effectuer la migration vers le nouvel emplacement.

La migration est effectuée au moyen de la procédure différée : CQ64CommerceMigrationTask.

La procédure se compose des étapes suivantes :

  • Adaptation des références pour qu’elles pointent vers le nouvel emplacement
  • Transfert du contenu de l’ancien emplacement vers le nouvel emplacement
  • Suppression de l’ancien emplacement en vue d’activer l’utilisation du nouvel emplacement à l’échelle du système

Les emplacements couverts par la tâche sont les suivants :

  • /etc/commerce/products
  • /etc/commerce/collections
  • /etc/commerce/orders
  • /etc/commerce/payment-methods
  • /etc/commerce/shipping-methods

Pour les catalogues plus volumineux, il est conseillé d’exécuter la tâche de migration de commerce en transmettant la propriété du système Java suivante à AEM :

  • property name: com.adobe.upgrade.forcemigration
  • property value: com.day.cq.compat.codeupgrade.impl.cq64.CQ64CommerceMigrationTask

Après la migration, AEM doit être redémarré.

AEM Commerce /etc/commerce/orders /var/commerce/orders

L’ancien contenu n’est pas transféré et reste utilisable après la mise à niveau.

Une tâche de migration différée est fournie pour effectuer la migration vers le nouvel emplacement.

Consultez la description ci-dessus pour /etc/commerce/products.
AEM Commerce /etc/commerce/collections /var/commerce/collections

L’ancien contenu n’est pas transféré et reste utilisable après la mise à niveau.

Une tâche de migration différée est fournie pour effectuer la migration vers le nouvel emplacement.

Consultez la description ci-dessus pour /etc/commerce/products.
AEM Commerce /etc/commerce/classifications /var/commerce/classifications Aucune action requise. Aucune action requise.
AEM Commerce /etc/commerce/shipping-methods /var/commerce/shipping-methods

L’ancien contenu n’est pas transféré et reste utilisable après la mise à niveau.

Une tâche de migration différée est fournie pour effectuer la migration vers le nouvel emplacement.

Consultez la description ci-dessus pour /etc/commerce/products.
AEM Commerce /etc/commerce/payment-methods /var/commerce/payment-methods

L’ancien contenu n’est pas transféré et reste utilisable après la mise à niveau.

Une tâche de migration différée est fournie pour effectuer la migration vers le nouvel emplacement.

Consultez la description ci-dessus pour /etc/commerce/products.
Tous /etc/taskmanagement /var/taskmanagement

Les nouvelles tâches sont créées sous /var/taskmanagement.

Les tâches qui sont présentes à l’emplacement hérité restent visibles dans la boîte de réception AEM.

Aucune action requise.
Tous /etc/workflow/packages /var/workflow/packages

Les modules AEM créés au moyen du gestionnaire de modules d’AEM sont toujours stockés sous /etc/workflow/packages.

Les autres modules créés au moyen d’AEM Sites et Workflows sont toujours stockés sous /var/workflow/packages.

Les modules stockés sous /etc/workflow/packages et /var/workflow/packages peuvent toujours être modifiés au moyen du gestionnaire de modules d’AEM. 

Aucune action requise.

 

Tous /etc/workflow/instances /var/workflow/instances De nouvelles instances de workflow seront automatiquement créées sous /var. Aucune action requise.
Tous /etc/commerce/searchpromote /var/cq/searchpromote

Nouvel emplacement pour le contenu de flux Search & Promote.

L’ancienne URL fonctionne toujours et la requête est transmise au nouvel emplacement par un ServletFilter.

Aucune action requise.

Tous /etc/dtm-hook /var/cq/dtm/web-hook

Nouvel emplacement pour DTM Web-Hooks.

L’ancienne URL fonctionne toujours et la requête est transmise au nouvel emplacement par un ServletFilter.

Aucune action requise.

Ce produit est distribué sous licence Creative Commons Attribution - Pas d’utilisation commerciale - Partage à l’identique 3.0 non transposé  Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.

Mentions légales   |   Politique de confidentialité en ligne