Guide de référence du schéma des types d’actions et de déclencheurs dans Azure Logic Apps

Ce document de référence décrit les types généraux utilisés pour identifier les déclencheurs et les actions dans la définition de flux de travail sous-jacente de votre application logique, qui est décrite et validée par le langage de définition du flux de travail. Pour rechercher des déclencheurs et des actions de connecteur spécifiques que vous pouvez utiliser dans vos applications logiques, consultez la liste figurant sous la présentation des connecteurs.

Vue d’ensemble des déclencheurs

Tous les flux de travail incluent un déclencheur, qui définit les appels qui instancient et démarrent le workflow. Voici les catégories générales de déclencheurs :

• Déclencheur d’interrogation, qui vérifie le point de terminaison d’un service à intervalles réguliers

• Déclencheur push, qui crée un abonnement à un point de terminaison et fournit une URL de rappel permettant au point de terminaison d’informer le déclencheur quand l’événement spécifié se produit ou quand des données sont disponibles. Le déclencheur attend ensuite la réponse du point de terminaison avant de s’activer

Les déclencheurs ont les éléments principaux suivants, bien que certains soient facultatifs :

"<trigger-name>": {
   "type": "<trigger-type>",
   "inputs": { "<trigger-inputs>" },
   "recurrence": { 
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "conditions": [ "<array-with-conditions>" ],
   "runtimeConfiguration": { "<runtime-config-options>" },
   "splitOn": "<splitOn-expression>",
   "operationOptions": "<operation-option>"
},

Obligatoire

Valeur	Type	Description
<trigger-name>	String	Nom du déclencheur
<trigger-type>	String	Type de déclencheur, tel que « Http » ou « ApiConnection »
<trigger-inputs>	Objet JSON	Entrées qui définissent le comportement du déclencheur
<time-unit>	String	Unité de temps qui décrit la fréquence d’activation du déclencheur : "Second", "Minute", "Hour", "Day", "Week", "Month"
<number-of-time-units>	Entier	Valeur qui spécifie la fréquence à laquelle le déclencheur se déclenche en fonction de la fréquence, qui correspond au nombre d’unités de temps à attendre jusqu’à ce que le déclencheur se déclenche à nouveau Voici les intervalles minimum et maximal : - Month: 1-16 months - Day: 1-500 days - Hour: 1-12,000 hours - Minute: 1-72,000 minutes - Second: 1-9,999,999 seconds Par exemple, si l’intervalle est défini sur 6 et la fréquence sur « Month », la périodicité est tous les six mois.

Facultatif

Valeur	Type	Description
<array-with-conditions>	Array	Tableau qui contient une ou plusieurs conditions qui déterminent s’il faut exécuter le workflow. Uniquement disponible pour les déclencheurs.
<runtime-config-options>	Objet JSON	Vous pouvez modifier le comportement d’exécution du déclencheur en définissant des propriétés runtimeConfiguration. Pour plus d’informations, consultez Paramètres de configuration d’exécution.
<splitOn-expression>	String	Pour les déclencheurs qui retournent un tableau, vous pouvez spécifier une expression qui fractionne ou dégroupe des éléments de tableau dans plusieurs instances de workflows à des fins de traitement.
<operation-option>	String	Vous pouvez modifier le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Liste des types de déclencheurs

Chaque type de déclencheur a une interface et des entrées différentes qui définissent son comportement.

Déclencheurs intégrés

Type de déclencheur	Description
HTTP	Vérifie ou interroge n’importe quel point de terminaison. Ce point de terminaison doit être conforme à un contrat de déclencheur spécifique, soit en utilisant un modèle asynchrone 202, soit en retournant un tableau.
HTTPWebhook	Crée un point de terminaison pouvant être appelé pour votre application logique, mais appelle l’URL spécifiée pour inscrire ou désinscrire.
Recurrence	Se déclenche selon une planification définie. Vous pouvez définir une date et une heure ultérieures pour déclencher ce déclencheur. En fonction de la fréquence, vous pouvez également spécifier des heures et des jours d’exécution de votre workflow.
Request	Crée un point de terminaison pouvant être appelé pour votre application logique (également appelé déclencheur « manuel »). Par exemple, consultez Appeler, déclencher ou imbriquer des workflows via des points de terminaison HTTP.

Déclencheurs d’API managées

Type de déclencheur	Description
ApiConnection	Vérifie ou interroge un point de terminaison grâce aux API ou connecteurs managés par Microsoft.
ApiConnectionWebhook	Crée un point de terminaison pouvant être appelé pour le flux de travail de votre application logique en appelant des API ou connecteurs managés par Microsoft afin de s’abonner et d’annuler l’abonnement.

Déclencheurs - Référence détaillée

Déclencheur APIConnection

Ce déclencheur vérifie ou interroge un point de terminaison au moyen des API ou connecteurs managés par Microsoft afin que les paramètres dudit déclencheur puissent différer en fonction du point de terminaison. De nombreuses sections de cette définition de déclencheur sont facultatives. Le comportement du déclencheur dépend de l’inclusion des sections.

"<APIConnection_trigger_name>": {
   "type": "ApiConnection",
   "inputs": {
      "host": {
         "connection": {
            "name": "@parameters('$connections')['<connection-name>']['connectionId']"
         }
      },
      "method": "<method-type>",
      "path": "/<api-operation>",
      "retryPolicy": { "<retry-behavior>" },
      "queries": { "<query-parameters>" }
   },
   "recurrence": { 
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "splitOn": "<splitOn-expression>",
   "operationOptions": "<operation-option>"
}

Obligatoire

Propriété	Valeur	Type	Description
None	<APIConnection_trigger_name>	String	Nom du déclencheur
host.connection.name	<connection-name>	String	Nom de la connexion à l’API managée utilisée par le workflow
method	<method-type>	Chaîne	Méthode HTTP pour communiquer avec l’API managée : GET, PUT, POST, PATCH, DELETE
path	<api-operation>	String	Opération d’API à appeler
recurrence.frequency	<time-unit>	Chaîne	Unité de temps qui décrit la fréquence à laquelle le déclencheur se déclenche : Seconde, Minute, Heure, Jour, Semaine, Mois
recurrence.interval	<number-of-time-units>	Entier	Valeur qui spécifie la fréquence à laquelle le déclencheur se déclenche en fonction de la fréquence, qui correspond au nombre d’unités de temps à attendre jusqu’à ce que le déclencheur se déclenche à nouveau Voici les intervalles minimum et maximal : - Mois : 1 à 16 mois - Jour : 1 à 500 jours - Heure : 1 à 12 000 heures - Minute : 1 à 72 000 minutes - Deuxième : 1-9,999,999 secondes Par exemple, si l’intervalle est de 6 et que la fréquence est Mois, la périodicité est toutes les 6 mois.

Facultatif

Propriété	Valeur	Type	Description
retryPolicy	<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
Requêtes	<query-parameters>	Objet JSON	Paramètres de requête à inclure avec l’appel d’API. Par exemple, l’objet "queries": { "api-version": "2018-01-01" } ajoute ?api-version=2018-01-01 à l’appel.
runtimeConfiguration.concurrency.runs	<max-runs>	Integer	Par défaut, les instances de workflow s’exécutent en même temps (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour changer cette limite en définissant une nouvelle valeur <count>, consultez Changer la concurrence du déclencheur.
runtimeConfiguration.maximum WaitingRuns	<max-runs-queue>	Entier	Si votre workflow exécute déjà le nombre maximal d’instances, toutes les nouvelles exécutions sont placées dans cette file d’attente jusqu’à la limite par défaut. Pour changer la limite par défaut, consultez Changer la limite d’exécutions en attente. Pour modifier le nombre maximal d’instances, spécifiez une valeur pour la propriété runtimeConfiguration.concurrency.runs . Remarque : Si vous définissez le
splitOn	<splitOn-expression>	String	Pour les déclencheurs qui retournent des tableaux, cette expression référence le tableau à utiliser pour que vous puissiez créer et exécuter une instance de workflow pour chaque élément du tableau, au lieu d’utiliser une boucle « for each ». Par exemple, cette expression représente un élément dans le tableau retourné dans le contenu du corps du déclencheur : @triggerbody()?['value']
operationOptions	<operation-option>	String	Vous pouvez modifier le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Sorties

Élément	Type	Description
headers	Objet JSON	En-têtes de la réponse
corps	Objet JSON	Corps de la réponse
code d’état	Integer	Code d’état de la réponse

Exemple

Cette définition de déclencheur vérifie tous les jours les e-mails dans la boîte de réception d’un compte professionnel ou scolaire :

"When_a_new_email_arrives": {
   "type": "ApiConnection",
   "inputs": {
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "get",
      "path": "/Mail/OnNewEmail",
      "queries": {
          "fetchOnlyWithAttachment": false,
          "folderPath": "Inbox",
          "importance": "Any",
          "includeAttachments": false
      }
   },
   "recurrence": {
      "frequency": "Day",
      "interval": 1
   }
}

Déclencheur ApiConnectionWebhook

Ce déclencheur envoie une demande d’abonnement à un point de terminaison à l’aide d’une API managée par Microsoft, fournit une URL de rappel où le point de terminaison peut envoyer une réponse, et attend que le point de terminaison réponde. Pour plus d’informations, consultez Abonnements de point de terminaison.

"<ApiConnectionWebhook_trigger_name>": {
   "type": "ApiConnectionWebhook",
   "inputs": {
      "body": {
          "NotificationUrl": "@{listCallbackUrl()}"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['<connection-name>']['connectionId']"
         }
      },
      "retryPolicy": { "<retry-behavior>" },
      "queries": "<query-parameters>"
   },
   "runTimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-run-queue>
      }
   },
   "splitOn": "<splitOn-expression>",
   "operationOptions": "<operation-option>"
}

Obligatoire

Valeur	Type	Description
<connection-name>	String	Nom de la connexion à l’API managée utilisée par le workflow
<body-content>	Objet JSON	Tout contenu de message à envoyer en tant que charge utile à l’API managée

Facultatif

Valeur	Type	Description
<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
<query-parameters>	Objet JSON	Tous les paramètres de requête à inclure avec l’appel d’API Par exemple, l’objet "queries": { "api-version": "2018-01-01" } ajoute ?api-version=2018-01-01 à l’appel.
<max-runs>	Integer	Par défaut, les instances de workflow s’exécutent en même temps (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour changer cette limite en définissant une nouvelle valeur <count>, consultez Changer la concurrence du déclencheur.
<max-runs-queue>	Integer	Lorsque votre application logique exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la propriété runtimeConfiguration.concurrency.runs, les nouvelles exécutions sont placées dans cette file d’attente jusqu’à la limite par défaut. Pour changer la limite par défaut, consultez Changer la limite d’exécutions en attente.
<splitOn-expression>	String	Pour les déclencheurs qui retournent des tableaux, cette expression référence le tableau à utiliser pour que vous puissiez créer et exécuter une instance de workflow pour chaque élément du tableau, au lieu d’utiliser une boucle « for each ». Par exemple, cette expression représente un élément dans le tableau retourné dans le contenu du corps du déclencheur : @triggerbody()?['value']
<operation-option>	String	Vous pouvez modifier le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Exemple

Cette définition de déclencheur s’abonne à l’API Office 365 Outlook, fournit une URL de rappel au point de terminaison d’API, et attend que le point de terminaison réponde quand un nouvel e-mail arrive.

"When_a_new_email_arrives_(webhook)": {
   "type": "ApiConnectionWebhook",
   "inputs": {
      "body": {
         "NotificationUrl": "@{listCallbackUrl()}" 
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "path": "/MailSubscription/$subscriptions",
      "queries": {
          "folderPath": "Inbox",
          "hasAttachment": "Any",
          "importance": "Any"
      }
   },
   "splitOn": "@triggerBody()?['value']"
}

Déclencheur HTTP

Ce déclencheur envoie une requête au point de terminaison HTTP ou HTTPS spécifié d’après la planification de périodicité définie. Le déclencheur vérifie ensuite la réponse pour déterminer si le workflow s’exécute. Pour plus d’informations, consultez Appeler des points de terminaison de service via HTTP ou HTTPS à partir d’Azure Logic Apps.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "<method-type>",
      "uri": "<HTTP-or-HTTPS-endpoint-URL>",
      "headers": { "<header-content>" },
      "queries": "<query-parameters>",
      "body": "<body-content>",
      "authentication": { "<authentication-type-and-property-values>" },
      "retryPolicy": {
         "type": "<retry-behavior>"
      }
   },
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

Obligatoire

Propriété	Valeur	Type	Description
method	<method-type>	String	Méthode à utiliser pour envoyer la requête sortante : « GET », « PUT », « POST », « PATCH » ou « DELETE »
uri	<HTTP-or-HTTPS-endpoint-URL>	String	URL du point de terminaison HTTP ou HTTPS où vous voulez envoyer la requête sortante. Taille de chaîne maximale : 2 Ko Pour un service ou une ressource Azure, cette syntaxe URI inclut l'ID de la ressource et le chemin vers la ressource à laquelle vous voulez accéder.
frequency	<time-unit>	String	Unité de temps qui décrit la fréquence d’activation du déclencheur : "Second", "Minute", "Hour", "Day", "Week", "Month"
interval	<number-of-time-units>	Entier	Valeur qui spécifie la fréquence à laquelle le déclencheur se déclenche en fonction de la fréquence, qui correspond au nombre d’unités de temps à attendre jusqu’à ce que le déclencheur se déclenche à nouveau Voici les intervalles minimum et maximal : - Month: 1-16 months - Day: 1-500 days - Hour: 1-12,000 hours - Minute: 1-72,000 minutes - Second: 1-9,999,999 seconds Par exemple, si l’intervalle est défini sur 6 et la fréquence sur « Month », la périodicité est tous les six mois.

Facultatif

Propriété	Valeur	Type	Description
headers	<header-content>	Objet JSON	Tous les en-têtes que vous devez inclure avec la demande Par exemple, pour définir la langue et le type : "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries	<query-parameters>	Objet JSON	Tous les paramètres de requête que vous devez utiliser dans la requête Par exemple, l’objet "queries": { "api-version": "2018-01-01" } ajoute ?api-version=2018-01-01 à la requête.
body	<body-content>	Objet JSON	Contenu du message à envoyer en tant que charge utile avec la requête
authentication	<authentication-type-and-property-values>	Objet JSON	Le modèle d'authentification que la requête utilise pour authentifier les requêtes sortantes. Pour plus d’informations, voir Ajouter l’authentification aux appels sortants. Au-delà de Scheduler, la propriété authority est prise en charge. Si vous ne spécifiez aucune valeur, la valeur par défaut est https://management.azure.com/, mais vous pouvez utiliser une autre valeur.
retryPolicy > type	<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
runs	<max-runs>	Integer	Par défaut, les instances de workflow s’exécutent en même temps (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour changer cette limite en définissant une nouvelle valeur <count>, consultez Changer la concurrence du déclencheur.
maximumWaitingRuns	<max-runs-queue>	Integer	Lorsque votre application logique exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la propriété runtimeConfiguration.concurrency.runs, les nouvelles exécutions sont placées dans cette file d’attente jusqu’à la limite par défaut. Pour changer la limite par défaut, consultez Changer la limite d’exécutions en attente.
operationOptions	<operation-option>	String	Vous pouvez modifier le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Sorties

Élément	Type	Description
headers	Objet JSON	En-têtes de la réponse
body	Objet JSON	Corps de la réponse
status code	Integer	Code d’état de la réponse

Conditions requises pour les requêtes entrantes

Pour fonctionner correctement avec votre application logique, le point de terminaison doit être conforme à un modèle ou contrat de déclencheur spécifique, et reconnaître les propriétés de réponse suivantes :

Propriété	Obligatoire	Description
Code d’état	Oui	Le code d’état « 200 OK » démarre une exécution. Les autres codes d’état ne démarrent pas d’exécution.
En-tête Retry-after	Non	Nombre de secondes au bout duquel l’application logique interroge à nouveau le point de terminaison
En-tête Location	Non	URL à appeler lors du prochain intervalle d’interrogation. Si aucune valeur n’est spécifiée, l’URL d’origine est utilisée.

Exemples de comportements pour différentes requêtes

Code d’état	Retry after (Réessayer après)	Comportement
200	{aucune}	Exécutez le workflow et vérifiez de nouveau pour obtenir plus de données après la périodicité définie.
200	10 secondes	Exécutez le workflow et vérifiez de nouveau pour obtenir plus de données après 10 secondes.
202	60 secondes	Ne pas déclencher le workflow. La prochaine tentative se produit dans une minute conformément à la périodicité définie. Si la périodicité définie est inférieure à une minute, l’en-tête retry-after est prioritaire. Dans le cas contraire, la périodicité définie est utilisée.
400	{aucune}	Requête incorrecte, ne pas exécuter le workflow. Si aucune valeur retryPolicy n’est définie, la stratégie par défaut est utilisée. Une fois que le nombre de nouvelles tentatives a été atteint, le déclencheur vérifie de nouveau pour obtenir plus de données après la périodicité définie.
500	{aucune}	Erreur de serveur, ne pas exécuter le workflow. Si aucune valeur retryPolicy n’est définie, la stratégie par défaut est utilisée. Une fois que le nombre de nouvelles tentatives a été atteint, le déclencheur vérifie de nouveau pour obtenir plus de données après la périodicité définie.

Déclencheur HTTPWebhook

Ce déclencheur permet à votre application logique de pouvoir être appelée en créant un point de terminaison capable d’inscrire un abonnement en appelant l’URL de point de terminaison spécifiée. Quand vous créez ce déclencheur dans votre workflow, une requête sortante effectue l’appel pour inscrire l’abonnement. De cette façon, le déclencheur peut commencer à écouter les événements. Quand une opération rend ce déclencheur non valide, une requête sortante effectue automatiquement l’appel afin d’annuler l’abonnement. Pour plus d’informations, consultez Abonnements de point de terminaison.

Vous pouvez également spécifier des limites asynchrones sur un déclencheur HTTPWebhook. Le comportement du déclencheur varie en fonction des sections que vous incluez ou omettez.

"HTTP_Webhook": {
   "type": "HttpWebhook",
   "inputs": {
      "subscribe": {
         "method": "<method-type>",
         "uri": "<endpoint-subscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" },
         "retryPolicy": { "<retry-behavior>" }
      },
      "unsubscribe": {
         "method": "<method-type>",
         "url": "<endpoint-unsubscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" }
      }
   },
   "runTimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

Certaines valeurs, telles que <method-type>, sont disponibles pour les objets "subscribe" et "unsubscribe".

Obligatoire

Valeur	Type	Description
<method-type>	String	Méthode HTTP utilisée pour la requête d’abonnement : « GET », « PUT », « POST », « PATCH » ou « DELETE »
<endpoint-subscribe-URL>	String	URL du point de terminaison où envoyer la requête d’abonnement

Facultatif

Valeur	Type	Description
<method-type>	String	Méthode HTTP utilisée pour la requête d’annulation : « GET », « PUT », « POST », « PATCH » ou « DELETE »
<endpoint-unsubscribe-URL>	String	URL du point de terminaison où envoyer la requête d’annulation
<body-content>	String	Tout contenu de message à envoyer dans la requête d’abonnement ou d’annulation
<authentication-type>	Objet JSON	Le modèle d'authentification que la requête utilise pour authentifier les requêtes sortantes. Pour plus d’informations, voir Ajouter l’authentification aux appels sortants.
<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
<max-runs>	Integer	Par défaut, les instances de workflow s’exécutent toutes en même temps (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour changer cette limite en définissant une nouvelle valeur <count>, consultez Changer la concurrence du déclencheur.
<max-runs-queue>	Integer	Lorsque votre application logique exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la propriété runtimeConfiguration.concurrency.runs, les nouvelles exécutions sont placées dans cette file d’attente jusqu’à la limite par défaut. Pour changer la limite par défaut, consultez Changer la limite d’exécutions en attente.
<operation-option>	String	Vous pouvez modifier le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Sorties

Élément	Type	Description
headers	Objet JSON	En-têtes de la réponse
body	Objet JSON	Corps de la réponse
Code d’état	Integer	Code d’état de la réponse

Exemple

Ce déclencheur crée un abonnement au point de terminaison spécifié, fournit une URL de rappel unique, et attend des articles sur la technologie venant d’être publiés.

"HTTP_Webhook": {
   "type": "HttpWebhook",
   "inputs": {
      "subscribe": {
         "method": "POST",
         "uri": "https://pubsubhubbub.appspot.com/subscribe",
         "body": {
            "hub.callback": "@{listCallbackUrl()}",
            "hub.mode": "subscribe",
            "hub.topic": "https://pubsubhubbub.appspot.com/articleCategories/technology"
         },
      },
      "unsubscribe": {
         "method": "POST",
         "url": "https://pubsubhubbub.appspot.com/subscribe",
         "body": {
            "hub.callback": "@{workflow().endpoint}@{listCallbackUrl()}",
            "hub.mode": "unsubscribe",
            "hub.topic": "https://pubsubhubbub.appspot.com/articleCategories/technology"
         }
      }
   }
}

Déclencheur recurrence

Ce déclencheur s’active en fonction de la planification de périodicité que vous spécifiez. Il offre un moyen simple de créer un workflow à l’exécution régulière.

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
      "startTime": "<start-date-time-with-format-YYYY-MM-DDThh:mm:ss>",
      "timeZone": "<time-zone>",
      "schedule": {
         // Applies only when frequency is Day or Week. Separate values with commas.
         "hours": [ <one-or-more-hour-marks> ], 
         // Applies only when frequency is Day or Week. Separate values with commas.
         "minutes": [ <one-or-more-minute-marks> ], 
         // Applies only when frequency is Week. Separate values with commas.
         "weekDays": [ "Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday" ] 
      }
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-runs-queue>
      }
   },
   "operationOptions": "<operation-option>"
}

Obligatoire

Valeur	Type	Description
<time-unit>	String	Unité de temps qui décrit la fréquence d’activation du déclencheur : "Second", "Minute", "Hour", "Day", "Week", "Month"
<number-of-time-units>	Entier	Valeur qui spécifie la fréquence à laquelle le déclencheur se déclenche en fonction de la fréquence, qui correspond au nombre d’unités de temps à attendre jusqu’à ce que le déclencheur se déclenche à nouveau Voici les intervalles minimum et maximal : - Month: 1-16 months - Day: 1-500 days - Hour: 1-12,000 hours - Minute: 1-72,000 minutes - Second: 1-9,999,999 seconds Par exemple, si l’intervalle est défini sur 6 et la fréquence sur « Month », la périodicité est tous les six mois.

Facultatif

Valeur	Type	Description
<start-date-time-with-format-YYYY-MM-DDThh:mm:ss>	Chaîne	Date et heure de début dans ce format : AAAA-MM-DDThh :mm :ss si vous spécifiez un fuseau horaire -ou- AAAA-MM-DDThh :mm :ssZ si vous ne spécifiez pas de fuseau horaire Par exemple, si vous choisissez le 18 septembre 2017 à 14h, spécifiez « 2017-09-18T14:00:00 » et spécifiez un fuseau horaire tel que « Pacific Standard Time » (Heure standard du Pacifique), ou spécifiez « 2017-09-18T14:00:00Z » sans fuseau horaire. Remarque : Cette heure de début ne peut pas dépasser 49 ans dans le futur, et doit être conforme à la spécification de date/heure ISO 8601 au format de date/heure UTC, mais sans décalage UTC. Si vous ne spécifiez pas de fuseau horaire, vous devez ajouter la lettre « Z » à la fin, sans espace. Ce « Z » fait référence au temps nautique équivalent. Pour les planifications simples, l’heure de début est la première occurrence, tandis que pour les planifications complexes, le déclencheur ne s’active pas avant l’heure de début. Pour plus d’informations sur les dates et heures de début, consultez Create and schedule regularly running tasks (Créer et planifier des tâches à exécution régulière).
<time-zone>	String	S’applique uniquement quand vous spécifiez une heure de début, car ce déclencheur n’accepte pas le décalage UTC. Spécifiez le fuseau horaire à appliquer.
<one-or-more-hour-marks>	Entier ou tableau d’entiers	Si vous spécifiez « Jour » ou « Semaine » pour frequency, vous pouvez spécifier un ou plusieurs entiers compris entre 0 et 23, séparés par des virgules, pour les heures de la journée durant lesquelles exécuter le workflow. Par exemple, si vous spécifiez « 10 », « 12 » et « 14 », vous obtenez 10h00, 12h00 et 14h00 comme marques horaires.
<one-or-more-minute-marks>	Entier ou tableau d’entiers	Si vous spécifiez « Jour » ou « Semaine » pour frequency, vous pouvez spécifier un ou plusieurs entiers compris entre 0 et 59, séparés par des virgules, pour les minutes de l’heure durant lesquelles exécuter le workflow. Par exemple, vous pouvez spécifier « 30 » pour les minutes et à l’aide de l’exemple précédent des heures de la journée, vous obtenez 10h30, 12h30 et 14h30.
weekDays	Chaîne ou tableau de chaînes	Si vous spécifiez « Semaine » pour frequency, vous pouvez spécifier un ou plusieurs jours, séparés par des virgules, pour exécuter le workflow : « Monday », « Tuesday », « Wednesday », « Thursday », « Friday », « Saturday » et « Sunday »
<max-runs>	Integer	Par défaut, les instances de workflow s’exécutent toutes en même temps (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour changer cette limite en définissant une nouvelle valeur <count>, consultez Changer la concurrence du déclencheur.
<max-runs-queue>	Integer	Lorsque votre application logique exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la propriété runtimeConfiguration.concurrency.runs, les nouvelles exécutions sont placées dans cette file d’attente jusqu’à la limite par défaut. Pour changer la limite par défaut, consultez Changer la limite d’exécutions en attente.
<operation-option>	String	Vous pouvez modifier le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Exemple 1

Ce déclencheur de périodicité de base s’active tous les jours :

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Day",
      "interval": 1
   }
}

Exemple 2

Vous pouvez définir une date et une heure de début pour activer le déclencheur. Ce déclencheur de périodicité démarre à la date spécifiée, puis s’active tous les jours :

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Day",
      "interval": 1,
      "startTime": "2017-09-18T00:00:00Z"
   }
}

Exemple 3

Ce déclencheur de périodicité commence le 9 septembre 2017 à 14h00, et il s’active tous les lundis à 10h30, 12h30 et 14h30 Heure standard du Pacifique :

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Week",
      "interval": 1,
      "schedule": {
         "hours": [ 10, 12, 14 ],
         "minutes": [ 30 ],
         "weekDays": [ "Monday" ]
      },
      "startTime": "2017-09-07T14:00:00",
      "timeZone": "Pacific Standard Time"
   }
}

Pour plus d’informations et pour obtenir des exemples pour ce déclencheur, consultez Créer et planifier l’exécution régulière de tâches.

Déclencheur de requête

Ce déclencheur fait en sorte que votre application logique puisse être appelée en créant un point de terminaison qui peut accepter des requêtes entrantes. Pour ce déclencheur, fournit un schéma JSON qui décrit et valide la charge utile ou les entrées que le déclencheur reçoit de la requête entrante. Le schéma facilite également le référencement des propriétés de déclencheur à partir d’actions ultérieures dans le workflow.

Pour appeler ce déclencheur, vous devez utiliser l’API listCallbackUrl, qui est décrite dans l’API REST de service de workflow. Pour découvrir comment utiliser ce déclencheur en tant que point de terminaison HTTP, consultez Appeler, déclencher ou imbriquer des workflows via des points de terminaison HTTP.

"manual": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      "method": "<method-type>",
      "relativePath": "<relative-path-for-accepted-parameter>",
      "schema": {
         "type": "object",
         "properties": { 
            "<property-name>": {
               "type": "<property-type>"
            }
         },
         "required": [ "<required-properties>" ]
      }
   },
   "runTimeConfiguration": {
      "concurrency": {
         "runs": <max-runs>,
         "maximumWaitingRuns": <max-run-queue>
      },
   },
   "operationOptions": "<operation-option>"
}

Obligatoire

Valeur	Type	Description
<property-name>	String	Nom d’une propriété dans le schéma JSON qui décrit la charge utile
<property-type>	String	Type de la propriété

Facultatif

Valeur	Type	Description
<method-type>	String	Méthode que les requêtes entrantes doivent utiliser pour appeler votre application logique : « GET », « PUT », « POST », « PATCH », « DELETE »
<relative-path-for-accepted-parameter>	String	Chemin relatif pour le paramètre que l’URL de votre point de terminaison peut accepter
<required-properties>	Array	Une ou plusieurs propriétés qui nécessitent des valeurs.
<max-runs>	Integer	Par défaut, les instances de workflow s’exécutent toutes en même temps (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour changer cette limite en définissant une nouvelle valeur <count>, consultez Changer la concurrence du déclencheur.
<max-runs-queue>	Integer	Lorsque votre application logique exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la propriété runtimeConfiguration.concurrency.runs, les nouvelles exécutions sont placées dans cette file d’attente jusqu’à la limite par défaut. Pour changer la limite par défaut, consultez Changer la limite d’exécutions en attente.
<operation-option>	String	Vous pouvez modifier le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Exemple

Ce déclencheur spécifie qu’une requête entrante doit utiliser la méthode HTTP POST pour appeler le déclencheur, et inclut un schéma qui valide l’entrée de la requête entrante :

"manual": {
   "type": "Request",
   "kind": "Http",
   "inputs": {
      "method": "POST",
      "schema": {
         "type": "object",
         "properties": {
            "customerName": {
               "type": "String"
            },
            "customerAddress": { 
               "type": "Object",
               "properties": {
                  "streetAddress": {
                     "type": "string"
                  },
                  "city": {
                     "type": "string"
                  }
               }
            }
         }
      }
   }
}

Conditions du déclencheur

Pour les déclencheurs uniquement, vous pouvez inclure un tableau qui contient une ou plusieurs expressions pour des conditions qui déterminent si le workflow doit s’exécuter. Pour ajouter la propriété conditions à un déclencheur dans votre flux de travail, ouvrez l’application logique dans l’éditeur en mode code.

Par exemple, vous pouvez spécifier qu’un déclencheur est activé uniquement quand un site web retourne une erreur interne du serveur référençant le code d’état du déclencheur dans la propriété conditions :

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Hour",
      "interval": 1
   },
   "conditions": [ {
      "expression": "@equals(triggers().code, 'InternalServerError')"
   } ]
}

Par défaut, un déclencheur s’active uniquement après avoir reçu une réponse « 200 OK ». Quand une expression référence le code d’état d’un déclencheur, le comportement par défaut du déclencheur est remplacé. Par conséquent, si vous souhaitez que le déclencheur s’active pour plusieurs codes d’état, par exemple les codes d’état « 200 » et « 201 », vous devez inclure cette expression comme condition :

@or(equals(triggers().code, 200),equals(triggers().code, 201))

Déclencher plusieurs exécutions sur un tableau

Si votre déclencheur reçoit un tableau à traiter pour votre workflow, il arrive qu’une boucle « for each » prenne trop de temps pour traiter chaque élément du tableau. Au lieu de cela, vous pouvez utiliser la propriété SplitOn dans votre déclencheur pour décomposer le tableau. La décomposition sépare les éléments de tableau et démarre une nouvelle instance de flux de travail qui s’exécute pour chaque élément du tableau. Par exemple, cette approche est utile lorsque vous souhaitez interroger un point de terminaison qui peut renvoyer plusieurs nouveaux éléments entre les intervalles d’interrogation.

Si le fichier Swagger de votre déclencheur décrit une charge utile sous forme de tableau, la propriété SplitOn est automatiquement ajoutée à votre déclencheur. Sinon, ajoutez cette propriété à l’intérieur de la charge utile de la réponse qui contient le tableau à décomposer.

Avant d’utiliser la fonctionnalité SplitOn, passez en revue les considérations suivantes :

• Lorsque la concurrence du déclencheur est activée, la limite SplitOn est considérablement réduite. Si le nombre d'éléments dépasse cette limite, la fonction SplitOn est désactivée.

• Vous ne pouvez pas utiliser SplitOn avec un modèle de réponse synchrone. Les workflows qui utilisent la propriété SplitOn et incluent une réponse action s’exécutent de façon asynchrone et envoient immédiatement une réponse 202 ACCEPTED.

• Pour connaître le nombre maximal d’éléments de tableau que SplitOn peut traiter en une seule exécution de workflow, consultez Limites et configurations.

Exemple

Supposons que vous avez un déclencheur HTTP qui appelle une API et reçoit cette réponse :

{
   "Status": "Succeeded",
   "Rows": [ 
      { 
         "id": 938109380,
         "name": "customer-name-one"
      },
      {
         "id": 938109381,
         "name": "customer-name-two"
      }
   ]
}

Comme votre workflow a uniquement besoin du contenu du tableau dans Rows, vous pouvez créer votre déclencheur comme dans cet exemple :

"HTTP_Debatch": {
   "type": "Http",
    "inputs": {
        "uri": "https://mydomain.com/myAPI",
        "method": "GET"
    },
   "recurrence": {
      "frequency": "Second",
      "interval": 1
    },
    "splitOn": "@triggerBody()?.Rows"
}

Votre définition de workflow peut désormais utiliser @triggerBody().name pour obtenir les valeurs name, qui sont "customer-name-one" à partir de la première exécution et "customer-name-two" à partir de la deuxième exécution. Par conséquent, les sorties du déclencheur se présentent comme dans les exemples suivants :

{
   "body": {
      "id": 938109380,
      "name": "customer-name-one"
   }
}

{
   "body": {
      "id": 938109381,
      "name": "customer-name-two"
   }
}

Vue d’ensemble des actions

Azure Logic Apps fournit différents types d’actions, chacun avec des entrées différentes qui définissent le comportement unique d’une action. Les actions ont les principaux éléments suivants, bien que certains soient facultatifs :

"<action-name>": {
   "type": "<action-type>",
   "inputs": { 
      "<input-name>": { "<input-value>" },
      "retryPolicy": "<retry-behavior>" 
   },
   "runAfter": { "<previous-trigger-or-action-status>" },
   "runtimeConfiguration": { "<runtime-config-options>" },
   "operationOptions": "<operation-option>"
},

Obligatoire

Valeur	Type	Description
<action-name>	String	Nom de l’action
<action-type>	String	Type d’action, par exemple « Http » ou « ApiConnection »
<input-name>	String	Nom d’une entrée qui définit le comportement de l’action
<input-value>	Divers	Valeur d’entrée, qui peut être une chaîne, un entier, nu objet JSON, et ainsi de suite
<previous-trigger-or-action-status>	Objet JSON	Nom et état résultant du déclencheur ou de l’action qui doit s’exécuter juste avant que cette action puisse s’exécuter

Facultatif

Valeur	Type	Description
<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
<runtime-config-options>	Objet JSON	Pour certaines actions, vous pouvez changer le comportement de l’action au moment de l’exécution en définissant des propriétés runtimeConfiguration. Pour plus d’informations, consultez Paramètres de configuration d’exécution.
<operation-option>	String	Pour certaines actions, vous pouvez changer le comportement par défaut en définissant la propriété operationOptions. Pour plus d’informations, consultez Options d’opérations.

Liste des types d’actions

Voici quelques types d’actions couramment utilisés :

• Types d’actions intégrés, tels que ces exemples et bien plus encore :

  • HTTP pour appeler des points de terminaison par le biais du protocole HTTP ou HTTPS

  • Response pour répondre aux requêtes

  • Exécuter du code JavaScript pour l’exécution d’extraits de code JavaScript

  • Function pour appeler Azure Functions

  • Actions d’opérations de données telles que Join, Compose, Table, Select et autres, qui créent ou transforment des données à partir de diverses entrées

  • Workflow pour appeler un autre workflow d’application logique

• Types d’actions d’API managées comme ApiConnection et ApiConnectionWebHook, qui appellent différents connecteurs et API managés par Microsoft, par exemple Azure Service Bus, Office 365 Outlook, Power BI, Stockage Blob Azure, OneDrive, GitHub et bien plus encore

• Types d’actions de workflows de contrôle comme If, Foreach, Switch, Scope et Until, qui contiennent d’autres actions et vous aident à organiser l’exécution du workflow

Actions intégrées

Type d'action	Description
Composer	Crée une sortie unique à partir des entrées, qui peuvent avoir différents types.
Exécuter du code JavaScript	Exécutez des extraits de code JavaScript qui répondent à des critères spécifiques. Pour connaître les exigences relatives au code et d’autres informations, voir Ajouter et exécuter des extraits de code avec du code inclus dans Azure Logic Apps.
Function	Appelle une fonction Azure.
HTTP	Appelle un point de terminaison HTTP.
Joindre	Crée une chaîne à partir de tous les éléments d’un tableau, et sépare ces éléments avec un caractère délimiteur spécifié.
Analyser JSON	Crée des jetons conviviaux à partir de propriétés dans du contenu JSON. Vous pouvez ensuite référencer ces propriétés en incluant les jetons dans votre application logique.
Query	Crée un tableau à partir des éléments d’un autre tableau en fonction d’une condition ou d’un filtre.
Response	Crée une réponse à une requête ou un appel entrant.
Sélectionner	Crée un tableau avec des objets JSON en transformant les éléments d’un autre tableau en fonction de la carte spécifiée.
Table	Crée une table CSV ou HTML à partir d’un tableau.
Terminate	Arrête un workflow en cours d’exécution.
Wait	Interrompt votre workflow pour une durée spécifiée ou jusqu’à la date et l’heure spécifiées.
Workflow	Imbrique un workflow à l’intérieur d’un autre workflow.

Actions d’API managées

Type d'action	Description
ApiConnection	Appelle un point de terminaison HTTP à l’aide d’une API managée par Microsoft.
ApiConnectionWebhook	Fonctionne comme HTTPWebhook, mais utilise une API managée par Microsoft.

Actions de workflows de contrôle

Ces actions vous permettent de contrôler l’exécution du workflow et d’inclure d’autres actions. À partir de l’extérieur d’une action de workflow de contrôle, vous pouvez directement référencer des actions à l’intérieur de cette action de workflow de contrôle. Par exemple, si vous avez une action Http à l’intérieur d’une étendue, vous pouvez référencer l’expression @body('Http') à partir de n’importe où dans le workflow. Toutefois, les actions qui existent à l’intérieur d’une action de workflow de contrôle ne peuvent « s’exécuter qu’après d’autres actions » qui se trouvent dans la même structure de workflow de contrôle.

Type d'action	Description
ForEach	Exécuter les mêmes actions dans une boucle pour chaque élément d’un tableau.
If	Exécuter des actions selon que la condition spécifiée est true ou false.
Scope	Exécuter des actions en fonction de l’état de groupe d’un ensemble d’actions.
Switch	Exécuter des actions organisées en cas quand les valeurs d’expressions, d’objets ou de jetons correspondent aux valeurs spécifiées par chaque cas.
Until	Exécuter des actions dans une boucle jusqu’à ce que la condition spécifiée ait la valeur true.

Actions - Référence détaillée

Action APIConnection

Cette action envoie une requête HTTP à une API managée par Microsoft et exige des informations sur l’API et les paramètres, ainsi qu’une référence à une connexion valide.

"<action-name>": {
   "type": "ApiConnection",
   "inputs": {
      "host": {
         "connection": {
            "name": "@parameters('$connections')['<api-name>']['connectionId']"
         },
         "<other-action-specific-input-properties>"        
      },
      "method": "<method-type>",
      "path": "/<api-operation>",
      "retryPolicy": "<retry-behavior>",
      "queries": { "<query-parameters>" },
      "<other-action-specific-properties>"
    },
    "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<action-name>	String	Nom de l’action fournie par le connecteur
<api-name>	String	Nom de l’API managée par Microsoft qui est utilisée pour la connexion
<method-type>	String	Méthode HTTP d’appel de l’API : « GET », « PUT », « POST », « PATCH » ou « DELETE »
<api-operation>	String	Opération d’API à appeler

Facultatif

Valeur	Type	Description
<other-action-specific-input-properties>	Objet JSON	Toutes autres propriétés d’entrée qui s’appliquent à cette action spécifique
<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
<query-parameters>	Objet JSON	Paramètres de requête à inclure avec l’appel d’API. Par exemple, l’objet "queries": { "api-version": "2018-01-01" } ajoute ?api-version=2018-01-01 à l’appel.
<other-action-specific-properties>	Objet JSON	Toutes autres propriétés qui s’appliquent à cette action spécifique

Exemple

Cette définition décrit l’action Envoyer un e-mail pour le connecteur Office 365 Outlook, qui est une API managée par Microsoft :

"Send_an_email": {
   "type": "ApiConnection",
   "inputs": {
      "body": {
         "Body": "Thank you for your membership!",
         "Subject": "Hello and welcome!",
         "To": "Sophie.Owen@contoso.com"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "POST",
      "path": "/Mail"
    },
    "runAfter": {}
}

Action APIConnectionWebhook

Cette action envoie une demande d’abonnement à un point de terminaison par le biais du protocole HTTP à l’aide d’une API managée par Microsoft, fournit une URL de rappel où le point de terminaison peut envoyer une réponse, et attend que le point de terminaison réponde. Pour plus d’informations, consultez Abonnements de point de terminaison.

"<action-name>": {
   "type": "ApiConnectionWebhook",
   "inputs": {
      "subscribe": {
         "method": "<method-type>",
         "uri": "<api-subscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" },
         "retryPolicy": "<retry-behavior>",
         "queries": { "<query-parameters>" },
         "<other-action-specific-input-properties>"
      },
      "unsubscribe": {
         "method": "<method-type>",
         "uri": "<api-unsubscribe-URL>",
         "headers": { "<header-content>" },
         "body": "<body-content>",
         "authentication": { "<authentication-type>" },
         "<other-action-specific-properties>"
      },
   },
   "runAfter": {}
}

Certaines valeurs, telles que <method-type>, sont disponibles pour les objets "subscribe" et "unsubscribe".

Obligatoire

Valeur	Type	Description
<action-name>	String	Nom de l’action fournie par le connecteur
<method-type>	String	Méthode HTTP à utiliser pour s’abonner ou annuler l’abonnement à un point de terminaison : « GET », « PUT », « POST », « PATCH » ou « DELETE »
<api-subscribe-URL>	String	URI à utiliser pour s’abonner à l’API

Facultatif

Valeur	Type	Description
<api-unsubscribe-URL>	String	URI à utiliser pour annuler l’abonnement à l’API
<header-content>	Objet JSON	Tous les en-têtes à envoyer dans la requête Par exemple, pour définir la langue et le type sur une requête : "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
<body-content>	Objet JSON	Tout contenu de message à envoyer dans la requête
<authentication-type>	Objet JSON	Le modèle d'authentification que la requête utilise pour authentifier les requêtes sortantes. Pour plus d’informations, voir Ajouter l’authentification aux appels sortants.
<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
<query-parameters>	Objet JSON	Tous les paramètres de requête à inclure avec l’appel d’API Par exemple, l’objet "queries": { "api-version": "2018-01-01" } ajoute ?api-version=2018-01-01 à l’appel.
<other-action-specific-input-properties>	Objet JSON	Toutes autres propriétés d’entrée qui s’appliquent à cette action spécifique
<other-action-specific-properties>	Objet JSON	Toutes autres propriétés qui s’appliquent à cette action spécifique

Vous pouvez aussi spécifier les limites sur une action ApiConnectionWebhook de la même manière que les limites asynchrones HTTP.

Action compose

Cette action crée une sortie unique à partir de plusieurs entrées, y compris des expressions. La sortie et les entrées peuvent avoir n’importe quel type pris en charge nativement par Azure Logic Apps, tels que des tableaux, objets JSON, XML et binaires. Vous pouvez ensuite utiliser la sortie de l’action dans d’autres actions.

"Compose": {
   "type": "Compose",
   "inputs": "<inputs-to-compose>",
   "runAfter": {}
},

Obligatoire

Valeur	Type	Description
<inputs-to-compose>	Quelconque	Entrées pour la création d’une sortie unique

Exemple 1

Cette définition d’action fusionne abcdefg avec un espace de fin et la valeur 1234 :

"Compose": {
   "type": "Compose",
   "inputs": "abcdefg 1234",
   "runAfter": {}
},

Voici la sortie créée par cette action :

abcdefg 1234

Exemple 2

Cette définition d’action fusionne une variable de chaîne qui contient abcdefg et une variable de type entier qui contient 1234 :

"Compose": {
   "type": "Compose",
   "inputs": "@{variables('myString')}@{variables('myInteger')}",
   "runAfter": {}
},

Voici la sortie créée par cette action :

"abcdefg1234"

Action Exécuter du code JavaScript

Cette action exécute un extrait de code JavaScript et renvoie les résultats via un jeton auquel les actions ultérieures du workflow peuvent faire référence.

"Execute_JavaScript_Code": {
   "type": "JavaScriptCode",
   "inputs": {
      "code": "<JavaScript-code-snippet>",
      "explicitDependencies": {
         "actions": [ <preceding-actions> ],
         "includeTrigger": true
      }
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<JavaScript-code-snippet>	Variable	Code JavaScript que vous souhaitez exécuter. Pour plus d’informations sur les exigences de code, consultez Exécuter des extraits de code dans des workflows. Dans l’attributcode, votre extrait de code peut utiliser l’objet workflowContexten lecture seule en tant qu’entrée. Cet objet possède des sous-propriétés qui permettent à votre code d’accéder aux sorties provenant du déclencheur, ainsi que de toutes actions précédentes, dans votre flux de travail. Pour en savoir plus sur l’objet workflowContext, voir Faire référence aux résultats des actions et du déclencheur avec l’objet workflowContext.

Obligatoire dans certains cas

L’attribut explicitDependencies spécifie que vous souhaitez inclure explicitement les résultats à partir du déclencheur et/ou des actions précédentes, en tant que dépendances de votre extrait de code. Pour plus d’informations sur l’ajout de ces dépendances, consultez Ajouter des dépendances en tant que paramètres à une action de code inline.

Pour l’attribut includeTrigger, vous pouvez spécifier les valeurs true ou false.

Valeur	Type	Description
<preceding-actions>	Tableau de chaînes	Tableau avec les noms d’actions au format JSON en tant que dépendances. Veillez à utiliser les noms d’action qui s’affichent dans votre définition de flux de travail lorsqu’ils utilisent des traits de soulignement (_), et non des espaces (« »).

Exemple 1

Cette action exécute le code qui obtient le nom de votre workflow d’application logique et renvoie le texte « Hello world de <nom-application-logique> » en tant que résultat. Dans cet exemple, le code référence le nom du flux de travail en accédant à la propriété workflowContext.workflow.name via l’objet workflowContext en lecture seule. Pour en savoir plus sur l’utilisation de l’objet workflowContext, voir Faire référence aux résultats des actions et du déclencheur dans votre code.

"Execute_JavaScript_Code": {
   "type": "JavaScriptCode",
   "inputs": {
      "code": "var text = \"Hello world from \" + workflowContext.workflow.name;\r\n\r\nreturn text;"
   },
   "runAfter": {}
}

Exemple 2

Cette action exécute le code dans un workflow d’application logique qui se déclenche lorsqu’un nouvel e-mail arrive sur un compte Outlook. Le workflow utilise également l’action Office 365 Outlook Envoyer un e-mail d’approbation qui transmet le contenu de l’e-mail reçu avec une demande d’approbation.

Le code extrait les adresses e-mail à partir de la propriété Body de l’e-mail, et renvoie les adresses avec la valeur de la propriété SelectedOption à partir de l’action d’approbation. L’action inclut explicitement l’action Envoyer un e-mail d’approbation comme dépendance de l’objet actions à l’intérieur de l’objet explicitDependencies.

"Execute_JavaScript_Code": {
   "type": "JavaScriptCode",
   "inputs": {
      "code": "var myResult = /(([^<>()\\[\\]\\\\.,;:\\s@\"]+(\\.[^<>()\\[\\]\\\\.,;:\\s@\"]+)*)|(\".+\"))@((\\[[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}\\.[0-9]{1,3}])|(([a-zA-Z\\-0-9]+\\.)+[a-zA-Z]{2,}))/g;\r\n\r\nvar email = workflowContext.trigger.outputs.body.Body;\r\n\r\nvar reply = workflowContext.actions.Send_approval_email.outputs.body.SelectedOption;\r\n\r\nreturn email.match(myResult) + \" - \" + reply;\r\n;",
      "explicitDependencies": {
         "actions": [
            "Send_approval_email"
         ]
      }
   },
   "runAfter": {}
}

Action function

Cette action appelle une fonction Azure créée précédemment.

"<Azure-function-name>": {
   "type": "Function",
   "inputs": {
     "function": {
        "id": "<Azure-function-ID>"
      },
      "method": "<method-type>",
      "headers": { "<header-content>" },
      "body": { "<body-content>" },
      "queries": { "<query-parameters>" } 
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<Azure-function-ID>	String	ID de ressource de la fonction Azure que vous souhaitez appeler. Voici le format de cette valeur : "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Web/sites/<Azure-function-app-name>/functions/<Azure-function-name>"
<method-type>	Chaîne	Méthode HTTP à utiliser pour appeler la fonction : « GET », « PUT », « POST », « PATCH » ou « DELETE » Si elle n’est pas spécifiée, la méthode par défaut est « POST ».

Facultatif

Valeur	Type	Description
<header-content>	Objet JSON	Tous les en-têtes à envoyer avec l’appel Par exemple, pour définir la langue et le type sur une requête : "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
<body-content>	Objet JSON	Tout contenu de message à envoyer dans la requête
<query-parameters>	Objet JSON	Tous les paramètres de requête à inclure avec l’appel d’API Par exemple, l’objet "queries": { "api-version": "2018-01-01" } ajoute ?api-version=2018-01-01 à l’appel.
<other-action-specific-input-properties>	Objet JSON	Toutes autres propriétés d’entrée qui s’appliquent à cette action spécifique
<other-action-specific-properties>	Objet JSON	Toutes autres propriétés qui s’appliquent à cette action spécifique

Lorsque vous enregistrez votre application logique, Azure Logic Apps effectue ces case activée sur la fonction référencée :

• Votre workflow doit avoir accès à la fonction.

• Votre workflow ne peut utiliser qu’un déclencheur HTTP standard ou un déclencheur webhook JSON générique.

  Azure Logic Apps obtient et met en cache l’URL du déclencheur, qui est utilisée au moment de l’exécution. Toutefois, si une opération invalide l’URL en cache, l’action Function échoue au moment de l’exécution. Pour résoudre ce problème, réenregistrez l’application logique afin qu’elle obtienne et mette en cache l’URL du déclencheur.

• La fonction ne doit pas avoir d’itinéraire défini.

• Seuls les niveaux d’autorisation « fonction » et « anonyme » sont autorisés.

Exemple

Cette définition d’action appelle la fonction « GetProductID » créée précédemment :

"GetProductID": {
   "type": "Function",
   "inputs": {
     "function": {
        "id": "/subscriptions/<XXXXXXXXXXXXXXXXXXXX>/resourceGroups/myLogicAppResourceGroup/providers/Microsoft.Web/sites/InventoryChecker/functions/GetProductID"
      },
      "method": "POST",
      "headers": { 
          "x-ms-date": "@utcnow()"
       },
      "body": { 
          "Product_ID": "@variables('ProductID')"
      }
   },
   "runAfter": {}
}

Action HTTP

Cette action envoie une requête au point de terminaison HTTP ou HTTPS spécifié et vérifie la réponse pour déterminer si le workflow s’exécute. Pour plus d’informations, consultez Appeler des points de terminaison de service via HTTP ou HTTPS à partir d’Azure Logic Apps.

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "<method-type>",
      "uri": "<HTTP-or-HTTPS-endpoint-URL>",
      "headers": { "<header-content>" },
      "queries": { "<query-parameters>" },
      "body": "<body-content>",
      "authentication": { "<authentication-type-and-property-values>" },
      "retryPolicy": {
         "type": "<retry-behavior>"
      },
   },
   "runAfter": {}
}

Obligatoire

Propriété	Valeur	Type	Description
method	<method-type>	String	Méthode à utiliser pour envoyer la requête sortante : « GET », « PUT », « POST », « PATCH » ou « DELETE »
uri	<HTTP-or-HTTPS-endpoint-URL>	String	URL du point de terminaison HTTP ou HTTPS où vous voulez envoyer la requête sortante. Taille de chaîne maximale : 2 Ko Pour un service ou une ressource Azure, cette syntaxe URI inclut l'ID de la ressource et le chemin vers la ressource à laquelle vous voulez accéder.

Facultatif

Propriété	Valeur	Type	Description
headers	<header-content>	Objet JSON	Tous les en-têtes que vous devez inclure avec la demande Par exemple, pour définir la langue et le type : "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries	<query-parameters>	Objet JSON	Tous les paramètres de requête que vous devez utiliser dans la requête Par exemple, l’objet "queries": { "api-version": "2018-01-01" } ajoute ?api-version=2018-01-01 à l’appel.
body	<body-content>	Objet JSON	Contenu du message à envoyer en tant que charge utile avec la requête
authentication	<authentication-type-and-property-values>	Objet JSON	Le modèle d'authentification que la requête utilise pour authentifier les requêtes sortantes. Pour plus d’informations, voir Ajouter l’authentification aux appels sortants. Au-delà de Scheduler, la propriété authority est prise en charge. Si vous ne spécifiez aucune valeur, la valeur par défaut est https://management.azure.com/, mais vous pouvez utiliser une autre valeur.
retryPolicy > type	<retry-behavior>	Objet JSON	Personnalise le comportement de nouvelle tentative pour les défaillances intermittentes, qui présentent le code d’état 408, 429 et 5XX, ainsi que les éventuelles exceptions de connectivité. Pour plus d’informations, consultez Stratégies de relance.
<other-action-specific-input-properties>	<input-property>	Objet JSON	Toutes autres propriétés d’entrée qui s’appliquent à cette action spécifique
<other-action-specific-properties>	<property-value>	Objet JSON	Toutes autres propriétés qui s’appliquent à cette action spécifique

Exemple

Cette définition d’action obtient les informations les plus récentes en envoyant une requête au point de terminaison spécifié :

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest"
   }
}

Action Joindre

Cette action crée une chaîne à partir de tous les éléments d’un tableau, et sépare ces éléments avec le caractère délimiteur spécifié.

"Join": {
   "type": "Join",
   "inputs": {
      "from": <array>,
      "joinWith": "<delimiter>"
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<array>	Array	Tableau ou expression qui fournit les éléments sources. Si vous spécifiez une expression, placez l’expression entre guillemets doubles.
<delimiter>	Chaîne d’un seul caractère	Caractère qui sépare chaque élément dans la chaîne

Exemple

Supposez que vous avez créé une variable « myIntegerArray » qui contient ce tableau d’entiers :

[1,2,3,4]

Cette définition d’action obtient les valeurs de la variable en utilisant la fonction variables() dans une expression, et elle crée cette chaîne avec ces valeurs, séparées par une virgule : "1,2,3,4"

"Join": {
   "type": "Join",
   "inputs": {
      "from": "@variables('myIntegerArray')",
      "joinWith": ","
   },
   "runAfter": {}
}

Action d’analyse de JSON

Cette action crée des jetons ou champs conviviaux à partir des propriétés dans le contenu JSON. Vous pouvez ensuite accéder à ces propriétés dans votre application logique en utilisant les jetons à la place. Par exemple, quand vous souhaitez utiliser la sortie JSON de services tels qu’Azure Service Bus et Azure Cosmos DB, vous pouvez inclure cette action dans votre application logique afin de pouvoir référencer plus facilement les données dans cette sortie.

"Parse_JSON": {
   "type": "ParseJson",
   "inputs": {
      "content": "<JSON-source>",
         "schema": { "<JSON-schema>" }
      },
      "runAfter": {}
},

Obligatoire

Valeur	Type	Description
<JSON-source>	Objet JSON	Contenu JSON que vous souhaitez analyser
<JSON-schema>	Objet JSON	Schéma JSON qui décrit le contenu JSON sous-jacent, utilisé par l’action pour analyser le contenu JSON source. Conseil : dans le concepteur de flux de travail, vous pouvez fournir le schéma ou fournir un exemple de charge utile afin que l’action puisse générer le schéma.

Exemple

Cette définition d’action crée les jetons que vous pouvez utiliser dans votre flux de travail, mais uniquement dans les actions qui s’exécutent après l’action Analyser JSON :

FirstName, LastName et Email

"Parse_JSON": {
   "type": "ParseJson",
   "inputs": {
      "content": {
         "Member": {
            "Email": "Sophie.Owen@contoso.com",
            "FirstName": "Sophie",
            "LastName": "Owen"
         }
      },
      "schema": {
         "type": "object",
         "properties": {
            "Member": {
               "type": "object",
               "properties": {
                  "Email": {
                     "type": "string"
                  },
                  "FirstName": {
                     "type": "string"
                  },
                  "LastName": {
                     "type": "string"
                  }
               }
            }
         }
      }
   },
   "runAfter": { }
},

Dans cet exemple, la propriété « content » spécifie le contenu JSON devant être analysé par l’action. Vous pouvez également fournir ce contenu JSON comme exemple de charge utile pour générer le schéma.

"content": {
   "Member": { 
      "FirstName": "Sophie",
      "LastName": "Owen",
      "Email": "Sophie.Owen@contoso.com"
   }
},

La propriété « schema » spécifie le schéma JSON utilisé pour décrire le contenu JSON :

"schema": {
   "type": "object",
   "properties": {
      "Member": {
         "type": "object",
         "properties": {
            "FirstName": {
               "type": "string"
            },
            "LastName": {
               "type": "string"
            },
            "Email": {
               "type": "string"
            }
         }
      }
   }
}

Action de requête

Cette action crée un tableau à partir des éléments d’un autre tableau en fonction d’une condition ou d’un filtre spécifié.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": <array>,
      "where": "<condition-or-filter>"
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<array>	Array	Tableau ou expression qui fournit les éléments sources. Si vous spécifiez une expression, placez l’expression entre guillemets doubles.
<condition-or-filter>	Chaîne	Condition utilisée pour filtrer les éléments dans le tableau source Remarque : Si aucune valeur ne remplit la condition, l’action crée un tableau vide.

Exemple

Cette définition d’action crée un tableau qui contient des valeurs supérieures à la valeur spécifiée (deux) :

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": [ 1, 3, 0, 5, 4, 2 ],
      "where": "@greater(item(), 2)"
   }
}

Action de réponse

Cette action crée la charge utile pour la réponse à une requête HTTP.

"Response" {
    "type": "Response",
    "kind": "http",
    "inputs": {
        "statusCode": 200,
        "headers": { <response-headers> },
        "body": { <response-body> }
    },
    "runAfter": {}
},

Obligatoire

Valeur	Type	Description
<response-status-code>	Integer	Code d’état HTTP envoyé à la requête entrante. Le code par défaut est « 200 OK », mais il peut s’agir de tout code d’état valide commençant par 2xx, 4xx ou 5xx, mais pas avec 3xxx.

Facultatif

Valeur	Type	Description
<response-headers>	Objet JSON	Un ou plusieurs en-têtes à inclure avec la réponse
<response-body>	Divers	Corps de réponse, qui peut être une chaîne, un objet JSON ou même du contenu binaire d’une action précédente

Exemple

Cette définition d’action crée une réponse à une requête HTTP avec le code d’état, le corps du message et les en-têtes de message spécifiés :

"Response": {
   "type": "Response",
   "inputs": {
      "statusCode": 200,
      "body": {
         "ProductID": 0,
         "Description": "Organic Apples"
      },
      "headers": {
         "x-ms-date": "@utcnow()",
         "content-type": "application/json"
      }
   },
   "runAfter": {}
}

Restrictions

Contrairement à d’autres actions, l’action Response présente des restrictions spéciales :

• Votre workflow peut utiliser l’action Response uniquement quand le workflow démarre avec un déclencheur de requête HTTP, ce qui signifie que votre workflow doit être déclenché par une requête HTTP.

• Votre workflow peut utiliser l’action Response n’importe où sauf à l’intérieur de boucles Foreach, de boucles Until, y compris les boucles séquentielles, et de branches parallèles.

• La requête d’origine obtient la réponse de votre workflow uniquement quand toutes les actions requises par l’action Response sont terminées dans la limite de délai d’attente HTTP.

  Toutefois, si votre workflow appelle une autre application logique en tant que workflow imbriqué, le workflow parent attend que le workflow imbriqué se termine, quelle que soit la durée nécessaire.

• Quand votre workflow utilise l’action Response et un modèle de réponse synchrone, le workflow ne peut pas non plus utiliser la commande splitOn dans la définition du déclencheur, car cette commande crée plusieurs exécutions. Vérifiez ce cas quand la méthode PUT est utilisée et, dans l’affirmative, retournez une réponse « requête incorrecte ».

  Sinon, si votre workflow utilise la commande splitOn et une action Response, le workflow s’exécute de façon asynchrone et retourne immédiatement une réponse « 202 ACCEPTED ».

• Quand l’exécution du workflow atteint l’action Response, mais que la requête entrante a déjà reçu une réponse, l’action Response, est marquée comme « Échec » à cause du conflit. En conséquence, l’exécution de votre application logique est également marquée avec l’état « Échec ».

Action select

Cette action crée un tableau avec des objets JSON en transformant les éléments d’un autre tableau en fonction de la carte spécifiée. Le tableau de sortie et le tableau source ont toujours le même nombre d’éléments. Bien que vous ne puissiez pas changer le nombre d’objets dans le tableau de sortie, vous pouvez ajouter ou supprimer des propriétés et leurs valeurs à ces objets. La propriété select spécifie au moins une paire clé-valeur qui définit le mappage pour transformer les éléments du tableau source. Une paire clé-valeur représente une propriété et sa valeur parmi tous les objets dans le tableau de sortie.

"Select": {
   "type": "Select",
   "inputs": {
      "from": <array>,
      "select": { 
          "<key-name>": "<expression>",
          "<key-name>": "<expression>"        
      }
   },
   "runAfter": {}
},

Obligatoire

Valeur	Type	Description
<array>	Array	Tableau ou expression qui fournit les éléments sources. N’oubliez pas de placer une expression entre guillemets doubles. Remarque : Si le tableau source est vide, l’action crée un tableau vide.
<key-name>	String	Nom de la propriété attribué au résultat à partir de <expression> Pour ajouter une nouvelle propriété à tous les objets dans le tableau de sortie, fournissez un <key-name> pour cette propriété et une <expression> pour la valeur de propriété. Pour supprimer une propriété de tous les objets dans le tableau, omettez le <key-name> pour cette propriété.
<expression>	String	Expression qui transforme l’élément du tableau source et assigne le résultat à <key-name>

L’action Select crée un tableau en tant que sortie. Par conséquent, toute action qui souhaite utiliser cette sortie doit accepter un tableau, ou vous devez convertir le tableau vers le type acceptée par l’action consommatrice. Par exemple, pour convertir le tableau de sortie en une chaîne, vous pouvez passer ce tableau à l’action Compose, puis référencer la sortie de l’action Compose dans vos autres actions.

Exemple

Cette définition d’action crée un tableau d’objets JSON à partir d’un tableau d’entiers. L’action itère au sein du tableau source, obtient chaque valeur entière à l’aide de l’expression @item(), et assigne chaque valeur à la propriété « number » dans chaque objet JSON :

"Select": {
   "type": "Select",
   "inputs": {
      "from": [ 1, 2, 3 ],
      "select": { 
         "number": "@item()" 
      }
   },
   "runAfter": {}
},

Voici le tableau créé par cette action :

[ { "number": 1 }, { "number": 2 }, { "number": 3 } ]

Pour utiliser ce tableau dans d’autres actions, passez cette sortie dans une action Compose :

"Compose": {
   "type": "Compose",
   "inputs": "@body('Select')",
   "runAfter": {
      "Select": [ "Succeeded" ]
   }
},

Vous pouvez ensuite utiliser la sortie de l’action Compose dans vos autres actions, par exemple l’action Office 365 Outlook - Envoyer un e-mail :

"Send_an_email": {
   "type": "ApiConnection",
   "inputs": {
      "body": {
         "Body": "@{outputs('Compose')}",
         "Subject": "Output array from Select and Compose actions",
         "To": "<your-email@domain>"
      },
      "host": {
         "connection": {
            "name": "@parameters('$connections')['office365']['connectionId']"
         }
      },
      "method": "post",
      "path": "/Mail"
   },
   "runAfter": {
      "Compose": [ "Succeeded" ]
   }
},

Action table

Cette action crée une table CSV ou HTML à partir d’un tableau. Pour les tableaux contenant des objets JSON, cette action crée automatiquement les en-têtes de colonnes à partir des noms de propriétés des objets. Pour les tableaux contenant d’autres types de données, vous devez spécifier les en-têtes de colonnes et les valeurs. Par exemple, ce tableau inclut les propriétés « ID » et « Product_Name » que cette action peut utiliser pour les noms d’en-têtes de colonnes :

[ {"ID": 0, "Product_Name": "Apples"}, {"ID": 1, "Product_Name": "Oranges"} ]

"Create_<CSV | HTML>_table": {
   "type": "Table",
   "inputs": {
      "format": "<CSV | HTML>",
      "from": <array>,
      "columns": [ 
         {
            "header": "<column-name>",
            "value": "<column-value>"
         },
         {
            "header": "<column-name>",
            "value": "<column-value>"
         } 
      ]
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<CSV ou HTML>	String	Format de la table que vous souhaitez créer
<array>	Tableau	Tableau ou expression qui fournit les éléments sources de la table Remarque : Si le tableau source est vide, l’action crée une table vide.

Facultatif

Pour spécifier ou personnaliser des en-têtes de colonne et des valeurs, utilisez le tableau columns. Quand des paires header-value ont le même nom d’en-tête, leurs valeurs s’affichent dans la même colonne sous ce nom d’en-tête. Dans le cas contraire, chaque en-tête unique définit une colonne unique.

Valeur	Type	Description
<column-name>	String	Nom d’en-tête pour une colonne
<column-value>	Quelconque	Valeur de la colonne

Exemple 1

Supposez que vous avez créé une variable « myItemArray » qui contenant actuellement ce tableau :

[ {"ID": 0, "Product_Name": "Apples"}, {"ID": 1, "Product_Name": "Oranges"} ]

Cette définition d’action crée une table CSV à partir de la variable « myItemArray ». L’expression utilisée par la propriété from obtient le tableau à partir de « myItemArray » à l’aide de la fonction variables() :

"Create_CSV_table": {
   "type": "Table",
   "inputs": {
      "format": "CSV",
      "from": "@variables('myItemArray')"
   },
   "runAfter": {}
}

Voici la table CSV créée par cette action :

ID,Product_Name 
0,Apples 
1,Oranges 

Exemple 2

Cette définition d’action crée une table HTML à partir de la variable « myItemArray ». L’expression utilisée par la propriété from obtient le tableau à partir de « myItemArray » à l’aide de la fonction variables() :

"Create_HTML_table": {
   "type": "Table",
   "inputs": {
      "format": "HTML",
      "from": "@variables('myItemArray')"
   },
   "runAfter": {}
}

Voici la table HTML créée par cette action :

id	Product_Name
0	Pommes
1	Oranges

Exemple 3

Cette définition d’action crée une table HTML à partir de la variable « myItemArray ». Toutefois, cet exemple remplace les noms d’en-têtes de colonnes par défaut par « Stock_ID » et « Description », et ajoute le mot « Organic » aux valeurs dans la colonne « Description ».

"Create_HTML_table": {
   "type": "Table",
   "inputs": {
      "format": "HTML",
      "from": "@variables('myItemArray')",
      "columns": [ 
         {
            "header": "Stock_ID",
            "value": "@item().ID"
         },
         {
            "header": "Description",
            "value": "@concat('Organic ', item().Product_Name)"
         }
      ]
    },
   "runAfter": {}
},

Voici la table HTML créée par cette action :

Stock_ID	Description
0	Organic Apples
1	Organic Oranges

Action terminate

Cette action arrête l’exécution de l’instance de flux de travail, annule toutes les actions en cours, ignore les actions restantes et renvoie l’état spécifié. Vous pouvez par exemple utiliser l’action Terminate quand votre application logique doit se fermer complètement suite à un état d’erreur. Cette action n’affecte pas les actions déjà terminées, et ne peut pas apparaître à l’intérieur de boucles Foreach et Until, y compris les boucles séquentielles.

"Terminate": {
   "type": "Terminate",
   "inputs": {
       "runStatus": "<status>",
       "runError": {
            "code": "<error-code-or-name>",
            "message": "<error-message>"
       }
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<status>	String	État à retourner pour l’exécution : « Démarré », « Échec » ou « Réussi »

Facultatif

Les propriétés de l’objet « runStatus » s’appliquent uniquement quand la propriété « runStatus » a l’état « Failed ».

Valeur	Type	Description
<error-code-or-name>	String	Code ou nom de l’erreur
<error-message>	String	Message ou texte qui décrit l’erreur et les actions que peut effectuer l’utilisateur de l’application

Exemple

Cette définition d’action arrête l’exécution d’un workflow, affecte la valeur « Failed » à l’état d’exécution, et retourne l’état, un code d’erreur et un message d’erreur :

"Terminate": {
    "type": "Terminate",
    "inputs": {
        "runStatus": "Failed",
        "runError": {
            "code": "Unexpected response",
            "message": "The service received an unexpected response. Please try again."
        }
   },
   "runAfter": {}
}

Action wait

Cette action interrompt l’exécution du workflow pendant l’intervalle spécifié ou jusqu’à l’heure spécifiée, mais pas les deux.

Intervalle spécifié

"Delay": {
   "type": "Wait",
   "inputs": {
      "interval": {
         "count": <number-of-units>,
         "unit": "<interval>"
      }
   },
   "runAfter": {}
},

Heure spécifiée

"Delay_until": {
   "type": "Wait",
   "inputs": {
      "until": {
         "timestamp": "<date-time-stamp>"
      }
   },
   "runAfter": {}
},

Obligatoire

Valeur	Type	Description
<number-of-units>	Integer	Pour l’action Delay, il s’agit du nombre d’unités pendant lesquelles attendre
<interval>	String	Pour l’action Delay, il s’agit de l’intervalle d’attente : "Second", "Minute", "Hour", "Day", "Week", "Month"
<date-time-stamp>	String	Pour l’action Delay, il s’agit de la date et de l’heure de reprise de l’exécution. Cette valeur doit utiliser le format date/heure UTC.

Exemple 1

Cette définition d’action suspend le workflow pendant 15 minutes :

"Delay": {
   "type": "Wait",
   "inputs": {
      "interval": {
         "count": 15,
         "unit": "Minute"
      }
   },
   "runAfter": {}
},

Exemple 2

Cette définition d’action suspend le workflow jusqu’à l’heure spécifiée :

"Delay_until": {
   "type": "Wait",
   "inputs": {
      "until": {
         "timestamp": "2017-10-01T00:00:00Z"
      }
   },
   "runAfter": {}
},

Action workflow

Cette action appelle une autre application logique créée précédemment, ce qui signifie que vous pouvez inclure et réutiliser d’autres workflows d’application logique. Vous pouvez également utiliser les sorties de l’application logique enfant ou imbriquée dans des actions qui suivent l’application logique imbriquée, à condition que l’application logique enfant retourne une réponse.

Azure Logic Apps case activée l’accès au déclencheur que vous souhaitez appeler. Veillez donc à pouvoir accéder à ce déclencheur. En outre, l’application logique imbriquée doit répondre aux critères suivants :

• Un déclencheur fait en sorte que l’application logique imbriquée puisse être appelée (par exemple un déclencheur Request ou HTTP)

• Il s’agit du même abonnement Azure que votre application logique parente

• Pour utiliser les sorties de l’application logique imbriquée dans votre application logique parente, l’application logique imbriquée doit avoir une action Response

"<nested-logic-app-name>": {
   "type": "Workflow",
   "inputs": {
      "body": { "<body-content" },
      "headers": { "<header-content>" },
      "host": {
         "triggerName": "<trigger-name>",
         "workflow": {
            "id": "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Logic/<nested-logic-app-name>"
         }
      }
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<nested-logic-app-name>	String	Nom de l’application logique que vous souhaitez appeler
<trigger-name>	String	Nom du déclencheur dans l’application logique imbriquée que vous souhaitez appeler
<Azure-subscription-ID>	String	ID d’abonnement Azure pour l’application logique imbriquée
<Azure-resource-group>	String	Nom du groupe de ressources Azure pour l’application logique imbriquée

Facultatif

Valeur	Type	Description
<header-content>	Objet JSON	En-têtes à envoyer avec l’appel
<body-content>	Objet JSON	Tout contenu de message à envoyer avec l’appel

Sorties

Les sorties de cette action dépendent de l’action Response de l’application logique imbriquée. Si celle-ci n’inclut pas d’action Response, les sorties sont vides.

Exemple

Une fois que l’action « Start_search » se termine correctement, cette définition d’action de workflow appelle une autre application logique nommée « Get_product_information », qui transmet les entrées spécifiées :

"actions": {
   "Start_search": { <action-definition> },
   "Get_product_information": {
      "type": "Workflow",
      "inputs": {
         "body": {
            "ProductID": "24601",
         },
         "host": {
            "id": "/subscriptions/XXXXXXXXXXXXXXXXXXXXXXXXXX/resourceGroups/InventoryManager-RG/providers/Microsoft.Logic/Get_product_information",
            "triggerName": "Find_product"
         },
         "headers": {
            "content-type": "application/json"
         }
      },
      "runAfter": { 
         "Start_search": [ "Succeeded" ]
      }
   }
},

Détails des actions de workflow de contrôle

Action Foreach

Cette action de bouclage effectue une itération au sein d’un tableau et exécute des actions sur chaque élément. Par défaut, la boucle « for each » s’exécute en parallèle jusqu’à un nombre maximal de boucles. Pour plus d’informations sur ce maximum, consultez Limites et configuration. Dévouvrez comment créer des boucles « for each ».

"For_each": {
   "type": "Foreach",
   "actions": { 
      "<action-1>": { "<action-definition-1>" },
      "<action-2>": { "<action-definition-2>" }
   },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "runtimeConfiguration": {
      "concurrency": {
         "repetitions": <count>
      }
    },
    "operationOptions": "<operation-option>"
}

Obligatoire

Valeur	Type	Description
<action-1...n>	String	Noms des actions qui s’exécutent sur chaque élément du tableau
<action-definition-1...n>	Objet JSON	Définitions des actions qui s’exécutent
<for-each-expression>	String	Expression référence chaque élément du tableau spécifié

Facultatif

Valeur	Type	Description
<count>	Integer	Par défaut, les itérations de boucle « for each » s’exécutent en même temps (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour changer cette limite en définissant une nouvelle valeur <count>, consultez Changer la concurrence de boucle « for each ».
<operation-option>	String	Pour exécuter une boucle « for each » séquentiellement plutôt qu’en parallèle, affectez à <operation-option> la valeur Sequential, ou à <count> la valeur 1, mais pas les deux. Pour plus d’informations, consultez Exécuter des boucles « for each » séquentiellement.

Exemple

Cette boucle « for each » envoie un e-mail pour chaque élément du tableau qui contient des pièces jointes à un e-mail entrant. La boucle envoie un e-mail, pièce jointe comprise, à une personne qui passe en revue la pièce jointe.

"For_each": {
   "type": "Foreach",
   "actions": {
      "Send_an_email": {
         "type": "ApiConnection",
         "inputs": {
            "body": {
               "Body": "@base64ToString(items('For_each')?['Content'])",
               "Subject": "Review attachment",
               "To": "Sophie.Owen@contoso.com"
                },
            "host": {
               "connection": {
                  "id": "@parameters('$connections')['office365']['connectionId']"
               }
            },
            "method": "post",
            "path": "/Mail"
         },
         "runAfter": {}
      }
   },
   "foreach": "@triggerBody()?['Attachments']",
   "runAfter": {}
}

Pour spécifier uniquement un tableau qui est passé en tant que sortie du déclencheur, cette expression obtient le tableau <array-name> à partir du corps du déclencheur. Pour éviter un échec si le tableau n’existe pas, l’expression utilise l’opérateur ? :

@triggerBody()?['<array-name>']

Action If

Cette action, qui est une instruction conditionnelle, évalue une expression qui représente une condition et exécute une branche différente selon que la condition est true ou false. Si la condition est true, elle est marquée avec l’état « Succeeded ». Découvrez comment créer des instructions conditionnelles.

"Condition": {
   "type": "If",
   "expression": { "<condition>" },
   "actions": {
      "<action-1>": { "<action-definition>" }
   },
   "else": {
      "actions": {
        "<action-2>": { "<action-definition" }
      }
   },
   "runAfter": {}
}

Valeur	Type	Description
<condition>	Objet JSON	Condition, qui peut être une expression, à évaluer
<action-1>	Objet JSON	Action à exécuter quand <condition> a la valeur true
<action-definition>	Objet JSON	Définition de l’action
<action-2>	Objet JSON	Action à exécuter quand <condition> a la valeur false

Les actions dans les objets actions ou else reçoivent ces états :

• Réussite, lorsqu’elles sont exécutées et qu’elles réussissent
• Échec, lorsqu’elles sont exécutées et qu’elles échouent
• Ignoré, lorsque la branche respective ne s’exécute pas

Exemple

Cette condition spécifie que quand la variable entière a une valeur supérieure à zéro, le workflow vérifie un site web. Si la variable est égale à zéro ou moins, le workflow vérifie un autre site web.

"Condition": {
   "type": "If",
   "expression": {
      "and": [ {
         "greater": [ "@variables('myIntegerVariable')", 0 ] 
      } ]
   },
   "actions": { 
      "HTTP - Check this website": {
         "type": "Http",
         "inputs": {
         "method": "GET",
            "uri": "http://this-url"
         },
         "runAfter": {}
      }
   },
   "else": {
      "actions": {
         "HTTP - Check this other website": {
            "type": "Http",
            "inputs": {
               "method": "GET",
               "uri": "http://this-other-url"
            },
            "runAfter": {}
         }
      }
   },
   "runAfter": {}
}

Utilisation des expressions dans les conditions

Voici des exemples illustrant comment utiliser des expressions dans des conditions :

JSON	Résultats
"expression": "@parameters('<hasSpecialAction>')"	Pour les expressions booléennes, la condition est satisfaite pour toute valeur évaluée comme True. Pour convertir d’autres types en valeurs booléennes, utilisez la fonction empty() ou equals().
"expression": "@greater(actions('<action>').output.value, parameters('<threshold>'))"	Pour les fonctions de comparaison, l’action s’exécute uniquement quand la sortie de <action> est supérieure à la valeur <threshold>.
"expression": "@or(greater(actions('<action>').output.value, parameters('<threshold>')), less(actions('<same-action>').output.value, 100))"	Pour les fonctions logiques et la création d’expressions booléennes imbriquées, l’action s’exécute quand la sortie de <action> est supérieure à la valeur de <threshold> ou inférieure à 100.
« expression » : « @equals(length(actions('<action>').outputs.errors), 0) »	Vous pouvez utiliser des fonctions de tableau pour vérifier si le tableau contient des éléments. L’action s’exécute quand le tableau errors est vide.

Action scope

Cette action regroupe logiquement des actions en étendues, qui reçoivent leur propre état à la fin de l’exécution des actions dans cette étendue. Vous pouvez ensuite utiliser l’état de l’étendue pour déterminer si d’autres actions s’exécutent. Découvrez comment créer des étendues.

"Scope": {
   "type": "Scope",
   "actions": {
      "<inner-action-1>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      },
      "<inner-action-2>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      }
   }
}

Obligatoire

Valeur	Type	Description
<inner-action-1...n>	Objet JSON	Une ou plusieurs actions qui s’exécutent au sein de l’étendue
<action-inputs>	Objet JSON	Entrées pour chaque action

Action Switch

Cette action, également appelée instruction switch, organise d’autres actions en cas, et affecte une valeur à chaque cas, sauf au cas par défaut s’il en existe un. Quand votre workflow s’exécute, l’action Switch compare la valeur d’une expression, d’un objet ou d’un jeton aux valeurs spécifiées pour chaque cas. Si l’action Switch détecte un cas correspondant, votre workflow exécute uniquement les actions pour ce cas. Chaque fois que l’action Switch s’exécute, soit il n’existe qu’un seul cas correspondant, soit il n’existe aucune correspondance. Si aucune correspondance n’existe, l’action Switch exécute les actions par défaut. Découvrez comment créer des instructions switch.

"Switch": {
   "type": "Switch",
   "expression": "<expression-object-or-token>",
   "cases": {
      "Case": {
         "actions": {
           "<action-name>": { "<action-definition>" }
         },
         "case": "<matching-value>"
      },
      "Case_2": {
         "actions": {
           "<action-name>": { "<action-definition>" }
         },
         "case": "<matching-value>"
      }
   },
   "default": {
      "actions": {
         "<default-action-name>": { "<default-action-definition>" }
      }
   },
   "runAfter": {}
}

Obligatoire

Valeur	Type	Description
<expression-object-or-token>	Variable	Expression, objet JSON ou jeton à évaluer
<action-name>	String	Nom de l’action à exécuter pour le cas correspondant
<action-definition>	Objet JSON	Définition de l’action à exécuter pour le cas correspondant
<matching-value>	Variable	Valeur à comparer au résultat évalué

Facultatif

Valeur	Type	Description
<default-action-name>	String	Nom de l’action par défaut à exécuter quand il n’existe aucun cas correspondant
<default-action-definition>	Objet JSON	Définition de l’action à exécuter quand il n’existe aucun cas correspondant

Exemple

Cette définition d’action évalue si la personne qui répond à l’e-mail de demande d’approbation a sélectionné l’option « Approuver » ou « Rejeter ». En fonction de ce choix, l’action Switch exécute les actions pour le cas correspondant, qui consistent à envoyer un autre e-mail au répondant, mais avec un libellé différent dans chaque cas.

"Switch": {
   "type": "Switch",
   "expression": "@body('Send_approval_email')?['SelectedOption']",
   "cases": {
      "Case": {
         "actions": {
            "Send_an_email": { 
               "type": "ApiConnection",
               "inputs": {
                  "Body": "Thank you for your approval.",
                  "Subject": "Response received", 
                  "To": "Sophie.Owen@contoso.com"
               },
               "host": {
                  "connection": {
                     "name": "@parameters('$connections')['office365']['connectionId']"
                  }
               },
               "method": "post",
               "path": "/Mail"
            },
            "runAfter": {}
         },
         "case": "Approve"
      },
      "Case_2": {
         "actions": {
            "Send_an_email_2": { 
               "type": "ApiConnection",
               "inputs": {
                  "Body": "Thank you for your response.",
                  "Subject": "Response received", 
                  "To": "Sophie.Owen@contoso.com"
               },
               "host": {
                  "connection": {
                     "name": "@parameters('$connections')['office365']['connectionId']"
                  }
               },
               "method": "post",
               "path": "/Mail"
            },
            "runAfter": {}     
         },
         "case": "Reject"
      }
   },
   "default": {
      "actions": { 
         "Send_an_email_3": { 
            "type": "ApiConnection",
            "inputs": {
               "Body": "Please respond with either 'Approve' or 'Reject'.",
               "Subject": "Please respond", 
               "To": "Sophie.Owen@contoso.com"
            },
            "host": {
               "connection": {
                  "name": "@parameters('$connections')['office365']['connectionId']"
               }
            },
            "method": "post",
            "path": "/Mail"
         },
         "runAfter": {} 
      }
   },
   "runAfter": {
      "Send_approval_email": [ 
         "Succeeded"
      ]
   }
}

Action until

Cette action de boucle contient des actions qui s’exécutent jusqu’à ce que la condition spécifiée ait la valeur true. La boucle vérifie la condition en guise de dernière étape une fois toutes les autres actions exécutées. Vous pouvez inclure plusieurs actions dans l’objet "actions", et l’action doit définir au moins une limite. Découvrez comment créer des boucles « until ».

 "Until": {
   "type": "Until",
   "actions": {
      "<action-name>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      },
      "<action-name>": {
         "type": "<action-type>",
         "inputs": { "<action-inputs>" },
         "runAfter": {}
      }
   },
   "expression": "<condition>",
   "limit": {
      "count": <loop-count>,
      "timeout": "<loop-timeout>"
   },
   "runAfter": {}
}

Valeur	Type	Description
<action-name>	String	Nom de l’action que vous souhaitez exécuter à l’intérieur de la boucle
<action-type>	String	Type d’action à exécuter
<action-inputs>	Divers	Entrées pour l’action à exécuter
<condition>	String	Condition ou expression à évaluer une fois que toutes les actions de la boucle ont été exécutées
<loop-count>	Integer	Quantité limite de boucles que l’action peut exécuter. Pour plus d’informations sur la limite par défaut et la limite maximale, consultez Limites and configuration pour Azure Logic Apps.
<loop-timeout>	String	Durée d’exécution maximale de la boucle. La valeur par défaut de timeout est PT1H, qui est le format ISO 8601 requis.

Exemple

Cette définition d’action de boucle envoie une requête HTTP à l’URL spécifiée jusqu’à ce que l’une des conditions suivantes soit remplie :

• La requête obtient une réponse avec le code d’état « 200 OK ».
• La boucle s’est exécutée 60 fois.
• La boucle s’est exécutée pendant une heure.

 "Run_until_loop_succeeds_or_expires": {
    "type": "Until",
    "actions": {
        "HTTP": {
            "type": "Http",
            "inputs": {
                "method": "GET",
                "uri": "http://myurl"
            },
            "runAfter": {}
        }
    },
    "expression": "@equals(outputs('HTTP')['statusCode'], 200)",
    "limit": {
        "count": 60,
        "timeout": "PT1H"
    },
    "runAfter": {}
}

Webhooks et abonnements

Les actions et déclencheurs basés sur des webhooks ne vérifient pas régulièrement les points de terminaison, mais attendent des événements ou des données spécifiques à ces points de terminaison. Ces actions et déclencheurs s’abonnent aux points de terminaison en fournissant une URL de rappel où le point de terminaison peut envoyer des réponses.

L’appel subscribe est effectué quand le workflow change de quelque façon, par exemple quand les informations d’identification sont renouvelées ou quand les paramètres d’entrée d’un déclencheur ou d’une action changent. Cet appel utilise les mêmes paramètres que les actions HTTP standard.

L’appel unsubscribe se produit automatiquement quand une opération rend le déclencheur ou l’action non valide, par exemple :

• Suppression ou désactivation du déclencheur.
• Suppression ou désactivation du workflow.
• Suppression ou désactivation de l’inscription.

Pour prendre en charge ces appels, l’expression @listCallbackUrl() retourne une « URL de rappel » unique pour le déclencheur ou l’action. Cette URL représente un identificateur unique des points de terminaison qui utilisent l’API REST du service. Les paramètres de cette fonction sont les mêmes que ceux de l’action ou du déclencheur webhook.

Modifier la durée asynchrone

Pour les déclencheurs et les actions, vous pouvez limiter la durée pour le modèle asynchrone à un intervalle de temps spécifique en ajoutant la propriété limit.timeout. De cette façon, si l’action n’est pas terminée à la fin de l’intervalle, l’état de l’action est marqué comme Cancelled avec le code ActionTimedOut. La propriété timeout utilise le format ISO 8601.

"<trigger-or-action-name>": {
   "type": "Workflow | Webhook | Http | ApiConnectionWebhook | ApiConnection",
   "inputs": {},
   "limit": {
      "timeout": "PT10S"
   },
   "runAfter": {}
}

Paramètres de configuration d’exécution

Vous pouvez changer le comportement d’exécution par défaut pour les déclencheurs et les actions en ajoutant ces propriétés runtimeConfiguration à la définition de déclencheur ou d’action.

Propriété	Type	Description	Déclencheur ou action
runtimeConfiguration.concurrency.runs	Integer	Modifiez la limite par défaut du nombre d’instances de workflow qui peuvent s’exécuter en même temps (simultanément ou en parallèle). L’ajustement de cette valeur peut aider à limiter le nombre de requêtes reçues par les systèmes back-end. L’affectation de la valeur 1 à la propriété runs fonctionne de la même façon que l’affectation de la valeur SingleInstance à la propriété operationOptions. Vous pouvez définir l’une ou l’autre propriété, mais pas les deux. Pour modifier la limite par défaut, consultez Changer la concurrence du déclencheur ou Déclencher des instances séquentiellement.	Tous les déclencheurs
runtimeConfiguration.concurrency.maximumWaitingRuns	Integer	Modifiez la limite par défaut du nombre d’instances de workflow qui doivent attendre de s’exécuter quand votre application logique exécute déjà le nombre maximal d’instances simultanées. Pour changer la limite par défaut, consultez Changer la limite d’exécutions en attente.	Tous les déclencheurs
runtimeConfiguration.concurrency.repetitions	Integer	Modifiez la limite par défaut du nombre d’itérations de boucle « for each » qui peuvent s’exécuter en même temps (simultanément ou en parallèle). L’affectation de la valeur 1 à la propriété repetitions fonctionne de la même façon que l’affectation de la valeur SingleInstance à la propriété operationOptions. Vous pouvez définir l’une ou l’autre propriété, mais pas les deux. Pour changer la limite par défaut, consultez Changer la concurrence « for each » ou Exécuter des boucles « for each » séquentiellement.	Action : Foreach
runtimeConfiguration.paginationPolicy.minimumItemCount	Integer	Pour des actions spécifiques qui prennent en charge la pagination activée et pour laquelle cette dernière est activée, cette valeur spécifie le nombre minimal de résultats à récupérer. Pour savoir comment activer la pagination, voir Obtenir d’autres données, des articles ou des enregistrements à l’aide de la pagination dans Azure Logic Apps	Action : Différentes possibilités
runtimeConfiguration.secureData.properties	Array	Sur de nombreux déclencheurs et actions, ces paramètres permettent de masquer les entrées et/ou les sorties dans l’historique d’exécution d’une application logique. Pour en savoir plus sur la protection de ces données, consultez Masquer les entrées et sorties de l’historique d’exécution.	La plupart des déclencheurs et des actions
runtimeConfiguration.staticResult	Objet JSON	Pour les actions qui prennent en charge et que le paramètre de résultat statique est activé, l’objet staticResult a les attributs suivants : - name, qui fait référence au nom de définition du résultat statique de l’action en cours, affiché dans l’attribut staticResults au sein de l’attribut definition du flux de travail. Pour en savoir plus, consultez le schéma de référence du langage de définition du flux de travail de la section Résultats statiques. - staticResultOptions, qui spécifie si les résultats statiques ont la valeur Enabled ou non pour l’action en cours. Pour en savoir plus, voir Tester des applications logiques avec des données fictives en configurant des résultats statiques.	Action : Différentes possibilités

Options d’opérations

Vous pouvez changer le comportement par défaut pour les déclencheurs et les actions avec la propriété operationOptions dans la définition de déclencheur ou d’action.

Option d’opération	Type	Description	Déclencheur ou action
DisableAsyncPattern	String	Exécuter des actions basées sur HTTP de manière synchrone plutôt qu’asynchrone. Pour définir cette option, consultez Exécuter des actions de manière synchrone.	Actions: Api Connecter ion, HTTP, Response
IncludeAuthorizationHeadersInOutputs	Chaîne	Pour les applications logiques qui permettent à OAuth avec Microsoft Entra ID d’autoriser l’accès pour les appels entrants à un point de terminaison de déclencheur basé sur une requête, incluez l’en-tête Authorization à partir du jeton d’accès OAuth dans les sorties du déclencheur. Pour plus d’informations, consultez Inclure l’en-tête « Authorization » dans les sorties du déclencheur de requête.	Déclenche: Demande, Déclencheur HTTPWebhook
Sequential	String	Exécutez les itérations de boucle « for each » une à la fois, plutôt que toutes en même temps en parallèle. Cette option fonctionne de la même façon que l’affectation de la valeur 1 à la propriété runtimeConfiguration.concurrency.repetitions. Vous pouvez définir l’une ou l’autre propriété, mais pas les deux. Pour définir cette option, consultez Exécuter des boucles « for each » séquentiellement.	Action : Foreach
SingleInstance	String	Exécuter le déclencheur pour chaque instance d’application logique de manière séquentielle, et attendre que l’exécution active précédente se termine avant de déclencher l’instance d’application logique suivante. Cette option fonctionne de la même façon que l’affectation de la valeur 1 à la propriété runtimeConfiguration.concurrency.runs. Vous pouvez définir l’une ou l’autre propriété, mais pas les deux. Pour définir cette option, consultez Déclencher des instances séquentiellement.	Tous les déclencheurs
SuppressWorkflowHeaders	Chaîne	Ne pas envoyer d’en-têtes de métadonnées x-ms-* dans les demandes sortantes. Par défaut, Azure Logic Apps inclut des en-têtes de métadonnées supplémentaires avec le préfixe dans le x-ms- nom de l’en-tête dans le cadre des demandes sortantes. Toutefois, certains services hérités n’acceptent pas les demandes avec des en-têtes inconnus supplémentaires, ce qui entraîne l’échec des demandes.	Actions: HTTP, Fonction, APIManagement
SuppressWorkflowHeadersOnResponse	Chaîne	Ne pas envoyer d’en-têtes de métadonnées x-ms-* dans les réponses aux demandes de déclencheur entrantes. Par défaut, Azure Logic Apps envoie des réponses aux demandes entrantes qui incluent des en-têtes de métadonnées supplémentaires avec le préfixe dans le x-ms- nom de l’en-tête. Toutefois, certains services hérités n’acceptent pas les demandes ou réponses avec des en-têtes inconnus supplémentaires, ce qui entraîne l’échec des demandes.	Déclenche: Demande, Déclencheur HTTPWebhook

Changer la concurrence du déclencheur

Par défaut, les instances de workflow d’application logique s’exécutent toutes en même temps (simultanément ou en parallèle). Ce comportement signifie que chaque instance de déclencheur s’active avant la fin de l’exécution de l’instance de workflow active précédente. Toutefois, le nombre d’instances exécutées simultanément a une limite par défaut. Lorsque le nombre d’instances de workflow exécutées simultanément atteint cette limite, toute autre nouvelle instance doit attendre de s’exécuter. Cette limite aide à contrôler le nombre de requêtes reçues par les systèmes backend.

Lorsque vous activez le contrôle d’accès concurrentiel du déclencheur, les instances de déclencheur s’exécutent en parallèle jusqu’à la limite par défaut. Pour modifier cette limite d’accès concurrentiel par défaut, vous pouvez utiliser l’éditeur de vue de code ou le concepteur de flux de travail, car la modification du paramètre d’accès concurrentiel par le biais du concepteur ajoute ou met à jour la runtimeConfiguration.concurrency.runs propriété dans la définition de déclencheur sous-jacente et vice versa. Cette propriété contrôle le nombre maximal de nouvelles instances de workflow qui peuvent s’exécuter en parallèle.

Avant d’activer l’accès concurrentiel sur un déclencheur, passez en revue les considérations suivantes :

• Vous ne pouvez pas désactiver la concurrence après avoir activé le contrôle de la concurrence.

• Si le nombre maximal d’exécutions de déclencheur simultanées atteint le degré maximal de parallélisme, les exécutions de déclencheur suivantes peuvent rencontrer des erreurs de limitation ou de type « 429 - Trop de requêtes ». Si vous configurez une stratégie Nouvelle tentative qui gère les erreurs 429, le déclencheur peut rencontrer un cycle de nouvelles tentatives et un comportement de limitation qui entraîne de longs retards dans le traitement des nouvelles demandes de déclencheur.

• Lorsque la concurrence est activée, la limite SplitOn est considérablement réduite pour la décomposition des tableaux. Si le nombre d'éléments dépasse cette limite, la fonction SplitOn est désactivée.

• Quand la concurrence est activée, une instance d’application logique de longue durée peut amener de nouvelles instances d’application logique à entrer dans un état d’attente. Cet état empêche Azure Logic Apps de créer des instances et se produit même quand le nombre d’exécutions simultanées est inférieur au nombre maximal spécifié d’exécutions simultanées.

  • Pour interrompre cet état, annulez les instances les plus anciennes qui sont toujours en cours d’exécution.

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

    2. Dans la section Historique des exécutions, sélectionnez l’instance la plus ancienne qui est toujours en cours d’exécution, par exemple :

       

       Conseil

       Pour voir uniquement les instances qui sont toujours en cours d’exécution, ouvrez la liste Tous, puis sélectionnez En cours d’exécution.

    3. Sous Exécution d’application logique, sélectionnez Annuler l’exécution.

       

  • Pour contourner cette éventualité, ajoutez un délai d’expiration aux actions susceptibles de retenir ces exécutions. Si vous travaillez dans l’éditeur de code, consultez Changer la durée asynchrone. Dans le cas contraire, si vous utilisez le concepteur, procédez comme suit :

    1. Dans votre workflow d’application logique, sélectionnez l’action dans laquelle vous souhaitez ajouter un délai d’expiration. En haut à droite de l’action, sélectionnez le bouton représentant des points de suspension (…), puis Paramètres.

       

    2. Sous Expiration, spécifiez la durée du délai d’expiration au format ISO 8601.

       

• Pour exécuter votre application logique séquentiellement, définissez la concurrence du déclencheur sur 1 à l’aide de l’éditeur en mode code ou du concepteur. Veillez à ne pas définir également la propriété operationOptions du déclencheur sur SingleInstance dans l’éditeur en mode code. car vous obtiendriez une erreur de validation. Pour plus d’informations, consultez Déclencher des instances séquentiellement.

Modifier en mode code

Dans la définition de déclencheur sous-jacente, ajoutez la propriété runtimeConfiguration.concurrency.runs et définissez la valeur en fonction des limites de concurrence du déclencheur. Pour exécuter votre flux de travail de manière séquentielle, définissez la valeur de propriété sur 1.

Cet exemple limite les exécutions simultanées à 10 instances :

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": 10
      }
   }
}

Pour plus d’informations, consultez Paramètres de configuration d’exécution.

Modifier dans le concepteur de flux de travail

1. En haut à droite du déclencheur, sélectionnez le bouton représentant des points de suspension ( ... ), puis Paramètres.

2. Sous Contrôle d’accès concurrentiel, définissez Limite sur Activé.

3. Positionnez le curseur Degré de parallélisme sur la valeur souhaitée. Pour exécuter votre application logique séquentiellement, faites glisser le curseur vers la valeur 1.

Changer la concurrence « for each »

Par défaut, les itérations de boucle « for each » s’exécutent toutes en même temps (simultanément ou en parallèle). Ce comportement signifie que chaque itération commence à s’exécuter avant la fin de l’exécution de l’itération précédente. Toutefois, le nombre d’itérations exécutées simultanément a une limite par défaut. Lorsque le nombre d’itérations exécutées simultanément atteint cette limite, toute autre itération doit attendre de s’exécuter.

Pour modifier la limite par défaut, vous pouvez utiliser l’éditeur de vue de code ou le concepteur de flux de travail, car la modification du paramètre d’accès concurrentiel par le biais du concepteur ajoute ou met à jour la runtimeConfiguration.concurrency.repetitions propriété dans la définition d’action « pour chaque » sous-jacente et inversement. Cette propriété contrôle le nombre maximal d’itérations qui peuvent s’exécuter en parallèle.

Modifier en mode code

Dans la définition « for each » sous-jacente, ajoutez ou mettez à jour la propriété runtimeConfiguration.concurrency.repetitions, qui peut avoir une valeur comprise entre 1 et 50.

Voici un exemple qui limite les exécutions simultanées à 10 itérations :

"For_each" {
   "type": "Foreach",
   "actions": { "<actions-to-run>" },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "runtimeConfiguration": {
      "concurrency": {
         "repetitions": 10
      }
   }
}

Pour plus d’informations, consultez Paramètres de configuration d’exécution.

Modifier dans le concepteur de flux de travail

1. Dans l’angle supérieur droit de l’action For each, sélectionnez le bouton représentant des points de suspension ( ... ), puis Paramètres.

2. Sous Contrôle d’accès concurrentiel, définissez Contrôle d’accès concurrentiel sur Activé.

3. Positionnez le curseur Degré de parallélisme sur la valeur souhaitée. Pour exécuter votre application logique séquentiellement, faites glisser le curseur vers la valeur 1.

Modifier la limite d’exécutions en attente

Par défaut, les instances de workflow d’application logique s’exécutent toutes en même temps (simultanément ou en parallèle). Ce comportement signifie que chaque instance de déclencheur s’active avant la fin de l’exécution de l’instance de workflow active précédente. Toutefois, une limite par défaut existe sur le nombre d’instances de workflow en cours d’exécution simultanée. Lorsque le nombre d’exécutions simultanées atteint cette limite, toutes les autres instances de workflow doivent attendre l’exécution. Une limite par défaut existe également sur le nombre d’instances de workflow en attente. Lorsque le nombre d’instances en attente atteint cette limite, Azure Logic Apps n’accepte plus les nouvelles instances de flux de travail à exécuter. Les déclencheurs de requête et de webhook retournent 429 - Trop d’erreurs de requêtes et les déclencheurs récurrents commencent à ignorer les tentatives d’interrogation.

Vous pouvez modifier la limite par défaut de la concurrence du déclencheur ainsi que la limite par défaut des exécutions en attente. Toutefois, ce changement ralentit principalement le déclencheur pour soulager la pression en raison de la concurrence. Par exemple, si vous avez un déclencheur d’interrogation et que la file d’attente des exécutions en attente est pleine en raison des exécutions en cours, Azure Logic Apps arrête l’interrogation. Si votre flux de travail utilise un déclencheur basé sur une requête et que la file d’attente des exécutions en attente est pleine, Azure Logic Apps commence à renvoyer l’erreur 429. Certains scénarios existent où Azure Logic Apps ne peut pas arrêter le déclencheur d’interrogation sans introduire d’échecs et opte pour ajouter ces exécutions à la file d’attente des exécutions en attente de toute façon sans échec des exécutions appelantes.

Dans la définition de déclencheur sous-jacente, ajoutez la propriété runtimeConfiguration.concurrency.maximumWaitingRuns, qui peut avoir une valeur comprise entre 1 et 100.

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "runtimeConfiguration": {
      "concurrency": {
         "maximumWaitingRuns": 50
      }
   }
}

Pour plus d’informations, consultez Paramètres de configuration d’exécution.

Déclencher des instances séquentiellement

Pour exécuter chaque instance de flux de travail de l’application logique uniquement après la fin de l’exécution de l’instance précédente, configurez le déclencheur pour qu’il s’exécute de manière séquentielle. Vous pouvez utiliser l’éditeur de vue de code ou le concepteur de flux de travail, car la modification du paramètre d’accès concurrentiel par le biais du concepteur ajoute ou met à jour la runtimeConfiguration.concurrency.runs propriété dans la définition de déclencheur sous-jacente et vice versa.

Modifier en mode code

Dans la définition du déclencheur, définissez l’une ou l’autre de ces propriétés, mais pas les deux.

Affectez la valeur 1 à la propriété runtimeConfiguration.concurrency.runs :

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "runtimeConfiguration": {
      "concurrency": {
         "runs": 1
      }
   }
}

-ou-

Affectez la valeur SingleInstance à la propriété operationOptions :

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "operationOptions": "SingleInstance"
}

Pour plus d’informations, consultez Paramètres de configuration d’exécution et Options d’opérations.

Modifier dans le concepteur de flux de travail

1. En haut à droite du déclencheur, sélectionnez le bouton représentant des points de suspension ( ... ), puis Paramètres.

2. Sous Contrôle d’accès concurrentiel, définissez Limite sur Activé.

3. Positionnez le curseur Degré de parallélisme sur le chiffre 1.

Exécuter des boucles « for each » séquentiellement

Pour exécuter une itération de boucle « for each » uniquement après la fin de l’exécution de l’itération précédente, configurez l’action « for each » pour qu’elle s’exécute de manière séquentielle. Vous pouvez utiliser l’éditeur de vue de code ou le concepteur de flux de travail, car la modification de la concurrence de l’action par le biais du concepteur ajoute ou met également à jour la runtimeConfiguration.concurrency.repetitions propriété dans la définition d’action sous-jacente et vice versa.

Modifier en mode code

Dans la définition de l’action, définissez l’une ou l’autre de ces propriétés, mais pas les deux.

Affectez la valeur 1 à la propriété runtimeConfiguration.concurrency.repetitions :

"For_each" {
   "type": "Foreach",
   "actions": { "<actions-to-run>" },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "runtimeConfiguration": {
      "concurrency": {
         "repetitions": 1
      }
   }
}

-ou-

Affectez la valeur Sequential à la propriété operationOptions :

"For_each" {
   "type": "Foreach",
   "actions": { "<actions-to-run>" },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "operationOptions": "Sequential"
}

Pour plus d’informations, consultez Paramètres de configuration d’exécution et Options d’opérations.

Modifier dans le concepteur de flux de travail

1. En haut à droite de l’action For each, sélectionnez le bouton représentant des points de suspension ( ... ), puis Paramètres.

2. Sous Contrôle d’accès concurrentiel, définissez Contrôle d’accès concurrentiel sur Activé.

3. Positionnez le curseur Degré de parallélisme sur le chiffre 1.

Exécuter des actions dans un modèle d’opération synchrone

Par défaut, l’action HTTP et les actions APIConnection dans Azure Logic Apps suivent le modèle d’opération asynchrone standard, alors que l’action Response suit le modèle d’opération synchrone. Le modèle asynchrone spécifie qu’une fois qu’une action a appelé ou envoyé une requête au point de terminaison, au service, au système ou à l’API spécifiée, le récepteur retourne immédiatement une réponse « 202 ACCEPTED ». 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 en-tête location qui spécifie l’URL et un ID d’actualisation que l’appelant peut utiliser pour interroger ou vérifier en permanence l’état de la requête asynchrone jusqu’à ce que le récepteur arrête le traitement et retourne la réponse de réussite « 200 OK » ou une réponse autre qu’une réponse 202. Pour plus d’informations, consultez L’intégration asynchrone des microservices permet l’autonomie des microservices.

• Dans le concepteur d’application logique, l’action HTTP, les actions APIConnection et l’action Response ont le paramètre Modèle asynchrone. Quand il est activé, ce paramètre spécifie que l’appelant n’a pas à attendre la fin du traitement et qu’il peut passer à l’action suivante, tout en continuant de 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 trouver ce paramètre, effectuez les étapes suivantes :

  1. Dans la barre de titre de l’action HTTP, sélectionnez le bouton de sélection ( ... ) qui permet d’ouvrir les paramètres de l’action.

  2. Recherchez le paramètre Modèle asynchrone.

     

• Dans la définition JSON (JavaScript Object Notation) sous-jacente de l’action, l’action HTTP et les actions APIConnection suivent implicitement le modèle d’opération asynchrone.

Dans certains scénarios, vous pouvez souhaiter qu’une action suive plutôt le modèle synchrone. Par exemple, quand vous utilisez l’action HTTP, vous souhaitez peut-être :

• É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

Dans ce cas, vous pouvez exécuter une action de manière synchrone en procédant comme indiqué ci-dessous :

• Remplacez la version d’interrogation de l’action par une version de Webhook, le cas échéant.

• Désactivez le comportement asynchrone de l’action en procédant de l’une des façons suivantes :

  • Dans concepteur d’application logique, désactivez le paramètre Modèle asynchrone.

  • Dans la définition JSON sous-jacente de l’action, ajoutez l’option d’opération "DisableAsyncPattern".

Désactiver le paramètre Modèle asynchrone

1. Dans le concepteur d’application logique, dans la barre de titre de l’action, sélectionnez le bouton de sélection ( ... ) qui permet d’ouvrir les paramètres de l’action.

2. Recherchez le paramètre Modèle asynchrone, configurez-le sur Désactivé s’il est activé, puis sélectionnez Terminé.

   

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

Dans la définition JSON sous-jacente de l’action, ajoutez la propriété « operationOptions » et affectez-lui la valeur "DisableAsyncPattern" sous la section "inputs" de l’action, par exemple :

"<some-long-running-action>": {
   "type": "Http",
   "inputs": { "<action-inputs>" },
   "operationOptions": "DisableAsyncPattern",
   "runAfter": {}
}

Authentifier les déclencheurs et les actions

Les points de terminaison HTTP et HTTPS prennent en charge différents types d’authentification. En fonction du déclencheur ou de l’action que vous utilisez pour effectuer des appels sortants ou des demandes qui accèdent à ces points de terminaison, vous pouvez choisir parmi différentes plages de types d’authentification. Pour plus d’informations, voir Ajouter l’authentification aux appels sortants.

Étapes suivantes

• En savoir plus sur le langage de définition de workflow