AEM as a Cloud Service : limites des tests de distribution de contenu Sling dans les environnements SDK locaux par rapport aux environnements cloud

Cet article explique les différences et les limites du test de la distribution de contenu Sling (SCD) à l’aide de l’SDK AEM as a Cloud Service locale par rapport aux environnements Cloud Service réels et explique ce qui peut et ne peut pas être validé localement.

Description description

Environnement

Adobe Experience Manager as a Cloud Service (toutes versions)

Symptômes

Il n’est pas certain que Sling Content Distribution (SCD) puisse être entièrement testé à l’aide du SDK AEM as a Cloud Service local. Des questions peuvent se poser sur l’équivalence du comportement de SDK local avec les environnements Cloud Service de production, notamment :

  • Si le SDK local prend en charge les tests SCD de bout en bout
  • Les fonctionnalités SCD simulées ou non disponibles localement
  • La possibilité de valider la création de packages de distribution, le traitement de la file d’attente, les événements de distribution, la diffusion de contenu et la gestion des échecs
  • La présence de composants, de services ou de pipelines spécifiques au cloud qui ne sont pas disponibles dans le SDK
  • Niveau de confiance pouvant être placé sur les résultats de validation locaux

Aucun message d’erreur spécifique n’est généré, mais les différences dans les mécanismes de réplication et l’absence de services de pipeline gérés par Adobe peuvent entraîner des résultats inattendus lors de la comparaison des environnements locaux et cloud.

Cause

Le SDK local est conçu comme une simulation au moment du développement et n’inclut pas le pipeline SCD géré par Adobe, le journal ou les microservices requis pour les tests de réplication complets de bout en bout, comme ceux des environnements Cloud Service.

Résolution resolution

Suivez les étapes ci-dessous pour comprendre et résoudre les limites :

  1. Découvrez les fonctionnalités de SDK en local : le SDK AEM as a Cloud Service en local n’inclut pas les microservices de pipeline SCD gérés par Adobe, de journal (réplication en tant que service) ou cloud présents dans les environnements de production. La réplication locale utilise les mécanismes classiques de création→publication, et non le pipeline SCD utilisé dans Cloud Service.
  2. Identifier ce qui peut être testé localement : vous pouvez valider l’utilisation de l’API de réplication par votre application (comme activer ou désactiver du contenu). Il est possible de tester la logique commerciale déclenchée par les événements de publication.
  3. Identifiez les éléments qui ne peuvent pas être testés localement : les files d’attente SCD basées sur les journaux, le comportement du pipeline et la mise à l’échelle sur plusieurs capsules de publication ne sont pas présents dans le SDK. Les scénarios de création/publication en cluster, les mises à niveau automatiques et l’attrition des capsules ne peuvent pas être simulés. Les microservices spécifiques au cloud, les couches de distribution et les files d’attente gérées par Adobe ne sont pas disponibles.
  4. Test dans les environnements cloud pour une couverture complète : pour la vérification SCD de bout en bout (y compris le comportement du pipeline, la mise en file d’attente, la mise à l’échelle et l’exécution distribuée), utilisez les environnements AEM as a Cloud Service réels (DEV, STAGE, PROD).
  5. Consultez la documentation officielle : consultez la documentation AEM as a Cloud Service pour obtenir les derniers conseils sur les portées de test prises en charge.
recommendation-more-help
experience-cloud-kcs-help-kbarticles