Note
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier les répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de changer de répertoire.
S’applique à : Azure Logic Apps (Consommation + Standard)
Certains scénarios peuvent nécessiter la création d’un flux de travail d’application logique capable de recevoir des demandes entrantes provenant d’autres services ou flux de travail, ou d’un flux de travail que vous pouvez appeler à l’aide d’une URL. Pour cette tâche, vous pouvez exposer un point de terminaison HTTPS synchrone natif sur votre flux de travail lorsque vous utilisez l’un des types de déclencheurs basés sur les requêtes suivants :
- Requête
- Webhook HTTP
- Déclencheurs de connecteur managé du type ApiConnectionWebhook et pouvant recevoir des requêtes HTTPS entrantes
Ce guide montre comment créer un point de terminaison pouvant être appelé pour votre flux de travail en ajoutant le déclencheur de requête , puis en appelant ce point de terminaison à partir d’un autre flux de travail. Tous les principes s’appliquent de manière identique aux autres types de déclencheurs basés sur les requêtes qui peuvent recevoir des requêtes entrantes.
Prérequis
Un compte et un abonnement Azure. Si vous n’avez pas encore d’abonnement, vous pouvez vous inscrire pour obtenir un compte Azure gratuitement.
Ressource d’application logique avec le workflow dans lequel vous souhaitez créer le point de terminaison pouvant être appelé.
Vous pouvez commencer par un flux de travail vide ou un flux de travail existant où vous pouvez remplacer le déclencheur actuel. Cet exemple commence par un workflow vide.
Installez ou utilisez un outil capable d’envoyer des requêtes HTTP pour tester votre solution, par exemple :
- Visual Studio Code avec une extension de Visual Studio Marketplace
- Invoke-RestMethod de PowerShell
- Microsoft Edge - Outil console réseau
- Bruno
- curl
Attention
Pour les scénarios où vous avez des données sensibles, telles que des informations d’identification, des secrets, des jetons d’accès, des clés API et d’autres informations similaires, veillez à utiliser un outil qui protège vos données avec les fonctionnalités de sécurité nécessaires. L’outil doit fonctionner hors connexion ou localement, et ne nécessite pas de se connecter à un compte en ligne ou de synchroniser des données sur le cloud. Lorsque vous utilisez un outil avec ces caractéristiques, vous réduisez le risque d’exposer des données sensibles au public.
Créer un point de terminaison pouvant être appelé
Selon que vous disposez d’un flux de travail d’application logique Standard ou Consommation, suivez les étapes correspondantes :
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 de requête à votre flux de travail en suivant les étapes générales pour ajouter un déclencheur.
Cet exemple continue avec le déclencheur nommé Lorsqu’une requête HTTP est reçue.
Si vous le souhaitez, dans la boîte du schéma JSON du corps de la requête, vous pouvez entrer un schéma JSON qui décrit la charge utile ou les données que le déclencheur doit recevoir.
Le concepteur utilise ce schéma pour générer des jetons qui représentent des sorties de déclencheur. Vous pouvez ensuite facilement référencer ces sorties dans le flux de travail de votre application logique. Cliquez sur le lien renvoyant à la section Jetons générés à partir de schémas JSON pour votre application logique pour en apprendre davantage.
Pour cet exemple, entrez le schéma suivant :
{ "type": "object", "properties": { "address": { "type": "object", "properties": { "streetNumber": { "type": "string" }, "streetName": { "type": "string" }, "town": { "type": "string" }, "postalCode": { "type": "string" } } } } }
Ou vous pouvez générer un schéma JSON en fournissant un exemple de charge utile :
Dans le déclencheur de requête, sélectionnez Utiliser l’exemple de charge utile pour générer le schéma.
Dans la boîte Entrer ou coller un exemple de charge utile JSON, entrez votre exemple de charge utile, par exemple :
{ "address": { "streetNumber": "00000", "streetName": "AnyStreet", "town": "AnyTown", "postalCode": "11111-1111" } }Quand vous êtes prêt, sélectionnez Terminé.
La boîte de Schéma JSON du corps de la requête affiche maintenant le schéma généré.
Enregistrez votre flux de travail.
La zone URL HTTP affiche désormais l’URL de rappel générée que d’autres services peuvent utiliser pour appeler et déclencher votre flux de travail d’application logique. Cette URL contient des paramètres de requête qui spécifient une clé de signature d’accès partagé (SAP), qui est utilisée pour l’authentification.
Copiez l’URL de rappel en sélectionnant l’icône de copie en regard de la zone URL HTTP.
Pour tester l’URL de rappel et déclencher le flux de travail, envoyez une requête HTTP à l’URL, y compris la méthode attendue par le déclencheur Requête, en utilisant votre outil de requête HTTP et ses instructions.
Cet exemple utilise la méthode POST avec l’URL copiée, qui ressemble à l’exemple suivant :
POST https://{logic-app-name}.azurewebsites.net:443/api/{workflow-name}/triggers/{trigger-name}/invoke?api-version=2022-05-01&sp=%2Ftriggers%2F{trigger-name}%2Frun&sv=1.0&sig={shared-access-signature}
Sélectionner la méthode de requête attendue
Par défaut, le déclencheur Requête attend une requête POST. Cependant, vous pouvez spécifier une autre méthode à utiliser par l’appelant, mais il doit s’agir d’une méthode unique.
Dans le déclencheur Requête, dans la liste Méthode, sélectionnez la méthode attendue par le déclencheur. Ou vous pouvez spécifier une méthode personnalisée.
Par exemple, sélectionnez la méthode GET pour pouvoir tester ultérieurement l’URL de votre point de terminaison.
Passer des paramètres via l’URL de point de terminaison
Lorsque vous souhaitez accepter des valeurs de paramètre par le biais de l’URL du point de terminaison, vous disposez des options suivantes :
Accepter les valeurs par le biais des paramètres d’extraction ou des paramètres d’URL.
Ces valeurs sont passées en tant que paires nom-valeur dans l’URL du point de terminaison. Pour cette option, vous devez utiliser la méthode GET dans votre déclencheur de requête. Plus tard, vous pouvez obtenir les valeurs de paramètre en tant que sorties de déclencheur à l’aide de la fonction
triggerOutputs()dans une expression.Acceptez les valeurs via un chemin relatif pour les paramètres de votre déclencheur de demande.
Ces valeurs sont transmises via un chemin d’accès relatif dans l’URL du point de terminaison. Vous devez également explicitement sélectionner la méthode que le déclencheur attend. Plus tard, vous pouvez obtenir les valeurs des paramètre en tant que sorties de déclencheur en référençant directement ces sorties.
Accepter les valeurs par le biais des paramètres GET
Dans le déclencheur De requête , dans la liste des méthodes , sélectionnez la méthode GET .
Pour plus d’informations, consultez Sélectionner la méthode de requête attendue.
Ajoutez l’action Réponse à votre flux de travail en suivant les étapes générales pour ajouter une action.
Pour générer l’expression
triggerOutputs()qui récupère la valeur du paramètre, procédez comme suit :Dans l’action Réponse , sélectionnez à l’intérieur de la propriété Body pour que les options de contenu dynamique (icône éclair) et l’éditeur d’expressions (icône de formule) apparaissent. Sélectionnez l’icône de formule pour ouvrir l’éditeur d’expression.
Dans la zone d’expression, entrez l’expression suivante, en remplaçant
parameter-namepar le nom de votre paramètre, puis sélectionnez OK.triggerOutputs()['queries']['parameter-name']
Dans la propriété Body, l’expression est résolue en jeton
triggerOutputs().
Si vous enregistrez le flux de travail, quittez le concepteur, puis revenez-y. Le jeton affiche le nom du paramètre que vous avez spécifié, par exemple :
En mode Code, la propriété Body apparaît dans la définition de l’action Response comme suit :
"body": "@{triggerOutputs()['queries']['parameter-name']}",Supposons, par exemple, que vous souhaitiez passer une valeur pour un paramètre nommé
postalCode. La propriété Body spécifie la chaîne,Postal Code:avec un espace de fin, suivi par l’expression correspondante :
Tester votre point de terminaison pouvant être appelé
À partir du déclencheur Requête, copiez l’URL du flux de travail et collez l’URL dans une autre fenêtre de navigateur. Dans l’URL, ajoutez le nom et la valeur du paramètre à l’URL au format suivant, puis appuyez sur Entrée.
...invoke/{parameter-name}/{parameter-value}?api-version=2022-05-01...Exemple :
https://mystandardlogicapp.azurewebsites.net/api/Stateful-Workflow/triggers/When_a_HTTP_request_is_received/invoke/address/12345?api-version=2022-05-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig={shared-access-signature}Le navigateur retourne une réponse avec ce texte : « Code postal : 123456 »
Remarque
Si vous souhaitez inclure le code de hachage ou le symbole dièse (#) dans l’URI, utilisez plutôt cette version encodée : %25%23
Accepter les valeurs via un chemin d’accès relatif
Dans le déclencheur Requête, ouvrez la liste Paramètres avancés, puis sélectionnez Chemin d’accès relatif qui ajoute cette propriété au déclencheur.
Dans la propriété Chemin d’accès relatif, spécifiez le chemin d’accès relatif que vous souhaitez que votre URL accepte pour le paramètre dans votre schéma JSON, par exemple
/address/{postalCode}.
Dans la propriété Body de l’action Réponse, incluez le jeton qui représente le paramètre que vous avez spécifié dans le chemin relatif de votre déclencheur.
Par exemple, supposons que vous souhaitez que l’action Réponse retourne
Postal Code: {postalCode}.Dans la propriété de corps, entrez
Postal Code:avec un espace de fin. Maintenez votre curseur à l’intérieur de la zone d’édition pour que la liste de contenu dynamique reste ouverte.Sélectionnez l’icône éclair pour ouvrir la liste de contenu dynamique. Dans la section Quand une requête HTTP est reçue , sélectionnez la sortie du déclencheur postalCode .
La propriété de corps contient désormais le paramètre sélectionné :
Enregistrez votre flux de travail.
Sous le déclencheur Requête, l’URL de rappel est mise à jour et comprend désormais le chemin d’accès relatif, par exemple :
https://mystandardlogicapp.azurewebsites.net/api/Stateful-Workflow/triggers/When_a_HTTP_request_is_received/invoke/address/%7BpostalCode%7D?api-version=2022-05-01&sp=%2Ftriggers%2FWhen_a_HTTP_request_is_received%2Frun&sv=1.0&sig={shared-access-signature}Pour tester le point de terminaison pouvant être appelé, copiez l’URL de rappel mise à jour à partir du déclencheur de requête, collez l’URL dans une autre fenêtre de navigateur, remplacez-la
%7BpostalCode%7Ddans l’URL par 123456, puis appuyez sur Entrée.Le navigateur retourne une réponse avec ce texte : « Code postal : 123456 »
Remarque
Si vous souhaitez inclure le code de hachage ou le symbole dièse (#) dans l’URI, utilisez plutôt cette version encodée : %25%23
Appeler un flux de travail via l’URL du point de terminaison
Après avoir créé le point de terminaison, vous pouvez déclencher le flux de travail en envoyant une requête HTTPS à l’URL complète du point de terminaison. Les flux de travail Azure Logic Apps ont une prise en charge intégrée pour les points de terminaison d’accès direct.
Jetons générés à partir du schéma
Lorsque vous fournissez un schéma JSON dans le déclencheur Requête, le concepteur de workflow génère des jetons pour les propriétés de ce schéma. Vous pouvez ensuite utiliser ces jetons pour transmettre des données via votre flux de travail.
Par exemple, si vous ajoutez d’autres propriétés, telles que "suite", à votre schéma JSON, vous pouvez utiliser des jetons pour ces propriétés dans les étapes ultérieures de votre flux de travail. Voici le schéma JSON complet :
{
"type": "object",
"properties": {
"address": {
"type": "object",
"properties": {
"streetNumber": {
"type": "string"
},
"streetName": {
"type": "string"
},
"suite": {
"type": "string"
},
"town": {
"type": "string"
},
"postalCode": {
"type": "string"
}
}
}
}
}
Appeler d’autres flux de travail
Vous pouvez appeler d’autres flux de travail qui peuvent recevoir des requêtes en les imbriquant à l’intérieur du flux de travail actuel. Pour appeler ces workflows, procédez comme suit :
Dans le concepteur, ajoutez l’action Opérations de workflow nommée Appeler le workflow dans cette application logique.
La liste Nom du flux de travail affiche les flux de travail éligibles que vous pouvez sélectionner.
Dans la liste Nom du flux de travail, sélectionnez le flux de travail que vous souhaitez appeler, par exemple :
Référencer du contenu à partir d’une requête entrante
Si le type de contenu de la requête entrante est application/json, vous pouvez référencer les propriétés dans la requête entrante. Sinon, ce contenu est traité comme une seule unité binaire que vous pouvez transmettre à d’autres API. Pour référencer ce contenu dans le flux de travail de votre application logique, vous devez d’abord convertir ce contenu.
Par exemple, si vous transmettez du contenu dont le type de application/xml est, vous pouvez utiliser l’expression xpath() pour effectuer une extraction XPath ou utiliser l’expression json() pour la conversion de XML en JSON. En savoir plus sur l’utilisation des types de contenus pris en charge.
Pour obtenir la sortie à partir d’une requête entrante, vous pouvez utiliser l’expression triggerOutputs. Par exemple, supposons que vous ayez une sortie ressemblant à l’exemple suivant :
{
"headers": {
"content-type" : "application/json"
},
"body": {
"myProperty" : "property value"
}
}
Pour accéder spécifiquement à la body propriété, vous pouvez utiliser l’expressiontriggerBody() comme raccourci.
Répondre aux requêtes
Parfois, vous souhaitez répondre à certaines demandes qui déclenchent votre flux de travail en renvoyant le contenu à l’appelant. Pour construire le code d’état, l’en-tête et le corps de votre réponse, utilisez l’action Réponse . Cette action peut apparaître n’importe où dans votre flux de travail, et pas seulement à la fin de celui-ci. Si votre flux de travail n’inclut pas d’action Réponse , le point de terminaison répond immédiatement avec l’état 202 Accepté .
Pour que l’appelant d’origine obtienne correctement la réponse, toutes les étapes requises pour la réponse doivent se terminer dans la limite de délai d’attente de la demande , sauf si le flux de travail déclenché est appelé en tant que flux de travail imbriqué. Si aucune réponse n’est retournée avant cette limite, la requête entrante expire et reçoit la réponse 408 - Dépassement du délai d’expiration par le client.
Pour les flux de travail imbriqués, le flux de travail parent continue à attendre une réponse jusqu’à ce que toutes les étapes aient été effectuées, quelle que soit la durée de l’opération.
Construire la réponse
Vous pouvez inclure plusieurs en-têtes et n’importe quel type de contenu dans le corps de la réponse. Par exemple, l’en-tête de la réponse suivante spécifie que le type de contenu de la réponse est application/json et que le corps contient des valeurs pour les propriétés town et postalCode, en fonction du schéma JSON décrit précédemment dans cette rubrique pour le déclencheur de requête.
Les réponses ont ces propriétés :
| Propriété (affichage) | Propriété (JSON) | Descriptif |
|---|---|---|
| Code d’état | statusCode |
Le code d’état HTTPS à utiliser dans la réponse pour la requête entrante. Ce code peut être tout code d’état valide commençant par 2xx, 4xx ou 5xx. Cependant, les codes d’état 3xx ne sont pas autorisés. |
| En-têtes | headers |
Un ou plusieurs en-têtes à inclure dans la réponse |
| Corps | body |
Un objet corps peut être une chaîne, un objet JSON ou même du contenu binaire référencé à partir d’une étape précédente |
Pour afficher la définition JSON de l’action Réponse et la définition JSON complète de votre flux de travail, passez du mode Concepteur à la vue de code.
"Response": {
"type": "Response",
"kind": "http",
"inputs": {
"body": {
"postalCode": "@triggerBody()?['address']?['postalCode']",
"town": "@triggerBody()?['address']?['town']"
},
"headers": {
"content-type": "application/json"
},
"statusCode": 200
},
"runAfter": {}
}
Questions fréquentes
Qu’en est-il de la sécurité des URL pour les appels entrants ?
Azure génère en toute sécurité des URL de rappel d’application logique à l’aide de la signature d’accès partagé (SAS). Cette signature est transmise directement comme paramètre de requête et doit être validée avant que votre flux de travail puisse être exécuté. Azure génère cette signature via la combinaison unique d’une clé secrète par application logique, du nom du déclencheur et de l’opération qui est effectuée. Ainsi, à moins que quelqu’un ait accès à la clé secrète de l’application logique, personne ne peut générer de signature valide.
Important
Pour les systèmes de production et les systèmes ayant un niveau de sécurité supérieur, nous vous déconseillons fortement d’appeler votre flux de travail directement à partir du navigateur pour les raisons suivantes :
- la clé d’accès partagé s’affiche dans l’URL ;
- Vous ne pouvez pas gérer les stratégies de contenu de sécurité en raison du partage de domaines entre les clients Azure Logic Apps.
Pour plus d’informations sur la sécurité, l’autorisation et le chiffrement pour les appels entrants à votre flux de travail, tels que Transport Layer Security (TLS),Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) , expose votre flux de travail d’application logique avec Gestion des API Azure ou limite les adresses IP qui proviennent des appels entrants, consultez Accès sécurisé et données - Accès pour les appels entrants aux déclencheurs basés sur des requêtes.
Puis-je configurer des points de terminaison pouvant être appelants plus loin ?
Oui, les points de terminaison HTTPS prennent en charge une configuration plus avancée via Gestion des API Azure. Ce service vous offre également la possibilité de gérer toutes vos API de façon systématique, y compris les applications logiques, de configurer les noms de domaines personnalisés, d’utiliser plus de méthodes d’authentification et bien plus encore, comme par exemple :
- Définir la méthode de requête
- URL de réécriture
- Configuration de vos domaines Gestion des API dans le portail Azure
- Configuration d’une stratégie pour vérifier l’authentification de base