Show Menu
SUJETS×

Nouveautés et différences

Depuis de nombreuses années, AEM est disponible :
  • Local
  • en tant que service géré
Il existe des différences intrinsèques entre ces approches antérieures et l'AEM en tant que Cloud Service :
Ces aperçus ne sont pas exhaustifs, mais visent à fournir une introduction.
Pour plus d'informations sur les versions sur site et de service géré, consultez la documentation relative à l' AEM 6.5 .

Architecture

Pour plus de détails, voir Architecture .
AEM as a Cloud Service présente désormais les caractéristiques suivantes :
  • Une architecture dynamique avec un nombre variable d’images AEM.

Architecture dynamique

Cette architecture :
  • est mise à l’échelle en fonction du trafic réel et de l’activité réelle  ;
  • comporte des instances individuelles qui ne s’exécutent que lorsque cela s’avère nécessaire ;
  • utilise des applications modulaires ;
  • comprend un cluster d’auteur par défaut, ce qui permet d’éviter les temps d’arrêt pour les tâches de maintenance.
Cela permet une mise à l’échelle automatique pour divers schémas d’utilisation :

Mise à l’échelle automatique pour divers schémas d’utilisation

Mises à jour AEM

Pour plus d'informations, reportez-vous à l' AEM Version Updates .
aem en tant que Cloud Service utilise maintenant l'intégration continue et la Diffusion continue (CI/CD) pour s'assurer que vos projets se trouvent sur la version AEM la plus récente. Cela signifie que les instances Production et Stage sont mises à jour vers la dernière version AEM sans interruption de service pour les utilisateurs.
Si la mise à jour de l’environnement de production échoue, Cloud Manager annule automatiquement l’environnement d’évaluation. Cette opération est effectuée automatiquement pour s’assurer qu’une fois la mise à jour terminée, les environnements d’étape et de production se trouvent sur la même version AEM.
aem mises à jour de version sont de deux types :
  • Mises à jour Push AEM
    • Peut être publié quotidiennement.
    • Principalement la maintenance, y compris les derniers correctifs de bogues et les mises à jour de sécurité.
      Les modifications étant appliquées régulièrement, l’impact est incrémentiel, ce qui réduit l’impact sur votre service.
  • Nouvelles fonctionnalités mises à jour
    • Publié selon un calendrier mensuel prévisible.

Cloud Manager

adobe Cloud Manager fait partie intégrante de l’approche de mise à niveau continue de l’AEM en tant que Cloud Service, car il contrôle toutes les mises à jour apportées à vos instances - ce qui est obligatoire.
Les mises à jour peuvent être déclenchées par Adobe lorsqu’une nouvelle version du service cloud est disponible. Vous pouvez également déclencher les mises à jour de votre application à l’aide des pipelines fournis par Cloud Manager.
Cloud Manager est :
  • utilisé pour gérer les programmes et environnements AEM,
  • une composante essentielle de l'AEM en tant que Cloud Service ; chaque nouveau client est d’abord configuré pour l’accès à Cloud Manager,
  • point d’entrée unique pour votre personnel d’exploitation et de développement.
Plus précisément, le nombre et le type d’programmes d’AEM pouvant être créés à partir de Cloud Manager sont dérivés de :
  • du contrat de licence client,
  • d'acteurs internes lorsque l'AEM en tant que Cloud Service est utilisé pour l'activation ou la formation,
  • des processus externes tels que les essais ont commencé à partir de Adobe.com.
Cloud Manager a évolué en tant que portail en libre-service où les principaux composants de l’AEM en tant que Cloud Service peuvent être créés et configurés :
  • Création et gestion de nouveaux programmes. Pour plus d'informations, consultez Présentation des Programmes et des types de Programme.
  • Création et gestion des environnements AEM dans ces programmes. Refer to Managing Environments for more details.
  • Création et gestion des pipelines pour le déploiement du code client et de la configuration associée sur un environnement spécifique. Consultez Configuration de votre pipeline CI-CD pour plus d'informations.
  • Être informé des événements de cycle de vie importants de ces composants (par exemple, les mises à jour de produits).
Actuellement, Cloud Manager est en mesure de créer des environnements dans 3 régions géographiques (avec plus de régions suivantes) :
  • États-Unis (Est)
  • EMEA (Pays-Bas)
  • APAC (Australie)
Reportez-vous à Accès au Experience Manager en tant que Cloud Service pour commencer à utiliser Cloud Manager en AEM en tant que Cloud Service.

Intégration

Pour plus d’informations, voir Intégration .
Le démarrage et la gestion d'un projet AEM sont simples lorsque l'utilisation d'AEM en tant que service Cloud en tant qu'Adobe est responsable de nombreux aspects :
  • Les images d’AEM de référence sont optimisées pour des cas d’utilisation spécifiques.
  • La plupart des tâches de configuration manuelle ont été rendues redondantes.
Elle est également très différente de celle qui existe actuellement :
  • une phase d'évaluation pour s'assurer que toutes les conditions préalables ont été remplies ; par exemple :
    • Exigences juridiques
    • Accords contractuels
    • Exigences techniques pour tout contenu et/ou code existant personnalisé par le client
  • Conditions requises pour le déploiement :
    • Mises à jour du code ; toutes les applications client développées pour une version précédente d'AEM devront être examinées et éventuellement mises à jour.
    • Migration du contenu

Développement

Pour plus de détails, vous pouvez début avec les lignes directrices Conseils de développement pour AEM as a Cloud Service de développement et Développement - le tutoriel WKND.
La nouvelle architecture qui prend en charge l'AEM en tant que Cloud Service implique quelques changements clés dans l'expérience globale des développeurs. L’un des principaux objectifs de l’AEM en tant que Cloud Service est de permettre aux clients expérimentés (ayant utilisé AEM sur site ou dans le contexte des services gérés Adobe) de migrer vers l’ le plus rapidement possible en tant que Cloud Service, sans avoir à réécrire la majeure partie de leur code personnalisé. Toutefois, certains ajustements pourraient encore être nécessaires.

Développement du cloud

Pour que les applications AEM existantes s’exécutent sur AEM en tant que Cloud Service, les étapes suivantes sont attendues :
  • Le code et la configuration de l’application doivent être stockés dans le référentiel de code Git du programme Cloud Manager associé.
  • Le code et la configuration de l'application doivent être compatibles avec la dernière version de l'AEM de ligne de base (qui peut changer quotidiennement).
    • L’application cliente doit être créée et déployée à l’aide du pipeline Cloud Manager associé à l’environnement Cloud Manager.
  • L'application cliente doit transmettre toutes les barrières de qualité, de sécurité et de performances du code appliquées dans le pipeline.
  • Les images créées pour l’application cliente doivent être déployées par le pipeline Cloud Manager.
Ce processus est généralement appelé développement Cloud initial. Comme la durée de bout en bout doit prendre des minutes (de 20 à 50 selon la complexité de l'application), il est nécessaire d'adopter des méthodologies de développement rapide avant que le code en attente et les modifications de configuration ne soient tentées dans le cloud.
La console Web, dans laquelle les lots OSGI et leur configuration associée sont gérés, et qui faisait auparavant partie de l'AEM QuickStart, n'est plus directement accessible aux utilisateurs d'un AEM en tant qu'environnement Cloud Service. Cette interface est toujours accessible en mode lecture seule à l’aide d’une nouvelle console de développement. Avec cette console, les développeurs peuvent sélectionner et se connecter directement à n’importe quel noeud particulier d’un service d’auteur ou de publication, puis accéder aux zones bloquées par défaut.
Voir aussi Configuration OSGi
Une autre exigence courante pour les développeurs est l'accès rapide aux fichiers journaux des différents environnements. Avec l’AEM en tant que Cloud Service, les fichiers journaux des différents noeuds des noeuds d’auteur et de publication sont disponibles via Cloud Manager, sous la forme de fichiers pouvant être téléchargés ou via des API.
En raison de la séparation claire du code et du contenu, les développeurs peuvent utiliser un processus particulier de mise à jour du contenu dans le cadre d’un déploiement. Les cas d’utilisation types pour le contenu mutable sont les suivants :
  • Contenu par défaut standard faisant partie du projet client (dossiers, modèles, workflows, etc.)
  • Rechercher les définitions d'index
  • Listes ACL et autorisations
  • Utilisateurs du service et groupes d’utilisateurs

Développement local

Afin de soutenir les itérations et le développement rapides, il est également possible de développer des applications AEM en dehors de l'AEM en tant que contexte Cloud Service. À cette fin, les artefacts suivants sont mis à la disposition des développeurs :
  • L'AEM en tant que Cloud Service QuickStart : un programme d'installation autonome .jar basé sur la dernière base de code AEM, avec la même surface fonctionnelle et API.
  • L’AEM en tant que SDK Cloud Service Dispatcher : un processus basé sur les images pour tester et valider localement les configurations du répartiteur
Notez que Cloud QuickStart ne prend pas en charge toutes les fonctionnalités AEM Sites et AEM Assets. Il s'agit d'un simple environnement d'auteur où la majorité des extensions peuvent être développées et testées.

Opérations et performances

Pour plus d’informations, commencez par Sauvegarde , Indexation et autres tâches de maintenance .
Avec l'AEM en tant que Cloud Service, ces opérations sont automatisées de sorte que toute interruption de service n'est plus nécessaire.
Dans ces domaines :
  • De nombreuses tâches ont été automatisées.
  • Les topologies sont optimisées pour une résilience et une efficacité optimales ; par exemple, la réplication binaire est la réplication par défaut.
  • Les tâches à charge importante, telles que les files d’attente, les tâches et les tâches de traitement en masse, ont été déplacées hors de l’instance AEM principale pour être gérées par des micro-services partagés et dédiés.
Les opérations d'AEM en tant que Cloud Service sont également soutenues par une nouvelle infrastructure de surveillance, de rapports et d'alerte. Cela permet aux SREs Adobes (Ingénieurs de fiabilité du site) de maintenir le service en bonne santé de façon proactive. Les différents éléments de l'architecture sont équipés d'une variété de contrôles de santé. Si, pour une raison quelconque, un noeud particulier de l'architecture est jugé malsain, il est retiré du service et remplacé en silence par un nouveau noeud sain.

Gestion d’identité

Pour plus de détails, voir Sécurité - Soutien IMS.
Un changement majeur apporté à l’AEM en tant que Cloud Service est l’utilisation entièrement intégrée des identifiants d’Adobe pour l’accès au niveau auteur.
Pour ce faire, vous devez utiliser la console d’administration des Adobes pour gérer les utilisateurs et les groupes d’utilisateurs. Les comptes d’utilisateurs permettent à vos utilisateurs d’accéder aux produits et services d’Adobe, dans la mesure où les informations utilisateur-profil sont centralisées dans l’Adobe Identity Management System (IMS) à partager dans tous les services de cloud. Une fois que l'accès à l'AEM est accordé, les comptes d'utilisateurs peuvent être référencés en AEM en tant que Cloud Service (comme auparavant); par exemple, pour définir des rôles et des autorisations à partir des interfaces utilisateur AEM Security.
Cela permet de combiner les avantages suivants :
  • Utilisation de l’Adobe Identity Management System (IMS) pour fournir une authentification unique à toutes les applications de cloud d’Adobes.
  • Préférences utilisateur restantes locales pour chaque instance particulière d’AEM en tant que Cloud Service.

Interface utilisateur de création

Pour plus de détails, la gestion Manipulation de base de base est un bon point de départ.
Les principes de base de l’interface utilisateur de création, tant pour les sites que pour les ressources, seront très familiers à toute personne qui a utilisé AEM dans le passé.
La principale différence réside dans le fait que l’interface utilisateur est uniquement tactile ; l’interface utilisateur classique n’est plus disponible. Sinon, les bases restent inchangées, avec seulement de petits changements apparents.

AEM Sites

adobe experience manager sites en tant que Cloud Service vous permet de fournir à vos clients des expériences personnalisées basées sur le contenu, en combinant la puissance du système d’Gestion de contenu AEM avec AEM Digital Asset Management.
Pour plus d'informations, reportez-vous à l'aperçu des modifications apportées aux sites .

AEM Assets

Adobe Experience Manager Assets en tant que Cloud Service offre une solution SaaS native de cloud pour les entreprises, qui leur permet non seulement d’exécuter rapidement et efficacement leurs opérations de gestion des ressources numériques et de médias dynamiques, mais également d’utiliser des fonctionnalités intelligentes de prochaine génération, telles que l’IA/ML, à partir d’un système toujours à jour, toujours disponible et toujours en cours d’apprentissage.
L’offre de ressources inclut le traitement des ressources de nouvelle génération dans le cloud et la recherche et l’assimilation des ressources hautes performances.