La section suivante décrit les notes de mise à jour générales d’Experience Manager as a Cloud Service 2020.7.0.
La date de publication d’Experience Manager as a Cloud Service version 2020.7.0 est le 30 juillet 2020.
Les connecteurs Experience Manager as a Cloud Service pour Adobe Target et Adobe Analytics sont améliorés de la manière suivante :
Une nouvelle implémentation de l’interface utilisateur remplace l’implémentation basée sur l’interface utilisateur classique.
Simplification des boîtes de dialogue de l’interface utilisateur, attribuant la création de framework pour le mappage des variables et d’autres configurations à Adobe Launch. Voir Intégration d’Adobe Analytics et Intégration d’Adobe Target.
Les configurations sont désormais stockées dans /conf
plutôt que /etc/cloudsettings
dans le référentiel Experience Manager.
Asset Compute Service est un service évolutif et extensible permettant de traiter les ressources. Les administrateurs peuvent configurer Experience Manager pour appeler des applications personnalisées créées à l’aide du Asset Compute Service. Les développeurs peuvent utiliser ce service pour créer des applications personnalisées spécialisées qui répondent à des cas d’utilisation complexes. Ce service web peut générer des miniatures pour différents types de fichiers et des rendus d’images haute qualité à partir de formats de fichiers Adobe, coder des vidéos (à venir), extraire des métadonnées, extraire du texte intégral en tant que précurseur de l’indexation et exécuter une ressource via tous les services Sensei disponibles. Voir Utilisation des microservices de ressources et des profils de traitement.
La configuration initiale de Dynamic Media dans Experience Manager as a Cloud Service est améliorée pour être plus robuste. Elle indique désormais aux administrateurs la progression des processus.
La publication des ressources dans Dynamic Media est simplifiée et rendue plus robuste en faisant une partie intégrante du processus de traitement global des ressources à l’aide de microservices de ressources et en améliorant le serveur principal de publication par lots.
Les étapes de workflow qui ne sont pas compatibles avec un déploiement de Cloud Service sont désormais signalées par un avertissement dans l’éditeur de modèle de workflow. De plus, lors de l’exécution des workflows existants dans un environnement Cloud Service, les étapes de workflow incompatibles sont ignorées.
Les modèles de workflow créés par les clients qui sont déployés vers /conf/global
dans le projet Git associé à l’environnement dans Cloud Manager sont automatiquement déployés vers /var
et sont donc disponibles dans Experience Manager. Les modèles de workflow de produit sous /libs
ayant été modifiés par le client ne sont pas automatiquement déployés vers /var
.
dam:size
et dam:sha1
sont exclues de l’écriture différée XMP. (CQ-4237355)AEM Commerce est désormais disponible dans Cloud Service.
Pour plus d’informations, reportez-vous à Prise en main d’AEM Commerce as a Cloud Service.
La version 2.11.0 des composants principaux AEM est maintenant disponible dans AEM Sites, notamment :
Introduction d’un nouveau composant Visionneuse PDF.
La prise en charge AMP (Accelerated Mobile Pages) des composants principaux est désormais disponible. Elle permet de générer des expériences client plus rapides en rendant la transition de page instantanée lors de l’accès au site à partir d’un résultat de recherche mobile Google, ce qui améliore l’engagement des utilisateurs et l’optimisation du moteur de recherche.
Pour plus d’informations, voir Prise en charge AMP des composants principaux.
Compatibilité avec la version 1.0.2 de la couche de données client Adobe.
Correctifs de bogues et amélioration de la qualité du code.
La date de publication de la mise à jour 2020.7.0 de Cloud Manager est le 09 juillet 2020.
La page Environnements a été repensée.
Les environnements en veille affichent désormais un état discret dans Cloud Manager.
Le nombre de variables d’environnement par environnement a été porté à 200.
Les pipelines de Cloud Manager prennent désormais en charge les variables et les secrets définis par le client.
Pour plus d’informations, consultez Variables de pipeline.
Les référentiels Maven privés liés à l’authentification sont désormais pris en charge.
Le conteneur de création Cloud Manager prend désormais en charge Java 8 et Java 11.
Consultez Utilisation de la prise en charge de Java 11 pour plus d’informations.
Le lien entre Cloud Manager et Developer Console était actif avant la création complète des environnements alors qu’il ne devait pas l’être.
Le lien direct vers Developer Console à partir de Cloud Manager n’affichait pas l’option permettant de mettre en veille/réactiver un environnement de programme Sandbox.
Les options Annuler et Enregistrer sur la page Modification d’un pipeline hors production n’étaient pas toujours visibles.
Certaines erreurs liées au u processus de qualité du code peuvent entraîner la génération incorrecte du fichier journal.
Lors de la création d’un programme, le nom suggéré renvoyait parfois un duplicata de nom de programme existant.
Certains journaux d’étape de pipeline volumineux n’ont pas pu être téléchargés de manière cohérente via l’interface utilisateur.
La validation des noms d’environnement comportait une erreur de décalage d’une unité.
La page Environnements affichait parfois des segments de publication et de répartiteur alors qu’aucun segment n’était présent.
Les journaux peuvent être transférés vers des comptes Splunk, ce qui permet aux entreprises d’exploiter leur investissement dans Splunk.
Une adresse IP de sortie statique et dédiée peut être affectée au trafic sortant programmé dans le code Java, ce qui peut s’avérer utile pour certaines intégrations.
L’interface utilisateur du service cloud AEM Analytics est passée de l’interface classique à la nouvelle interface AEM. De plus, l’emplacement du service cloud Analytics dans le référentiel AEM est passé de /etc
à /conf
pour refléter les autres services cloud AEM.
L’interface utilisateur du service cloud AEM Target est passée de l’interface classique à la nouvelle interface AEM. De plus, l’emplacement du service cloud Target dans le référentiel AEM est passé de /etc
à /conf
pour refléter les autres services cloud AEM.
Suivez cette section pour en savoir plus sur les nouveautés et les mises à jour de la version 1.0.2 de Cloud Readiness Analyzer.
La version antérieure de CRA ne pouvait pas s’exécuter sur Adobe Experience Manager (AEM) 6.1. Nous avons ajouté la prise en charge explicite de l’autorisation des utilisateurs dans le groupe d’administrateurs.
Voir Installation de CRA sur AEM 6.1 pour plus d’informations.
L’horodatage d’expiration affiché sur le rapport résumé était incorrect.
CRA détectait des doublons de composants personnalisés.
Dans AEM 6.1, l’inspection du contenu se terminait avant la fin de l’analyse complète. Nous avons ajouté la gestion des exceptions pour permettre à l’inspecteur d’ignorer et de continuer jusqu’à ce que l’inspection complète soit terminée.