Le SDK d’AEM as a Cloud Service est constitué des artefacts suivants :
En outre, certains clients qui ont déjà été déployés avec AEM 6.5 ou des versions antérieures utiliseront les artefacts ci-dessous. Si la compilation locale ne fonctionne pas avec le fichier Quickstart Jar et que vous pensez que cela est dû à la suppression des interfaces d’AEM déployé en tant que Cloud Service, contactez le service clientèle pour déterminer si vous avez besoin d’un accès. Cela nécessitera des modifications sur le serveur principal.
Le SDK AEM as a Cloud Service permet de créer et de déployer du code personnalisé. Pour plus d’informations, consultez la documentation sur l’archétype de projet AEM. Voici ce qui est réalisé de manière générale :
Les mêmes opérations sont exécutées par Cloud Manager lors du déploiement vers des environnements cloud. L’exécution locale de compilations permet de développer et de tester localement afin que les développeurs puissent découvrir efficacement les problèmes de code ou de structure bien avant de s’engager dans le contrôle de code source et de déclencher des déploiements Cloud Manager, ce qui peut prendre plus de temps.
<dependency>
<groupId>com.adobe.aem</groupId>
<artifactId>aem-sdk-api</artifactId>
<version>2019.11.3006.20191108T223635Z-191201</version>
<scope>provided</scope>
</dependency>
L’entrée de version du SDK doit correspondre à la version d’AEM as a Cloud Service. Vous pouvez voir quelle version vous utilisez en vous connectant à AEM, puis en accédant au point d’interrogation dans le coin supérieur droit de l’écran et en sélectionnant À propos d’Adobe Experience Manager.
Quand est-il recommandé d’actualiser le projet local avec un nouveau SDK ?
Il est recommandé de l’actualiser au moins après une version de maintenance mensuelle.
Il est facultatif de l’actualiser après une version de maintenance quotidienne. Les clients seront informés lorsque leur instance de production a été correctement mise à niveau vers une nouvelle version d’AEM. Pour les versions de maintenance quotidiennes, il n’est pas prévu que le nouveau SDK change de manière significative, voire qu’il change du tout. Il est toutefois recommandé d’actualiser occasionnellement l’environnement de développement AEM local avec le dernier SDK, puis de recréer et de tester l’application personnalisée. La version de maintenance mensuelle comprend généralement des modifications ayant davantage d’impact. Les développeurs doivent par conséquent immédiatement actualiser, recréer et tester.
Voici la procédure recommandée pour actualiser un environnement local :
crx-quickstart
vers un autre dossier pour le conserver en lieu sûr.-r
).
Si du contenu doit être installé avec chaque nouvelle version de quickstart d’AEM, incluez-le dans un module de contenu et dans le contrôle de code source du projet. Installez-le ensuite à chaque fois.
Il est recommandé de mettre à jour fréquemment le SDK (par exemple, toutes les deux semaines) et de supprimer quotidiennement l’état local complet pour ne pas dépendre accidentellement de données avec état dans l’application.
Si vous dépendez de CryptoSupport (soit en configurant les informations d’identification des services cloud ou du service de messagerie SMTP dans AEM, soit en utilisant l’API CryptoSupport dans votre application), les propriétés sont chiffrées par une clé qui est générée automatiquement au premier démarrage de l’environnement AEM. Bien que la configuration du cloud s’occupe de réutiliser automatiquement la clé de chiffrement (CryptoKey) spécifique à l’environnement, il est nécessaire d’injecter la clé de chiffrement dans l’environnement de développement local.
Par défaut, AEM est configuré pour stocker les données clés dans le dossier de données d’un dossier, mais pour faciliter leur réutilisation dans le développement, le processus AEM peut être initialisé au premier démarrage avec « -Dcom.adobe.granite.crypto.file.disable=true
». Les données de chiffrement seront alors générées à l’emplacement « /etc/key
».
Pour pouvoir réutiliser des modules de contenu contenant les valeurs chiffrées, procédez comme suit :
-Dcom.adobe.granite.crypto.file.disable=true
». Il est recommandé de toujours l’ajouter, bien qu’il soit facultatif./etc/key
». Le secret sera alors réutilisé dans tous les environnements pour lesquels vous souhaitez qu’il le soit./crx/de
pour les ajouter au module qui sera réutilisé dans toutes les installations.