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

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 :

Ce guide montre comment créer un point de terminaison pouvant être appelé pour votre workflow en ajoutant le déclencheur 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.

  • Un flux de travail d’application logique dans lequel vous souhaitez utiliser le déclencheur basé sur la requête pour 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.

  • Pour tester l’URL du point de terminaison pouvant être appelé que vous créez, vous aurez besoin d’un outil ou d’une application tel que Postman.

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 :

  1. Dans le portail Microsoft Azure, ouvrez votre ressource d’application logique Standard et votre flux de travail vide dans le concepteur.

  2. Suivez cette procédure générale pour ajouter le déclencheur Requête nommé Lors de la réception d’une requête HTTP.

  3. 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"
                }
             }
          }
       }
    }
    

    Screenshot shows Standard workflow with Request trigger and Request Body JSON Schema parameter with example schema.

    Ou vous pouvez générer un schéma JSON en fournissant un exemple de charge utile :

    1. Dans le déclencheur de requête, sélectionnez Utiliser l’exemple de charge utile pour générer le schéma.

    2. 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"
        }
      }
      
    3. 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é.

  4. Enregistrez votre flux de travail.

    La zone URL POST HTTP affiche désormais l’URL de rappel générée que les 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.

    Screenshot shows Standard workflow, Request trigger, and generated callback URL for endpoint.

  5. Pour copier l’URL de rappel, vous disposez des options suivantes :

    • À droite de la zone URL POST HTTP, sélectionnez Copier l’URL (icône de copie de fichier).

    • Copiez l’URL de rappel à partir de la page Vue d’ensemble de votre flux de travail.

      1. Dans le menu de votre workflow, sélectionnez Vue d’ensemble.

      2. Sur la page Vue d’ensemble, sous URL du flux de travail, déplacez votre pointeur sur l’URL, puis sélectionnez Copier dans le presse-papiers :

        Screenshot shows Standard workflow and Overview page with workflow URL.

  6. Pour tester l’URL de rappel dont vous disposez maintenant pour le déclencheur de requête, utilisez un outil ou une application tel que Postmanet envoyez la requête à l’aide de la méthode attendue par le déclencheur de requête.

    Cet exemple utilise la méthode POST :

    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 de 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.

  1. Dans le déclencheur Requête, ouvrez la liste Paramètres avancés, puis sélectionnez Méthode qui ajoute cette propriété au déclencheur.

  2. 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 d’accès relatif pour les paramètres de votre déclencheur de requête.

    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

  1. Dans le déclencheur Requête, ouvrez la liste Paramètres avancés, ajoutez la propriété Méthode au déclencheur, puis sélectionnez la méthode GET.

    Pour plus d’informations, consultez Sélectionner la méthode de requête attendue.

  2. Dans le concepteur, suivez cette procédure générale pour ajouter l’action dans laquelle vous souhaitez utiliser la valeur du paramètre.

    Pour cet exemple, sélectionnez l’action nommée Réponse.

  3. Pour générer l’expression triggerOutputs() qui récupère la valeur du paramètre, procédez comme suit :

    1. Dans l’action Réponse, cliquez à l’intérieur de la propriété Body pour que les options de contenu dynamique (icône d’éclair) et l’éditeur d’expressions (icône de formule) apparaissent. Sélectionnez l’icône de formule pour ouvrir l’éditeur d’expression.

    2. Dans la zone d’expression, entrez l’expression suivante, en remplaçant parameter-name par le nom de votre paramètre, puis sélectionnez OK.

      triggerOutputs()['queries']['parameter-name']

      Screenshot shows Standard workflow, Response action, and the triggerOutputs() expression.

      Dans la propriété Body, l’expression est résolue en jeton triggerOutputs().

      Screenshot shows Standard workflow with Response action's resolved triggerOutputs() expression.

      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 :

      Screenshot shows Standard workflow with Response action's resolved expression for parameter name.

      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 :

      Screenshot shows Standard workflow with Response action and example triggerOutputs() expression.

Tester votre point de terminaison pouvant être appelé

  1. À 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 au format suivant, puis appuyez sur Entrée.

    ...invoke/{parameter-name}/{parameter-value}?api-version=2022-05-01...

    Par 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 renvoie une réponse avec le texte suivant : Postal Code: 123456

    Screenshot shows browser with Standard workflow response from request to callback URL.

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

  1. 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.

    Screenshot shows Standard workflow, Request trigger, and added property named Relative path.

  2. 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}.

    Screenshot shows Standard workflow, Request trigger, and Relative path parameter value.

  3. Sous le déclencheur Requête, suivez cette procédure générale pour ajouter l’action dans laquelle vous souhaitez utiliser la valeur du paramètre.

    Pour cet exemple, ajoutez l’action Response.

  4. Dans la propriété de corps de l’action de réponse, incluez le jeton qui représente le paramètre que vous avez spécifié dans le chemin d’accès relatif de votre déclencheur.

    Par exemple, supposons que vous souhaitiez que l’action de réponse retourne Postal Code: {postalCode}.

    1. 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.

    2. Dans la liste de contenu dynamique, dans la section Lors de la réception d’une requête HTTP, sélectionnez la sortie du déclencheur Paramètres du chemin d’accès postalCode.

      Screenshot shows Standard workflow, Response action, and specified trigger output to include in response body.

      La propriété de corps contient désormais le paramètre sélectionné :

      Screenshot shows Standard workflow and example response body with parameter.

  5. Enregistrez votre flux de travail.

    L’URL de rappel est mise à jour dans le déclencheur Request. Elle comprend maintenant 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}

  6. Pour tester votre point de terminaison pouvant être appelé, copiez l’URL de rappel mise à jour à partir du déclencheur Request, collez-la dans une autre fenêtre de navigateur, remplacez %7BpostalCode%7D dans l’URL par 123456, puis appuyez sur entrée.

    Le navigateur renvoie une réponse avec le texte suivant : Postal Code: 123456

    Screenshot shows browser with Standard workflow response from request to callback URL.

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 de 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 :

  1. Dans le concepteur, suivez cette procédure générale pour ajouter l’action Opérations de flux de travail nommée Appeler un flux de travail dans cette application de flux de travail.

    La liste Nom du flux de travail affiche les flux de travail éligibles que vous pouvez sélectionner.

  2. Dans la liste Nom du flux de travail, sélectionnez le flux de travail que vous souhaitez appeler, par exemple :

    Screenshot shows Standard workflow, action named Invoke a workflow in this workflow app, opened Workflow Name list, and available workflows to call.

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 propriété body, vous pouvez utiliser l’expression @triggerBody() 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 créer 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 un état 202 Accepté.

Pour que l’appelant d’origine obtienne la réponse, toutes les étapes nécessaires pour la réponse doivent être terminées avant la limite du délai d’expiration de la requête, 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 Requête.

Screenshot shows Response action and response content type.

Les réponses ont ces propriétés :

Propriété (affichage) Propriété (JSON) Description
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 et réponses

Q : Qu’en est-il de la sécurité des URL pour les appels entrants ?

R : Les URL de rappel de l’application logique sont générées de façon sécurisée par Azure à l’aide d’une signature d’accès partagé (SAP). 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 des appels entrants vers votre flux de travail, par exemple, sur TLS (Transport Layer Security), précédemment appelé SSL (Secure Sockets Layer), Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), l’exposition du flux de travail votre application logique avec Gestion des API Azure, ou la restriction des adresses IP dont proviennent les appels entrants, consultez Sécuriser l’accès et les données : accès pour les appels entrants aux déclencheurs basés sur des requêtes.

Q : Puis-je configurer des points de terminaison que je peux appeler de façon plus approfondie ?

R : Oui, les points de terminaison HTTPS prennent en charge une configuration plus avancée par le biais de la 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 :

Étapes suivantes