Décrire un workflow Logic Apps à l’aide du langage de définition de workflow
Vous définissez la structure et le workflow d’un workflow Azure Logic Apps avec un document JSON. Ce document contient une description JSON des éléments qui composent le workflow d’application logique, et le schéma de langage de définition de workflow le valide. Le moyen le plus simple d’expliquer le schéma est d’examiner un workflow existant créé à l’aide du concepteur de workflows dans le portail Azure, puis de visualiser la description JSON de cette application logique.
Dans l’exemple de scénario, vous souhaitez fournir à vos consultants des workflows courants qu’ils pourront adapter aux besoins spécifiques des universités avec lesquelles ils travaillent. Comme vous souhaitez rendre aussi simples que possible la personnalisation et le déploiement de chaque workflow, vous décidez d’examiner le code sous-jacent du workflow, à savoir le code JSON qui le définit.
Concepteur de workflow
Le concepteur de workflows vous permet de créer et de déboguer le workflow graphiquement dans le cas d’un workflow d’application logique. Le concepteur permet également aux développeurs d’examiner un workflow en profondeur afin de voir comment il est implémenté. L’image suivante montre un exemple de workflow simple, qui est déclenché par l’envoi d’une requête HTTP GET à une URL spécifiée. Le résultat est retourné dans la réponse HTTP. Dans cet exemple, le workflow renvoie un simple message Hello Logic Apps Template!.
À présent, intéressons-nous au langage de définition de workflow utilisé par le modèle JSON.
Mode code
La fenêtre Affichage du code montre le document JSON qui décrit le workflow. Dans l’exemple d’application, le JSON ressemble à ceci :
{
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
"Response": {
"inputs": {
"body": "Hello Azure Logic Apps Template!",
"statusCode": 200
},
"kind": "Http",
"runAfter": {},
"type": "Response"
}
},
"contentVersion": "1.0.0.0",
"outputs": {},
"parameters": {},
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"schema": {}
},
"kind": "Http",
"type": "Request"
}
}
}
}
Observez les sections dans l’étendue definition qui concernent les actions et déclencheurs indiqués dans le Concepteur. Vous pouvez modifier le code JSON de ce document afin de refléter les éventuelles modifications à apporter dans les fonctionnalités du workflow d’application logique. Vous pouvez également ajouter d’autres actions et préciser comment la logique du workflow fonctionne d’une action à l’autre.
Section Déclencheurs
La section triggers contient la description du type de déclencheur et indique comment il peut être appelé. Dans cet exemple, le déclencheur est un déclencheur HTTP simple qui s’exécute en réponse à une requête HTTP GET.
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"schema": {}
},
"kind": "Http",
"type": "Request"
}
}
Un déclencheur doit inclure les éléments suivants :
Un nom unique à l’intérieur du workflow. Dans l’exemple précédent, le nom par défaut du déclencheur est manuel, mais vous pouvez remplacer le nom par défaut par un identificateur plus significatif.
Le type de déclencheur. Le type indique l’événement qui entraîne l’exécution du déclencheur. Un déclencheur Request s’exécute en réponse à une requête HTTP. Les autres types de déclencheurs disponibles sont les suivants :
Recurrence, pour créer un déclencheur qui s’exécute selon une planification périodique.
HttpWebhook, pour écouter des événements sur un point de terminaison.
ApiConnection, pour répondre aux événements déclenchés par d’autres services Azure, par exemple, un message arrivant sur une file d’attente, un e-mail, etc. Le type de déclencheur ApiConnection est généralisé ; vous spécifiez des informations supplémentaires indiquant le type du service et les informations de connexion requises.
La section inputs. Cette section spécifie les données qui définissent le comportement du déclencheur. Dans le cas d’un déclencheur Request, method indique le type de requête HTTP qui entraîne l’exécution du déclencheur. Dans le cas d’un déclencheur ApiConnection, la section inputs contient des informations indiquant comment se connecter à la ressource qui déclenche l’événement (une chaîne de connexion de message de file d’attente, par exemple). Si le déclencheur est un déclencheur Request, la section schema de la définition d’entrée spécifie le schéma auquel doit se conformer la charge utile du corps de la demande. Les requêtes HTTP GET n’ayant pas de corps de demande, la section schema est vide dans l’exemple précédent.
L’exemple suivant illustre la définition d’un autre déclencheur Request qui démarre un workflow et reçoit des requêtes HTTP POST. Une requête POST fournit généralement un corps de demande contenant les données à publier. Le corps de la demande dans cet exemple contient un nom de client et une adresse, comprenant la rue et la ville.
"mypostrequest": {
"type": "Request",
"kind": "Http",
"inputs": {
"method": "POST",
"schema": {
"type": "object",
"properties": {
"customerName": {
"type": "String"
},
"customerAddress": {
"type": "Object",
"properties": {
"streetAddress": {
"type": "string"
},
"city": {
"type": "string"
}
}
}
}
}
}
}
Un déclencheur peut également spécifier des conditions. Le déclencheur se déclenche uniquement si ces conditions sont remplies. Vous définissez les conditions dans une section conditions facultative. Par exemple, vous souhaiterez peut-être exécuter le déclencheur mypostrequest (illustré dans l’exemple précédent) uniquement si le corps de la demande spécifie une ville nommée New York :
"mypostrequest": {
"type": "Request",
"kind": "Http",
"inputs": {
...
}
"conditions": [
{
"expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], 'New York')"
}
]
}
Section Actions
La section actions d’une application logique définit la logique et la structure du workflow. Elle contient une série d’éléments d’action. Un élément d’action est une composante fondamentale de la construction des workflows. Les éléments d’action prennent des entrées et produisent des sorties, qui sont passées à l’élément d’action suivant dans le workflow. Le tableau suivant répertorie différents types d’actions disponibles :
| Élément d’action | Description |
|---|---|
| ApiConnection | Envoie une requête HTTP à un service spécifique. Ce type d’action vous permet d’intégrer un workflow d’application logique aux fonctionnalités Azure, telles qu’Azure Service Bus, Azure Event Grid, etc. L’action nécessite des entrées qui incluent une chaîne de connexion pour l’accès au service ainsi que les informations et paramètres supplémentaires nécessaires pour appeler le service. |
| Composer. | Combine plusieurs entrées et expressions dans une seule sortie. |
| Fonction | Vous permet d’appeler une fonction Azure. |
| HTTP | Envoie une requête HTTP à un point de terminaison HTTP, plutôt qu’à un service Azure. |
| Join | Prend un tableau d’éléments de données comme entrée et génère une chaîne contenant ces éléments séparés par un délimiteur spécifié. |
| Analyser. | Analyse un document JSON en un ensemble de jetons, en utilisant un schéma spécifié. |
| Requête | Filtre les éléments dans un tableau d’entrée en utilisant une condition spécifiée. |
| Réponse | Crée une réponse pour une requête HTTP. |
| Table | Génère un tableau HTML à partir d’un tableau d’objets JSON. |
| Terminer. | Annule immédiatement un workflow. |
| Attendre. | Interrompt le workflow pendant un intervalle spécifié ou jusqu’à ce qu’un dépassement du délai d’expiration se produise. |
| Workflow | Exécute un autre workflow d’application logique. |
| Condition | Un ensemble de types d’action (Foreach, If, Switch et Until) qui vous permettent d’implémenter un flux programmatique de contrôle dans un workflow. Vous pouvez parcourir les éléments d’une collection, prendre des décisions basées sur les valeurs des paramètres d’entrée et boucler jusqu’à ce qu’une condition soit remplie. |
| InitializeVariable, IncrementVariable, DecrementVariable |
Définit, initialise, assigne et modifie des variables que vous pouvez passer entre les éléments d’action dans un workflow. |
À l’image d’un déclencheur, chaque action doit avoir un nom unique dans le workflow. Dans l’exemple suivant, le nom d’action par défaut est Response, mais vous pouvez utiliser un identificateur valide et plus significatif. Une action doit avoir une section inputs qui spécifie les données sur lesquelles l’action travaille. Dans l’action Response, vous pouvez spécifier les données pour une expression à retourner dans le message de réponse ainsi qu’un code d’état HTTP.
Dans notre définition de workflow de base, l’action génère une réponse HTTP dont le corps est un message court.
"actions": {
"Response": {
"inputs": {
"body": "Hello Azure Logic Apps Template!",
"statusCode": 200
},
"kind": "Http",
"runAfter": {},
"type": "Response"
}
}
La section runAfter indique où l’action s’exécute dans la séquence du workflow. Dans l’exemple précédent, comme il n’y a qu’une seule action, elle est toujours exécutée quand le déclencheur est activé. Si le workflow avait plusieurs actions, vous pourriez spécifier le nom d’une action et un état pour celle-ci dans cette section. L’action s’exécute si l’action runAfter se termine avec l’état spécifié. Le code ci-après présente un exemple. L’action mySecondAction s’exécute après myFirstAction, mais uniquement si myFirstAction se termine avec l’état « Succeeded » :
"actions": {
"mySecondAction": {
"inputs": {
...
},
"runAfter": {
"myFirstAction": [
"Succeeded"
]
},
"type": ...
},
"myFirstAction": {
"inputs": {
...
},
"runAfter": {},
"type": ...
}
}
Section Sorties
Utilisez la section outputs pour définir les données que votre workflow peut retourner quand son exécution prend fin. Vous pouvez suivre un état ou des données spécifiques pour chaque exécution du workflow. Vous pouvez examiner la sortie de chaque exécution d’un workflow à l’aide de l’historique des exécutions d’Azure Logic Apps, disponible dans le portail Azure ou l’API REST Workflow.
Le format de la section outputs ressemble à ceci :
"outputs": {
"<key-name>": {
"type": "<key-type>",
"value": "<key-value>"
}
}
Expressions de workflow
Vous pouvez utiliser une expression de workflow à la place de toute constante, variable ou valeur fixe. Vous pouvez également placer une expression n’importe où dans une valeur de chaîne JSON en faisant précéder l’expression d’une arobase (@). Par exemple, vous pouvez utiliser la fonction @parameters dans une expression pour récupérer la valeur d’un paramètre nommé (les paramètres sont décrits dans la section suivante).
"customerFullName": "Bill Frost",
"accountName": "@parameters('customerName')"
Azure Logic Apps fournit des fonctions intégrées que vous pouvez utiliser pour créer des expressions complexes :
- Fonctions de chaîne : Pour concaténer ou fractionner des chaînes, convertir des caractères en majuscules ou minuscules et rechercher des sous-chaînes.
- Fonctions de collection : Pour détecter si une collection contient des éléments qui correspondent à un modèle spécifique, extraire des éléments d’une collection et combiner des collections.
- Fonctions de comparaison logique : Pour détecter si les opérandes sont égaux, différents, numériquement supérieurs ou inférieurs l’un à l’autre.
- Fonctions de conversion : Pour changer le type ou le format de données.
- Fonctions mathématiques : Par exemple, add, sub, div et mul.
- Fonctions de date et d’heure : Pour analyser et traiter les dates et les heures.
- Fonctions de workflow : Pour récupérer des informations sur les données transmises à une action de workflow. Par exemple, la fonction parameter (illustrée précédemment) extrait la valeur d’un paramètre nommé, tandis que la fonction body (illustrée précédemment) retourne les données générées par une action.
- Fonctions de manipulation JSON et XML : Pour analyser et traiter les documents JSON et XML.
Vous pouvez définir des variables dans la section inputs d’une action InitializeVariable et vous pouvez manipuler ces variables à l’aide d’expressions. Lisez la valeur d’une variable à l’aide de la fonction variables. L’exemple suivant utilise une action InitializeVariable pour créer une variable de type entier nommée myIntegerVariable et l’initialiser à 99. Cet exemple montre également une action Condition avec le type If. La condition utilise une expression pour tester la valeur de la variable myIntegerVariable ; si cette dernière est égale à 100, la condition utilise une action HTTP pour effectuer une requête GET.
"actions": {
"Condition": {
"actions": {
"HTTP": {
"inputs": {
"method": "GET",
"uri": "http://dummyurl.com"
},
"runAfter": {},
"type": "Http"
}
},
"expression": {
"equals": [
"@variables('myIntegerVariable')",
100
]
} ,
"runAfter": {
"Initialize": [
"Succeeded"
]
},
"type": "If"
},
"Initialize": {
"inputs": {
"variables": [
{
"name": "myIntegerVariable",
"type": "Integer",
"value": 99
}
]
},
"runAfter": {},
"type": "InitializeVariable"
}
}
Section Paramètres
La section parameters vous permet de paramétrer un workflow. Au moment de l’exécution, vous pouvez fournir des valeurs pour chacun de ces paramètres. Vous pouvez référencer les paramètres dans le workflow là où vous êtes susceptible d’utiliser une constante ou une expression.
Vous pouvez ajouter une définition de paramètres avec une valeur par défaut. La valeur par défaut est utilisée si vous ne fournissez pas de valeur pour le paramètre au moment de l’exécution. L’exemple suivant montre comment définir un paramètre nommé cityParam. Le paramètre est utilisé à l’intérieur de la condition pour l’action mypostrequest. L’action est effectuée uniquement si le document de la requête contient une ville qui correspond à la valeur du paramètre. La valeur de paramètre par défaut est New York :
"definition": {
"$schema": "https://schema.management.azure.com/providers/Microsoft.Logic/schemas/2016-06-01/workflowdefinition.json#",
"actions": {
...
},
"contentVersion": "1.0.0.0",
"outputs": {},
"parameters": {
"cityParam": {
"defaultValue": "New York",
"type": "String"
}
},
"triggers": {
"mypostrequest": {
"conditions": [
{
"expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], parameters('cityParam'))"
}
],
"inputs": {
...
},
"kind": "Http",
"type": "Request"
}
}
}
}