Restructuration des référentiels dans AEM 6.4 common-repository-restructuring-in-aem

/libs/settings/workflow/models

/conf/global/settings/workflow/models

/var/workflow/models

Les modèles de workflow, nouveaux ou modifiés, doivent être migrés vers /conf/global/workflow/models.

1. Déployez les modèles de workflow modifiés dans une instance locale de développement AEM 6.4, comme ils existent dans l’emplacement précédent.

2. Modifiez le modèle de processus à l’aide de AEM’éditeur de modèle de processus sous AEM > Outils > Processus > Modèles.

3. Lors de la migration de modèles de processus fournis par AEM modifiés

   1. Une fois l’éditeur de modèle de processus ouvert, modifiez l’URL de l’adresse du navigateur et remplacez le segment de chemin /libs/settings/workflow/models par /etc/workflow/models.
      • Par exemple, modifiez http://localhost:4502/editor.html /libs/settings/workflow/models/dam/update_asset.html en  http://localhost:4502/editor.html /etc/workflow/models/dam/update_asset.html

4. Activez le mode d’édition dans l’éditeur de modèle de processus qui copiera la définition du modèle de processus dans /conf/global/workflow/models.

5. Appuyez sur le bouton Synchroniser pour synchroniser les modifications apportées au modèle de processus d’exécution sous /var/workflow/models.

6. Exportez le modèle de workflow (https://experienceleague.adobe.com/conf/global/workflow/models/?lang=fr)<workflow-model>) et le modèle de processus d’exécution (https://experienceleague.adobe.com/var/workflow/models/?lang=fr)<workflow-model>) et intégrer dans le projet AEM.

   1. Par exemple, exporter :

      • /config/settings/workflow/models/dam/my_workflow_model et
      • /var/workflow/models/dam/my_workflow_model

La résolution d’un modèle de workflow s’effectue dans l’ordre suivant :

1. /conf/global/settings/workflow/models
2. /libs/settings/workflow/models
3. /etc/workflow/models

Ainsi, toute personnalisation des modèles de workflow fournis par AEM et conservés à l’emplacement précédent doit être déplacée vers /conf/global/settings/workflow/models si elle doit être conservée, sinon elle sera remplacée par la définition de modèle de workflow fournie par AEM dans /libs/settings/workflow/models.

Aucune action n’est requise pour s’aligner sur le nouvel emplacement.

Les instances de workflow historiques peuvent continuer à résider en toute sécurité à l’emplacement précédent, et de nouvelles instances de workflow seront créées dans le nouvel emplacement.

/libs/settings/workflow/launcher/config

/conf/global/settings/workflow/launcher/config

Les lanceurs de workflow nouveaux ou modifiés doivent être migrés vers /conf/global/workflow/launcher/config.

1. Copiez les configurations nouvelles ou modifiées du lanceur de workflow de l’emplacement précédent dans un nouvel emplacement (/conf/global).

La résolution du lanceur de workflow s’effectue dans l’ordre suivant :

1. /conf/global/settings/workflow/launcher
2. /libs/settings/workflow/launcher
3. /etc/workflow/launcher

Ainsi, toute personnalisation du lanceur de workflow fourni par AEM et conservée à l’emplacement précédent doit être déplacée vers le nouvel emplacement (/conf/global/settings/workflow/launcher si elle doit être conservée), sinon, elle sera remplacée par la définition du lanceur de workflow fourni par AEM dans /libs/settings/workflow/launcher.

/libs/workflow/scripts

/apps/workflow/scripts

Les scripts de workflow nouveaux ou modifiés doivent être migrés vers le nouvel emplacement et les modèles de workflow de référence mis à jour pour refléter le nouvel emplacement.

1. Copiez les scripts de workflow nouveaux ou modifiés de l’emplacement précédent vers le nouvel emplacement.
   • /apps/workflow/scripts doit être conservé dans SCM.
2. Mettez à jour les références aux scripts de workflow à l’emplacement précédent dans les modèles de workflow pour pointer vers les nouveaux emplacements.

AEM 6.4 SP1, à sa publication, permet de différer cette restructuration jusqu’à la mise à niveau vers la version 6.5 upgrade .

Si vous effectuez une mise à niveau vers AEM 6.4 avant la publication d’AEM 6.4 SP1, cette restructuration doit être effectuée dans le cadre du projet de mise à niveau. Sinon, la modification et l’enregistrement des étapes de workflow référençant des scripts à l’emplacement précédent supprime entièrement la référence du script de workflow de l’étape de workflow, et seuls les scripts de workflow dans de nouveaux emplacements seront disponibles dans la liste déroulante de sélection de script.

/libs/settings/cloudsettings

/conf/global/settings/cloudsettings

/conf/<tenant>/settings/cloudsettings

Toute configuration ContextHub nouvelle ou modifiée doit être migrée vers le nouvel emplacement et les pages AEM Sites de référencement doivent être mises à jour pour refléter le nouvel emplacement.

1. Copiez les configurations ContextHub nouvelles ou modifiées de l’emplacement précédent vers le nouvel emplacement.
2. Associez les configurations AEM applicables aux hiérarchies de contenu AEM.
   1. Hiérarchies de page AEM Sites via AEM Sites > Page > Propriétés de page > Onglet avancé > Configuration cloud.
3. Dissociez les configurations ContextHub héritées migrées des hiérarchies de contenu AEM mentionnées ci-dessus.

/libs/settings/wcm/designs/cloudservices

/apps/settings/wcm/designs/cloudservices

Pour les conceptions gérées dans SCM et qui ne sont pas écrites au moment de l’exécution via les boîtes de dialogue de conception.

1. Copiez les conceptions de l’emplacement précédent dans le nouvel emplacement (/apps).
2. Convertissez les ressources statiques, CSS et JavaScript dans la conception en bibliothèque cliente avec allowProxy = true.
3. Mettez à jour les références à l’emplacement précédent dans la propriété cq : designPath .
4. Mettez à jour les pages faisant référence à l’emplacement précédent pour utiliser la nouvelle catégorie de bibliothèque cliente (cela nécessite la mise à jour du code d’implémentation de la page).
5. Mettez à jour les règles du Dispatcher AEM pour autoriser le service des bibliothèques clientes via /etc.clientlibs/.. servlet proxy.

Pour les conceptions NON gérées dans SCM et modifiées au moment de l’exécution via les boîtes de dialogue de conception.

• Ne déplacez pas les conceptions activées par l’auteur en dehors de /etc.

/libs/settings/wcm/designs/dashboards

/apps/settings/wcm/designs/dashboards

Pour les conceptions gérées dans SCM et qui ne sont pas écrites au moment de l’exécution via les boîtes de dialogue de conception.

1. Copiez les conceptions de l’emplacement précédent dans le nouvel emplacement (https://experienceleague.adobe.com/apps?lang=fr).
2. Convertissez les ressources statiques, CSS et JavaScript dans la conception en bibliothèque cliente avec allowProxy = true.
3. Mettez à jour les références à l’emplacement précédent dans la propriété cq  : designPath .
4. Mettez à jour les pages faisant référence à l’emplacement précédent pour utiliser la nouvelle catégorie de bibliothèque cliente (cela nécessite la mise à jour du code d’implémentation de la page).
5. Mettez à jour les règles du Dispatcher AEM pour autoriser le service des bibliothèques clientes via /etc.clientlibs/.. servlet proxy.

Pour les conceptions NON gérées dans SCM et modifiées au moment de l’exécution via les boîtes de dialogue de conception.

• Ne déplacez pas les conceptions activées par l’auteur en dehors de /etc.

/libs/settings/wcm/designs/reports

/apps/settings/wcm/designs/reports

Pour les conceptions gérées dans SCM et qui ne sont pas écrites au moment de l’exécution via les boîtes de dialogue de conception.

1. Copiez les conceptions de l’emplacement précédent dans le nouvel emplacement (https://experienceleague.adobe.com/apps?lang=fr).
2. Convertissez les ressources statiques, CSS et JavaScript dans la conception en bibliothèque cliente avec allowProxy = true.
3. Mettez à jour les références à l’emplacement précédent dans la propriété cq  : designPath .
4. Mettez à jour les pages faisant référence à l’emplacement précédent pour utiliser la nouvelle catégorie de bibliothèque cliente (cela nécessite la mise à jour du code d’implémentation de la page).
5. Mettez à jour les règles du Dispatcher AEM pour autoriser le service des bibliothèques clientes via /etc.clientlibs/.. servlet proxy.

Pour les conceptions NON gérées dans SCM et modifiées au moment de l’exécution via les boîtes de dialogue de conception.

• Ne déplacez pas les conceptions activées par l’auteur en dehors de /etc.

/libs/settings/wcm/designs/default

/apps/settings/wcm/designs/default

Pour les conceptions gérées dans SCM et qui ne sont pas écrites au moment de l’exécution via les boîtes de dialogue de conception.

1. Copiez les conceptions de l’emplacement précédent dans le nouvel emplacement (https://experienceleague.adobe.com/apps?lang=fr).
2. Convertissez les ressources statiques, CSS et JavaScript dans la conception en bibliothèque cliente avec allowProxy = true.
3. Mettez à jour les références à l’emplacement précédent dans la propriété cq  : designPath .
4. Mettez à jour les pages faisant référence à l’emplacement précédent pour utiliser la nouvelle catégorie de bibliothèque cliente (cela nécessite la mise à jour du code d’implémentation de la page).
5. Mettez à jour les règles du Dispatcher AEM pour autoriser le service des bibliothèques clientes via /etc.clientlibs/.. servlet proxy.

Pour les conceptions NON gérées dans SCM et modifiées au moment de l’exécution via les boîtes de dialogue de conception.

• Ne déplacez pas les conceptions activées par l’auteur en dehors de /etc.

Aucune action requise.

L’emplacement public précédent agit comme un point de terminaison proxy pour le nouvel emplacement privé.

Aucune action requise.

L’emplacement public précédent agit comme un point de terminaison proxy pour le nouvel emplacement privé.

Aucune action n’est requise pour la migration des tâches vers le nouvel emplacement.

• Les tâches présentes dans l’emplacement précédent restent disponibles et fonctionnent.
• De nouvelles tâches sont créées dans le nouvel emplacement.

/libs/msm

/apps/msm

1. Copiez les configurations personnalisées depuis /etc/blueprints vers /apps/msm.
2. Supprimez /etc/blueprints.

/libs/cq/core/content/projects/dashboard/gadgets

/apps/cq/core/content/projects/dashboard/gadgets

Les configurations de gadget de tableau de bord Projets AEM nouvelles ou modifiées doivent être migrées vers le nouvel emplacement (/apps).

1. Copiez les configurations de gadget de tableau de bord Projets AEM nouvelles ou modifiées de l’emplacement précédent dans le nouvel emplacement (/apps).
   1. Ne copiez pas les configurations non modifiées, car elles existent maintenant dans le nouvel emplacement (/libs).
2. Mettez à jour les modèles Projets AEM faisant référence à l’emplacement précédent pour qu’ils pointent vers le nouvel emplacement approprié.

/libs/settings/notification-templates/com.day.cq.replication

/apps/settings/notification-templates/com.day.cq.replication

Les modèles d’e-mail de notification de réplication nouveaux ou modifiés doivent être migrés vers le nouvel emplacement (/apps).

1. Copiez les modèles d’e-mail de notification de réplication nouveaux ou modifiés de l’emplacement précédent vers le nouvel emplacement (/apps).
2. Supprimez les modèles d’e-mail de notification de réplication migrés de l’emplacement précédent.

Les seuls nouveaux modèles d’e-mail de notification de réplication pris en charge sont la prise en charge de nouveaux paramètres régionaux.

La résolution du modèle d’e-mail de notification de réplication s’effectue dans l’ordre suivant :

1. /etc/notification/email/default/com.day.cq.replication
2. /apps/settings/notification-templates/com.day.cq.replication
3. /libs/settings/notification-templates/com.day.cq.replication

Toutes les balises doivent être migrées vers /content/cq:tags.

1. Copiez toutes les balises de l’emplacement précédent vers le nouvel emplacement.
2. Supprimez toutes les balises de l’emplacement précédent.
3. Dans la console Web AEM, redémarrez le lot OSGi Tagging Day Communique 5 à l’adresse https://serveraddress:serverport/system/console/bundles/com.day.cq.cq-tagging pour qu’AEM détermine que le nouvel emplacement contient du contenu et qu’il doit être utilisé.

Le redémarrage du lot OSGi Day Communique Tagging n’enregistrera le nouvel emplacement en tant que racine de balise que si l’emplacement précédent est vide.

Les références à l’emplacement précédent continueront à fonctionner après la migration vers le nouvel emplacement pour toutes les fonctionnalités qui utilisent AEM API TagManager pour la résolution des balises.

Tout code personnalisé qui référence explicitement le chemin d’accès

/etc/tags

doit être remplacé par /content/

cq

:tags

, ou de préférence réécrit en utilisant l’API Java TagManager, en même temps que cette migration.

/libs/settings/cloudconfigs/translation/translationcfg

/apps/settings/cloudconfigs/translation/translationcfg

/conf/global/settings/cloudconfigs/translation/translationcfg

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

Les nouveaux services cloud de traduction doivent être migrés vers le nouvel emplacement (/apps, /conf/global ou /conf/<tenant>).

1. Migrez les configurations existantes de l’emplacement précédent vers le nouvel emplacement.

   • Recréez manuellement de nouvelles configurations de Cloud Services de traduction via l’interface utilisateur de création AEM à l’adresse Outils > Cloud Services > Cloud Services de traduction.
     OU
   • Copiez les nouvelles configurations de services cloud de traduction de l’emplacement précédent dans le nouvel emplacement (/apps, /conf/global ou /conf/<tenant>).

2. Associez les configurations AEM applicables aux hiérarchies de contenu AEM.

   1. Hiérarchies de page AEM Sites via AEM Sites > Page > Propriétés de page > Onglet avancé > Configuration cloud.
   2. AEM des hiérarchies de fragments d’expérience via AEM Fragments d’expérience > Fragment d’expérience > Propriétés > Onglet Cloud Services > Configuration cloud.
   3. AEM des hiérarchies de dossiers de fragments d’expérience via AEM Fragments d’expérience > Dossier > Propriétés > Onglet Cloud Services > Configuration cloud.
   4. Hiérarchies des dossiers AEM Assets via AEM Assets > Dossier > Propriétés du dossier > Onglet Services cloud > Configuration.
   5. Projets AEM via Projets AEM > Projet > Propriétés du projet > Onglet avancé > Configuration cloud.

3. Dissociez les anciens services cloud de traduction migrés des hiérarchies de contenu AEM mentionnées ci-dessus.

La résolution des services cloud de traduction s’effectue dans l’ordre suivant :

1. /conf/<tenant>/settings/cloudconfigs/translations/translationcfg
2. /conf/global/settings/cloudconfigs/translations/translationcfg
3. /apps/settings/cloudconfigs/translations/translationcfg
4. /libs/settings/cloudconfigs/translations/translationcfg

Les Cloud Services de traduction migrés doivent être compatibles avec AEM 6.4.

/libs/settings/translation/supportedLanguages

/apps/settings/translation/supportedLanguages

Les définitions de langue de traduction nouvelles ou modifiées requièrent une migration de toutes les définitions de langue de traduction vers le nouvel emplacement (/apps).

1. Si des ajouts ou des modifications ont été apportés aux définitions de langue de traduction, copiez toutes les définitions de langue de traduction dans le nouvel emplacement (/apps).

La résolution du chemin de langue de traduction s’effectue dans l’ordre suivant :

1. /etc/translation/supportedLanguages
2. /apps/settings/translation/supportedLanguage
3. /libs/settings/translation/supportedLanguages

Cette résolution ne prend pas en charge une superposition de fusion, ce qui signifie que le chemin résolu doit contenir toutes les langues prises en charge et n’héritera pas des langues prises en charge de résolutions d’ordre supérieur.

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

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

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

Un fichier XML de règles de traduction modifié doit être migré vers le nouvel emplacement (/apps ou /conf/global).

1. Copiez le fichier XML de règles de traduction modifié de l’emplacement précédent dans le nouvel emplacement.

La résolution XML des règles de traduction de la réplication s’effectue dans l’ordre suivant :

1. /conf/global/settings/translation/rules/translation_rules.xml
2. /apps/settings/translation/rules/translation_rules.xml
3. /etc/workflow/models/translation/translation_rules.xml
4. /libs/settings/translation/rules/translation_rules.xml

/libs/settings/wcm/designs/translation/translationwidget

/apps/settings/wcm/designs/translation/translationwidget

Pour les conceptions gérées dans SCM et qui ne sont pas écrites au moment de l’exécution via les boîtes de dialogue de conception.

1. Copiez les conceptions de l’emplacement précédent dans le nouvel emplacement (https://experienceleague.adobe.com/apps?lang=fr).
2. Convertissez les ressources statiques, CSS et JavaScript dans la conception en bibliothèque cliente avec allowProxy = true.
3. Mettez à jour les références à l’emplacement précédent dans la propriété cq  : designPath .
4. Mettez à jour les pages faisant référence à l’emplacement précédent pour utiliser la nouvelle catégorie de bibliothèque cliente (cela nécessite la mise à jour du code d’implémentation de la page).
5. Mettez à jour les règles du Dispatcher AEM pour autoriser le service des bibliothèques clientes via /etc.clientlibs/.. servlet proxy.

Pour les conceptions NON gérées dans SCM et modifiées au moment de l’exécution via les boîtes de dialogue de conception.

• Ne déplacez pas les conceptions activées par l’auteur en dehors de /etc.

/libs/settings/cloudconfigs/translation/<vendor>

/apps/settings/cloudconfigs/translation/<vendor>

/conf/global/settings/cloudconfigs/translation/<vendor>

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

Les nouveaux services cloud de connecteur de traduction de fournisseur doivent être migrés vers le nouvel emplacement (/apps, /conf/global ou /conf/<tenant>).

1. Migrez les configurations existantes de l’emplacement précédent vers le nouvel emplacement.

   • Créez manuellement de nouvelles configurations de Cloud Services de connecteur de traduction de fournisseur via le AEM l’interface utilisateur de création sous Outils > Cloud Services > Cloud Services de traduction.
     OU
   • Copiez les nouvelles configurations des services cloud de connecteur de traduction de fournisseur de l’emplacement précédent dans le nouvel emplacement (/apps, /conf/global ou /conf/<tenant>).

2. Associez les configurations AEM applicables aux hiérarchies de contenu AEM.

   1. Hiérarchies de page AEM Sites via AEM Sites > Page > Propriétés de page > Onglet avancé > Configuration cloud.
   2. AEM des hiérarchies de fragments d’expérience via AEM Fragments d’expérience > Fragment d’expérience > Propriétés > Onglet Cloud Services > Configuration cloud.
   3. AEM des hiérarchies de dossiers de fragments d’expérience via AEM Fragments d’expérience > Dossier > Propriétés > Onglet Cloud Services > Configuration cloud.
   4. Hiérarchies des dossiers AEM Assets via AEM Assets > Dossier > Propriétés du dossier > Onglet Services cloud > Configuration.
   5. Projets AEM via Projets AEM > Projet > Propriétés du projet > Onglet avancé > Configuration cloud.

3. Dissociez les anciens services cloud de traduction migrés des hiérarchies de contenu AEM mentionnées ci-dessus.

La résolution des services cloud de traduction s’effectue dans l’ordre suivant :

1. /conf/<tenant>/settings/cloudconfigs/translations/<vendor>
2. /conf/global/settings/cloudconfigs/translations/<vendor>
3. /apps/settings/cloudconfigs/translations/<vendor>
4. /libs/settings/cloudconfigs/translations/<vendor>

/libs/settings/workflow/notification

/conf/global/settings/workflow/notification

Les modèles d’e-mail de notification de workflow modifiés doivent être migrés vers le nouvel emplacement (/conf/global).

1. Copiez les modèles d’e-mail de notification de workflow modifiés de l’emplacement précédent vers le nouvel emplacement.
2. Supprimez les modèles d’e-mail de notification de workflow migrés de l’emplacement précédent.

La résolution du modèle d’e-mail de notification de workflow s’effectue dans l’ordre suivant :

1. /etc/workflow/notification
2. /conf/global/settings/workflow/notification
3. /libs/settings/workflow/notification

Les modules de workflow existants situés à l’emplacement précédent doivent être migrés vers le nouvel emplacement.

1. Supprimez les packages de workflow de l’emplacement précédent qui ne sont pas référencés par un autre contenu et qui ne sont pas requis dans le cas contraire.
2. Déplacez les packages de workflow de l’emplacement précédent qui ne sont pas référencés par un autre contenu, mais qui sont requis dans le nouvel emplacement.
3. Laissez les packages de workflow qui sont référencés par un autre contenu à l’emplacement précédent.

Les modules de workflow créés via la console Miscadmin de l’interface utilisateur classique sont conservés à l’emplacement précédent, tandis que tous les autres sont conservés au nouvel emplacement.

Les packages de workflow stockés aux emplacements précédents ou précédents peuvent être gérés via la console Miscadmin de l’interface utilisateur classique.