Descrivere un flusso di lavoro di App per la logica di Azure tramite il linguaggio di definizione del flusso di lavoro
Per definire la struttura e il flusso di lavoro per il flusso di lavoro di un'app per la logica di Azure si usa un documento JSON. Questo documento contiene una descrizione JSON degli elementi che costituiscono il flusso di lavoro dell'app per la logica e viene convalidato dallo schema del linguaggio di definizione del flusso di lavoro. Il modo più semplice per illustrare lo schema è quello di esaminare un flusso di lavoro esistente creato tramite la finestra di progettazione del flusso di lavoro nel portale di Azure, quindi visualizzare la descrizione JSON di questa app per la logica.
Nello scenario di esempio, si vogliono fornire ai consulenti flussi di lavoro comuni, che questi possono adattare alle esigenze specifiche delle università con cui collaborano. Le personalizzazione e la distribuzione di ogni flusso di lavoro devono essere il più semplici possibile, pertanto si decide di esaminare il codice sottostante al flusso di lavoro, ovvero il codice JSON di definizione del flusso.
Progettazione flusso di lavoro
La finestra di progettazione del flusso di lavoro consente di creare il flusso di lavoro per un'app per la logica ed eseguirne il debug usando un'interfaccia grafica. ma consente anche agli sviluppatori di esaminare un flusso di lavoro dietro le quinte per verificare il modo in cui è implementato. L'immagine seguente mostra un esempio di flusso di lavoro semplice, attivato inviando una richiesta HTTP GET a un URL specificato. Il risultato viene restituito nella risposta HTTP. In questo esempio il flusso di lavoro restituisce un semplice messaggio Hello Logic Apps Template!.
Adesso, esaminiamo il linguaggio di definizione dei flussi di lavoro usato nel modello JSON.
Visualizzazione Codice
La finestra Visualizzazione codice mostra il documento JSON che descrive il flusso di lavoro. Nell'app di esempio, il documento JSON è simile al seguente:
{
"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"
}
}
}
}
Nell'ambito definition è possibile notare le sezioni correlate alle azioni e ai trigger mostrati nella finestra di progettazione. È possibile modificare il codice JSON in questo documento in base alle personalizzazioni richieste per le funzionalità del flusso di lavoro delle app per la logica. È inoltre possibile aggiungere altre azioni e specificare l'evoluzione della logica del flusso di lavoro da un'azione alla successiva.
Sezione triggers
La sezione triggers contiene la descrizione del tipo di trigger e mostra come può essere richiamato. In questo esempio viene usato un trigger HTTP semplice che viene eseguito in risposta a una richiesta HTTP GET.
"triggers": {
"manual": {
"inputs": {
"method": "GET",
"schema": {}
},
"kind": "Http",
"type": "Request"
}
}
Un trigger deve includere gli elementi seguenti:
Un nome univoco all'interno del flusso di lavoro. Nell'esempio precedente il nome predefinito del trigger è
manual, ma è possibile sostituire il nome predefinito con un identificatore più significativo.Il tipo di trigger. Il tipo indica l'evento che determina l'esecuzione del trigger. Un trigger
Requestviene eseguito in risposta a una richiesta HTTP. Gli altri tipi di trigger disponibili includono:Recurrence, per creare un trigger che viene eseguito in base a una pianificazione ricorrente.HttpWebhook, per rimanere in ascolto di eventi su un endpoint.ApiConnection, per rispondere agli eventi attivati da altri servizi di Azure, ad esempio un messaggio in arrivo in una coda, un messaggio di posta elettronica e così via. Il tipo di trigger ApiConnection è generalizzato. È quindi possibile specificare altri dettagli per indicare il tipo di servizio e le eventuali informazioni di connessione necessarie.
La sezione
inputs. Questa sezione specifica i dati che definiscono il comportamento del trigger. Per un trigger Request,methodindica il tipo di richiesta HTTP che determina l'esecuzione del trigger. Per un triggerApiConnection, la sezioneinputscontiene informazioni su come connettersi alla risorsa che attiva l'evento, ad esempio una stringa di connessione alla coda dei messaggi. Se il trigger è di tipoRequest, la sezioneschemadella definizione di input specifica lo schema che il payload del corpo della richiesta deve rispettare. Poiché le richieste HTTP GET non hanno un corpo specifico, loschemanell'esempio precedente è vuoto.
L'esempio seguente mostra la definizione di un altro trigger Request che avvia un flusso di lavoro e riceve richieste HTTP POST. Una richiesta POST presenta in genere un corpo che contiene i dati da pubblicare. Il corpo della richiesta in questo esempio contiene il nome e l'indirizzo di un cliente, con l'indicazione della via e della città.
"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 trigger può inoltre specificare alcune condizioni. In tal caso, il trigger viene attivato solo se le condizioni sono soddisfatte. Le condizioni vengono definite in una sezione facoltativa denominata conditions. Può ad esempio essere necessario eseguire il trigger mypostrequest, illustrato nell'esempio precedente, solo se il corpo della richiesta specifica il nome della città di New York:
"mypostrequest": {
"type": "Request",
"kind": "Http",
"inputs": {
...
}
"conditions": [
{
"expression": "@equals(triggerOutputs()['body']['customerAddress']['city'], 'New York')"
}
]
}
Sezione actions
La sezione actions di un'app per la logica definisce la logica e la struttura del flusso di lavoro. La sezione contiene una serie di azioni. Un'azione è un blocco predefinito di base per la creazione di flussi di lavoro. Le azioni accettano input e generano output, che vengono passati all'azione successiva nel flusso di lavoro. Nella tabella seguente sono elencati diversi tipi di azione disponibili:
| Azione | Descrizione |
|---|---|
ApiConnection |
Invia una richiesta HTTP a un servizio specifico. Questo tipo di azione consente di integrare un flusso di lavoro delle app per la logica con le funzionalità di Azure, ad esempio il bus di servizio di Azure, Griglia di eventi di Azure e altre. Per l'azione è necessario specificare vari input tra cui una stringa di connessione per l'accesso al servizio e le informazioni e i parametri aggiuntivi necessari per richiamare il servizio. |
Compose |
Combina più input ed espressioni in un singolo output. |
Function |
Consente di chiamare una funzione di Azure. |
HTTP |
Invia una richiesta HTTP a un endpoint HTTP anziché a un servizio di Azure. |
Join |
Accetta come input una matrice di elementi di dati e genera una stringa contenente questi elementi separati da un delimitatore specificato. |
Parse |
Analizza un documento JSON in un set di token usando uno schema specificato. |
Query |
Filtra gli elementi in una matrice di input usando una condizione specificata. |
Response |
Crea una risposta per una richiesta HTTP. |
Table |
Genera una tabella HTML da una matrice di oggetti JSON. |
Terminate |
Annulla immediatamente un flusso di lavoro. |
Wait |
Sospende il flusso di lavoro per un intervallo specificato o finché non si verifica un timeout. |
Workflow |
Esegue un altro flusso di lavoro delle app per la logica. |
Condition |
Set di tipi di azione (Foreach, If, Switch e Until) che consentono di implementare un flusso di controllo a livello di codice in un flusso di lavoro. È possibile eseguire un'iterazione attraverso gli elementi di una raccolta, prendere decisioni in base a valori di parametri di input ed eseguire operazioni in ciclo finché non vengono soddisfatte determinate condizioni. |
InitializeVariable,IncrementVariable,DecrementVariable,SetVariable |
Definisce, inizializza, assegna e modifica le variabili che è possibile passare tra le azioni all'interno di un flusso di lavoro. |
Come per i trigger, ogni azione deve avere un nome univoco nel flusso di lavoro. Nell'esempio seguente il nome dell'azione predefinito è Response, ma è possibile usare un identificatore valido e più significativo. Un'azione deve avere una sezione inputs che specifica i dati a cui viene applicata. Nell'azione Risposta è possibile specificare i dati per un'espressione da restituire nel messaggio di risposta, insieme a un codice di stato HTTP.
In questa definizione di flusso di lavoro semplice, l'azione genera una risposta HTTP con un corpo costituito da un breve messaggio.
"actions": {
"Response": {
"inputs": {
"body": "Hello Azure Logic Apps Template!",
"statusCode": 200
},
"kind": "Http",
"runAfter": {},
"type": "Response"
}
}
La sezione runAfter indica il momento in cui l'azione viene eseguita nella sequenza del flusso di lavoro. Nell'esempio precedente è presente una sola azione, che viene quindi sempre eseguita all'attivazione del trigger. Se il flusso di lavoro includesse più azioni, in questa sezione si potrebbe specificare il nome di un'azione e uno stato correlato. L'azione viene eseguita se l'azione runAfter viene completata con lo stato specificato. Il seguente codice illustra un esempio. L'azione mySecondAction viene eseguita dopo myFirstAction, ma solo se myFirstAction termina con lo stato Succeeded:
"actions": {
"mySecondAction": {
"inputs": {
...
},
"runAfter": {
"myFirstAction": [
"Succeeded"
]
},
"type": ...
},
"myFirstAction": {
"inputs": {
...
},
"runAfter": {},
"type": ...
}
}
Sezione outputs
La sezione outputs consente di definire i dati che il flusso di lavoro può restituire al termine dell'esecuzione. È possibile tenere traccia di uno stato o di dati specifici per ogni esecuzione del flusso di lavoro. Per esaminare l'output di ogni esecuzione di un flusso di lavoro è possibile usare la cronologia di esecuzione di App per la logica di Azure, disponibile nel portale di Azure o tramite l'API REST per i flussi di lavoro.
Il formato della sezione outputs ha un aspetto simile al seguente:
"outputs": {
"<key-name>": {
"type": "<key-type>",
"value": "<key-value>"
}
}
Espressioni del flusso di lavoro
È possibile usare un'espressione del flusso di lavoro in sostituzione di qualsiasi valore fisso, variabile o costante. È inoltre possibile inserire un'espressione in qualsiasi punto di un valore stringa JSON aggiungendo all'espressione il prefisso chiocciola (@). La funzione @parameters può ad esempio essere usata in un'espressione per recuperare il valore di un parametro denominato. Per informazioni sui parametri, vedere la sezione successiva.
"customerFullName": "Bill Frost",
"accountName": "@parameters('customerName')"
App per la logica di Azure offre un set di funzioni predefinite che è possibile usare per creare espressioni complesse:
- Funzioni stringa: per concatenare e dividere stringhe, convertire i caratteri tra maiuscole e minuscole ed eseguire la ricerca di sottostringhe.
- Funzioni di raccolta: per rilevare se una raccolta contiene elementi che corrispondono a un modello specifico, recuperare elementi da una raccolta e combinare raccolte.
- Funzioni di confronto logico: funzioni di confronto logiche, per determinare se gli operandi sono uguali, diversi oppure numericamente maggiori o minori tra loro.
- Funzioni di conversione: per modificare il tipo o il formato dei dati.
- Funzioni matematiche: ad esempio
add,sub,divemule molte altre. - Funzioni di data e ora: Per l'analisi e l'elaborazione di date e ore.
- Funzioni del flusso di lavoro: per recuperare informazioni sui dati passati a un'azione del flusso di lavoro. Ad esempio, la funzione
parameter(illustrata in precedenza) recupera il valore di un parametro denominato, mentre la funzionebody(illustrata in precedenza) restituisce i dati generati da un'azione. - Funzioni di manipolazione JSON e XML: per l'analisi e l'elaborazione di documenti JSON e XML.
È possibile definire le variabili nella sezione inputs di un'azione InitializeVariable ed è possibile modificare queste variabili usando espressioni. Leggere il valore di una variabile usando la funzione variables. Nell'esempio seguente viene usata un'azione InitializeVariable per creare una variabile integer denominata myIntegerVariable e inizializzarla su 99. Questo esempio mostra anche un'azione Condition con il tipo If. La condizione usa un'espressione per testare il valore della variabile myIntegerVariable e, se corrisponde a 100, usa un'azione HTTP per eseguire una richiesta 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"
}
}
Sezione Parametri
La sezione parameters consente di impostare i parametri per un flusso di lavoro. In fase di esecuzione, è possibile specificare valori per ognuno dei parametri impostati. Si possono inserire riferimenti ai parametri in qualsiasi punto del flusso di lavoro in cui viene usata una costante o un'espressione.
È possibile aggiungere una definizione di parametro con un valore predefinito, che viene usato se non si specifica un valore per il parametro in fase di esecuzione. L'esempio seguente illustra come definire un parametro denominato cityParam. Il parametro viene usato all'interno della condizione per l'azione mypostrequest. L'azione viene eseguita solo se il documento della richiesta contiene una città corrispondente al valore del parametro. Il valore predefinito del parametro è 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"
}
}
}
}