Guide de référence du schéma du langage de définition de workflow dans Azure Logic Apps

Quand vous créez une application logique dans Azure Logic Apps, elle dispose d’une définition de flux de travail sous-jacente qui décrit la logique réelle qui s’exécute dans votre application logique. Cette définition de flux de travail utilise JSON et suit une structure validée par le schéma de langage de définition de flux de travail. Cette référence fournit une vue d’ensemble de cette structure et de la façon dont le schéma définit les attributs dans votre définition de flux de travail.

Structure d’une définition de flux de travail

Une définition de flux de travail inclut toujours un déclencheur afin d’instancier votre application logique, ainsi qu’une ou plusieurs actions qui s’exécutent après le déclencheur.

Voici la structure de haut niveau d’une définition de flux de travail :

"definition": {
  "$schema": "<workflow-definition-language-schema-version>",
  "actions": { "<workflow-action-definitions>" },
  "contentVersion": "<workflow-definition-version-number>",
  "outputs": { "<workflow-output-definitions>" },
  "parameters": { "<workflow-parameter-definitions>" },
  "staticResults": { "<static-results-definitions>" },
  "triggers": { "<workflow-trigger-definitions>" }
}

Déclencheurs et actions

Dans une définition de flux de travail, les sections triggers et actions définissent les appels qui se produisent pendant l’exécution de votre flux de travail. Pour obtenir des informations supplémentaires sur ces sections et connaître la syntaxe à utiliser, consultez Déclencheurs et actions du flux de travail.

Paramètres

Le cycle de vie du déploiement a généralement des environnements différents pour le développement, le test, la mise en lots et la production. Lorsque vous déployez des applications logiques dans différents environnements, vous souhaiterez probablement utiliser des valeurs différentes, telles que des chaînes de connexion, en fonction de vos besoins en matière de déploiement. Ou bien, vous pouvez avoir des valeurs que vous souhaitez réutiliser dans votre application logique sans codage en dur ou codes qui changent souvent. Dans la section parameters de votre définition de flux de travail, vous pouvez définir ou modifier des paramètres pour les valeurs que votre application logique utilise au moment de l’exécution. Vous devez d’abord définir ces paramètres avant de pouvoir référencer ces paramètres ailleurs dans votre définition de flux de travail.

Voici la structure générale d’une définition de paramètre :

"parameters": {
   "<parameter-name>": {
      "type": "<parameter-type>",
      "defaultValue": <default-parameter-value>,
      "allowedValues": [ <array-with-permitted-parameter-values> ],
      "metadata": {
         "description": "<parameter-description>"
      }
   }
},

Ensuite, créez un modèle Azure Resource Manager pour votre définition de flux de travail, définissez les paramètres de modèle qui acceptent les valeurs que vous souhaitez au moment du déploiement, remplacez les valeurs codées en dur par des références au modèle ou à la définition du flux de travail et stockez les valeurs à utiliser au moment du déploiement dans un fichier de paramètres distinct. De cette façon, vous pouvez modifier ces valeurs plus facilement par le biais du fichier de paramètres sans avoir à mettre à jour et à redéployer votre application logique. Pour les informations sensibles ou qui doivent être sécurisées, telles que des mots de passe et des secrets, vous pouvez les stocker dans Azure Key Vault et faire en sorte que votre fichier de paramètres récupère ces valeurs de votre coffre de clés. Pour plus d’informations et des exemples sur la définition des paramètres au niveau du modèle et de la définition du flux de travail, consultez Vue d’ensemble : Automatiser le déploiement pour les applications logiques avec des modèles Azure Resource Manager.

Résultats statiques

Dans l’attribut staticResults, définissez une sortie outputs et status fictives que l’action renvoie lorsque le paramètre de résultat statique de l’action est activé. Dans la définition de l’action, l’attribut runtimeConfiguration.staticResult.name fait référence au nom de la définition de résultat statique dans staticResults. Découvrez comment tester des flux de travail d’application logique avec des données fictives en configurant des résultats statiques.

"definition": {
   "$schema": "<...>",
   "actions": { "<...>" },
   "contentVersion": "<...>",
   "outputs": { "<...>" },
   "parameters": { "<...>" },
   "staticResults": {
      "<static-result-definition-name>": {
         "outputs": {
            <output-attributes-and-values-returned>,
            "headers": { <header-values> },
            "statusCode": "<status-code-returned>"
         },
         "status": "<action-status>"
      }
   },
   "triggers": { "<...>" }
}

Par exemple, dans la définition de l’action HTTP, l’attribut runtimeConfiguration.staticResult.name fait référence à HTTP0 dans l’attribut staticResults, où les sorties fictives de l’action sont définies. L’attribut runtimeConfiguration.staticResult.staticResultOptions spécifie le paramètre du résultat statique Enabled sur l’action HTTP.

"actions": {
   "HTTP": {
      "inputs": {
         "method": "GET",
         "uri": "https://www.microsoft.com"
      },
      "runAfter": {},
      "runtimeConfiguration": {
         "staticResult": {
            "name": "HTTP0",
            "staticResultOptions": "Enabled"
         }
      },
      "type": "Http"
   }
},

L’action HTTP retourne les sorties dans la définition HTTP0 dans staticResults. Dans cet exemple, pour le code d’état, la sortie fictive est OK. Pour les valeurs d’en-tête, la sortie fictive est "Content-Type": "application/JSON". Pour l’état de l’action, la sortie fictive est Succeeded.

"definition": {
   "$schema": "<...>",
   "actions": { "<...>" },
   "contentVersion": "<...>",
   "outputs": { "<...>" },
   "parameters": { "<...>" },
   "staticResults": {
      "HTTP0": {
         "outputs": {
            "headers": {
               "Content-Type": "application/JSON"
            },
            "statusCode": "OK"
         },
         "status": "Succeeded"
      }
   },
   "triggers": { "<...>" }
},

Expressions

Avec JSON, vous pouvez avoir des valeurs littérales qui existent au moment du design, par exemple :

"customerName": "Sophia Owen",
"rainbowColors": ["red", "orange", "yellow", "green", "blue", "indigo", "violet"],
"rainbowColorsCount": 7

Vous pouvez également avoir des valeurs qui n’existent pas avant l’exécution. Pour représenter ces valeurs, vous pouvez utiliser des expressions, qui sont évaluées au moment de l’exécution. Une expression est une séquence qui peut contenir un ou plusieurs opérateurs, fonctions, variables, valeurs explicites ou constantes. Dans votre définition de flux de travail, vous pouvez utiliser une expression n’importe où dans une valeur de chaîne JSON en faisant précéder l’expression d’une arobase (@). Quand une expression qui représente une valeur JSON est évaluée, le corps de l’expression est extrait en supprimant le caractère @, et une autre valeur JSON est systématiquement générée.

Par exemple, pour la propriété customerName définie précédemment, vous pouvez obtenir la valeur de la propriété en utilisant la fonction parameters() dans une expression de fonction et en assignant cette valeur à la propriété accountName :

"customerName": "Sophia Owen",
"accountName": "@parameters('customerName')"

L’interpolation de chaîne permet également d’utiliser plusieurs expressions placées entre le caractère @ et des accolades ({}) à l’intérieur d’une chaîne. Voici la syntaxe :

@{ "<expression1>", "<expression2>" }

Le résultat est toujours une chaîne, ce qui rend cette fonctionnalité similaire à la fonction concat(), par exemple :

"customerName": "First name: @{parameters('firstName')} Last name: @{parameters('lastName')}"

Si vous avez une chaîne littérale qui commence par le caractère @, faites précéder le caractère @ d’un autre caractère @ faisant office de caractère d’échappement : @@.

Ces exemples montrent comment les expressions sont évaluées :

Pour ces exemples, supposons que vous définissiez "January" pour "myBirthMonth" et le nombre 42 pour "myAge" :

"myBirthMonth": "January",
"myAge": 42

Ces exemples montrent comment les expressions suivantes sont évaluées :

Lorsque vous travaillez visuellement dans le concepteur de flux de travail, vous pouvez créer des expressions à l’aide de l’éditeur d’expressions, par exemple :

Quand vous avez terminé, l’expression apparaît pour la propriété correspondante dans votre définition de flux de travail, par exemple, la propriété searchQuery ici :

"Search_tweets": {
  "inputs": {
    "host": {
      "connection": {
        "name": "@parameters('$connections')['x']['connectionId']"
      }
    }
  },
  "method": "get",
  "path": "/searchtweets",
  "queries": {
    "maxResults": 20,
    "searchQuery": "Azure @{concat('firstName','', 'LastName')}"
  }
},

Outputs

Dans la section outputs, définissez les données que votre flux de travail peut renvoyer une fois son exécution terminée. Par exemple, pour suivre un état ou une valeur spécifique à chaque exécution, spécifiez le renvoi de cette donnée par la sortie du flux de travail.

Voici la structure générale d’une définition de sortie :

"outputs": {
  "<key-name>": {
    "type": "<key-type>",
    "value": "<key-value>"
  }
}

Pour obtenir la sortie d’une exécution de flux de travail, examinez l’historique et les détails des exécutions de votre application logique dans le portail Azure ou utilisez l’API REST de flux de travail. Vous pouvez également transmettre la sortie à des systèmes externes, par exemple Power BI, afin de créer des tableaux de bord.

Opérateurs

Dans les expressions et les fonctions, les opérateurs effectuent des tâches spécifiques, telles que référencer une propriété ou une valeur dans un tableau.

Functions

Certaines expressions obtiennent leurs valeurs à partir d’actions runtime qui peuvent ne pas encore exister au début de l’exécution de votre définition de flux de travail. Pour référencer ou utiliser ces valeurs dans des expressions, vous pouvez faire appel à des fonctions fournies par le Langage de définition de workflow.

Étapes suivantes

• En savoir plus sur les actions et déclencheurs du langage de définition de flux de travail
• En savoir plus sur la création et la gestion par programmation des applications logiques avec l’API REST de flux de travail