Prise en main d’AEM découplé getting-started

Dans cette partie du parcours de développement découplé, découvrez ce qui est nécessaire pour démarrer votre propre projet avec AEM découplé.

Un peu d’histoire… story-so-far

Dans le document précédent relatif au parcours concernant AEM découplé, Découvrir le développement découplé du système de gestion de contenu (CMS), vous avez appris la théorie de base d’un CMS découplé et vous devez maintenant :

Cet article s’appuie sur ces principes fondamentaux pour vous permettre de comprendre comment utiliser AEM lors de la mise en œuvre d’une solution découplée.

Objectif objective

Ce document est destiné à vous permettre de mieux comprendre AEM découplé dans le contexte de votre propre projet. Après l’avoir lu, vous devriez :

Notions de base concernant AEM aem-basics

Avant de pouvoir définir votre projet découplé dans AEM, il est important de comprendre certains concepts AEM de base.

Instance d’auteur author

Dans sa forme la plus simple, AEM se compose d’une instance d’auteur et d’une instance de publication qui fonctionnent conjointement pour créer, gérer et publier votre contenu.

Le contenu commence sur l’instance d’auteur où les auteurs le créent. L’environnement de création propose différents outils pour que les auteurs puissent créer, organiser et réutiliser leur contenu.

Instance de publication publish

Une fois que le contenu a été créé sur l’instance d’auteur, il doit être publié pour permettre à d’autres services de l’utiliser. Une instance de publication contient tous les contenus publiés.

Réplication replication

La réplication consiste à transférer le contenu entre l’instance de création et celle de publication. Cette opération est effectuée automatiquement par AEM lorsqu’un auteur ou un autre utilisateur disposant des droits appropriés publie du contenu.

Résumé des notions de base concernant AEM aem-basics-summary

À son niveau le plus simple, la création d’expériences digitales dans AEM nécessite les étapes suivantes :

AEM découplé s’appuie sur cette base technique en offrant des outils puissants pour gérer le contenu en mode découplé, approche décrite dans la section suivante.

Concepts de base d’AEM découplé aem-headless-basics

Les fonctionnalités d’AEM découplé sont basées sur quelques fonctionnalités essentielles. Elles sont expliquées en détail dans les parties ultérieures du parcours. Le plus important, pour le moment, c’est de savoir pour l’essentiel ce que font ces fonctionnalités et leur dénomination.

Modèles de fragment de contenu content-fragment-models

Les modèles de fragment de contenu définissent la structure des données et du contenu que vous créez et gérez dans AEM. Il s’agit en quelque sorte du squelette de votre contenu. Lorsque vous choisissez de créer du contenu, vos auteurs choisissent parmi les modèles de fragment de contenu que vous définissez, ce qui les guide dans la création de contenu.

Fragments de contenu content-fragments

Les fragments de contenu vous permettent de concevoir, de créer, d’organiser et de publier du contenu indépendant des pages. Ils permettent de préparer le contenu prêt à être utilisé dans des emplacements multiples et sur plusieurs canaux.

Les fragments de contenu contiennent du contenu structuré et peuvent être diffusés au format JSON.

API GraphQL et REST apis

Pour modifier votre contenu en mode découplé, AEM propose deux API robustes.

Vous découvrirez ces API et comment les utiliser dans une partie ultérieure du parcours AEM découplé. Vous pouvez également consulter la section Ressources supplémentaires pour plus d’informations.

Niveaux d’intégration en mode découplé integration-levels

AEM prend en charge les modèles Découplé et Pile complète traditionnelle d’un CMS. Cependant, AEM offre non seulement ces deux choix exclusifs, mais aussi la possibilité de prendre en charge des modèles hybrides conjuguant les avantages de l’un et de l’autre, offrant ainsi une flexibilité inégalée pour votre projet découplé.

Pour vous assurer de bien comprendre le concept de découplage, ce parcours de développement découplé AEM se concentre sur le modèle purement découplé, ce qui vous permettra d’être opérationnel le plus rapidement possible sans codage dans AEM.

Toutefois, vous devez tenir compte des possibilités hybrides supplémentaires qui s’offrent à vous une fois que vous avez compris les fonctionnalités découplées d’AEM. Ces cas sont présentés ci-dessous pour que vous puissiez en prendre connaissance. À la fin du parcours, vous découvrirez plus en détail ces concepts si cette flexibilité est nécessaire pour votre projet.

Vous utilisez déjà de manière externe des contenus découplés, par exemple avec les applications monopage (SPA). already-have-a-spa

Supposons que votre besoin de base soit au minimum de diffuser du contenu depuis AEM vers un service externe existant.

Niveau 1 : intégration de fragments de contenu – Modèle découplé traditionnel level-1

Ce niveau d’intégration est le modèle découplé traditionnel. Il permet aux auteurs de créer des contenus dans AEM et de les diffuser sans interface utilisateur vers un certain nombre de services externes à l’aide de GraphQL, ou de les modifier dans des services externes à l’aide de l’API Assets. Aucun codage n’est nécessaire dans AEM.

Dans ce modèle, AEM ne sert qu’à créer et à diffuser du contenu en utilisant des fragments de contenu AEM. Le rendu et l’interaction avec le contenu sont délégués à l’application externe consommatrice, souvent une application monopage.

Niveau 2 : incorporation de la SPA dans AEM – Modèle hybride level-2

Ce niveau d’intégration repose sur le premier niveau, mais permet également à l’application externe (SPA) d’être incorporée dans AEM afin que les auteurs puissent voir le contenu dans le contexte de l’application externe, dans AEM. L’application peut également prendre en charge la modification limitée de l’application externe dans AEM.

Ce niveau a l’avantage de permettre aux auteurs de créer du contenu de manière flexible et sécurisée dans AEM. Les contenus sont ainsi présentés dans leur contexte avec une SPA externe incorporée, tout en diffusant le contenu hors interface utilisateur.

Niveau 3 : incorporation et activation complète des SPA dans AEM – Modèle hybride level-3

Ce niveau d’intégration repose sur le niveau 2 en permettant de modifier l’essentiel du contenu de la SPA externe dans AEM.

Vous n’avez pas encore de consommateur externe de contenu découplé, par exemple les applications monopages. do-not-have-a-spa

Si votre objectif est de créer une SPA qui consomme du contenu en toute sécurité depuis AEM, vous pouvez utiliser des fonctionnalités telles que les fragments de contenu pour gérer votre contenu découplé et créer également une SPA avec le framework de l’éditeur de SPA d’AEM.

Avec cet éditeur, la SPA consomme non seulement du contenu issu d’AEM, mais elle est en outre entièrement modifiable dans AEM par les auteurs ou autrices de contenu, ce qui vous donne à la fois la flexibilité d’une diffusion découplée et de la modification replacée dans son contexte au sein d’AEM.

Exigences et conditions préalables requirements-prerequisites

Un certain nombre d’exigences s’imposent avant de vous engager dans votre projet AEM découplé.

Connaissances knowledge

Outils tools

Définition de votre projet defining-your-project

Pour la réussite d’un projet, il est important de définir clairement non seulement les exigences du projet, mais aussi les rôles et les responsabilités.

Portée scope

Il est très important de définir clairement la portée du projet. La portée définit les critères d’acceptation et permet d’établir une définition de l’état « terminé ».

La première question que vous devez vous poser est la suivante : « Quel est l’objectif que je veux atteindre grâce à AEM Headless ? » En général, la réponse devrait indiquer que vous disposez ou disposerez d’une application d’expérience créée avec vos propres outils de développement, et non avec AEM. Cette application d’expérience peut être une application mobile, un site web ou toute autre application d’expérience destinée aux utilisateurs finaux. La finalité d’AEM découplé est d’alimenter votre application d’expérience en contenus créés, stockés et gérés dans AEM à l’aide d’API dernier cri. Celles-ci appellent AEM découplé pour récupérer du contenu, ou même du contenu intégralement CRUD, directement depuis votre application d’expérience. Si ce n’est pas ce que vous souhaitez faire, vous devrez probablement revenir à la documentation d’AEM et déterminer la section la mieux adaptée à ce que vous souhaitez accomplir.

Rôles et responsabilités roles-responsibilities

Les rôles de chaque projet individuel varient, mais les plus importants à prendre en compte pour le contenu du développement découplé AEM sont les suivants :

Administrateur administrator

L’administrateur est responsable de l’installation et de la configuration de base de votre système. Par exemple, l’administrateur configure votre organisation dans le système de gestion des utilisateurs d’Adobe, désigné sous le nom d’IMS (Identity Management System). Il est le premier utilisateur de l’organisation à recevoir une invitation d’Adobe par e-mail, une fois votre organisation créée dans I’IMS. L’administrateur a la possibilité de se connecter à l’IMS et d’ajouter des utilisateurs d’autres personnages.

Une fois les personnes configurées par l’administrateur ou l’administratrice, celles-ci possèdent les autorisations nécessaires pour accéder à toutes les ressources d’AEM. Ils pourront ainsi accomplir leur travail de contributeurs pour la diffusion de l’application d’expérience à l’aide d’AEM Headless.

L’administrateur doit être l’utilisateur qui a installé AEM et préparé l’environnement d’exécution pour permettre aux auteurs de contenu de créer et de mettre à jour du contenu, et aux développeurs d’utiliser des API qui récupèrent ou modifient du contenu pour leurs applications d’expérience.

Auteur de contenu content-author

Les personnes chargées de la création de contenu créent et gèrent le contenu diffusé de manière découplée par AEM. Pour gérer leurs contenus, les auteurs utilisent les fonctionnalités d’AEM, notamment les fragments de contenu et la console Assets.

Elles doivent garder à l’esprit les bonnes pratiques suivantes.

Planification de la traduction translation

Planifiez la traduction dès le début de votre projet. Considérez le « Spécialiste de traduction » comme un profil à part entière. Sa responsabilité consiste à définir les contenus à traduire et ceux qui ne doivent pas l’être, et les contenus traduits qui peuvent être modifiés par les producteurs de contenus régionaux ou locaux.

Créez un plan pour la traduction de contenu dont vous avez besoin.

Clarifiez la situation concernant votre workflow de mise à jour de contenu. Quel est le processus d’approbation que le système doit prendre en charge ? Est-il possible d’utiliser des workflows AEM pour automatiser ce processus ?

Notez qu’il est possible d’utiliser votre hiérarchie de contenu pour faciliter la traduction.

Consultez la section des ressources supplémentaires pour obtenir de la documentation supplémentaire sur les workflows AEM et les outils de traduction, y compris des liens vers le parcours de traduction découplée AEM.

Tirer parti de la hiérarchie du contenu content-hierarchy

La hiérarchie des dossiers peut répondre à deux préoccupations majeures concernant la gestion des contenus :

AEM offre une structure de contenu flexible, car une hiérarchie peut être arbitrairement volumineuse. Toutefois, il est important de comprendre que toute modification de la structure des dossiers peut avoir des conséquences inattendues sur les requêtes existantes qui dépendent du chemin d’accès au contenu. Une hiérarchie bien définie, établie avec clarté à l’avance, peut donc être utile pour les auteurs de contenu.

Les dossiers peuvent également être limités de manière à n’autoriser que certains types de contenu (en fonction des modèles de fragment de contenu). Il est recommandé de toujours spécifier explicitement les modèles autorisés pour tous les dossiers de la hiérarchie. Spécification du contenu autorisé pour un dossier donné :

En créant une structure de contenu appropriée, il devient plus facile de coordonner la création de contenus découplés sur plusieurs canaux afin d’optimiser la réutilisation de ces contenus. L’utilisation du contenu sur plusieurs canaux améliore considérablement l’efficacité de la production et la gestion des modifications.

Définir de bonnes conventions d’affectation de noms naming-conventions

Les noms des fragments de contenu doivent être explicites pour les auteurs de contenu. AEM gère de manière transparente l’échappement et/ou la troncation des noms utilisés pour les ID au niveau du référentiel. Les noms logiques attribués par les auteurs de contenu doivent donc toujours être lisibles et représenter le contenu.

Voir la section Ressources supplémentaires pour accéder à d’autres documentations à propos des conventions d’affectation de noms de pages dans AEM.

Ne pas étendre excessivement l’imbrication de contenu content-nesting

Les fragments de contenu sont utilisés dans AEM pour créer des contenus en mode découplé. AEM prend en charge jusqu’à dix niveaux d’imbrication pour les fragments de contenu. Toutefois, il faut garder à l’esprit qu’AEM devra résoudre de manière itérative chaque référence définie dans le fragment de contenu parent, puis vérifier s’il existe des références enfants dans tous les frères. Ces opérations peuvent rapidement se cumuler et poser des problèmes de performances.

En règle générale, les références aux fragments de contenu ne doivent pas être imbriquées au-delà de cinq niveaux.

Architecte de contenu content-architect

Les architectes de contenu analysent les exigences relatives aux données qui doivent être diffusées en mode découplé, et définissent la structure de ces données. Dans AEM, ces structures sont appelées Modèles de fragment de contenu. Les modèles de fragments de contenu servent de base pour les fragments de contenu créés par les auteurs.

Lors de la définition de modèles de fragment de contenu, il peut être utile de créer des modèles associés aux composants d’expérience utilisateur des applications qui consomment les contenus.

Comme les auteurs interagissent avec les modèles de manière permanente lorsqu’ils créent des contenus, l’alignement des modèles avec l’expérience utilisateur les aide à visualiser l’expérience digitale obtenue. Pour aller plus loin, vous pouvez attribuer des icônes aux modèles de fragment de contenu qui représentent l’élément d’expérience utilisateur afin que les auteurs puissent sélectionner intuitivement le bon modèle en fonction des indices visuels.

Développeur developer

Les équipes de développement sont chargées de rapprocher le contenu créé dans AEM découplé et le consommateur de ce contenu. Souvent il s’agit d’une application monopage, d’une application web progressive (PWA), d’une boutique en ligne ou d’un autre service extérieur à AEM.

GraphQL sert de « liant » entre AEM et les consommateurs de contenu en mode découplé. GraphQL est un langage qui permet d’interroger AEM pour obtenir le contenu nécessaire.

Les développeurs doivent garder à l’esprit quelques recommandations de base lorsqu’ils planifient leurs requêtes :

Pour une mise en œuvre découplée de type général à l’aide d’AEM, un développeur n’a besoin d’aucune connaissance en matière de codage avec AEM.

Exigences de performance performance-requirements

Pour la réussite d’un projet, les performances doivent être prises en compte avant la création d’un contenu.

Veillez à comprendre les attentes de vos utilisateurs et utilisatrices ou visiteurs et visiteuses et concevoir le projet pour eux. Définissez des objectifs de niveau de service (SLO) et mesurez-les pour savoir si vous répondez aux attentes de vos utilisateurs et utilisatrices.

Modèles de trafic traffic-patterns

Pour comprendre le trafic et les schémas de trafic, commencez par recueillir des connaissances à propos du passé, puis effectuez une projection de la croissance attendue pour les prochaines années. Certaines des variables les plus importantes à prendre en compte :

Fréquence de mise à jour update-frequency

Souvent, les différentes sections d’expériences ont des fréquences de mises à jour de contenu variables. Il est important de comprendre cela pour pouvoir affiner les configurations du réseau de diffusion de contenu (CDN) et du cache. Il s’agit également d’une entrée importante pour les Architectes de contenu, car ils conçoivent des modèles pour représenter votre contenu. Prenez en compte les éléments suivants :

Prochaines étapes what-is-next

Maintenant que vous avez terminé cette partie du parcours de développement découplé AEM, vous devriez pouvoir :

Vous devriez poursuivre votre parcours avec AEM découplé en consultant le document Accès à votre première expérience à l’aide d’AEM découplé. Vous pourrez y découvrir comment configurer les outils nécessaires et commencer à réfléchir à la modélisation de vos données dans AEM.

Ressources supplémentaires additional-resources

Bien qu’il soit recommandé de passer à la partie suivante du parcours de développement en mode découplé en examinant le document Accès à votre première expérience à l’aide d’AEM découplé, vous trouverez ci-après quelques ressources facultatives supplémentaires pour approfondir un certain nombre de concepts mentionnés dans ce document, mais non obligatoires pour poursuivre le parcours en mode découplé.