Résolution des échecs de chargement/accès du gestionnaire de packages AEM (autorisations, restrictions réseau, URL et d’exécution)

Les chargements ou installations du gestionnaire de packages peuvent échouer lorsque les packages n’apparaissent pas, que l’accès est bloqué ou que l’installation renvoie un message indéfini.

Il se peut que vous ne puissiez pas ouvrir le gestionnaire de packages, charger un package, afficher les packages chargés ou terminer une installation. Dans certains cas, les téléchargements semblent terminés, mais le package n’apparaît pas dans la liste. Dans les environnements cloud, l’installation peut également échouer lorsque le package contient du contenu non modifiable qui n’est pas pris en charge au moment de l’exécution.

Les causes courantes incluent les autorisations manquantes, les URL incorrectes, les restrictions réseau, les interférences du navigateur et les packages contenant des chemins immuables dans les environnements cloud. Confirmez le chemin d’accès, testez les autorisations et le comportement du navigateur, et passez en revue les filtres de package pour le contenu non pris en charge. N’utilisez l’installation du package d’exécution que pour le contenu modifiable et déployez le contenu non modifiable via le pipeline de déploiement.

Description description

Environnement :

  • Adobe Experience Manager as a Cloud Service
  • AEM Managed Services
  • Adobe Experience Manager On-Premise

Problème/Symptômes :

  1. Si le gestionnaire de packages n’est pas accessible à l’adresse /crx/packmgr, ouvrez l’URL du gestionnaire de packages appropriée pour l’environnement cible et confirmez que le /crx/packmgr/index.jsp se charge sans erreur de redirection ou d’accès.
  2. Si aucun package n’est visible dans le gestionnaire de packages, vérifiez si un autre utilisateur disposant de l’accès attendu peut afficher ou charger des packages afin de déterminer si le problème est lié aux autorisations.
  3. Si le chargement d’un package est terminé mais que le package n’apparaît pas dans le gestionnaire de packages, actualisez l’interface et réessayez avec un petit package de test pour confirmer que le chargement est accepté et affiché correctement.
  4. Si un chargement échoue sans erreur claire, réessayez la même action à partir d’un autre réseau afin de déterminer si un pare-feu ou une restriction de proxy bloque la requête avant qu’elle n’atteigne AEM.
  5. Si le navigateur affiche une erreur indéfinie lors de l’installation, répétez l’action dans une session incognito ou dans un autre navigateur pris en charge afin d’exclure toute interférence spécifique à l’extension, à la session ou au navigateur.
  6. Si un environnement cloud rejette le package car il contient du contenu d’exécution non pris en charge, passez en revue les filtres du package et confirmez que le package contient uniquement du contenu modifiable destiné à l’installation à l’exécution et n’inclut pas de chemins non modifiables tels que /apps.

Cause principale :

Ces échecs sont généralement causés par des autorisations manquantes sur les chemins d’accès aux packages, une URL de gestionnaire de packages incorrecte, des restrictions réseau ou de pare-feu, des extensions de navigateur ou un comportement de session qui interfère avec les requêtes, des outils de sécurité locaux qui bloquent les chargements, ou des filtres de package qui incluent des chemins d’accès non modifiables tels que /apps dans les environnements cloud.

Résolution resolution

Essayez les étapes suivantes :

  1. Ouvrez l’URL du gestionnaire de packages appropriée pour l’environnement cible et vérifiez que le /crx/packmgr/index.jsp se charge sans erreur de redirection ou d’accès.
  2. Vérifiez que l’utilisateur affecté est autorisé à créer, charger, afficher et installer des packages en comparant le résultat avec un autre utilisateur qui devrait avoir le même niveau d’accès.
  3. Si le gestionnaire de packages ne s’ouvre pas ou si les chargements ne démarrent pas, réessayez la même action à partir d’un autre réseau pour déterminer si un pare-feu ou une restriction de proxy bloque la requête.
  4. Si le chargement ou l’installation échoue dans le navigateur, répétez l’action dans une session incognito ou dans un autre navigateur pris en charge afin d’exclure toute interférence spécifique à l’extension, à la session ou au navigateur.
  5. Si le même chargement échoue à la fois dans l’environnement cible et dans un SDK local, passez en revue les contrôles de sécurité locaux ou organisationnels, car la requête peut être bloquée avant d’atteindre AEM.
  6. Pour les environnements cloud, passez en revue les filtres de package et confirmez que le package contient uniquement du contenu modifiable destiné à l’installation à l’exécution et n’inclut pas de chemins non modifiables tels que /apps.
  7. Si le package comprend du contenu non modifiable, déployez ce contenu par le biais du pipeline de déploiement au lieu du gestionnaire de packages.
  8. Après avoir apporté des modifications, chargez un petit package de test, actualisez le gestionnaire de packages et vérifiez que le package apparaît dans la liste et s’installe sans nouvelles erreurs.

Si le problème persiste après ces vérifications, envoyez un ticket à l’assistance 🔗 lorsque les chargements échouent dans plusieurs navigateurs, que le gestionnaire de packages est inaccessible à tous les utilisateurs, qu’un autre utilisateur disposant d’un accès similaire peut effectuer l’action tandis que l’utilisateur affecté ne le peut pas, ou que le test indique que la requête n’atteint pas AEM. Incluez des captures d’écran, des fichiers HAR, les journaux de la console de navigateur, le nom du package et un résumé des résultats de dépannage.

Lecture connexe

recommendation-more-help
experience-cloud-kcs-help-kbarticles