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 sous la vue d’ensemble 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

• Un déclencheur Push , qui crée un abonnement à un point de terminaison et fournit une URL de rappel afin que le point de terminaison puisse notifier le déclencheur lorsque l’événement spécifié se produit ou que les 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>"
},

Required

Value	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"
< nombre d’unités temporelles>	Integer	Valeur qui spécifie la fréquence d’activation du déclencheur, qui correspond au nombre d’unités de temps à attendre avant que le déclencheur soit activé à nouveau Les intervalles minimaux et maximaux sont les suivants : - Mois : 1 à 16 mois - Jour : 1-500 jours - Heure : 1-12 000 heures - Minute : 1-72 000 minutes - Seconde : 1-999 999 secondes Par exemple, si l’intervalle est défini sur 6 et la fréquence sur « Month », la périodicité est tous les six mois.

Optional

Value	Type	Description
< array-with-conditions>	Array	Tableau qui contient une ou plusieurs conditions qui déterminent s’il faut exécuter le flux de travail. 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ération.

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 à l’aide d’API gérées par Microsoft ou de « connecteurs ».
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 à l’aide d’API gérées par Microsoft ou de « connecteurs » afin que les paramètres de ce 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>"
}

Required

Property	Value	Type	Description
None	< APIConnection_trigger_name>	String	Nom du déclencheur
host.connection.name	< nom de connexion>	String	Nom de la connexion à l’API managée utilisée par le workflow
method	< type de méthode>	String	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>	String	Unité de temps qui décrit la fréquence à laquelle le déclencheur se déclenche : Seconde, Minute, Heure, Jour, Semaine, Mois
recurrence.interval	< nombre d’unités temporelles>	Integer	Valeur qui spécifie la fréquence d’activation du déclencheur, qui correspond au nombre d’unités de temps à attendre avant que le déclencheur soit activé à nouveau Les intervalles minimaux et maximaux sont les suivants : - Mois : 1-16 mois - Jour : 1-500 jours - Heure : 1-12 000 heures - Minute : 1-72 000 minutes - Seconde : 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.

Optional

Property	Value	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.
queries	< 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 modifier cette limite en définissant une nouvelle < valeur de nombre>, consultez Modifier l’accès concurrentiel du déclencheur.
runtimeConfiguration.maximumWaitingRuns	< max-runs-queue>	Integer	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ération.

Outputs

Element	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

Example

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 gérée par Microsoft, fournit une URL de rappel à l’endroit 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>"
}

Required

Value	Type	Description
< nom de connexion>	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

Optional

Value	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	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 modifier cette limite en définissant une nouvelle < valeur de nombre>, consultez Modifier l’accès concurrentiel du déclencheur.
< max-runs-queue>	Integer	Lorsque votre flux de travail exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la runtimeConfiguration.concurrency.runs propriété, 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.
< 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ération.

Example

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

Required

Property	Value	Type	Description
method	< type de méthode>	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	< nombre d’unités temporelles>	Integer	Valeur qui spécifie la fréquence d’activation du déclencheur, qui correspond au nombre d’unités de temps à attendre avant que le déclencheur soit activé à nouveau Les intervalles minimaux et maximaux sont les suivants : - Mois : 1 à 16 mois - Jour : 1-500 jours - Heure : 1-12 000 heures - Minute : 1-72 000 minutes - Seconde : 1-999 999 secondes Par exemple, si l’intervalle est défini sur 6 et la fréquence sur « Month », la périodicité est tous les six mois.

Optional

Property	Value	Type	Description
headers	< en-tête-contenu>	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 modifier cette limite en définissant une nouvelle < valeur de nombre>, consultez Modifier l’accès concurrentiel du déclencheur.
maximumWaitingRuns	< max-runs-queue>	Integer	Lorsque votre flux de travail exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la runtimeConfiguration.concurrency.runs propriété, 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.
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ération.

Outputs

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

Property	Required	Description
Code de statut	Yes	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	No	Nombre de secondes au bout duquel l’application logique interroge à nouveau le point de terminaison
En-tête d’emplacement	No	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 de statut	Réessayer après	Behavior
200	{none}	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	{none}	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	{none}	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 <le type> de méthode, sont disponibles pour les objets et "subscribe" les "unsubscribe" objets.

Required

Value	Type	Description
< type de méthode>	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

Optional

Value	Type	Description
< type de méthode>	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
< type d’authentification>	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 modifier cette limite en définissant une nouvelle < valeur de nombre>, consultez Modifier l’accès concurrentiel du déclencheur.
< max-runs-queue>	Integer	Lorsque votre flux de travail exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la runtimeConfiguration.concurrency.runs propriété, 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.
< 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ération.

Outputs

Element	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

Example

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 de périodicité

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

Required

Value	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"
< nombre d’unités temporelles>	Integer	Valeur qui spécifie la fréquence d’activation du déclencheur, qui correspond au nombre d’unités de temps à attendre avant que le déclencheur soit activé à nouveau Les intervalles minimaux et maximaux sont les suivants : - Mois : 1 à 16 mois - Jour : 1-500 jours - Heure : 1-12 000 heures - Minute : 1-72 000 minutes - Seconde : 1-999 999 secondes Par exemple, si l’intervalle est défini sur 6 et la fréquence sur « Month », la périodicité est tous les six mois.

Optional

Value	Type	Description
< start-date-time-with-format-AAAA-MM-DDThh :mm :ss>	String	Date et heure de début au format suivant : AAAA-MM-JJThh:mm:ss si vous spécifiez un fuseau horaire -or- AAAA-MM-JJThh: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).
< fuseau horaire>	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.
< une ou plusieurs heures>	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.
< une ou plusieurs minutes>	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 modifier cette limite en définissant une nouvelle < valeur de nombre>, consultez Modifier l’accès concurrentiel du déclencheur.
< max-runs-queue>	Integer	Lorsque votre flux de travail exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la runtimeConfiguration.concurrency.runs propriété, 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.
< 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ération.

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.

Note

Le nom d’origine du déclencheur de requête était manuel, qui peut toujours apparaître à certains endroits. Ce nom a changé pour créer plus de cohérence autour du type de modèle de flux de travail que vous utilisez pour générer le déclencheur.

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.

"Request": {
   "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>"
}

Required

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

Optional

Value	Type	Description
< type de méthode>	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 modifier cette limite en définissant une nouvelle < valeur de nombre>, consultez Modifier l’accès concurrentiel du déclencheur.
< max-runs-queue>	Integer	Lorsque votre flux de travail exécute déjà le nombre maximal d’instances, que vous pouvez modifier en fonction de la runtimeConfiguration.concurrency.runs propriété, 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.
< 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ération.

Example

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 :

"Request": {
   "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 de flux de travail sur un tableau

Dans les scénarios où votre workflow utilise un déclencheur qui reçoit des tableaux pour le traitement, parfois l’utilisation d’une boucle For chaque boucle peut prendre trop de temps. Pour accélérer le traitement, une option consiste à créer des branches parallèles. Ou, si le déclencheur prend en charge le débat, vous pouvez avoir le déclencheur fractionné des éléments de tableau et exécuter une instance de flux de travail distincte pour chaque élément de tableau. Cette option est utile, par exemple, lorsque vous souhaitez interroger un point de terminaison qui peut retourner plusieurs nouveaux éléments entre les intervalles d’interrogation.

Seuls les déclencheurs qui peuvent accepter des tableaux et retourner des tableaux prennent en charge cette fonctionnalité, comme la requête, HTTP, Azure Service Bus ou Office Outlook 365. Pour ces déclencheurs, dans le concepteur de flux de travail, vous pouvez activer le paramètre Split on , qui ajoute la splitOn propriété à la définition du déclencheur.

Note

Si le fichier Swagger du déclencheur décrit une charge utile qui est un tableau, la splitOn propriété est automatiquement ajoutée à votre définition de déclencheur. Si ce n’est pas le cas, et le déclencheur peut accepter des tableaux, vous pouvez ajouter la propriété à la charge utile de réponse qui contient le tableau que vous souhaitez débattre.

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

• Si l’accès concurrentiel du déclencheur est également activé, la limite de fractionnement est considérablement réduite. Si le nombre d’éléments dépasse cette limite, le fractionnement sur la fonctionnalité n’est pas disponible.

• La fonctionnalité Fractionner sur ne fonctionne pas avec le modèle de réponse synchrone. Si un flux de travail utilise l’action Réponse et active le fractionnement sur le paramètre s’exécute de manière asynchrone et envoie immédiatement une 202 ACCEPTED réponse.

• Une limite existe sur le nombre d’éléments de tableau sur tableaux sur utilisant fractionnés dans une seule exécution de flux de travail. Pour plus d’informations, consultez Limites de bouclage et de traitement par lot.

• Si vous configurez le débat par le biais de la définition du déclencheur à l’aide de la splitOn propriété, vous ne pouvez pas référencer ou accéder directement aux propriétés qui existent en dehors du tableau. Pour éviter les défaillances, faites précéder la référence avec l’opérateur ? . Pour obtenir des exemples, consultez Activer le débat dans la définition du déclencheur.

Activer le débat par le biais du concepteur

Suivez ces étapes dans le concepteur de flux de travail pour configurer le débat sur un déclencheur où il est pris en charge :

1. Dans le [portail Azure], ouvrez votre ressource d’application logique.

2. Ouvrez votre flux de travail dans le concepteur.

3. Dans le concepteur, sélectionnez le déclencheur qui prend en charge le débat pour ouvrir le volet d’informations du déclencheur.

4. Sous l’onglet Paramètres , sous Général, recherchez le paramètre Fractionner et définissez le paramètre sur Activé , s’il n’est pas activé.

Activer le débat dans la définition du déclencheur

Certains déclencheurs gèrent les tableaux, mais le fractionnement sur le paramètre n’est pas disponible via le concepteur. Pour ces déclencheurs, procédez comme suit pour ajouter la splitOn propriété dans la définition du déclencheur :

Par exemple, supposons que votre flux de travail utilise le déclencheur HTTP pour appeler une API et obtient la réponse suivante :

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

Si votre flux de travail a uniquement besoin du contenu du Rows tableau, vous pouvez ajouter et configurer la splitOn propriété dans la définition du déclencheur, comme illustré dans l’exemple suivant :

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

Note

N’oubliez pas que si vous utilisez la splitOn propriété, vous ne pouvez pas accéder directement ou référencer des propriétés qui existent en dehors du tableau. Pour éviter les défaillances, utilisez l’opérateur ? comme indiqué dans les exemples.

Votre définition de flux de travail peut également utiliser splitOn et @triggerBody().name obtenir des valeurs à partir de la name propriété. Ces valeurs proviennent "customer-name-one" de la première exécution du flux de travail et "customer-name-two" de la deuxième exécution du flux de travail. Pour cet exemple, les sorties du déclencheur ressemblent aux valeurs suivantes :

{
   "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>"
},

Required

Value	Type	Description
< action-name>	String	Nom de l’action
< type d’action>	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>	Various	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

Optional

Value	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ération.

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 via HTTP ou HTTPS

  • Réponse pour répondre aux demandes

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

  • Fonction pour appeler Azure Functions

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

  • Flux de travail pour appeler un autre flux de travail 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
Compose	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.
Join	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.
Select	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 gérée par Microsoft.
ApiConnectionWebhook	Fonctionne comme le Webhook HTTP, mais utilise une API géré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 gérée par Microsoft et nécessite 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": {}
}

Required

Value	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
< type de méthode>	String	Méthode HTTP d’appel de l’API : « GET », « PUT », « POST », « PATCH » ou « DELETE »
< api-operation>	String	Opération d’API à appeler

Optional

Value	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.
< autres propriétés spécifiques à l’action>	Objet JSON	Toutes autres propriétés qui s’appliquent à cette action spécifique

Example

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 via HTTP à un point de terminaison à l’aide d’une API gérée par Microsoft, fournit une URL de rappel à l’endroit 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 <le type> de méthode, sont disponibles pour les objets et "subscribe" les "unsubscribe" objets.

Required

Value	Type	Description
< action-name>	String	Nom de l’action fournie par le connecteur
< type de méthode>	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

Optional

Value	Type	Description
< API-unsubscribe-URL>	String	URI à utiliser pour annuler l’abonnement à l’API
< en-tête-contenu>	Objet JSON	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
< type d’authentification>	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	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
< autres propriétés spécifiques à l’action>	Objet JSON	Toutes autres propriétés qui s’appliquent à cette action spécifique

Vous pouvez également spécifier des limites sur une action ApiConnectionWebhook de la même façon que les limites asynchrones HTTP.

Action Composer

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": {}
},

Required

Value	Type	Description
< entrées à composer>	Any	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": {}
}

Required

Value	Type	Description
< JavaScript-code-snippet>	Varies	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.

Value	Type	Description
< actions précédentes>	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 apparaissent dans votre définition de flux de travail où les noms d’actions 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 de fonction

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": {}
}

Required

Value	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-function-name> »
< type de méthode>	String	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 ».

Optional

Value	Type	Description
< en-tête-contenu>	Objet JSON	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	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
< autres propriétés spécifiques à l’action>	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 contrôles de 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 mise en cache, l’action de fonction é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.

Example

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": {}
}

Required

Property	Value	Type	Description
method	< type de méthode>	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.

Optional

Property	Value	Type	Description
headers	< en-tête-contenu>	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
< autres propriétés spécifiques à l’action>	< property-value>	Objet JSON	Toutes autres propriétés qui s’appliquent à cette action spécifique

Example

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

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": {}
}

Required

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

Example

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 champs ou des jetons conviviaux à partir des propriétés du 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": {}
},

Required

Value	Type	Description
< SOURCE JSON>	Objet JSON	Contenu JSON que vous souhaitez analyser
< Schéma JSON>	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.

Example

Cette définition d’action crée ces jetons que vous pouvez utiliser dans votre workflow, mais uniquement dans les actions qui s’exécutent en suivant l’action JSON d’analyse :

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": {}
}

Required

Value	Type	Description
< tableau>	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>	String	Condition utilisée pour le filtrage des éléments dans le tableau source Remarque : si aucune valeur ne satisfait la condition, l’action crée un tableau vide.

Example

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": {}
},

Required

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

Optional

Value	Type	Description
< response-headers>	Objet JSON	Un ou plusieurs en-têtes à inclure avec la réponse
< response-body>	Various	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

Example

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 Réponse a des restrictions spéciales :

• Votre flux de travail peut utiliser l’action Réponse uniquement lorsque le flux de travail commence par un déclencheur de requête HTTP, ce qui signifie que votre flux de travail doit être déclenché par une requête HTTP.

• Votre flux de travail peut utiliser l’action Réponse n’importe où , à l’exception des boucles Foreach , des boucles Until , y compris des boucles séquentielles et des branches parallèles.

• La requête d’origine obtient la réponse de votre flux de travail uniquement lorsque toutes les actions requises par l’action Réponse sont terminées dans la limite de délai d’expiration 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.

• Lorsque votre flux de travail utilise l’action Réponse et un modèle de réponse synchrone, le flux de travail ne peut pas également 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 flux de travail utilise la commande splitOn et une action Réponse , le flux de travail s’exécute de manière asynchrone et retourne immédiatement une réponse « 202 ACCEPTÉ ».

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

Sélectionner une action

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": {}
},

Required

Value	Type	Description
< tableau>	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.
< nom de clé>	String	Nom de propriété affecté au résultat de <> Pour ajouter une nouvelle propriété à tous les objets du tableau de sortie, fournissez un <nom> clé pour cette propriété et une <expression> pour la valeur de propriété. Pour supprimer une propriété de tous les objets du tableau, omettez le nom <de clé> de cette propriété.
< expression>	String	Expression qui transforme l’élément dans le tableau source et affecte le résultat au <nom de clé>

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

Example

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 cette sortie de tableau dans d’autres actions, transmettez cette sortie dans une action Compose :

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

Vous pouvez ensuite utiliser la sortie de l’action Composer dans vos autres actions, par exemple, Office 365 Outlook - Envoyer une action de messagerie :

"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 de 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": {}
}

Required

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

Optional

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.

Value	Type	Description
< nom de colonne>	String	Nom d’en-tête pour une colonne
< column-value>	Any	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	Apples
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	Pommes biologiques
1	Oranges biologiques

Terminer l’action

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é. Par exemple, vous pouvez utiliser l’action Terminer lorsque votre application logique doit quitter complètement un état d’erreur. Cette action n’affecte pas les actions déjà terminées et ne peut pas apparaître dans les 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": {}
}

Required

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

Optional

Les propriétés de l’objet « runError » s’appliquent uniquement lorsque la propriété « runStatus » a la valeur « Échec ».

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

Example

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 d’attente

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": {}
},

Required

Value	Type	Description
< nombre d’unités>	Integer	Pour l’action Delay , le nombre d’unités à attendre
< intervalle>	String	Pour l’action Delay , l’intervalle à attendre : « Second », « Minute », « Heure », « Jour », « Semaine », « Mois »
< horodatage>	String	Pour l’action Delay Until , date et 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 de flux de travail

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 les actions qui suivent l’application logique imbriquée, à condition que l’application logique enfant retourne une réponse.

Azure Logic Apps vérifie l’accès au déclencheur que vous souhaitez appeler. Par conséquent, vérifiez que vous pouvez accéder à ce déclencheur. En outre, l’application logique imbriquée doit répondre aux critères suivants :

• Un déclencheur rend l’application logique imbriquée appelante, telle qu’une requête ou un déclencheur 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 Réponse

"<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": {}
}

Required

Value	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
< ID d’abonnement Azure>	String	ID d’abonnement Azure pour l’application logique imbriquée
< Groupe de ressources Azure>	String	Nom du groupe de ressources Azure pour l’application logique imbriquée

Optional

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

Outputs

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.

Example

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

Required

Value	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é

Optional

Value	Type	Description
< compter>	Integer	Par défaut, les itérations de boucle « for each » s’exécutent simultanément (simultanément ou en parallèle) jusqu’à la limite par défaut. Pour modifier cette limite en définissant une nouvelle < valeur de nombre>, consultez Modifier la concurrence de boucle « for each ».
< operation-option>	String	Pour exécuter une boucle « for each » séquentiellement, plutôt que parallèlement, définissez <> d’opération sur ou Sequential<>sur 1 , mais pas les deux. Pour plus d’informations, consultez Exécuter des boucles « for each » séquentiellement.

Example

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 transmis en tant que sortie du déclencheur, cette expression obtient le <tableau de noms> de tableau à 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>']

Si l’action

Cette action, qui est une instruction conditionnelle, évalue une expression qui représente une condition et exécute une branche différente en fonction de la valeur 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": {}
}

Value	Type	Description
< condition>	Objet JSON	Condition, qui peut être une expression, à évaluer
< action-1>	Objet JSON	Action à exécuter lorsque <la condition> prend la valeur true
< action-définition>	Objet JSON	Définition de l’action
< action-2>	Objet JSON	Action à exécuter lorsque <la condition> prend 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

Example

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	Result
« 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 lorsque la sortie de <l’action> est supérieure à la < valeur de seuil>.
« 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 lorsque la sortie de <l’action> est supérieure à la < valeur seuil> 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 d’étendue

Cette action regroupe logiquement les actions en étendues, qui obtiennent leur propre état une fois que les actions de cette étendue se terminent en cours d’exécution. 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": {}
      }
   }
}

Required

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

Changer d’action

Cette action, également appelée instruction switch, organise d’autres actions dans des cas et affecte une valeur à chaque cas, à l’exception du cas par défaut s’il en existe un. Lorsque votre flux de travail 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 trouve un cas correspondant, votre flux de travail exécute uniquement les actions pour ce cas. Chaque fois que l’action Switch s’exécute, il n’existe qu’un seul cas correspondant ou aucune correspondance n’existe. 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": {}
}

Required

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

Optional

Value	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

Example

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 de la casse correspondante, qui consiste à envoyer un autre e-mail au répondeur, mais avec une formulation différente 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"
      ]
   }
}

Jusqu’à l’action

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": {}
}

Value	Type	Description
< action-name>	String	Nom de l’action que vous souhaitez exécuter à l’intérieur de la boucle
< type d’action>	String	Type d’action à exécuter
< entrées d’action>	Various	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
< nombre de boucles>	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.
< délai d’expiration de boucle>	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.

Note

Si l’expression dépend de la sortie d’une action dans la boucle Until, veillez à prendre en compte les échecs résultant de cette action.

Example

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 déclencheurs et actions 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.

Property	Type	Description	Déclencheur ou action
runtimeConfiguration.concurrency.runs	Integer	Modifiez la limite par défaut du nombre d’instances de flux de travail 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 runs à la propriété 1 fonctionne de la même façon que l’affectation de la valeur operationOptions à la propriété SingleInstance. 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 flux de travail qui doivent attendre l’exécution lorsque votre application logique exécute déjà les instances simultanées maximales. 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 simultanément (simultanément ou en parallèle). L’affectation de la valeur repetitions à la propriété 1 fonctionne de la même façon que l’affectation de la valeur operationOptions à la propriété SingleInstance. 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 les actions spécifiques qui prennent en charge et dont la pagination 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 : Variée
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 : Variée

Options d’opération

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: ApiConnection, HTTP, Response
IncludeAuthorizationHeadersInOutputs	String	Pour les applications logiques qui activent OAuth avec Microsoft Entra ID pour autoriser l’accès aux appels entrants vers un point de terminaison d’un déclencheur basé sur une requête, incluez l’en-tête Authorization 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.	Triggers: Request, HTTP Webhook
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 runtimeConfiguration.concurrency.repetitions à la propriété 1. 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 runtimeConfiguration.concurrency.runs à la propriété 1. 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	String	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 x-ms- dans le nom d’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, Function, APIManagement
SuppressWorkflowHeadersOnResponse	String	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 x-ms- dans le nom d’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.	Triggers: Request, HTTP Webhook

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 en cours d’exécution simultanée 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 changer cette limite du nombre d’exécutions simultanées par défaut, vous pouvez utiliser l’éditeur en mode code ou le concepteur de flux de travail, car la modification du paramètre de simultanéité par le biais du concepteur ajoute ou met à jour la propriété runtimeConfiguration.concurrency.runs 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 l’accès concurrentiel est activé, le fractionnement sur la limite est considérablement réduit pour les tableaux de débat. Si le nombre d’éléments dépasse cette limite, la fonctionnalité Fractionner 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 en cours d’exécution, par exemple :

       

       Tip

       Pour afficher uniquement les instances en cours d’exécution, ouvrez la liste Toutes , 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. Dans le coin supérieur droit de l’action, sélectionnez le bouton de sélection (...), puis sélectionnez Paramètres.

       

    2. Sous Délai d’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.

Modifiez le concepteur de flux de travail

1. Dans le coin supérieur droit du déclencheur, sélectionnez le bouton de sélection (...), puis sélectionnez Paramètres.

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

3. Positionnez le curseur Degré de parallélisme sur la valeur souhaitée. Pour exécuter votre application logique de manière séquentielle, faites glisser la valeur du curseur sur 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 en cours d’exécution simultanées 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 changer la limite par défaut, vous pouvez utiliser l’éditeur en mode code ou le concepteur de flux de travail, car la modification du paramètre de concurrence par le biais du concepteur ajoute ou met à jour la propriété runtimeConfiguration.concurrency.repetitions dans la définition d’action « for each » sous-jacente et vice versa. Cette propriété contrôle le nombre maximal d’itérations qui peuvent s’exécuter en parallèle.

Note

Si vous configurez l’action « for each » pour une exécution séquentielle à l’aide du concepteur ou de l’éditeur en mode code, n’affectez pas la valeur operationOptions à la propriété Sequential de l’action dans l’éditeur en mode code, car vous obtiendriez une erreur de validation. Pour plus d’informations, consultez Exécuter des boucles « for each » séquentiellement.

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.

Modifiez le concepteur de flux de travail

1. Dans l’action Pour chaque action, dans le coin supérieur droit, sélectionnez le bouton de sélection (...), puis sélectionnez Paramètres.

2. Sous Contrôle d’accès concurrentiel, définissez Le 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 de manière séquentielle, faites glisser la valeur du curseur sur 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, toute nouvelle instance de flux de travail doit attendre pour s’exécuter. 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êtes et de webhook retournent des erreurs 429 – Trop de requêtes , et les déclencheurs récurrents commencent à ignorer les tentatives d’interrogation.

Vous pouvez modifier la limite par défaut du nombre d’exécutions simultanées du déclencheur, ainsi que la limite par défaut des exécutions en attente. Toutefois, cette modification 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’interroger 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 d’appel.

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 en mode code ou le concepteur de flux de travail, car la modification du paramètre de simultanéité par le biais du concepteur ajoute ou met également à jour la propriété runtimeConfiguration.concurrency.runs dans la définition de déclencheur sous-jacente et vice versa.

Note

Quand vous configurez un déclencheur pour une exécution séquentielle à l’aide du concepteur ou de l’éditeur en mode code, n’affectez pas la valeur operationOptions à la propriété Sequential du déclencheur dans l’éditeur en mode code, car vous obtiendriez une erreur de validation.

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 runtimeConfiguration.concurrency.runs à la propriété 1 :

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

-or-

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

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

Modifiez le concepteur de flux de travail

1. Dans le coin supérieur droit du déclencheur, sélectionnez le bouton de sélection (...), puis sélectionnez Paramètres.

2. Sous Contrôle d’accès concurrentiel, définissez La limitesur 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 en mode code ou le concepteur de flux de travail, car la modification de la simultanéité de l’action par le biais du concepteur ajoute ou met également à jour la propriété runtimeConfiguration.concurrency.repetitions dans la définition d’action sous-jacente et vice versa.

Note

Quand vous configurez une action « for each » pour une exécution séquentielle à l’aide du concepteur ou de l’éditeur en mode code, n’affectez pas la valeur operationOptions à la propriété Sequential de l’action dans l’éditeur en mode code, car vous obtiendriez une erreur de validation.

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 runtimeConfiguration.concurrency.repetitions à la propriété 1 :

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

-or-

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

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

Modifiez le concepteur de flux de travail

1. Dans le coin supérieur droit de chaque action, sélectionnez le bouton de sélection (...), puis sélectionnez Paramètres.

2. Sous Contrôle d’accès concurrentiel, définissez Le 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’après un appel d’action ou envoie une requête au point de terminaison, au service, au système ou à l’API spécifiés, le récepteur retourne immédiatement une réponse « 202 ACCEPTÉ ». Ce code confirme que le récepteur a accepté la requête, mais qu’il n’a pas fini le traitement. La réponse peut inclure un location en-tête qui spécifie l’URL et un ID d’actualisation que l’appelant peut utiliser pour interroger ou vérifier continuellement l’état de la demande asynchrone jusqu’à ce que le récepteur arrête le traitement et retourne une réponse de réussite « 200 OK » ou une autre réponse non-202. Pour plus d’informations, consultez L’intégration asynchrone des microservices permet l’autonomie des microservices.

• Dans le Concepteur d’applications logiques, l’action HTTP, les actions APIConnection et l’action Réponse 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 ouvre les paramètres de l’action.

  2. Recherchez le paramètre De 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 de 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 ouvre les paramètres de l’action.

2. Recherchez le paramètre De modèle asynchrone , désactivez le paramètre si 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 et définissez la propriété "DisableAsyncPattern" sous la section de "inputs" 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