Implémentation d’un connecteur AEM

Dernière mise à jour : 18 octobre 2024
  • Rubriques :

Créé pour :

  • Administration

Les références fournies ci-dessous sont utiles pour la création AEM connecteurs et doivent être lues avec des conseils sur l’ envoi et la maintenance des connecteurs.

Une licence de développeur pour AEM peut être obtenue via le programme Adobe Exchange.

Modèles d’intégration courants

AEM est une solution de gestion de l’expérience web haut de gamme qui propose de nombreux domaines d’intégration potentiels. Les modèles d’intégration courants sont les suivants :

  • Extraction de données d’un système externe dans AEM ; par exemple, exporter des informations de contact depuis un système CRM afin de les mettre à la disposition d’un plus grand nombre de personnes qui visitent un site web utilisant la technologie AEM. Les implémentations doivent utiliser les tâches planifiées de Sling, ce qui garantit que la tâche est exécutée même si les conteneurs tombent en panne. Le code doit être conçu de manière à supposer que la tâche peut être déclenchée plusieurs fois.
  • Exportation de données d’AEM vers un système externe. Par exemple, les paramètres d’abonnement à la newsletter sont envoyés à un CRM sur un site web optimisé par AEM.
  • Récupération de ressources d’AEM. Il peut s’agir, par exemple, d’un système de gestion de contenu (CMS) externe faisant référence à une ressource stockée dans AEM Assets. Autre exemple : un système PIM lié à une image dans AEM Assets.
  • Stockage de ressources dans l’infrastructure AEM. Il peut s’agir, par exemple, d’un système de gestion des ressources marketing (MRM) qui stocke une ressource approuvée dans AEM Assets.
  • Configuration et rendu d’un composant d’interface utilisateur personnalisé. Vous pouvez, par exemple, autoriser un auteur à faire glisser un composant vidéo et à configurer une vidéo spécifique pour qu’elle soit lue sur le site en direct.
  • Utilisation d’une ressource avec un service partenaire. Il s’agit, par exemple, de l’envoi d’une ressource vers une plateforme vidéo lorsqu’une page est publiée.
  • Analyse d’un site, d’une page ou d’une ressource dans l’Admin Console AEM. Il peut s’agir, par exemple, de recommandations d’optimisation du moteur de recherche pour une page existante ou dépubliée.
  • Accès au niveau de la page aux données utilisateur gérées par un service externe. Il peut s’agir, par exemple, d’utiliser des informations démographiques pour personnaliser l’expérience sur le site. Apprenez-en plus sur ContextHub, un framework qui permet de stocker, de manipuler et de présenter des données de contexte.
  • Traduction d’une copie de site ou de métadonnées de ressource. Rendez-vous sur la page AEM Translation Framework Bootstrap Connector pour obtenir un exemple qui utilise AEM Translation Framework, l’implémentation privilégiée pour les connecteurs de traduction.

Documentation utile

La documentation d’Experience Manager as a Cloud Service contient de précieuses informations sur le développement dans AEM. Vous trouverez, ci-dessous, quelques rubriques et références techniques que vous trouverez utiles lors de l’implémentation d’un connecteur AEM :

  • Adobe Consulting Services (ACS) AEM Samples : code commenté destiné à aider les développeurs AEM
  • Divers liens de documentation dans la section Modèles d’intégration courants de cet article

Ressources de la communauté

Outre la documentation statique ci-dessus, Adobe et la communauté AEM proposent des ressources destinées à faciliter la commercialisation d’un connecteur :

  • Le forum AEM de la communauté Adobe est un site actif sur lequel vous pouvez poser des questions et obtenir des réponses de vos pairs.
  • D’autres ressources techniques Adobe sont disponibles pour certains niveaux de partenaire. En savoir plus sur le programme Adobe Exchange.
  • Si votre entreprise souhaite obtenir une assistance en matière d’implémentation, contactez l’équipe Services professionnels d’Adobe ou utilisez le Solution Partner Finder pour obtenir la liste des partenaires d’Adobe dans le monde entier.

Règles de structure du package

Pour faciliter les déploiements continus, les modules AEM as a Cloud Service, tels que les connecteurs, maintiennent une stricte division entre le contenu "non modifiable" et le contenu "modifiable". Les packages doivent être clairement organisés pour inclure :

  • /apps
  • /content et /conf

Les connecteurs doivent respecter les directives de conditionnement décrites sous AEM Structure de projet. Les connecteurs existants doivent également être restructurés pour être conformes.

En outre, seul Adobe doit écrire du code dans /libs ; les clients et les partenaires écrivent du code dans /apps.

Les connecteurs existants peuvent également être restructurés pour déplacer toute configuration qui aurait pu placer /etc dans d’autres dossiers de niveau supérieur, tels que /conf. Cette restructuration a été effectuée dans le cadre d’AEM 6.5 et est décrite dans la documentation d’AEM 6.5.

Adobe recommande de placer la plupart du code du connecteur sous /apps/connectors/<vendor> afin de maintenir une structure de référentiel propre, en particulier pour les clients qui utilisent plusieurs connecteurs.

Configuration de Cloud Services

L’un des aspects de l’implémentation du connecteur est le code qui sous-tend la configuration du connecteur. Ce code entraîne l’affichage d’une carte portant le nom du connecteur sous Outils > Opérations > Cloud Services. Lorsque vous cliquez dessus, un explorateur de configurations apparaît. Il permet au client de sélectionner le dossier parent où sera stockée la configuration du connecteur. Le code du connecteur doit générer un formulaire avec toutes les propriétés à configurer et stocker, au final, les valeurs dans un dossier de configuration sous /conf. Ce dossier pourra ensuite être sélectionné sous l’onglet Propriétés de Sites ou Propriétés d’Assets.

Configurations basées sur le contexte

Les configurations basées sur le contextevous permettent de superposer la configuration entre différents dossiers, y compris /libs, /apps, /conf et sous-dossiers sous /conf. L’héritage est pris en charge, de telle sorte qu’un client puisse définir la configuration globale tout en apportant des modifications spécifiques à chaque microsite. Comme il est possible d’utiliser cette fonctionnalité pour les configurations de Cloud Service, le code de connecteur doit référencer la configuration à l’aide de l’API Context-Aware Configuration au lieu de référencer un noeud de configuration spécifique.

Si des configurations modifiées sont utilisées dans le connecteur, concevez ce dernier de manière à gérer l’inclusion/la fusion des futures mises à jour apportées aux configurations par défaut fournies par le connecteur dans toute configuration client. Gardez à l’esprit que la modification du contenu ou des configurations personnalisées par le client sans préavis et sans consentement peut perturber ou provoquer un comportement inattendu dans leur connecteur.