Gérer les problèmes de limitation (429 – erreurs « Trop de requêtes ») dans Azure Logic Apps
S’applique à : Azure Logic Apps (Consommation + Standard)
Si votre workflow d’application logique subit une limitation, ce qui se produit lorsque le nombre de requêtes dépasse la vitesse que la destination peut gérer sur une période spécifique, vous obtenez l’erreur « HTTP 429 Trop de demandes ». La limitation peut créer des problèmes tels que le traitement différé des données, une réduction des performances de vitesse et des erreurs telles que le dépassement de la stratégie de nouvelles tentatives spécifiée.
Par exemple, l’action SQL Server suivante dans un workflow Consommation montre une erreur 429, qui signale un problème de limitation :
Les sections suivantes décrivent les niveaux courants auxquels votre workflow peut subir une limitation :
Limitation de ressource d’application logique
Azure Logic Apps a ses propres limites de débit. Si votre ressource d’application logique dépasse ces limites, c’est votre ressource d’application logique qui est limitée, et pas simplement une instance ou une exécution spécifique de workflow.
Pour rechercher les événements de limitation à ce niveau, procédez comme suit :
Dans le portail Azure, ouvrez votre ressource d’application logique.
Dans le menu de l’application logique, sous Surveillance, sélectionnez Métriques.
Sous Titre du graphique, sélectionnez Ajouter une métrique, ce qui ajoute une autre barre de métrique au graphique.
Dans la première barre de métrique, dans la liste Métrique, sélectionnez Événements limités d’action. Dans la liste Agrégation, sélectionnez Nombre.
Dans la deuxième barre de métrique, dans la liste Métrique, sélectionnez Événements limités de déclenchement. Dans la liste Agrégation, sélectionnez Nombre.
Le graphique affiche désormais les événements limités pour les actions et les déclencheurs dans votre workflow d’application logique. Pour plus d’informations, consultez Afficher les métriques pour l’intégrité et les performances des workflows dans Azure Logic Apps.
Pour gérer la limitation à ce niveau, les options suivantes s’offrent à vous :
Limitez le nombre d’instances de workflow qui peuvent s’exécuter simultanément.
Par défaut, si la condition du déclencheur de votre workflow est remplie plusieurs fois en même temps, plusieurs instances de ce déclencheur s’exécutent simultanément ou en parallèle. Chaque instance de déclencheur s’active avant la fin de l’exécution de l’instance de workflow précédente.
Bien que le nombre d’instances de déclencheur par défaut pouvant s’exécuter simultanément soit illimité, vous pouvez limiter ce nombre en activant le paramètre de concurrence du déclencheur et, si nécessaire, sélectionner une limite autre que la valeur par défaut.
Activer le mode de débit élevé.
Un workflow Consommation a une limite par défaut pour le nombre d’actions pouvant s’exécuter à un intervalle de roulement de 5 minutes. Pour augmenter cette limite au nombre d’actions maximal, activez le mode de débit élevé sur votre ressource d’application logique.
Un workflow Standard n’a aucune limite sur le nombre d’actions pouvant s’exécuter pendant n’importe quel intervalle.
Désactivez le comportement de décomposition du tableau « Fractionner sur » dans les déclencheurs.
Si un déclencheur retourne un tableau pour les actions de workflow restant à traiter, le paramètre Fractionner sur du déclencheur fractionne les éléments du tableau et démarre une instance de workflow pour chaque élément de ce dernier. Ce comportement déclenche efficacement plusieurs exécutions simultanées jusqu’à la limite Fractionner sur.
Pour contrôler la limitation, désactivez le comportement Fractionner sur du déclencheur et faites en sorte que votre workflow traite l’ensemble du tableau avec un seul appel, plutôt que de gérer un seul élément par appel.
Refactorisez les actions en plusieurs workflows plus petits.
Comme mentionné précédemment, un workflow d’application logique Consommation est limité à un nombre par défaut d’actions pouvant être exécutées sur une période de 5 minutes. Même si vous pouvez augmenter cette limite en activant le mode de débit élevé, vous pouvez également envisager de répartir les actions de votre workflow en workflows plus petits pour que le nombre d’actions exécutées dans chaque workflow reste inférieur à la limite. Cela vous permet de réduire la charge pesant sur un seul workflow et de répartir la charge sur plusieurs workflows. Cette solution fonctionne mieux pour les actions qui gèrent des jeux de données volumineux ou lancent un grand nombre d’actions exécutées simultanément, pour les itérations de boucle ou pour les actions au sein de chaque itération de boucle qui dépassent la limite d’exécution des actions.
Par exemple, le workflow Consommation suivant effectue tout le travail pour obtenir des tables à partir d’une base de données SQL Server et obtient les lignes de chaque table. La boucle Pour chaque itère simultanément dans chaque table afin que l’action Obtenir des lignes retourne les lignes de chaque table. Selon les quantités de données contenues dans ces tables, ces actions peuvent dépasser la limite des actions exécutées.
Après la refactorisation, le workflow d’origine est divisé en workflow parent et en workflow enfant.
Le workflow parent suivant obtient les tables de SQL Server, puis appelle un workflow enfant pour chaque table pour obtenir les lignes :
Le workflow enfant suivant est appelé par le workflow parent pour obtenir les lignes de chaque table :
Limitation des connecteurs
Chaque connecteur a ses propres limitations, que vous pouvez trouver sur la page de référence technique de chaque connecteur. Par exemple, le connecteur Azure Service Bus a une limitation qui autorise jusqu’à 6 000 appels par minute, tandis que le connecteur SQL Server a des limitations qui varient en fonction du type d’opération.
Certains déclencheurs et actions, tels que HTTP, ont une « stratégie de nouvelle tentative » que vous pouvez personnaliser en fonction des limites de la stratégie de nouvelle tentative pour implémenter la gestion des exceptions. Cette stratégie spécifie si et à quelle fréquence un déclencheur ou une action réessaie d’effectuer une requête quand la requête d’origine expire ou échoue et génère une réponse 408, 429 ou 5xx. Ainsi, lorsque la limitation démarre et renvoie une erreur 429, Logic Apps suit la stratégie de nouvelle tentative lorsqu’elle est prise en charge.
Pour savoir si un déclencheur ou une action prend en charge les stratégies de nouvelle tentative, vérifiez les paramètres du déclencheur ou de l’action. Pour afficher les nouvelles tentatives d’un déclencheur ou d’une action, accédez à l’historique des exécutions de votre application logique, sélectionnez l’exécution que vous souhaitez examiner, puis développez le déclencheur ou l’action pour afficher des détails sur les entrées, les sorties et les nouvelles tentatives.
L’exemple de workflow Consommation suivant montre où vous pouvez trouver ces informations pour une action HTTP :
Bien que l’historique des nouvelles tentatives fournisse des informations sur les erreurs, vous risquez de rencontrer des problèmes de différenciation entre les limitations de connecteur et les limitations de destination. Dans ce cas, vous devrez peut-être examiner les détails de la réponse ou effectuer des calculs d’intervalles de limitations pour identifier la source.
Pour les workflows d’applications logiques Consommation dans Azure Logic Apps multilocataire, la limitation a lieu au niveau de la connexion. Pour les workflows d’applications logiques qui s’exécutent dans un environnement de service d’intégration (ISE), la limitation concerne toujours les connexions hors environnement ISE, car elles s’exécutent dans Azure Logic Apps multilocataire. Les connexions ISE, qui sont créées par les connecteurs ISE, ne sont cependant pas limitées, car elles s’exécutent dans votre environnement ISE.
Pour gérer la limitation à ce niveau, les options suivantes s’offrent à vous :
Configurez plusieurs connexions pour une seule action pour que le workflow partitionne les données en vue de leur traitement.
Déterminez si vous pouvez distribuer la charge de travail en divisant les requêtes d’une action sur plusieurs connexions vers la même destination à l’aide des mêmes informations d’identification.
Par exemple, supposons que votre workflow obtienne des tables d’une base de données SQL Server, puis les lignes de chaque table. En fonction du nombre de lignes que vous devez traiter, vous pouvez utiliser plusieurs connexions et plusieurs boucles Pour chaque afin de diviser le nombre total de lignes en jeux plus petits pour le traitement. Ce scénario utilise deux boucles Pour chaque afin de diviser le nombre total de lignes par deux. La première boucle Pour chaque utilise une expression qui obtient la première moitié. L’autre boucle Pour chaque utilise une expression différente qui obtient la deuxième moitié, par exemple :
Expression 1 : la fonction
take()obtient le début d’une collection. Pour plus d’informations, consultez latake()fonction.@take(collection-or-array-name, div(length(collection-or-array-name), 2))Expression 2 : la fonction
skip()supprime le début d’une collection et retourne tous les autres éléments. Pour plus d’informations, consultez laskip()fonction.@skip(collection-or-array-name, div(length(collection-or-array-name), 2))L’exemple de workflow Consommation suivant montre comment utiliser ces expressions :
Configurer une connexion différente pour chaque action.
Déterminez si vous pouvez distribuer la charge de travail en répartissant les demandes de chaque action sur leur propre connexion, même lorsque des actions se connectent au même service ou système et utilisent les mêmes informations d’identification.
Par exemple, supposons que votre workflow obtienne les tables d’une base de données SQL Server et chaque ligne de chaque table. Vous pouvez utiliser des connexions distinctes pour que l’obtention des tables utilise une seule connexion, tandis que l’obtention de chaque ligne utilise une autre connexion.
L’exemple suivant montre un workflow Consommation qui crée et utilise une connexion différente pour chaque action :
Modifiez la concurrence ou le parallélisme sur une boucle « For each ».
Par défaut, les itérations de boucle « For each » s’exécutent en même temps jusqu’à la limite de concurrence. Si vous disposez d’une connexion limitée à l’intérieur d’une boucle « For each », vous pouvez réduire le nombre d’itérations de boucle qui s’exécutent en parallèle. Pour plus d’informations, consultez la documentation suivante :
Boucles « For each » : modifier l’accès simultané ou exécuter séquentiellement
Schéma de langage de définition de workflow : boucles For each
Schéma de langage de définition de workflow : concurrence de boucles « For each »
Schéma du langage de définition de workflow : exécuter des boucles « For each » séquentiellement
Limitation du service ou du système de destination
Bien qu’un connecteur ait ses propres limitations, le service ou le système de destination appelé par le connecteur peut également en avoir. Par exemple, certaines API dans Microsoft Exchange Server ont des limitations plus strictes que le connecteur Office 365 Outlook.
Par défaut, les instances de workflow et toutes les boucles ou branches situées à l’intérieur de ces instances s’exécutent en parallèle. Ce comportement signifie que plusieurs instances peuvent appeler le même point de terminaison en même temps. Chaque instance ne connaît pas l’existence de l’autre. Par conséquent, les nouvelles tentatives d’actions ayant échoué peuvent créer des conditions de concurrence où plusieurs appels essaient de s’exécuter en même temps, mais pour aboutir, ces appels doivent parvenir au service ou au système de destination avant que la limitation ne démarre.
Par exemple, supposons que vous ayez un tableau de 100 éléments. Vous utilisez une boucle « For each » pour itérer dans tout le tableau et activer le contrôle d’accès concurrentiel de la boucle afin de pouvoir limiter le nombre d’itérations parallèles à 20 ou à la limite par défaut actuelle. Au sein de cette boucle, une action insère un élément du tableau dans une base de données SQL Server, ce qui n’autorise que 15 appels par seconde. Ce scénario entraîne un problème de limitation, car un backlog de nouvelles tentatives est accumulé, mais jamais exécuté.
Le tableau suivant décrit la chronologie de ce qui se produit dans la boucle lorsque l’intervalle avant une nouvelle tentative de l’action est de 1 seconde :
| Limite dans le temps | Nombre d’actions qui s’exécutent | Nombre d’actions qui échouent | Nombre de nouvelles tentatives en attente |
|---|---|---|---|
| T + 0 seconde | 20 insertions | 5 échecs en raison de la limite SQL | 5 nouvelles tentatives |
| T + 0,5 seconde | 15 insertions en raison de 5 dernières tentatives en attente | Les 15 échouent en raison de la limite SQL précédente toujours en vigueur pendant 0,5 seconde supplémentaires | 20 nouvelles tentatives (les 5 précédentes + 15 nouvelles) |
| T + 1 seconde | 20 insertions | 5 ayant échoué, plus 20 nouvelles tentatives précédentes, en raison de la limite SQL | 25 nouvelles tentatives (20 + 5 nouvelles) |
Pour gérer la limitation à ce niveau, les options suivantes s’offrent à vous :
Créez des workflows individuels, chacun gérant une seule opération.
Si vous poursuivez avec l’exemple de scénario SQL Server dans cette section, vous pouvez créer un workflow qui place des éléments de tableau dans une file d’attente, telle qu’une file d’attente Azure Service Bus. Vous créez ensuite un autre workflow qui effectue uniquement l’opération d’insertion pour chaque élément de cette file d’attente. De cette façon, une seule instance de workflow s’exécute à un moment spécifique, termine l’opération d’insertion et passe à l’élément suivant de la file d’attente, ou l’instance obtient des erreurs 429, mais n’effectue pas de nouvelles tentatives infructueuses.
Créez un workflow parent qui appelle un workflow enfant ou imbriqué pour chaque action. Si le parent doit appeler différents workflows enfants en fonction du résultat du parent, vous pouvez utiliser une action de condition ou une action de commutation qui détermine le workflow enfant à appeler. Ce modèle peut vous aider à réduire le nombre d’appels ou d’opérations.
Supposons, par exemple, que vous disposiez de deux workflows, chacune avec un déclencheur d’interrogation qui vérifie votre compte de messagerie chaque minute pour trouver un sujet spécifique, tel que « Réussite » ou « Échec ». Cette configuration entraîne 120 appels par heure. Au lieu de cela, si vous créez un workflow parent unique qui interroge toutes les minutes, mais appelle un workflow enfant qui s’exécute selon que le sujet est « Succès » ou « Échec », vous divisez le nombre de vérifications d’interrogation de moitié, soit 60 ici.
Configurer le traitement par lots. (Flux de travail de consommation uniquement)
Si le service de destination prend en charge les opérations par lots, vous pouvez traiter la limitation en traitant des éléments par groupes ou par lots, plutôt qu’individuellement. Pour implémenter la solution de traitement par lots, vous devez créer un workflow d’application logique « destinataire de lots » et un workflow d’application logique « expéditeur de lots ». L’expéditeur de lots collecte des messages ou des éléments jusqu’à ce que vos critères spécifiés soient remplis, puis envoie ces messages ou éléments dans un groupe unique. Le récepteur de lots accepte ce groupe et traite ces messages ou éléments. Pour plus d’informations, consultez la section Messages de traitement par lots dans des groupes.
Utilisez les versions du webhook pour les déclencheurs et les actions, plutôt que les versions d’interrogation.
Pourquoi ? Un déclencheur d’interrogation continue à vérifier le service ou le système de destination à intervalles spécifiques. Un intervalle très fréquent, par exemple toutes les secondes, peut créer des problèmes de limitation. Toutefois, une action ou un déclencheur de webhook, comme Webhook HTTP, crée un seul appel au service ou au système de destination, qui a lieu au moment de l’abonnement et demande que la destination informe le déclencheur ou l’action uniquement lorsqu’un événement se produit. Ainsi, le déclencheur ou l’action n’a pas à vérifier continuellement la destination.
Par conséquent, si le service ou le système de destination prend en charge les webhooks ou fournit un connecteur avec une version de webhook, cette option est préférable à l’utilisation de la version d’interrogation. Pour identifier les déclencheurs et actions de webhook, confirmez qu’ils sont de type
ApiConnectionWebhookou qu’ils ne requièrent pas que vous spécifiiez une récurrence. Pour plus d’informations, consultez déclencheur APIConnectionWebhook et action APIConnectionWebhook.