Appeler des points de terminaison HTTP ou HTTPS externes à partir de flux de travail dans Azure Logic Apps

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

Certains scénarios peuvent nécessiter la création d’un flux de travail d’application logique qui envoie des requêtes sortantes aux points de terminaison sur d’autres services ou systèmes via HTTP ou HTTPS. Par exemple, supposons que vous souhaitez surveiller un point de terminaison de service pour votre site web en vérifiant ce point de terminaison selon une planification spécifique. Lorsqu’un événement spécifique se produit sur ce point de terminaison, tel que votre site web en panne, cet événement déclenche votre flux de travail et exécute les actions de ce flux de travail.

Remarque

Pour créer un flux de travail qui reçoit et répond aux appels HTTPS entrants, consultez Créer des flux de travail que vous pouvez appeler, déclencher ou imbriquer à l’aide de points de terminaison HTTPS dans Azure Logic Apps. Pour utiliser le déclencheur intégré de requête, consultez Recevoir et répondre aux appels HTTPS entrants aux flux de travail dans Azure Logic Apps.

Ce guide montre comment utiliser le déclencheur HTTP et l’action HTTP afin que votre flux de travail puisse envoyer des appels sortants à d’autres services et systèmes, par exemple :

Pour vérifier ou interroger un point de terminaison selon une planification périodique, ajoutez le déclencheur intégré nommé HTTP comme première étape de votre flux de travail. Chaque fois que le déclencheur vérifie le point de terminaison, le déclencheur appelle ou envoie une demande au point de terminaison. La réponse du point de terminaison détermine si votre flux de travail s’exécute. Le déclencheur transmet tout le contenu de la réponse de l'endpoint aux actions de votre flux de travail.
Pour appeler un point de terminaison n’importe où dans votre workflow, ajoutez l’action intégrée nommée HTTP. La réponse du point de terminaison détermine la façon dont les actions restantes de votre workflow s’exécutent.

Conditions préalables

Un compte et un abonnement Azure. Si vous n’avez pas d’abonnement Azure, inscrivez-vous pour bénéficier d’un compte Azure gratuit.
URL du point de terminaison de destination que vous souhaitez appeler.
Ressource d’application logique avec le flux de travail à partir duquel vous souhaitez appeler le point de terminaison externe.

Pour démarrer votre flux de travail avec le déclencheur HTTP , vous devez disposer d’un flux de travail vide. Pour utiliser l’action HTTP , votre flux de travail peut commencer par un déclencheur qui correspond le mieux à votre scénario. Les exemples de flux de travail de cet article utilisent le déclencheur HTTP .

Si vous n’avez pas de ressource et de flux de travail d’application logique, créez-les maintenant en suivant les étapes de l’application logique souhaitée :
- Créer un workflow d’application logique de consommation
- Créer un exemple de flux de travail d’application logique standard

Référence technique du connecteur

Pour plus d’informations techniques sur les paramètres de déclencheur et d’action, consultez les sections suivantes dans le guide de référence du schéma :

Ajouter un déclencheur HTTP

Ce déclencheur intégré effectue un appel HTTP à l’URL spécifiée pour un point de terminaison et retourne une réponse.

Standard
Consommation

Dans le portail Azure, ouvrez votre ressource d’application logique Standard.
Dans le menu de la barre latérale des ressources, sous Flux de travail, sélectionnez Flux de travail, puis sélectionnez votre flux de travail vide.
Dans le menu de la barre latérale du flux de travail, sous Outils, sélectionnez le concepteur pour ouvrir le flux de travail.
Ajoutez le déclencheur intégré HTTP à votre flux de travail en suivant les étapes générales pour ajouter un déclencheur.

Cet exemple renomme le déclencheur en déclencheur HTTP - Appeler l’URL du point de terminaison afin que le déclencheur ait un nom plus descriptif. En outre, l’exemple ajoute ultérieurement une action HTTP et les noms d’opérations dans votre workflow doivent être uniques.
Fournissez les valeurs des paramètres de déclencheur HTTP que vous souhaitez inclure dans l’appel au point de terminaison de destination. Configurez la périodicité pour la fréquence à laquelle vous souhaitez que le déclencheur vérifie le point de terminaison de destination.
Dans la liste Paramètres avancés, sélectionnez Authentification.

Si vous sélectionnez un type d’authentification autre qu’Aucun, les paramètres d’authentification diffèrent en fonction de votre sélection. Pour plus d’informations sur les types d’authentification disponibles pour HTTP, consultez les articles suivants :
- Ajouter l’authentification aux appels sortants
- Authentifier l’accès aux ressources avec des identités managées
Ajoutez toutes les autres actions que vous souhaitez exécuter lorsque le déclencheur se déclenche.
Lorsque vous avez terminé, enregistrez votre flux de travail. Dans la barre d’outils du Concepteur, sélectionnez Enregistrer.

Ajouter une action HTTP

Cette action intégrée envoie un appel HTTPS ou HTTP à l’URL spécifiée pour un point de terminaison et retourne avec une réponse.

Standard
Consommation

Dans le portail Azure, ouvrez votre ressource d’application logique Standard.
Dans le menu de la barre latérale des ressources, sous Flux de travail, sélectionnez Flux de travail, puis sélectionnez votre flux de travail.
Dans le menu de la barre latérale du flux de travail, sous Outils, sélectionnez le concepteur pour ouvrir le flux de travail.

Cet exemple utilise le déclencheur HTTP ajouté dans la section précédente.
Ajoutez l’action intégrée HTTP à votre flux de travail en suivant les étapes générales pour ajouter une action.

Cet exemple renomme l’action en action HTTP : appelez l’URL du point de terminaison afin que l’action ait un nom plus descriptif. En outre, les noms des opérations dans votre flux de travail doivent être uniques.
Fournissez les valeurs des paramètres d’action HTTP que vous souhaitez inclure dans l’appel au point de terminaison de destination.
Dans la liste Paramètres avancés, sélectionnez Authentification.

Si vous sélectionnez un type d’authentification autre qu’Aucun, les paramètres d’authentification diffèrent en fonction de votre sélection. Pour plus d’informations sur les types d’authentification disponibles pour HTTP, consultez les articles suivants :
- Ajouter l’authentification aux appels sortants
- Authentifier l’accès aux ressources avec des identités managées
Ajoutez toutes les autres actions que vous souhaitez exécuter lorsque le déclencheur se déclenche.
Lorsque vous avez terminé, enregistrez votre flux de travail. Dans la barre d’outils du Concepteur, sélectionnez Enregistrer.

Sorties des déclencheurs et des actions

Un déclencheur HTTP ou une action génère les informations suivantes :

Propriété	Type	Descriptif
`headers`	Objet JSON	En-têtes de la requête
`body`	Objet JSON	Objet avec le contenu du corps de la requête
`status code`	Nombre entier	Code d’état de la requête

Code de statut	Descriptif
200	Ok
202	Accepté
400	Demande incorrecte
401	Non autorisée
403	Interdit
404	Introuvable
500	Erreur interne du serveur. Une erreur inconnue s’est produite.

Sécurité d’URL pour les appels sortants

Pour plus d’informations sur le chiffrement, la sécurité et l’autorisation pour les appels sortants à partir de votre flux de travail, tels que Transport Layer Security (TLS), les certificats auto-signés ou l’authentification open d’ID Microsoft Entra, consultez Access pour les appels sortants vers d’autres services et systèmes.

Authentification pour un environnement à locataire unique

Si vous disposez d’une ressource d’application logique standard dans Azure Logic Apps à locataire unique et que vous souhaitez utiliser une opération HTTP avec l’un des types d’authentification suivants, veillez à suivre les étapes de configuration supplémentaires pour le type d’authentification correspondant. Dans le cas contraire, l’appel échoue.

Certificat TLS : ajoutez le paramètre WEBSITE_LOAD_ROOT_CERTIFICATESd’application et définissez la valeur sur l’empreinte numérique de votre certificat TLS.
Certificat client ou authentification ouverte Microsoft Entra ID (OAuth) avec le type d'informations d'identification du certificat : Ajoutez le paramètre WEBSITE_LOAD_USER_PROFILE d’application et définissez la valeur sur 1.

Authentification par certificat TLS

Dans les paramètres d’application de votre ressource d’application logique, ajoutez ou mettez à jour le paramètre d’application appelé WEBSITE_LOAD_ROOT_CERTIFICATES. Pour obtenir des étapes spécifiques, consultez Gérer les paramètres de l’application - local.settings.json.
Pour la valeur de paramètre, indiquez l’empreinte numérique de votre certificat TLS en tant que certificat racine à faire confiance.

"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>"

Par exemple, si vous travaillez dans Visual Studio Code, procédez comme suit :

Ouvrez le fichier local.settings.json de votre projet d'application logique.

Dans l’objet Values JSON, ajoutez ou mettez à jour le WEBSITE_LOAD_ROOT_CERTIFICATES paramètre :

{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS-certificate>",
      <...>
   }
}

Remarque

Pour trouver l’empreinte numérique, procédez comme suit :

Dans le menu des ressources de votre application logique, sous Paramètres, sélectionnez Certificats.
Sélectionnez Bring your own certificates (.pfx) ou Public key certificates (.cer).
Recherchez le certificat que vous souhaitez utiliser et copiez l’empreinte numérique.

Pour plus d’informations, consultez Rechercher l’empreinte numérique - Azure App Service.

Pour plus d’informations, consultez Gérer les paramètres de l’application - local.settings.json.

Certificat client ou OAuth Microsoft Entra ID avec authentification du type d’informations d’identification Certificat

Dans les paramètres d’application de votre ressource d’application logique, ajoutez ou mettez à jour le paramètre d’application appelé WEBSITE_LOAD_USER_PROFILE. Pour obtenir des étapes spécifiques, consultez Gérer les paramètres de l’application - local.settings.json
Pour la valeur de paramètre, spécifiez 1.

"WEBSITE_LOAD_USER_PROFILE": "1"

Par exemple, si vous travaillez dans Visual Studio Code, procédez comme suit :

Ouvrez le fichier local.settings.json de votre projet d'application logique.

Dans l’objet Values JSON, ajoutez ou mettez à jour le WEBSITE_LOAD_USER_PROFILE paramètre :

{
   "IsEncrypted": false,
   "Values": {
      <...>
      "AzureWebJobsStorage": "UseDevelopmentStorage=true",
      "WEBSITE_LOAD_USER_PROFILE": "1",
      <...>
   }
}

Si vous travaillez dans le portail Azure, ouvrez votre application logique. Sous Paramètres dans le menu de la barre latérale, sélectionnez Variables d’environnement. Sous Paramètres de l’application, ajoutez ou modifiez le paramètre.

Contenu avec type multipart/form-data

Pour traiter le contenu de type multipart/form-data dans les requêtes HTTP, vous pouvez ajouter un objet JSON qui inclut les attributs $content-type et $multipart dans le corps de la requête HTTP en utilisant ce format.

"body": {
   "$content-type": "multipart/form-data",
   "$multipart": [
      {
         "body": "<output-from-trigger-or-previous-action>",
         "headers": {
            "Content-Disposition": "form-data; name=file; filename=<file-name>"
         }
      }
   ]
}

Par exemple, supposons que vous disposez d’un flux de travail qui envoie une requête HTTP POST pour un fichier Excel à un site web à l’aide de l’API de ce site, qui prend en charge le multipart/form-data type. L’exemple suivant montre comment cette action peut apparaître :

Voici le même exemple qui montre la définition JSON de l’action HTTP dans la définition de workflow sous-jacente :

"HTTP_action": {
   "inputs": {
      "body": {
         "$content-type": "multipart/form-data",
         "$multipart": [
            {
               "body": "@trigger()",
               "headers": {
                  "Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
               }
            }
         ]
      },
      "method": "POST",
      "uri": "https://finance.contoso.com"
   },
   "runAfter": {},
   "type": "Http"
}

Contenu avec application/x-www-form-urlencoded type

Pour fournir des données form-urlencoded dans le corps d’une requête HTTP, vous devez indiquer que les données présentent le type de contenu application/x-www-form-urlencoded. Dans le déclencheur ou l’action HTTP, ajoutez l’en-tête content-type . Définissez la valeur d’en-tête sur application/x-www-form-urlencoded.

Par exemple, supposons que vous disposez d’une application logique qui envoie une requête HTTP POST à un site web, qui prend en charge le application/x-www-form-urlencoded type. Voici comment cette action peut ressembler :

Comportement de requête-réponse asynchrone

Pour les flux de travail avec état dans Azure Logic Apps multilocataire et monolocataire, toutes les actions basées sur HTTP suivent le modèle d’opération asynchrone standard comme comportement par défaut. Ce modèle spécifie qu’après qu’une action HTTP appelle ou envoie une requête à un point de terminaison, un service, un système ou une API, le récepteur retourne immédiatement une réponse acceptée 202 . Ce code confirme que le récepteur a accepté la requête, mais qu’il n’a pas fini le traitement. La réponse peut inclure un location en-tête qui spécifie l’URI et un ID d’actualisation que l’appelant peut utiliser pour interroger ou vérifier l’état de la demande asynchrone jusqu’à ce que le récepteur cesse de traiter et retourne une réponse de réussite 200 OK ou une autre réponse non-202. Toutefois, l’appelant n’a pas besoin d’attendre la fin du traitement de la requête et peut exécuter l’action suivante. Pour plus d’informations, consultez La messagerie synchrone et asynchrone.

Pour les flux de travail sans état dans les applications logiques Azure monolocataires, les actions HTTP n’utilisent pas le modèle d’opération asynchrone. Au lieu de cela, ils s’exécutent uniquement de manière synchrone, retournent la réponse acceptée 202 as-is, puis passent à l’étape suivante de l’exécution du flux de travail. Si la réponse inclut un location en-tête, un flux de travail sans état n’interroge pas l’URI spécifié pour vérifier l’état. Pour suivre le modèle d’opération asynchrone standard, utilisez plutôt un flux de travail avec état.

La définition JSON sous-jacente de l’action HTTP suit implicitement le modèle d’opération asynchrone.
L’action HTTP, mais pas le déclencheur, a un paramètre de modèle asynchrone , qui est activé par défaut. Ce paramètre spécifie que l’appelant n’attend pas la fin du traitement et peut passer à l’action suivante, mais continue à vérifier l’état jusqu’à ce que le traitement s’arrête. S’il est désactivé, ce paramètre spécifie que l’appelant doit attendre la fin du traitement avant de passer à l’action suivante.

Pour rechercher le paramètre de modèle asynchrone :
1. Dans le concepteur de flux de travail, sélectionnez l’action HTTP .
2. Dans le volet d’information qui s’ouvre, sélectionnez Paramètres.
3. Sous Mise en réseau, recherchez le paramètre de modèle asynchrone .

Désactiver les opérations asynchrones

Parfois, vous souhaiterez peut-être désactiver le comportement asynchrone de l’action HTTP dans des scénarios spécifiques, par exemple, lorsque vous souhaitez :

Éviter les expirations de délai d’attente HTTP pour les tâches de longue durée
Désactiver la vérification des en-têtes d’emplacement

Désactiver le paramètre de modèle asynchrone

Dans le concepteur de flux de travail, sélectionnez l’action HTTP, puis, dans le volet d’informations qui s’ouvre, sélectionnez Paramètres.
Sous Mise en réseau, recherchez le paramètre de modèle asynchrone . Réglez le paramètre sur Désactivé si c'est le cas.

Désactiver le modèle asynchrone dans la définition JSON de l’action

Dans la définition JSON sous-jacente de l’action HTTP, ajoutez l’option DisableAsyncPattern d’opération à la définition de l’action afin que l’action suit le modèle d’opération synchrone à la place. Pour plus d’informations, consultez également Exécuter des actions dans un modèle d’opération synchrone.

Éviter les délais d’expiration HTTP pour les tâches longues

Les requêtes HTTP ont une limite de délai d’expiration. Si vous avez une action HTTP longue qui expire en raison de cette limite, vous disposez de ces options :

Désactivez le modèle d’opération asynchrone de l’action HTTP afin que l’action ne interroge pas continuellement ou vérifie l’état de la requête. Au lieu de cela, l’action attend que le destinataire réponde avec le statut et les résultats une fois le traitement de la demande terminé.
Remplacez l’action HTTP par l’action Http Webhook, qui attend que le récepteur réponde avec l’état et les résultats une fois la requête terminée le traitement.

Configurer l’intervalle entre les nouvelles tentatives avec l’en-tête Retry-After

Pour spécifier le nombre de secondes entre les nouvelles tentatives, vous pouvez ajouter l’en-tête Retry-After à la réponse d’action HTTP. Par exemple, si le point de terminaison de destination retourne le 429 - Too many requests code d’état, vous pouvez spécifier un intervalle plus long entre les nouvelles tentatives. L’en-tête Retry-After fonctionne également avec le code d’état 202 - Accepted .

Voici le même exemple qui montre la réponse d’action HTTP qui contient Retry-After:

{
    "statusCode": 429,
    "headers": {
        "Retry-After": "300"
    }
}

Prise en charge de la pagination

Parfois, le service de destination répond en retournant les résultats d’une page à la fois. Si la réponse spécifie la page suivante avec la propriété nextLink ou @odata.nextLink, vous pouvez activer le paramètre de Pagination dans l’action HTTP. Ce paramètre entraîne l’action HTTP à suivre automatiquement ces liens et à obtenir la page suivante. Toutefois, si la réponse spécifie la page suivante avec une autre balise, vous devrez peut-être ajouter une boucle à votre flux de travail. Effectuez cette boucle en suivant cette balise et obtenez manuellement chaque page jusqu’à ce que la balise soit null.

Désactiver la vérification des en-têtes d’emplacement

Certains points de terminaison, services, systèmes ou API retournent une 202 ACCEPTED réponse qui n’a pas d’en-tête location . Pour éviter d’avoir une action HTTP vérifie continuellement l’état de la demande lorsque l’en-tête location n’existe pas, vous pouvez avoir ces options :

Désactivez le modèle d’opération asynchrone de l’action HTTP afin que l’action ne interroge pas continuellement ou vérifie l’état de la requête. Au lieu de cela, l’action attend que le destinataire réponde avec le statut et les résultats une fois le traitement de la demande terminé.
Remplacez l’action HTTP par l’action Http Webhook, qui attend que le récepteur réponde avec l’état et les résultats une fois la requête terminée le traitement.

Problèmes connus

En-têtes HTTP omis

Si un déclencheur ou une action HTTP inclut ces en-têtes, Azure Logic Apps supprime ces en-têtes du message de requête généré sans afficher d’avertissement ou d’erreur :

En-têtes Accept-*, à l’exception de Accept-version
Allow
En-têtes Content-*, à l’exception de Content-Disposition, Content-Encoding et Content-Type, qui sont respectés quand vous utilisez les opérations POST et PUT. Toutefois, Azure Logic Apps supprime ces en-têtes lorsque vous utilisez l’opération GET .
Cookie en-tête, mais Azure Logic Apps respecte n'importe quelle valeur que vous spécifiez à l'aide de la propriété Cookie.
Expires
Host
Last-Modified
Origin
Set-Cookie
Transfer-Encoding

Bien qu’Azure Logic Apps ne vous empêche pas d’enregistrer des applications logiques qui utilisent un déclencheur HTTP ou une action avec ces en-têtes, Azure Logic Apps ignore ces en-têtes.

Le contenu de réponse ne correspond pas au type de contenu attendu

L’action HTTP génère une erreur BadRequest si l’action HTTP appelle l’API back-end avec l’en-tête Content-Type défini sur application/json, mais que la réponse du back-end ne contient pas réellement de contenu au format JSON, ce qui échoue à la validation du format JSON interne.

Rétroaction

Cette page a-t-elle été utile ?

Last updated on 2025-07-21