Guida di riferimento allo schema per il linguaggio di definizione del flusso di lavoro in App per la logica di Azure

Quando si crea un'app per la logica in App per la logica di Azure, l'app per la logica ha una definizione del flusso di lavoro sottostante che descrive la logica effettiva eseguita nell'app per la logica. That workflow definition uses JSON and follows a structure that's validated by the Workflow Definition Language schema. Questo riferimento fornisce una panoramica di questa struttura e del modo in cui lo schema definisce gli attributi nella definizione del flusso di lavoro.

Struttura della definizione del flusso di lavoro

Una definizione del flusso di lavoro include sempre un trigger per creare un'istanza dell'app per la logica, oltre a una o più azioni eseguite dopo l'attivazione del trigger.

Di seguito è riportata la struttura generale di una definizione del flusso di lavoro:

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

Trigger e azioni

In una definizione del flusso di lavoro, le sezioni triggers e actions definiscono le chiamate che si verificano durante l'esecuzione del flusso di lavoro. Per la sintassi e altre informazioni su queste sezioni, vedere Trigger e azioni del flusso di lavoro.

Parameters

Il ciclo di vita della distribuzione ha in genere ambienti diversi per lo sviluppo, il test, la gestione temporanea e la produzione. Quando si distribuiscono app per la logica in vari ambienti, è probabile che si vogliano usare valori diversi, ad esempio stringa di connessione, in base alle esigenze di distribuzione. In alternativa, è possibile avere valori che si desidera riutilizzare in tutta l'app per la logica senza hardcoding o che cambiano spesso. Nella sezione della definizione del flusso di parameters lavoro è possibile definire o modificare i parametri per i valori usati dall'app per la logica in fase di esecuzione. È necessario definire questi parametri prima di poter fare riferimento a questi parametri altrove nella definizione del flusso di lavoro.

Di seguito è riportata la struttura generale della definizione di un parametro:

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

Creare quindi un modello di Azure Resource Manager per la definizione del flusso di lavoro, definire i parametri del modello che accettano i valori da distribuire, sostituire i valori hardcoded con riferimenti ai parametri di definizione del modello o del flusso di lavoro in base alle esigenze e archiviare i valori da usare nella distribuzione in un file di parametri separato. In questo modo, è possibile modificare questi valori più facilmente tramite il file di parametri senza dover aggiornare e ridistribuire l'app per la logica. Per informazioni sensibili o che devono essere protette, ad esempio nomi utente, password e segreti, è possibile archiviare tali valori in Azure Key Vault e recuperare tali valori dall'insieme di credenziali delle chiavi. Per altre informazioni ed esempi sulla definizione dei parametri a livello di modello e definizione del flusso di lavoro, vedere Panoramica: Automatizzare la distribuzione per le app per la logica con i modelli di Azure Resource Manager.

Static results

Nell'attributo staticResults definire la simulazione outputs di un'azione e status che l'azione restituisce quando l'impostazione del risultato statico dell'azione è attivata. Nella definizione dell'azione, l'attributo runtimeConfiguration.staticResult.name fa riferimento al nome per la definizione del risultato statico all'interno staticResultsdi . Informazioni su come testare i flussi di lavoro delle app per la logica con dati fittizi configurando i risultati statici.

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

In questa definizione di azione HTTP, ad esempio, l'attributo runtimeConfiguration.staticResult.name fa HTTP0 riferimento all'interno dell'attributo staticResults in cui vengono definiti gli output fittizi per l'azione. L'attributo runtimeConfiguration.staticResult.staticResultOptions specifica che l'impostazione del risultato statico si trova Enabled nell'azione HTTP.

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

L'azione HTTP restituisce gli output nella HTTP0 definizione all'interno staticResultsdi . In questo esempio, per il codice di stato, l'output fittizio è OK. Per i valori di intestazione, l'output fittizio è "Content-Type": "application/JSON". Per lo stato dell'azione, l'output fittizio è Succeeded.

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

Expressions

Con JSON è possibile avere valori letterali già esistenti in fase di progettazione, ad esempio:

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

È anche possibile avere valori che non esistono fino all'esecuzione. To represent these values, you can use expressions, which are evaluated at run time. An expression is a sequence that can contain one or more functions, operators, variables, explicit values, or constants. Nella definizione del flusso di lavoro è possibile usare un'espressione in qualsiasi punto di un valore stringa JSON aggiungendo all'espressione il prefisso @. Quando si valuta un'espressione che rappresenta un valore JSON, il corpo dell'espressione viene estratto rimuovendo il carattere @ e si ottiene sempre un altro valore JSON.

For example, for the previously defined customerName property, you can get the property value by using the parameters() function in an expression and assign that value to the accountName property:

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

String interpolation also lets you use multiple expressions inside strings that are wrapped by the @ character and curly braces ({}). La sintassi è la seguente:

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

Il risultato è sempre una stringa, rendendo questa funzionalità simile alla funzione concat(), ad esempio:

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

In presenza di una stringa letterale che inizia con il carattere @, prefissare il carattere @ con un altro carattere @ come carattere di escape: @@

Questi esempi mostrano come vengono valutate le espressioni:

Per questi esempi si supponga di definire "myBirthMonth" uguale a "January" e "myAge" uguale al numero 42:

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

Questi esempi mostrano come vengono valutate le espressioni seguenti:

Quando si lavora visivamente nella finestra di progettazione del flusso di lavoro, è possibile creare espressioni usando l'editor di espressioni, ad esempio:

Al termine viene visualizzata l'espressione per la proprietà corrispondente nella definizione del flusso di lavoro, ad esempio la proprietà searchQuery:

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

Outputs

Nella sezione outputs definire i dati che il flusso di lavoro può restituire al termine dell'esecuzione. Ad esempio, per tenere traccia di uno stato o di un valore specifico per ogni esecuzione, specificare che l'output del flusso di lavoro restituisca tali dati.

Di seguito è riportata la struttura generale della definizione di un output:

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

Per ottenere l'output da un'esecuzione del flusso di lavoro, esaminare la cronologia di esecuzione dell'app per la logica e i dettagli nella portale di Azure o usare l'API REST del flusso di lavoro. È anche possibile passare l'output a sistemi esterni, ad esempio Power BI, per creare dashboard.

Operators

In expressions and functions, operators perform specific tasks, such as reference a property or a value in an array.

Functions

Alcune espressioni ottengono i valori dalle azioni di runtime che potrebbero non esistere ancora quando la definizione del flusso di lavoro inizia a essere eseguita. To reference or work with these values in expressions, you can use functions that the Workflow Definition Language provides.

Related content

• Azioni e trigger del linguaggio di definizione del flusso di lavoro
• API REST del flusso di lavoro