Les informations fournies ci-dessous vous seront d’une grande utilité pour la création de connecteurs AEM. Elles doivent être lues parallèlement aux conseils sur l’envoi et la maintenance des connecteurs.
Notez qu’une licence de développeur pour AEM peut être obtenue via le programme Adobe Exchange.
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 :
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 :
Outre la documentation statique ci-dessus, Adobe et la communauté AEM proposent des ressources destinées à faciliter la commercialisation d’un connecteur :
Pour prendre en charge les déploiements en continu, AEM modules as a Cloud Service, dont les connecteurs sont des exemples, présentent une séparation stricte entre le contenu "non modifiable" et le contenu "modifiable". Les packages doivent être clairement séparés entre ceux qui incluent :
/apps
/content
et /conf
Les connecteurs doivent respecter les directives de conditionnement décrites dans cet article. 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.
Il est recommandé de placer la majorité du code du connecteur sous /apps/connectors/<vendor>
afin de promouvoir une structure de référentiel nette pour les clients qui ont plusieurs connecteurs.
Le code sur lequel est basée la configuration du connecteur constitue l’un des aspects de son implémentation. 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.
L’API Context-Aware Configuration permet de superposer la configuration entre différents dossiers, dont /libs
, /apps
et /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 Services, 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. Pour rappel, modifier la configuration ou le contenu personnalisé (tel que modifié par le client) sans en avertir le client ou obtenir son accord est de nature à entraîner la défaillance du connecteur (ou à provoquer un comportement inattendu).
AEM as a Cloud Service est une solution basée dans le cloud. Certaines directives peuvent donc avoir une incidence sur les stratégies de code d’un connecteur. Pour plus d’informations, voir Directives de développement pour AEM as a Cloud Service.
Pour créer des connecteurs (ou modifier des connecteurs existants), vous devez utiliser les techniques de développement de l’environnement local. L’équipe en charge des partenaires mettra à la disposition des partenaires ISV un sandbox dans lequel ils pourront déployer leur connecteur AEM sur une application Vanilla pour s’assurer qu’il fonctionne.