Résoudre les problèmes et diagnostiquer les échecs de flux de travail dans Azure Logic Apps

  • Article

S’applique à : Azure Logic Apps (Consommation + Standard)

Votre workflow d’application logique génère des informations qui peuvent vous aider à diagnostiquer et déboguer ses problèmes. Vous pouvez diagnostiquer votre flux de travail en examinant les entrées, sorties et autres informations pour chaque étape du flux de travail à l’aide du Portail Azure. Vous pouvez également ajouter des étapes à un flux de travail pour effectuer un débogage du runtime.

Vérifier l'historique du déclencheur

Chaque exécution de flux de travail commence par un déclencheur, qui se déclenche selon une planification ou attend une demande ou un événement entrant. L’historique du déclencheur répertorie toutes les tentatives de déclenchement que votre workflow a faites et contient des informations sur les entrées et sorties pour chaque tentative. Si le déclencheur ne se déclenche pas, essayez les étapes suivantes.

  1. Pour vérifier l’état du déclencheur dans votre application logique Consommation, passez en revue l’historique des déclencheurs. Pour afficher plus d’informations sur la tentative de déclenchement, sélectionnez cet événement du déclencheur, par exemple :

    Capture d’écran montrant le portail Azure avec l’historique des déclencheurs du workflow d’application logique Consommation.

  2. Vérifiez les entrées du déclencheur pour vous assurer qu’elles s’affichent comme prévu. Dans le volet Historique, sous le lien Entrées, sélectionnez le lien, qui affiche le volet Entrées.

    Les entrées du déclencheur incluent les données attendues et requises par le déclencheur pour démarrer le flux de travail. L’examen de ces entrées peut vous aider à déterminer si les entrées du déclencheur sont correctes et si la condition a été remplie afin que le flux de travail puisse se poursuivre.

    Capture d’écran montrant les entrées de déclencheur du concepteur de workflow d’application logique Consommation.

  3. Vérifiez les sorties du déclencheur, le cas échéant, pour vérifier qu’elles s’affichent comme prévu. Dans le volet Historique, sous le lien Sorties, sélectionnez le lien, qui affiche le volet Sorties.

    Les sorties du déclencheur incluent les données que le déclencheur transmet à l’étape suivante de votre flux de travail. L’examen de ces sorties peut vous aider à déterminer si les valeurs correctes ou attendues ont été transmises à l’étape suivante de votre flux de travail.

    Par exemple, un message d’erreur indique que le flux RSS n’a pas été trouvé :

    Capture d’écran les sorties des déclencheurs du workflow d’application logique Consommation.

    Conseil

    Si vous rencontrez un contenu que vous ne reconnaissez pas, apprenez-en davantage sur les différents types de contenu dans Azure Logic Apps.

Vérifier l’historique des exécutions du flux de travail

Chaque fois que le déclencheur est activé, Azure Logic Apps crée une instance de workflow et l’exécute. Si une exécution échoue, essayez les étapes suivantes pour pouvoir examiner ce qu’il s’est passé pendant cette exécution. Vous pouvez examiner l’état, les entrées et les sorties de chaque étape du workflow.

  1. Pour vérifier l’état d’exécution du flux de travail dans votre application logique Consommation, passez en revue l’historique des exécutions. Pour afficher plus d’informations sur une exécution ayant échoué, y compris ses différentes étapes et leur état, sélectionnez cette exécution.

    Capture d’écran montrant le portail Azure avec les exécutions du workflow d’application logique Consommation et une exécution en échec sélectionnée.

  2. Une fois toutes les étapes de l’exécution affichées, sélectionnez chaque étape pour développer leurs formes.

    Capture d’écran montrant le workflow d’application logique Consommation avec une étape en échec sélectionnée.

  3. Passez en revue les entrées, les sorties et les messages d’erreur de l’étape ayant échoué.

    Capture d’écran montrant le workflow d’application logique Consommation avec les détails d’une étape en échec.

    Par exemple, la capture d’écran suivante montre les sorties de l’action RSS ayant échoué.

    Capture d’écran montrant le workflow d’application logique Consommation avec les sorties d’une étape en échec.

Effectuer le débogage du runtime

Pour faciliter le débogage, vous pouvez ajouter des étapes de diagnostic à un flux de travail d'application logique, ainsi qu’examiner les historiques des déclencheurs et des exécutions. Par exemple, vous pouvez ajouter des étapes qui utilisent le service Webhook Tester afin de pouvoir inspecter les requêtes HTTP et déterminer précisément leur taille, leur forme et leur format.

  1. Dans un navigateur, accédez au site Webhook Tester et copiez l’URL unique générée.

  2. Dans votre application logique, ajoutez une action HTTP POST avec le contenu du corps que vous voulez tester (par exemple, une expression ou une autre sortie de l’étape).

  3. Collez votre URL à partir de l'élément Webhook Tester dans l’action HTTP POST.

  4. Pour examiner comment Azure Logic Apps génère et forme une requête, exécutez le flux de travail de l’application logique. Vous pouvez ensuite revisiter le site Webhook Tester pour plus d’informations.

Performances - Questions fréquentes (FAQ)

Pourquoi la durée d’exécution du workflow est-elle supérieure à la somme de toutes les durées des actions du workflow ?

Une surcharge de planification se produit lors de l’exécution d’actions, tandis que des temps d’attente entre les actions peuvent se produire en raison de la charge du système backend. Une durée d’exécution du workflow inclut ces temps de planification et ces temps d’attente ainsi que la somme de toutes les durées des actions.

En règle générale, mon workflow se termine en 10 secondes. Parfois cependant, sa durée d’exécution peut durer bien plus longtemps. Comment puis-je être sûr que le workflow se termine toujours au bout de 10 secondes ?

  • Il n’existe aucune garantie SLA sur la latence.

  • Les workflows de consommation s’exécutent sur Azure Logic Apps multilocataire : les charges de travail d’autres clients peuvent donc affecter négativement les performances de votre workflow.

  • Pour des performances plus prévisibles, vous pouvez envisager de créer des workflows Standard, qui s’exécutent dans Azure Logic Apps monolocataire. Vous aurez plus de contrôle pour effectuer un scale-up ou un scale-out pour améliorer les performances.

Mon action dépasse le délai d’expiration au bout de 2 minutes. Comment puis-je augmenter la valeur du délai d’expiration ?

La valeur du délai d’expiration de l’action ne peut pas être changée et elle est fixée à 2 minutes. Si vous utilisez l’action HTTP et que vous êtes propriétaire du service appelé par l’action HTTP, vous pouvez modifier votre service pour éviter le délai d’expiration de 2 minutes en utilisant le modèle asynchrone. Pour plus d’informations, consultez Effectuer des tâches d’exécution longue avec le modèle d’action d’interrogation.

Problèmes courants - Applications logiques standard

Artefacts inaccessibles dans le compte de stockage Azure

Les applications logiques standard stockent tous les artefacts dans un compte de stockage Azure. Vous pouvez obtenir les erreurs suivantes si ces artefacts ne sont pas accessibles. Par exemple, le compte de stockage lui-même peut ne pas être accessible, ou le compte de stockage se trouve derrière un pare-feu, mais aucun point de terminaison privé n’est configuré pour que les services de stockage soient utilisés.

Emplacement du portail Azure Erreur
Volet Vue d’ensemble - System.private.corelib : L’accès au chemin d'accès « C:\home\site\wwwroot\hostj.son » est refusé

- Azure.Storage.Blobs : Cette requête n’est pas autorisée à effectuer cette opération.
Volet Flux de travail - Impossible d’atteindre le runtime d’hôte. Détails de l’erreur, Code : « BadRequest », Message : « Rencontré une erreur (InternalServerError) à partir du runtime hôte. »

- Impossible d’atteindre le runtime d’hôte. Détails de l’erreur, Code : « BadRequest », Message : « Rencontré une erreur (ServiceUnavailable) à partir du runtime hôte. »

- Impossible d’atteindre le runtime d’hôte. Détails de l’erreur, Code : « BadRequest », Message : « Rencontré une erreur (BadGateway) à partir du runtime hôte. »
Pendant la création et l’exécution du flux de travail - L'enregistrement du workflow a échoué

- Erreur dans le concepteur : GetCallFailed. Échec des opérations d’extraction

- Échec de l’appel ajaxExtended

Options de résolution des problèmes

La liste suivante inclut des causes possibles pour ces erreurs et étapes afin de vous aider à résoudre les problèmes.

  • Pour un compte de stockage public, vérifiez l’accès au compte de stockage de la manière suivante :

    Si la connectivité échoue, vérifiez si la clé SAP (Shared Access Signature) dans la chaîne de connexion est la plus récente.

    Important

    Quand vous avez des informations sensibles, comme des chaînes de connexion qui incluent des noms d’utilisateur et des mots de passe, veillez à utiliser le flux d’authentification le plus sécurisé disponible. Par exemple, dans les workflows d’applications logiques Standard, les types de données sécurisés tels que securestring et secureobject ne sont pas pris en charge. Microsoft vous recommande d’authentifier l’accès aux ressources Azure avec une identité managée quand c’est possible et d’attribuer un rôle disposant du privilège minimum nécessaire.

    Si cette fonctionnalité n’est pas disponible, veillez à sécuriser les chaînes de connexion via d’autres mesures, comme

Azure Key Vault, que vous pouvez utiliser avec des paramètres d’application. Vous pouvez ensuite référencer directement des chaînes sécurisées, telles que des chaînes de connexion et des clés. Comme pour les modèles ARM, où vous pouvez définir des variables d’environnement au moment du déploiement, vous pouvez définir des paramètres d’application dans la définition de workflow de votre application logique. Vous pouvez ensuite capturer des valeurs d’infrastructure générées dynamiquement, comme des points de terminaison de connexion, des chaînes de stockage, etc. Pour plus d’informations, consultez Types d’application pour la plateforme d’identités Microsoft.

  • Pour un compte de stockage derrière un pare-feu, vérifiez l’accès au compte de stockage de la manière suivante :

    • Si les restrictions de pare-feu sont activées sur le compte de stockage, vérifiez si les points de terminaison privés sont configurés pour les services de stockage Blob, Fichier, Table et File d’attente.

    • Vérifiez la connectivité du compte de stockage à l’aide de l’Explorateur Stockage Azure.

    Si vous trouvez des problèmes de connectivité, poursuivez avec les étapes suivantes :

    1. Dans le même réseau virtuel intégré à votre application logique, créez une machine virtuelle Azure que vous pouvez placer dans un autre sous-réseau.

    2. À partir d’une invite de commandes, exécutez nslookup pour vérifier que les services de stockage Blob, Fichier, Table et File d’attente sont résolus sur les adresses IP attendues.

      Syntaxe : nslookup [StorageaccountHostName] [OptionalDNSServer]

      Objet blob : nslookup {StorageaccountName}.blob.core.windows.net

      Fichier : nslookup {StorageaccountName}.file.core.windows.net

      Table : nslookup {StorageaccountName}.table.core.windows.net

      File d’attente : nslookup {StorageaccountName}.queue.core.windows.net

    3. Si les requêtes DNS (Domain Name Server) précédentes sont résolues avec succès, exécutez les commandes psping ou tcpping pour vérifier la connectivité au compte de stockage sur le port 443 :

      Syntaxe : psping [StorageaccountHostName] [Port] [OptionalDNSServer]

      Objet blob : psping {StorageaccountName}.blob.core.windows.net:443

      Fichier : psping {StorageaccountName}.file.core.windows.net:443

      Table : psping {StorageaccountName}.table.core.windows.net:443

      File d’attente : psping {StorageaccountName}.queue.core.windows.net:443

    4. Si chaque service de stockage est résolu à partir de votre machine virtuelle Azure, recherchez le DNS utilisé par la machine virtuelle pour la résolution.

      1. Définissez le paramètre d’application WEBSITE_DNS_SERVER de votre application logique sur le DNS et vérifiez que le DNS fonctionne correctement.

      2. Confirmez que l'intégration VNet est correctement configurée avec le réseau virtuel et le sous-réseau appropriés dans votre application logique standard.

    5. Si vous utilisez des zones Azure DNS privées pour les services de point de terminaison privé de votre compte de stockage, vérifiez qu’une liaison de réseau virtuel a été créée vers le réseau virtuel intégré de votre application logique.

Pour plus d’informations, consultez Déployer une application logique Standard sur un compte de stockage derrière un pare-feu à l’aide de points de terminaison privés ou de service.

Étapes suivantes