Résoudre les délais d’expiration des demandes d’API sortantes dans l’instance de publication AEM
Cet article explique comment résoudre les problèmes de délai d’expiration intermittent dans la publication Adobe Experience Manager (AEM) lors de la récupération de jeux de données volumineux à partir d’API externes et fournit des stratégies pour éviter les erreurs de délai d’expiration au niveau de la plateforme.
Description description
Environnement
Publication Adobe Experience Manager (AEM) (toutes les versions, y compris AEM as a Cloud Service)
Symptômes
- Des délais d’expiration intermittents se produisent lorsque l’instance de publication AEM récupère des jeux de données volumineux (tels que des données d’inventaire) à partir d’une API externe.
- L’API externe prend plus de temps que la temporisation au niveau de la plateforme pour renvoyer le premier octet, ce qui entraîne des erreurs ServiceUnavailable ou de temporisation du premier octet.
- Ces délais entraînent des échecs dans le processus de récupération des données.
Cause
L’instance de publication AEM applique un délai d’expiration au niveau de la plateforme sur les connexions HTTP sortantes. Si une API externe tarde à répondre, les requêtes synchrones de l’instance de publication AEM dépassent ce délai, ce qui entraîne des erreurs et l’échec de la récupération des données.
Résolution resolution
Suivez les étapes ci-dessous pour résoudre le problème :
-
Vérifiez la configuration de votre client HTTP dans votre code de publication AEM :
- Définissez des délais de connexion et de lecture explicites pour les requêtes HTTP sortantes vers des API externes. La plateforme applique un délai d’expiration global (par exemple : 10 secondes pour la connexion et 60 secondes pour la lecture) si votre code ne spécifie pas ses propres délais d’expiration.
-
Optimisez votre intégration pour éviter les appels synchrones longs :
-
Requêtes de récupération d’inventaire par lots ou par pagination afin que chaque appel API individuel traite un plus petit sous-ensemble de données et se termine correctement dans le délai d’expiration de la plateforme.
-
Par exemple, au lieu de demander tous les éléments d’inventaire dans un seul appel, demandez des pages plus petites (par exemple : 500 ou 1 000 éléments par appel) et agrégez les résultats, si nécessaire.
-
-
Implémentez la mise en cache ou précalculez les données d’inventaire dans la mesure du possible :
- Stockez les données d’inventaire fréquemment consultées dans un cache ou précalculez-les pendant les heures creuses afin de réduire la nécessité d’appels d’API volumineux et répétés.
-
Déplacez les extractions d’inventaire de longue durée vers un traitement asynchrone :
- Au lieu de faire attendre la réponse de l’API tierce dans la requête de page, déclenchez les mises à jour d’inventaire de manière asynchrone (par exemple : via des tâches planifiées ou des programmes de travail en arrière-plan) et diffusez les données mises en cache ou prérécupérées aux utilisateurs finaux.
-
Si vous avez besoin d’une temporisation plus longue que celle autorisée par la plateforme, reconcevez l’intégration afin d’éviter les appels synchrones à exécution longue. L’augmentation du délai d’expiration au niveau de la plateforme n’est pas prise en charge.
-
Après avoir apporté ces modifications, vérifiez que la récupération de l’inventaire s’est terminée correctement et que les erreurs de délai d’expiration ne se produisent plus.