Phase de préparation readiness-phase

Dans cette phase du parcours de migration AEM as a Cloud Service, vous vous familiarisez avec AEM as a Cloud Service. Vous pouvez passer en revue les modifications notables introduites et découvrir les actions à entreprendre pour planifier une migration réussie vers le cloud.

Un peu d’histoire… story-so-far

Le document précédent, Prise en main de la transition vers AEM as a Cloud Service, présente une liste des étapes à suivre pour pouvoir migrer vers AEM as a Cloud Service. Il présente également les avantages de la migration.

Objectif objective

Ce document vous aide à comprendre les facteurs à prendre en compte pour vous assurer que votre installation AEM est prête à être déplacée vers le cloud :

  • En savoir plus sur les modifications notables et les fonctionnalités obsolètes.
  • Comprendre comment planifier la migration vers AEM as a Cloud Service.

Examinez les modifications notables apportées à l’architecture AEM as a Cloud Service notable-changes-in-aem-cloud-service-architecture

AEM as a Cloud Service offre de très nombreuses fonctionnalités et possibilités nouvelles pour gérer vos projets AEM.

Outre ces améliorations, plusieurs différences ont été introduites entre les installations on-premise d’AEM et d’Adobe Managed Services, par rapport à AEM as a Cloud Service.

La liste des éléments du tableau ci-dessous est le sous-ensemble des modifications les plus pertinentes pour une migration vers AEM as a Cloud Service. Vous pouvez consulter la liste complète des modifications notables apportées à Adobe Experience Manager as a Cloud Service.

Qu’est-ce qui a changé ?
Référence
Points clés
Séparation des filtres modifiables et non modifiables en packages correspondants
Modifications notables d’AEM as a Cloud Service
Structure de projet AEM pour AEM as a Cloud Service
Un package unique pouvant être déployé dans AEM as a Cloud Service peut comporter des sous-packages, principalement pour contenir du contenu modifiable et non modifiable séparé dans leurs propres packages.
Repo Init
Documentation d’Apache Sling RepoInit
Les scripts Repoinit sont recommandés pour créer les structures de nœud, les personnes utilisatrices, les groupes ou les personnes utilisatrices de service initiaux. Comme ces scripts peuvent être ciblés par le mode d’exécution et gérables via le déploiement du package de code, ils offrent une grande flexibilité pour réaliser les tâches d’initialisation du référentiel.
Les modes d’exécution personnalisés ne sont pas autorisés.
Seuls les modes d’exécution prêts à l’emploi avec AEM as a Cloud Service sont pris en charge.
Lorsque d’autres environnements de développement sont ajoutés, ils sont tous liés au mode d’exécution « dev ».
L’exécution du pipeline de Cloud Manager est la seule méthode de déploiement.
Dans AEM as a Cloud Service, l’accès à /system/console n’est pas autorisé. Par conséquent, toutes les configurations OSGi doivent faire partie du code et doivent être déployées en tant que code.
Les configurations OSGi sont disponibles en mode lecture seule pour un affichage via Developer Console via Cloud Manager.
Les agents de réplication sont remplacés par la distribution de contenu Sling.
Le concept de l’agent de réplication est remplacé par la distribution de contenu Sling. Si des personnalisations utilisent des agents de réplication, elles doivent être repensées.
La réplication inverse n’est pas prise en charge.
CRX/DE et le Gestionnaire de package
CRX/DE n’est autorisé que dans l’environnement de développement.
Le Gestionnaire de package est accessible sur toutes les instances de création, mais les packages qui vont être déployés ne doivent contenir que du contenu modifiable (par exemple : /content ou /conf).
Réseau de diffusion de contenu intégré et Obtention de votre propre réseau de diffusion de contenu
AEM as a Cloud Service inclut le réseau de diffusion de contenu pour tous les environnements, optimisé pour la plupart des cas d’utilisation.
Si vous souhaitez configurer votre propre réseau de diffusion de contenu, vous devez envoyer une demande à l’assistance Adobe pour qu’il soit approuvé.
Si votre demande est approuvée, le réseau CDN pointe vers Fastly et non vers les instances AEM, quel que soit lʼenvironnement.
Tâches de longue durée
Évitez les tâches de longue durée telles que des planifications Sling ou des tâches Cron, car les instances AEM exécutées dans les conteneurs peuvent apparaître et disparaître à tout moment.
Repensez ces fonctionnalités afin de pouvoir les décharger vers Adobe Developer.
Passer aux opérations asynchrones
Configurer des opérations asynchrones
Dans le but dʼaméliorer les performances globales de vos environnements, certaines opérations sont exécutées en mode asynchrone. Les tâches asynchrones seront mises en file d’attente et exécutées lorsque les ressources système seront disponibles.
Stratégies d’authentification et d’intégration basées sur des jetons
Génération de jetons d’accès pour les API côté serveur
Tutoriel sur l’authentification par jeton
Il est fréquent que des systèmes externes à AEM tentent d’effectuer des opérations HTTP dans AEM.
L’approche recommandée consiste à implémenter les stratégies décrites ici, plutôt que de sʼappuyer sur la création de noms dʼutilisateurs locaux avec des mots de passe dans AEM.
Fichier E/S / Espace disque
Il n’y a aucune garantie quant à la quantité d’espace disque allouée. Les instances dans les conteneurs apparaissent et disparaissent. Par conséquent, il n’est pas recommandé d’utiliser les opérations d’E/S de fichier pour écrire ou lire à partir du disque attaché à l’instance AEM.
Workflow Ressource de mise à jour de la gestion des ressources numériques (DAM)
Asset Compute Service
Les étapes de traitement des médias qui font partie du workflow Ressource de mise à jour de la gestion des ressources numériques (DAM) sont désormais remplacées par Asset Compute Service.
Méthodes de téléchargement des ressources et étapes du processus de workflow prises en charge dans AEM as a Cloud Service
Comparaisons des API de téléchargement et étapes du processus de workflow prises en charge
Dans AEM as a Cloud Service, lors du chargement ou téléchargement d’une ressource, celle-ci entre ou sort directement du stockage binaire.
Toutes les étapes de processus de workflow ne sont pas prises en charge dans AEMaaCS.
Lanceurs de workflow
Supprimez de votre code tous les lanceurs de workflow qui déclenchent un workflow Ressource de mise à jour de la gestion des ressources numériques prêt à lʼemploi ou personnalisé.
Toutes les ressources téléchargées vers AEM as a Cloud Service seront traitées par le service de traitement des ressources. Pour les étapes personnalisées, reportez-vous à la section Workflows de post-traitement sur la configuration des workflows de post-traitement.
Étapes de rendu personnalisé
Profils de traitement
Toute opération de génération de rendus personnalisés, de conversion dʼimages ou dʼencodage vidéo doit être confiée au service de traitement des ressources en créant les profils de traitement correspondants.
Recherche et indexation de contenu
Modifications apportées à la recherche et lʼindexation de contenu
Le traitement sous-jacent des index et le moment dʼentrée en action ont subi des modifications importantes.
Assurez-vous de comprendre pleinement et de refactoriser les index Oak avant de les gérer dans le code que vous déployez.
Certaines tâches de maintenance ne sont pas configurables
Tâches de maintenance AEM as a Cloud Service
Vous ne pouvez configurer que certaines tâches de maintenance avec AEM as a Cloud Service.
Modifications apportées au référentiel de publication
Les modifications directes du référentiel de publication ne sont pas autorisées, sauf celles effectuées sous /home. Il est toujours recommandé de distribuer les modifications apportées à l’instance de création. Toutes les modifications de code et de configuration doivent être déployées via le pipeline correspondant de Cloud Manager.
Configurations et mise en cache du Dispatcher
Gestion du cache du Dispatcher en mode cloud
Les configurations du Dispatcher doivent suivre une structure spécifique.
Les configurations doivent être gérées dans le cadre du code et déployées via le pipeline Cloud Manager.
Sauvegarder et restaurer
Sauvegarde et restauration d’AEM as a Cloud Service
Modifications de l’authentification
Prise en charge IMS d’AEM as a Cloud Service
Si vous utilisiez précédemment l’intégration SAML 2.0 sur les instances de création et de publication avant de passer à Cloud Service, notez que le principal changement est que l’instance de création d’AEM as a Cloud Service s’intègre uniquement à Adobe IMS. Cependant, l’instance de publication d’AEM as a Cloud Service peut toujours utiliser SAML ou d’autres intégrations d’authentification. AEM as a Cloud Service ne prend en charge l’authentification IMS que pour les utilisateurs et utilisatrices ayant les droits de création, d’administration et de développement. L’authentification IMS n’offre pas de prise en charge pour les utilisateurs finaux externes de sites clients tels que les visiteurs de site.

Fonctionnalités obsolètes deprecated-features

Adobe étudie constamment les fonctionnalités du produit de façon à les réinventer au fil du temps ou à remplacer les fonctions plus anciennes par des variantes plus modernes, pour améliorer la valeur client globale, le tout en faisant toujours attention à la compatibilité ascendante.

Adobe vous recommande de consulter les Fonctionnalités obsolètes pour vous familiariser avec les fonctionnalités signalées comme étant obsolètes dans Experience Manager as a Cloud Service. Découvrez l’impact sur votre déploiement AEM.

Planifier la révision de votre installation AEM review-planning

Après avoir pris connaissance des modifications apportées à AEM as a Cloud Service, il est temps de commencer à planifier un examen de votre installation existante. Vous pourrez ainsi évaluer le niveau de modifications requis pour le déplacement vers le cloud.

La figure suivante présente les principales étapes impliquées lors de la phase de révision :

Principales étapes impliquées lors de la phase de révision

Ensuite, vous allez explorer en détail la signification de chacune de ces étapes.

Évaluer le niveau de préparation pour la transition vers Cloud Service assess-cloud-readiness

La première étape consiste à évaluer votre préparation pour passer de votre version d’AEM existante à Cloud Service et à déterminer les domaines qui nécessitent une refactorisation afin d’être compatibles avec AEM as a Cloud Service.

Effectuez une évaluation complète de votre code source AEM actuel par rapport aux modifications notables et aux fonctionnalités obsolètes afin de déterminer le niveau d’effort attendu dans le parcours de transition.

La quantité de connaissances influence directement les chronologies et la réussite globale du projet. Par conséquent, Adobe vous recommande d’en obtenir le plus possible afin de pouvoir planifier la diffusion. Vous pouvez également lancer des discussions afin de reconcevoir les personnalisations qui doivent être conformes aux bonnes pratiques d’AEM as a Cloud Service.

Analyseur des bonnes pratiques

Vous pouvez accélérer l’évaluation en exécutant l’analyseur des bonnes pratiques par rapport à votre version d’AEM actuelle. Une bonne compréhension de son fonctionnement est essentielle pour accélérer la planification de votre évaluation.

Vous pouvez en savoir plus sur son fonctionnement en consultant la documentation Analyseur des bonnes pratiques.

Création d’un rapport d’évaluation du niveau de préparation pour la transition vers Cloud

L’étape suivante consiste à créer un rapport basé sur toutes les connaissances acquises jusqu’à présent. Vous créez des rapports Best Practices Analyzer à partir des instances d’évaluation et de production, puis les chargez dans Cloud Acceleration Manager pour obtenir un rapport digestible d’éléments exploitables.

Un rapport type doit contenir les entrées suivantes :

  • Documentation détaillant l’ensemble des fonctionnalités de votre installation AEM particulière.
  • Détails sur vos configurations et code personnalisés AEM.
  • Configurations du Dispatcher de production.
  • Configurations du réseau de diffusion de contenu (le cas échéant).

Socialisation du rapport

Une fois les rapports Best Practices Analyzer terminés, partagez-les avec les équipes appropriées afin de confirmer vos résultats et de planifier vos prochaines étapes. En fonction des préférences, vous pouvez également distribuer une version imprimée du rapport à l’aide de l’option Aperçu avant impression.

Examen de la planification des ressources review-resource-planning

Une fois que vous avez estimé le niveau d’effort requis pour passer à Cloud Service, vous devez identifier les ressources, créer une équipe et définir les rôles et les responsabilités pour le processus de transition.

Définition des indicateurs de performance clés (IPC) establish-kpis

Si vous n’avez pas encore défini d’indicateurs de performance clés (IPC), il est recommandé d’établir des indicateurs de performance clés pour votre implémentation AEM afin d’aider votre équipe à se concentrer sur ce qui importe le plus.

Voir Développement des KPI pour savoir comment choisir les KPI appropriés à vos objectifs métier.

Prochaines étapes what-is-next

Une fois que vous avez compris la portée des modifications requises pour passer à AEM as a Cloud Service, il est temps de Rendre votre code et votre contenu prêts pour le cloud avant d’effectuer la migration.

Ressources supplémentaires additional-resources

recommendation-more-help
fbcff2a9-b6fe-4574-b04a-21e75df764ab