Guida di riferimento allo schema per i tipi di trigger e azione in App per la logica di Azure

Questo riferimento descrive i tipi generali usati per identificare i trigger e le azioni nella definizione del flusso di lavoro sottostante dell'app per la logica, descritta e convalidata dal linguaggio di definizione del flusso di lavoro. Per trovare trigger e azioni specifici del connettore che è possibile usare nelle app per la logica, vedere l'elenco nella panoramica dei connettori.

Panoramica dei trigger

Ogni flusso di lavoro include un trigger, che definisce le chiamate che creano un'istanza e avviano il flusso di lavoro. Ecco le categorie generali di trigger:

• Un trigger di polling , che controlla l'endpoint di un servizio a intervalli regolari

• Un trigger push , che crea una sottoscrizione a un endpoint e fornisce un URL di callback in modo che l'endpoint possa inviare una notifica al trigger quando si verifica l'evento specificato o sono disponibili dati. Il trigger rimane quindi in attesa della risposta dell'endpoint prima dell'attivazione.

I trigger hanno questi elementi di livello superiore, anche se alcuni sono facoltativi:

"<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	Nome del trigger
< trigger-type>	String	Tipo di trigger, ad esempio "Http" o "ApiConnection"
< trigger-input>	Oggetto JSON	Input che definiscono il comportamento del trigger
< unità temporale>	String	Unità di tempo che descrive la frequenza con cui viene attivato il trigger: "Second" (Secondo), "Minute" (Minuto), "Hour" (Ora), "Day" (Giorno), "Week" (Settimana), "Month" (Mese)
< numero di unità temporali>	Integer	Valore che specifica la frequenza con cui il trigger viene attivato in base alla frequenza, ovvero il numero di unità di tempo di attesa fino a quando il trigger non viene generato di nuovo Di seguito sono riportati gli intervalli minimo e massimo: - Mese: 1-16 mesi - Giorno: 1-500 giorni - Ora: 1-12.000 ore - Minuto: 1-72.000 minuti - Secondo: 1-9.999.999 secondi Ad esempio, se l'intervallo è 6 e la frequenza è "Month", la ricorrenza è ogni 6 mesi.

Optional

Value	Type	Description
< array-with-conditions>	Array	Matrice che contiene una o più condizioni che determinano se eseguire il flusso di lavoro. Disponibile solo per i trigger.
< runtime-config-options>	Oggetto JSON	È possibile modificare il comportamento di runtime del trigger impostando le proprietà runtimeConfiguration. Per altre informazioni vedere Impostazioni di configurazione di runtime.
< splitOn-expression>	String	Per i trigger che restituiscono una matrice è possibile specificare un'espressione che suddivide o esegue il debatch degli elementi della matrice in più istanze del flusso di lavoro per l'elaborazione.
< opzione operation>	String	È possibile modificare il comportamento predefinito impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Elenco dei tipi di trigger

Ogni tipo di trigger ha un'interfaccia e input diversi che ne definiscono il comportamento.

Trigger predefiniti

Tipo di innesco	Description
HTTP	Controlla o esegue il polling di qualsiasi endpoint. Questo endpoint deve essere conforme a un contratto trigger specifico usando un 202 modello asincrono o restituendo una matrice.
HTTPWebhook	Crea un endpoint richiamabile dall'app per la logica, ma chiama l'URL specificato per la registrazione o l'annullamento della registrazione.
Recurrence	Attivato in base a una pianificazione definita. È possibile impostare una data e un'ora future per l'attivazione di questo trigger. In base alla frequenza, è anche possibile specificare le ore e i giorni per l'esecuzione del flusso di lavoro.
Request	Crea un endpoint richiamabile per l'app per la logica ed è anche conosciuto come trigger "manuale". Ad esempio, vedere Chiamare, attivare o annidare i flussi di lavoro con endpoint HTTP.

Trigger per l'API gestita

Tipo di innesco	Description
ApiConnection	Controlla o esegue il polling di un endpoint usando le API gestite da Microsoft o "connettori".
ApiConnectionWebhook	Crea un endpoint chiamabile per il flusso di lavoro dell'app per la logica chiamando API gestite da Microsoft o "connettori" per sottoscrivere e annullare la sottoscrizione.

Trigger - Riferimento dettagliato

Trigger APIConnection

Questo trigger controlla o esegue il polling di un endpoint usando API gestite da Microsoft o "connettori", in modo che i parametri per questo trigger possano differire in base all'endpoint. Numerose sezioni in questa definizione di trigger sono facoltative. Il comportamento del trigger dipende dalle sezioni incluse o escluse.

"<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	Nome del trigger
host.connection.name	< nome connessione>	String	Il nome della connessione all'API gestita usata dal flusso di lavoro
method	< method-type>	String	Metodo HTTP per la comunicazione con l'API gestita: GET, PUT, POST, PATCH, DELETE
path	< api-operation>	String	L'operazione API da chiamare
recurrence.frequency	< unità temporale>	String	Unità di tempo che descrive la frequenza con cui il trigger viene attivato: Secondo, Minuto, Ora, Giorno, Settimana, Mese
recurrence.interval	< numero di unità temporali>	Integer	Valore che specifica la frequenza con cui il trigger viene attivato in base alla frequenza, ovvero il numero di unità di tempo di attesa fino a quando il trigger non viene generato di nuovo Di seguito sono riportati gli intervalli minimo e massimo: - Mese: 1-16 mesi - Giorno: 1-500 giorni - Ora: 1-12.000 ore - Minuto: 1-72.000 minuti - Secondo: 1-9.999.999 secondi Ad esempio, se l'intervallo è 6 e la frequenza è Month, la ricorrenza è ogni 6 mesi.

Optional

Property	Value	Type	Description
retryPolicy	< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
queries	< parametri di query>	Oggetto JSON	Tutti i parametri di query da includere nella chiamata API. Ad esempio, l'oggetto "queries": { "api-version": "2018-01-01" } aggiunge ?api-version=2018-01-01 alla chiamata.
runtimeConfiguration.concurrency.runs	< max-run>	Integer	Per impostazione predefinita, le istanze del flusso di lavoro vengono eseguite contemporaneamente (simultaneamente o in parallelo) fino al limite predefinito. Per modificare questo limite impostando un nuovo < valore di conteggio>, vedere Modificare la concorrenza dei trigger.
runtimeConfiguration.maximumWaitingRuns	< max-runs-queue>	Integer	Se il flusso di lavoro esegue già il numero massimo di istanze, tutte le nuove esecuzioni vengono inserite in questa coda fino al limite predefinito. Per modificare il limite predefinito, vedere Modificare il limite delle esecuzioni in attesa. Per modificare il numero massimo di istanze, specificare un valore per la proprietà runtimeConfiguration.concurrency.runs . Nota: se si imposta
splitOn	< splitOn-expression>	String	Per i trigger che restituiscono matrici, questa espressione fa riferimento alla matrice da usare in modo che sia possibile creare ed eseguire un'istanza del flusso di lavoro per ogni elemento della matrice, anziché usare un ciclo "for each". Ad esempio, questa espressione rappresenta un elemento nella matrice restituito nel contenuto del corpo del trigger: @triggerbody()?['value']
operationOptions	< opzione operation>	String	È possibile modificare il comportamento predefinito impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Outputs

Element	Type	Description
headers	Oggetto JSON	Intestazioni dalla risposta
body	Oggetto JSON	Il corpo dalla risposta
codice di stato	Integer	Il codice di stato della risposta

Example

Questa definizione di trigger verifica la presenza di posta elettronica ogni giorno all'interno della posta in arrivo per un account aziendale o dell'istituto di istruzione:

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

Trigger ApiConnectionWebhook

Questo trigger invia una richiesta di sottoscrizione a un endpoint usando un'API gestita da Microsoft, fornisce un URL di callback a cui l'endpoint può inviare una risposta e attende che l'endpoint risponda. Per altre informazioni, vedere Sottoscrizioni di endpoint.

"<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
< nome connessione>	String	Il nome della connessione all'API gestita usata dal flusso di lavoro
< body-content>	Oggetto JSON	Qualsiasi contenuto del messaggio da inviare come payload all'API gestita

Optional

Value	Type	Description
< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
< parametri di query>	Oggetto JSON	Tutti i parametri di query da includere con la chiamata API Ad esempio, l'oggetto "queries": { "api-version": "2018-01-01" } aggiunge ?api-version=2018-01-01 alla chiamata.
< max-run>	Integer	Per impostazione predefinita, le istanze del flusso di lavoro vengono eseguite contemporaneamente (simultaneamente o in parallelo) fino al limite predefinito. Per modificare questo limite impostando un nuovo < valore di conteggio>, vedere Modificare la concorrenza dei trigger.
< max-runs-queue>	Integer	Quando il flusso di lavoro esegue già il numero massimo di istanze, che è possibile modificare in base alla runtimeConfiguration.concurrency.runs proprietà , tutte le nuove esecuzioni vengono inserite in questa coda fino al limite predefinito. Per modificare il limite predefinito, vedere Modificare il limite delle esecuzioni in attesa.
< splitOn-expression>	String	Per i trigger che restituiscono matrici, questa espressione fa riferimento alla matrice da usare in modo che sia possibile creare ed eseguire un'istanza del flusso di lavoro per ogni elemento della matrice, anziché usare un ciclo "for each". Ad esempio, questa espressione rappresenta un elemento nella matrice restituito nel contenuto del corpo del trigger: @triggerbody()?['value']
< opzione operation>	String	È possibile modificare il comportamento predefinito impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Example

Questa definizione di trigger sottoscrive l'API Outlook di Office 365, fornisce un URL di callback all'endpoint dell'API e attende che l'endpoint risponda quando arriva una nuova e-mail.

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

Trigger HTTP

Questo trigger invia una richiesta all'endpoint HTTP o HTTPS specificato in base alla pianificazione di ricorrenza specificata. Il trigger controlla quindi la risposta per determinare se il flusso di lavoro viene eseguito. Per altre informazioni, vedere Chiamare gli endpoint del servizio tramite HTTP o HTTPS da App per la logica di Azure.

"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	< method-type>	String	Metodo da usare per l'invio della richiesta in uscita: "GET", "PUT", "POST", "PATCH" o "DELETE"
uri	< HTTP-or-HTTPS-endpoint-URL>	String	URL dell'endpoint HTTP o HTTPS in cui si vuole inviare la richiesta in uscita. Dimensioni massime stringa: 2 KB Per un servizio o una risorsa di Azure, questa sintassi URI include l'ID risorsa e il percorso della risorsa a cui si vuole accedere.
frequency	< unità temporale>	String	Unità di tempo che descrive la frequenza con cui viene attivato il trigger: "Second" (Secondo), "Minute" (Minuto), "Hour" (Ora), "Day" (Giorno), "Week" (Settimana), "Month" (Mese)
interval	< numero di unità temporali>	Integer	Valore che specifica la frequenza con cui il trigger viene attivato in base alla frequenza, ovvero il numero di unità di tempo di attesa fino a quando il trigger non viene generato di nuovo Di seguito sono riportati gli intervalli minimo e massimo: - Mese: 1-16 mesi - Giorno: 1-500 giorni - Ora: 1-12.000 ore - Minuto: 1-72.000 minuti - Secondo: 1-9.999.999 secondi Ad esempio, se l'intervallo è 6 e la frequenza è "Month", la ricorrenza è ogni 6 mesi.

Optional

Property	Value	Type	Description
headers	< header-content>	Oggetto JSON	Eventuali intestazioni da includere con la richiesta Ad esempio, per impostare la lingua e il tipo: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries	< parametri di query>	Oggetto JSON	Tutti i parametri di query che è necessario usare nella richiesta Ad esempio, l'oggetto "queries": { "api-version": "2018-01-01" } aggiunge ?api-version=2018-01-01 alla richiesta.
body	< body-content>	Oggetto JSON	Il contenuto del messaggio da inviare come payload con la richiesta
authentication	< authentication-type-and-property-values>	Oggetto JSON	Modello di autenticazione usato dalla richiesta per l'autenticazione delle richieste in uscita. Per altre informazioni, vedere Aggiungere l'autenticazione alle chiamate in uscita. Oltre all'Utilità di pianificazione, la proprietà authority è supportata. Se non specificato, il valore predefinito è https://management.azure.com/, ma è possibile usare un valore diverso.
retryPolicy > type	< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
runs	< max-run>	Integer	Per impostazione predefinita, le istanze del flusso di lavoro vengono eseguite contemporaneamente (simultaneamente o in parallelo) fino al limite predefinito. Per modificare questo limite impostando un nuovo < valore di conteggio>, vedere Modificare la concorrenza dei trigger.
maximumWaitingRuns	< max-runs-queue>	Integer	Quando il flusso di lavoro esegue già il numero massimo di istanze, che è possibile modificare in base alla runtimeConfiguration.concurrency.runs proprietà , tutte le nuove esecuzioni vengono inserite in questa coda fino al limite predefinito. Per modificare il limite predefinito, vedere Modificare il limite delle esecuzioni in attesa.
operationOptions	< opzione operation>	String	È possibile modificare il comportamento predefinito impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Outputs

Element	Type	Description
headers	Oggetto JSON	Intestazioni dalla risposta
body	Oggetto JSON	Il corpo dalla risposta
status code	Integer	Il codice di stato della risposta

Requisiti per le richieste in ingresso

Per funzionare correttamente con l'app per la logica, l'endpoint deve essere conforme a un modello o un contratto di trigger specifico e riconoscere queste proprietà di risposta:

Property	Required	Description
Codice di stato	Yes	Il codice di stato "200 OK" avvia un'esecuzione. Nessun altro codice di stato avvia un'esecuzione.
Intestazione Retry-after	No	Numero di secondi fino a quando l'app per la logica esegue di nuovo il polling dell'endpoint
Intestazione percorso	No	URL da chiamare al successivo intervallo di polling. Se non è specificato, viene usato l'URL originale.

Comportamenti di esempio per diverse richieste

Codice di stato	Riprovare dopo	Behavior
200	{none}	Esegue il flusso di lavoro e quindi controlla di nuovo la presenza di altri dati dopo la ricorrenza definita.
200	10 secondi	Esegue il flusso di lavoro e quindi controlla di nuovo la presenza di altri dati dopo 10 secondi.
202	60 secondi	Non attiva il flusso di lavoro. Il tentativo successivo viene eseguito dopo un minuto, in base alla ricorrenza definita. Se la ricorrenza definita è inferiore a un minuto, l'intestazione retry-after ha la precedenza. In caso contrario, viene usata la ricorrenza definita.
400	{none}	Richiesta non valida, non esegue il flusso di lavoro. Se non è definito alcun oggetto retryPolicy, viene usato il criterio predefinito. Dopo aver raggiunto il numero di tentativi, il trigger controlla di nuovo la presenza di dati dopo la ricorrenza definita.
500	{none}	Errore del server, il flusso di lavoro non viene eseguito. Se non è definito alcun oggetto retryPolicy, viene usato il criterio predefinito. Dopo aver raggiunto il numero di tentativi, il trigger controlla di nuovo la presenza di dati dopo la ricorrenza definita.

Trigger HTTPWebhook

Questo trigger rende l'app per la logica richiamabile tramite la creazione di un endpoint che può registrare una sottoscrizione chiamando l'URL dell'endpoint specificato. Quando si crea il trigger nel flusso di lavoro, una richiesta in uscita effettua la chiamata per registrare la sottoscrizione. In questo modo il trigger può iniziare l'ascolto degli eventi. Quando un'operazione rende il trigger non valido, una richiesta in uscita effettua automaticamente una chiamata per annullare la sottoscrizione. Per altre informazioni, vedere Sottoscrizioni di endpoint.

È anche possibile specificare limiti asincroni per un trigger HTTPWebhook . Il comportamento del trigger dipende dalle sezioni usate o omesse.

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

Alcuni valori, ad esempio <il tipo di> metodo, sono disponibili per entrambi gli "subscribe" oggetti e "unsubscribe" .

Required

Value	Type	Description
< method-type>	String	Metodo HTTP da usare per la richiesta di sottoscrizione: "GET", "PUT", "POST", "PATCH" o "DELETE"
< endpoint-subscribe-URL>	String	URL dell'endpoint a cui inviare la richiesta di sottoscrizione

Optional

Value	Type	Description
< method-type>	String	Metodo HTTP da usare per la richiesta di annullamento: "GET", "PUT", "POST", "PATCH" o "DELETE"
< endpoint-unsubscribe-URL>	String	URL dell'endpoint a cui inviare la richiesta di annullamento
< body-content>	String	Qualsiasi contenuto di messaggio da inviare nella richiesta di sottoscrizione o di annullamento
< tipo di autenticazione>	Oggetto JSON	Modello di autenticazione usato dalla richiesta per l'autenticazione delle richieste in uscita. Per altre informazioni, vedere Aggiungere l'autenticazione alle chiamate in uscita.
< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
< max-run>	Integer	Per impostazione predefinita, tutte le istanze del flusso di lavoro vengono eseguite contemporaneamente (simultaneamente o in parallelo) fino al limite predefinito. Per modificare questo limite impostando un nuovo < valore di conteggio>, vedere Modificare la concorrenza dei trigger.
< max-runs-queue>	Integer	Quando il flusso di lavoro esegue già il numero massimo di istanze, che è possibile modificare in base alla runtimeConfiguration.concurrency.runs proprietà , tutte le nuove esecuzioni vengono inserite in questa coda fino al limite predefinito. Per modificare il limite predefinito, vedere Modificare il limite delle esecuzioni in attesa.
< opzione operation>	String	È possibile modificare il comportamento predefinito impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Outputs

Element	Type	Description
headers	Oggetto JSON	Intestazioni dalla risposta
body	Oggetto JSON	Il corpo dalla risposta
status code	Integer	Il codice di stato della risposta

Example

Questo trigger crea una sottoscrizione all'endpoint specificato, fornisce un URL di callback univoco e resta in attesa dei nuovi articoli di tecnologia pubblicati.

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

Trigger ricorrenza

Questo trigger viene eseguito in base alla pianificazione delle ricorrenze specificata e offre un modo semplice di creare un flusso di lavoro eseguito regolarmente.

"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
< unità temporale>	String	Unità di tempo che descrive la frequenza con cui viene attivato il trigger: "Second" (Secondo), "Minute" (Minuto), "Hour" (Ora), "Day" (Giorno), "Week" (Settimana), "Month" (Mese)
< numero di unità temporali>	Integer	Valore che specifica la frequenza con cui il trigger viene attivato in base alla frequenza, ovvero il numero di unità di tempo di attesa fino a quando il trigger non viene generato di nuovo Di seguito sono riportati gli intervalli minimo e massimo: - Mese: 1-16 mesi - Giorno: 1-500 giorni - Ora: 1-12.000 ore - Minuto: 1-72.000 minuti - Secondo: 1-9.999.999 secondi Ad esempio, se l'intervallo è 6 e la frequenza è "Month", la ricorrenza è ogni 6 mesi.

Optional

Value	Type	Description
< start-date-time-with-format-AAAA-MM-DDThh:mm:ss>	String	Data e ora di inizio in questo formato: AAAA-MM-GGThh:mm:ss se si specifica un fuso orario -or- AAAA-MM-GGThh:mm:ssZ se non si specifica un fuso orario Ad esempio, per il 18 settembre 2017 alle 14.00, specificare "2017-09-18T14:00:00" e indicare un fuso orario, ad esempio l'ora solare del Pacifico, oppure specificare "2017-09-18T14:00:00Z" senza fuso orario. Nota: questa ora di inizio ha un massimo di 49 anni in futuro e deve seguire la specifica dell'ora di data ISO 8601 in formato ora UTC, ma senza un offset UTC. Se non si specifica un fuso orario, è necessario aggiungere la lettera "Z" alla fine senza spazi. La lettera "Z" fa riferimento all'ora nautica equivalente. Per le pianificazioni semplici, l'ora di inizio è la prima occorrenza, mentre per le pianificazioni complesse il trigger non viene attivato prima dell'ora di inizio. Per altre informazioni sulle date e le ore di inizio, vedere Creare e pianificare attività eseguite regolarmente.
< fuso orario>	String	Valido solo quando si specifica un'ora di inizio, perché il trigger non accetta la differenza dall'ora UTC. Specificare il fuso orario che si vuole applicare.
< contrassegni uno o più ore>	Intero o matrice di intero	Se si specifica "Day" o "Week" per frequency, è possibile specificare uno o più numeri interi compresi tra 0 e 23, separati da virgole, come ore del giorno in cui eseguire il flusso di lavoro. Ad esempio, se si specifica "10", "12" e "14", gli indicatori di ora corrisponderanno alle 10.00, alle 12.00 e alle 14.00.
< contrassegni uno o più minuti>	Intero o matrice di intero	Se si specifica "Day" o "Week" per frequency, è possibile specificare uno o più numeri interi compresi tra 0 e 59, separati da virgole, come minuti dell'ora in cui eseguire il flusso di lavoro. Ad esempio, è possibile specificare "30" come indicatore dei minuti e, usando l'esempio precedente per le ore del giorno, si otterranno le ore 10.30, 12.30 e 14.30.
weekDays	Stringa o matrice di stringhe	Se si specifica "Week" per frequency, è possibile specificare uno o più giorni, separati da virgole, in cui eseguire il flusso di lavoro: "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" e "Sunday"
< max-run>	Integer	Per impostazione predefinita, tutte le istanze del flusso di lavoro vengono eseguite contemporaneamente (simultaneamente o in parallelo) fino al limite predefinito. Per modificare questo limite impostando un nuovo < valore di conteggio>, vedere Modificare la concorrenza dei trigger.
< max-runs-queue>	Integer	Quando il flusso di lavoro esegue già il numero massimo di istanze, che è possibile modificare in base alla runtimeConfiguration.concurrency.runs proprietà , tutte le nuove esecuzioni vengono inserite in questa coda fino al limite predefinito. Per modificare il limite predefinito, vedere Modificare il limite delle esecuzioni in attesa.
< opzione operation>	String	È possibile modificare il comportamento predefinito impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Esempio 1

Questo trigger di ricorrenza di base viene eseguito ogni giorno:

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Day",
      "interval": 1
   }
}

Esempio 2

È possibile specificare una data e un'ora di inizio per l'attivazione del trigger. Questo trigger di ricorrenza inizia alla data specificata e quindi viene attivato ogni giorno:

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Day",
      "interval": 1,
      "startTime": "2017-09-18T00:00:00Z"
   }
}

esempio 3

Questo trigger di ricorrenza inizia il 9 settembre 2017 alle 14.00 e viene attivato ogni settimana il lunedì alle 10.30, 12.30 e 14.30, ora solare Pacifico:

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

Per altre informazioni ed esempi per questo trigger, vedere Creare e pianificare attività eseguite regolarmente.

Trigger di richiesta

Questo trigger fa in modo che l'app per la logica possa essere chiamata mediante la creazione di un endpoint in grado di accettare le richieste in ingresso. Per questo trigger fornire uno schema JSON che descrive e convalida il payload o gli input che il trigger riceve dalla richiesta in ingresso. Lo schema semplifica il riferimento alle proprietà del trigger da parte delle azioni più recenti nel flusso di lavoro.

Note

Il nome originale per il trigger di richiesta era manuale, che potrebbe essere ancora visualizzato in alcune posizioni. Questo nome è stato modificato per creare maggiore coerenza rispetto al tipo di modello di flusso di lavoro usato per la compilazione.

Per chiamare questo trigger, è necessario usare l'API listCallbackUrl che viene descritta nell'API REST del servizio di flusso di lavoro. Per informazioni su come usare questo trigger come endpoint HTTP, vedere Chiamare, attivare o annidare i flussi di lavoro con endpoint 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	Il nome di una proprietà nello schema JSON che descrive il payload
< tipo di proprietà>	String	Il tipo della proprietà

Optional

Value	Type	Description
< method-type>	String	Metodo che le richieste in ingresso devono usare per chiamare l'app per la logica: "GET", "PUT", "POST", "PATCH", "DELETE"
< relative-path-for-accepted-parameter>	String	Percorso relativo per il parametro che l'URL dell'endpoint può accettare
< proprietà obbligatorie>	Array	Una o più proprietà che richiedono valori.
< max-run>	Integer	Per impostazione predefinita, tutte le istanze del flusso di lavoro vengono eseguite contemporaneamente (simultaneamente o in parallelo) fino al limite predefinito. Per modificare questo limite impostando un nuovo < valore di conteggio>, vedere Modificare la concorrenza dei trigger.
< max-runs-queue>	Integer	Quando il flusso di lavoro esegue già il numero massimo di istanze, che è possibile modificare in base alla runtimeConfiguration.concurrency.runs proprietà , tutte le nuove esecuzioni vengono inserite in questa coda fino al limite predefinito. Per modificare il limite predefinito, vedere Modificare il limite delle esecuzioni in attesa.
< opzione operation>	String	È possibile modificare il comportamento predefinito impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Example

Questo trigger specifica che una richiesta in ingresso deve usare il metodo HTTP POST per chiamare il trigger e include uno schema che convalida l'input della richiesta in ingresso:

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

Condizioni di attivazione

Esclusivamente per i trigger, è possibile includere una matrice con una o più espressioni per le condizioni che determinano se il flusso di lavoro deve essere eseguito o meno. Per aggiungere la proprietà a un trigger nel flusso di lavoro, aprire l'app conditions per la logica nell'editor della visualizzazione codice.

Ad esempio, è possibile specificare che un trigger venga attivato solo quando un sito Web restituisce un errore interno del server facendo riferimento al codice di stato del trigger nella proprietà conditions:

"Recurrence": {
   "type": "Recurrence",
   "recurrence": {
      "frequency": "Hour",
      "interval": 1
   },
   "conditions": [ {
      "expression": "@equals(triggers().code, 'InternalServerError')"
   } ]
}

Per impostazione predefinita, un trigger viene attivato solo dopo la ricezione di una risposta "200 OK". Quando un'espressione fa riferimento a un codice di stato di un trigger, il comportamento predefinito del trigger viene sostituito. Pertanto, se si vuole che il trigger venga attivato per più di un codice di stato, ad esempio "200" e "201", è necessario includere questa espressione come condizione:

@or(equals(triggers().code, 200),equals(triggers().code, 201))

Attivare più esecuzioni del flusso di lavoro in una matrice

Negli scenari in cui il flusso di lavoro usa un trigger che riceve matrici per l'elaborazione, a volte l'uso di un ciclo For each potrebbe richiedere troppo tempo. Per velocizzare l'elaborazione, è possibile creare rami paralleli. In alternativa, se il trigger supporta il debatching, è possibile che il trigger divida gli elementi della matrice ed esegua un'istanza separata del flusso di lavoro per ogni elemento della matrice. Questa opzione è utile, ad esempio, quando si vuole eseguire il polling di un endpoint che potrebbe restituire più nuovi elementi tra intervalli di polling.

Solo i trigger che possono accettare matrici e matrici restituite supportano questa funzionalità, ad esempio Request, HTTP, Azure Service Bus o Office Outlook 365. Per questi trigger, nella finestra di progettazione del flusso di lavoro è possibile attivare l'impostazione Dividi, che aggiunge la splitOn proprietà alla definizione del trigger.

Note

Se il file Swagger del trigger descrive un payload che è una matrice, la splitOn proprietà viene aggiunta automaticamente alla definizione del trigger. In caso contrario, e il trigger può accettare matrici, è possibile aggiungere la proprietà al payload della risposta che contiene la matrice da debatch.

Prima di usare la funzionalità di debatching, esaminare le considerazioni seguenti:

• Se viene attivata anche la concorrenza dei trigger, il limite di divisione viene ridotto in modo significativo. Se il numero di elementi supera questo limite, la funzionalità Split on non è disponibile.

• La funzionalità Split on non funziona con il modello di risposta sincrono. Se un flusso di lavoro usa l'azione Risposta e attiva l'impostazione Dividi in modo asincrono e invia immediatamente una 202 ACCEPTED risposta.

• Esiste un limite per il numero di elementi di matrice su cui è possibile elaborare l'elaborazione in un'unica esecuzione del flusso di lavoro. Per altre informazioni, vedere Limiti di ciclo e invio in batch.

• Se si configura il debatching tramite la definizione del trigger usando la splitOn proprietà , non è possibile fare riferimento direttamente o accedere alle proprietà esistenti all'esterno della matrice. Per evitare errori, precedere il riferimento con l'operatore ? . Per esempi, vedere Attivare il debatching nella definizione del trigger.

Attivare il debatching tramite la finestra di progettazione

Seguire questi passaggi nella finestra di progettazione del flusso di lavoro per configurare il debatching su un trigger in cui è supportato:

1. Nel [portale di Azure]aprire la risorsa dell'app per la logica.

2. Aprire il flusso di lavoro nella finestra di progettazione.

3. Nella finestra di progettazione selezionare il trigger che supporta il debatching per aprire il riquadro informazioni sul trigger.

4. Nella scheda Impostazioni , in Generale, trovare l'impostazione Dividi in e modificare l'impostazione su Sì se non è attivata.

Attivare il debatching nella definizione del trigger

Alcuni trigger gestiscono le matrici, ma l'impostazione Split on non è disponibile tramite la finestra di progettazione. Per questi trigger, seguire questa procedura per aggiungere la splitOn proprietà nella definizione del trigger:

Si supponga, ad esempio, che il flusso di lavoro usi il trigger HTTP per chiamare un'API e ottiene la risposta seguente:

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

Se il flusso di lavoro richiede solo il contenuto della Rows matrice, è possibile aggiungere e configurare la splitOn proprietà nella definizione del trigger, come illustrato nell'esempio seguente:

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

Note

Tenere presente che, se si usa la splitOn proprietà , non è possibile accedere direttamente o fare riferimento alle proprietà esistenti all'esterno della matrice. Per evitare errori, usare l'operatore ? come illustrato negli esempi.

La definizione del flusso di lavoro può anche usare splitOn e @triggerBody().name per ottenere valori dalla name proprietà . Questi valori provengono "customer-name-one" dalla prima esecuzione del flusso di lavoro e "customer-name-two" dalla seconda esecuzione del flusso di lavoro. Per questo esempio, gli output del trigger sono simili ai valori seguenti:

{
   "body": {
      "id": 938109380,
      "name": "customer-name-one"
   }
}

{
   "body": {
      "id": 938109381,
      "name": "customer-name-two"
   }
}

Panoramica delle azioni

Le app per la logica di Azure forniscono vari tipi di azione, ognuna con input diversi che definiscono il comportamento univoco di un'azione. Le azioni hanno questi elementi di livello superiore, anche se alcuni sono facoltativi:

"<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	Il nome dell'azione
< tipo di azione>	String	Tipo di azione, ad esempio "Http" o "ApiConnection"
< input-name>	String	Il nome di un input che definisce il comportamento dell'azione
< input-value>	Various	Il valore di input, che può essere una stringa, un numero intero, un oggetto JSON e così via
< previous-trigger-or-action-status>	Oggetto JSON	Il nome e lo stato risultante per il trigger o l'azione che devo essere eseguiti immediatamente prima di poter eseguire questa azione corrente

Optional

Value	Type	Description
< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
< runtime-config-options>	Oggetto JSON	Per alcune azioni, è possibile modificare il comportamento dell'azione in fase di esecuzione impostando le proprietà runtimeConfiguration. Per altre informazioni vedere Impostazioni di configurazione di runtime.
< opzione operation>	String	È possibile modificare il comportamento predefinito di alcune azioni impostando la proprietà operationOptions. Per altre informazioni, vedere Opzioni operative.

Elenco dei tipi di azione

Di seguito sono riportati alcuni tipi di azioni di uso comune:

• Tipi di azioni predefinite come in questi e altri esempi:

  • HTTP per chiamare gli endpoint tramite HTTP o HTTPS

  • Risposta per rispondere alle richieste

  • Eseguire codice JavaScript per l'esecuzione di frammenti di codice JavaScript

  • Funzione per chiamare Funzioni di Azure

  • Azioni dell'operazione dati, ad esempio Join, Compose, Table, Select e altre che creano o trasformano i dati da vari input

  • Flusso di lavoro per chiamare un altro flusso di lavoro dell'app per la logica

• Tipi di azione gestiti dall'API, ad esempio ApiConnection e ApiConnectionWebHook che chiama vari connettori e API gestite da Microsoft, ad esempio, bus di servizio di Azure, Office 365 Outlook, Power BI, Archiviazione BLOB di Azure, OneDrive, GitHub e altro ancora

• Tipi di azione di controllo del flusso di lavoro, ad esempio If, Foreach, Switch, Scope e Until che contengono altre azioni che consentono di organizzare l'esecuzione del flusso di lavoro

Azioni predefinite

Tipo di azione	Description
Compose	Crea un singolo output dagli input, che possono essere di vari tipi.
Esegui codice JavaScript	Eseguire frammenti di codice JavaScript che rientrano in criteri specifici. Per i requisiti di codice e altre informazioni, vedere Aggiungere ed eseguire frammenti di codice con codice inline.
Function	Chiama una funzione di Azure.
HTTP	Chiama un endpoint HTTP.
Join	Crea una stringa da tutti gli elementi in una matrice e separa gli elementi con un carattere delimitatore specificato.
Analizzare JSON	Crea token semplici da usare dalle proprietà nel contenuto JSON. È quindi possibile fare riferimento a tali proprietà includendo i token nell'app per la logica.
Query	Crea una matrice di elementi in un'altra matrice in base a una condizione o a un filtro.
Response	Crea una risposta a una richiesta o a una chiamata in ingresso.
Select	Crea una matrice con gli oggetti JSON mediante la trasformazione degli elementi di un'altra matrice basata sul mapping specificato.
Table	Crea una tabella CSV o HTML da una matrice.
Terminate	Arresta un flusso di lavoro in esecuzione attiva.
Wait	Sospende il flusso di lavoro per la durata specificata o fino alla data e ora specificate.
Workflow	Consente di annidare un flusso di lavoro all'interno di un altro flusso di lavoro.

Azioni delle API gestite

Tipo di azione	Description
ApiConnection	Chiama un endpoint HTTP usando un'API gestita da Microsoft.
ApiConnectionWebhook	Funziona come webhook HTTP, ma usa un'API gestita da Microsoft.

Azioni di controllo del flusso di lavoro

Queste azioni consentono di controllare l'esecuzione del flusso di lavoro e includono altre azioni. Dall'esterno di un'azione di controllo del flusso di lavoro è possibile fare riferimento direttamente ad azioni all'interno di tale azione di controllo di flusso di lavoro. Ad esempio, se si dispone di un'azione Http all'interno di un ambito, è possibile fare riferimento all'espressione @body('Http') da qualsiasi posizione nel flusso di lavoro. Tuttavia, le azioni esistenti all'interno di un'azione di controllo del flusso di lavoro possono essere solo "eseguite dopo" altre azioni che sono nella stessa struttura di controllo del flusso di lavoro.

Tipo di azione	Description
ForEach	Esegue le stesse azioni in un ciclo per ogni elemento in una matrice.
If	Esegue le azioni a seconda se la condizione specificata è true o false.
Scope	Esegue le azioni in base allo stato di gruppo da un set di azioni.
Switch	Esegue le azioni organizzate in casi quando i valori delle espressioni, oggetti o token corrispondono ai valori specificati per ogni caso.
Until	Esegue le azioni in un ciclo fino a quando la condizione specificata è true.

Azioni - Riferimento dettagliato

Azione APIConnection

Questa azione invia una richiesta HTTP a un'API gestita da Microsoft e richiede informazioni sull'API e sui parametri più un riferimento a una connessione valida.

"<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	Il nome dell'azione fornito dal connettore
< api-name>	String	Il nome dell'API gestita da Microsoft usata per la connessione
< method-type>	String	Il metodo HTTP per chiamare l'API: "GET", "PUT", "POST", "PATCH" o "DELETE"
< api-operation>	String	L'operazione API da chiamare

Optional

Value	Type	Description
< other-action-specific-input-properties>	Oggetto JSON	Altre proprietà di input che si applicano a questa azione specifica
< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
< parametri di query>	Oggetto JSON	Tutti i parametri di query da includere nella chiamata API. Ad esempio, l'oggetto "queries": { "api-version": "2018-01-01" } aggiunge ?api-version=2018-01-01 alla chiamata.
< altre proprietà specifiche dell'azione>	Oggetto JSON	Le altre proprietà che si applicano a questa azione specifica

Example

Questa definizione descrive l'azioneSend an email per il connettore Outlook Office 365 che è un'API gestita da 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": {}
}

AZIONE APIConnectionWebhook

Questa azione invia una richiesta di sottoscrizione tramite HTTP a un endpoint usando un'API gestita da Microsoft, fornisce un URL di callback a cui l'endpoint può inviare una risposta e attende che l'endpoint risponda. Per altre informazioni, vedere Sottoscrizioni di endpoint.

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

Alcuni valori, ad esempio <il tipo di> metodo, sono disponibili per entrambi gli "subscribe" oggetti e "unsubscribe" .

Required

Value	Type	Description
< action-name>	String	Il nome dell'azione fornito dal connettore
< method-type>	String	Il metodo HTTP da usare per la sottoscrizione o l'annullamento della sottoscrizione da un endpoint: "GET", "PUT", "POST", "PATCH" o "DELETE"
< API-subscribe-URL>	String	L'URI da usare per la sottoscrizione all'API

Optional

Value	Type	Description
< API-unsubscribe-URL>	String	L'URI da usare per annullare la sottoscrizione all'API
< header-content>	Oggetto JSON	Eventuali intestazioni da inviare nella richiesta Ad esempio, per impostare il linguaggio e il tipo in una richiesta: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
< body-content>	Oggetto JSON	Gli eventuali messaggi da inviare nella richiesta
< tipo di autenticazione>	Oggetto JSON	Modello di autenticazione usato dalla richiesta per l'autenticazione delle richieste in uscita. Per altre informazioni, vedere Aggiungere l'autenticazione alle chiamate in uscita.
< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
< parametri di query>	Oggetto JSON	Tutti i parametri di query da includere con la chiamata API Ad esempio, l'oggetto "queries": { "api-version": "2018-01-01" } aggiunge ?api-version=2018-01-01 alla chiamata.
< other-action-specific-input-properties>	Oggetto JSON	Altre proprietà di input che si applicano a questa azione specifica
< altre proprietà specifiche dell'azione>	Oggetto JSON	Le altre proprietà che si applicano a questa azione specifica

È anche possibile specificare limiti per un'azione ApiConnectionWebhook nello stesso modo dei limiti asincroni HTTP.

Componi azione

Questa azione crea un singolo output da più input, incluse le espressioni. Sia l'output che gli input possono essere di qualsiasi tipo tra quelli supportati in modo nativo dalle app per la logica di Azure, ad esempio matrici, oggetti JSON, XML e oggetti binari. È quindi possibile usare l'output dell'azione in altre azioni.

"Compose": {
   "type": "Compose",
   "inputs": "<inputs-to-compose>",
   "runAfter": {}
},

Required

Value	Type	Description
< input da comporre>	Any	Gli input per la creazione di un singolo output

Esempio 1

Questa definizione di azione unisce abcdefg con uno spazio finale e il valore 1234:

"Compose": {
   "type": "Compose",
   "inputs": "abcdefg 1234",
   "runAfter": {}
},

Ecco l'output creato da questa azione:

abcdefg 1234

Esempio 2

Questa definizione di azione unisce una variabile di stringa che contiene abcdefg e una variabile integer che contiene 1234:

"Compose": {
   "type": "Compose",
   "inputs": "@{variables('myString')}@{variables('myInteger')}",
   "runAfter": {}
},

Ecco l'output creato da questa azione:

"abcdefg1234"

Eseguire l'azione Codice JavaScript

Questa azione esegue un frammento di codice JavaScript e restituisce i risultati tramite un token a cui possono fare riferimento le azioni successive nel flusso di lavoro.

"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	Codice JavaScript da eseguire. Per i requisiti di codice e altre informazioni, vedere Eseguire frammenti di codice nei flussi di lavoro. Nell'attributo code il frammento di codice può usare l'oggetto di sola workflowContext lettura come input. Questo oggetto ha proprietà secondarie che consentono al codice di accedere agli output dal trigger e alle azioni precedenti nel flusso di lavoro. Per altre informazioni sull'oggetto workflowContext , vedere Risultati di trigger e azioni di riferimento tramite l'oggetto workflowContext.

Obbligatorio in alcuni casi

L'attributo explicitDependencies specifica che si desidera includere in modo esplicito i risultati del trigger, le azioni precedenti o entrambe come dipendenze per il frammento di codice. Per altre informazioni sull'aggiunta di queste dipendenze, vedere Aggiungere dipendenze come parametri a un'azione Codice inline.

Per l'attributo includeTrigger è possibile specificare true o false valori.

Value	Type	Description
< azioni precedenti>	Matrice di stringhe	Matrice con i nomi delle azioni in formato JSON come dipendenze. Assicurarsi di usare i nomi delle azioni visualizzati nella definizione del flusso di lavoro in cui i nomi delle azioni usano caratteri di sottolineatura (_), non spazi (" ").

Esempio 1

Questa azione esegue il codice che ottiene il nome del flusso di lavoro dell'app per la logica e restituisce il testo "Hello world from <logic-app-name>" come risultato. In questo esempio il codice fa riferimento al nome del flusso di lavoro accedendo alla workflowContext.workflow.name proprietà tramite l'oggetto di sola lettura workflowContext . Per altre informazioni sull'uso dell'oggetto workflowContext , vedere Trigger di riferimento e risultati dell'azione nel codice.

"Execute_JavaScript_Code": {
   "type": "JavaScriptCode",
   "inputs": {
      "code": "var text = \"Hello world from \" + workflowContext.workflow.name;\r\n\r\nreturn text;"
   },
   "runAfter": {}
}

Esempio 2

Questa azione esegue il codice in un flusso di lavoro dell'app per la logica che viene attivato quando arriva un nuovo messaggio di posta elettronica in un account outlook. Il flusso di lavoro usa anche l'azione di posta elettronica di approvazione di Office 365 Outlook Send che inoltra il contenuto dal messaggio di posta elettronica ricevuto insieme a una richiesta di approvazione.

Il codice estrae gli indirizzi di posta elettronica dalla proprietà del messaggio di Body posta elettronica e restituisce gli indirizzi insieme al valore della SelectedOption proprietà dall'azione di approvazione. L'azione include in modo esplicito l'azione Invia messaggio di posta elettronica di approvazione come dipendenza nell'oggetto all'interno dell'oggetto actionsexplicitDependencies .

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

Azione funzione

Questa azione chiama una funzione di Azure creata in precedenza.

"<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 risorsa per la funzione di Azure che si vuole chiamare. Ecco il formato per questo valore: "/subscriptions/<Azure-subscription-ID>/resourceGroups/<Azure-resource-group>/providers/Microsoft.Web/sites/<Azure-function-app-name>/functions/<Azure-function-name>"
< method-type>	String	Metodo HTTP da usare per chiamare la funzione: "GET", "PUT", "POST", "PATCH" o "DELETE" Se non è specificato, il metodo predefinito è "POST".

Optional

Value	Type	Description
< header-content>	Oggetto JSON	Eventuali intestazioni da inviare con la chiamata Ad esempio, per impostare il linguaggio e il tipo in una richiesta: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
< body-content>	Oggetto JSON	Gli eventuali messaggi da inviare nella richiesta
< parametri di query>	Oggetto JSON	Tutti i parametri di query da includere con la chiamata API Ad esempio, l'oggetto "queries": { "api-version": "2018-01-01" } aggiunge ?api-version=2018-01-01 alla chiamata.
< other-action-specific-input-properties>	Oggetto JSON	Altre proprietà di input che si applicano a questa azione specifica
< altre proprietà specifiche dell'azione>	Oggetto JSON	Le altre proprietà che si applicano a questa azione specifica

Quando si salva l'app per la logica, App per la logica di Azure esegue questi controlli sulla funzione a cui si fa riferimento:

• Il flusso di lavoro deve avere accesso alla funzione.

• Il flusso di lavoro può usare solo un trigger HTTP standard o un trigger Webhook JSON generico.

  App per la logica di Azure ottiene e memorizza nella cache l'URL del trigger, usato in fase di esecuzione. Tuttavia, se un'operazione invalida l'URL memorizzato nella cache, l'azione Funzione ha esito negativo in fase di esecuzione. Per risolvere questo problema, salvare di nuovo l'app per la logica in modo che ottenga e memorizzi nuovamente nella cache l'URL del trigger.

• Per la funzione non deve essere definita alcuna route.

• Sono consentiti solo i livelli di autorizzazione "funzione" e "anonimo".

Example

Questa definizione di azione chiama la funzione "GetProductID" creata in precedenza:

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

Azione HTTP

Questa azione invia una richiesta all'endpoint HTTP o HTTPS specificato e controlla la risposta per determinare se il flusso di lavoro viene eseguito. Per altre informazioni, vedere Chiamare gli endpoint del servizio tramite HTTP o HTTPS da App per la logica di Azure.

"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	< method-type>	String	Metodo da usare per l'invio della richiesta in uscita: "GET", "PUT", "POST", "PATCH" o "DELETE"
uri	< HTTP-or-HTTPS-endpoint-URL>	String	URL dell'endpoint HTTP o HTTPS in cui si vuole inviare la richiesta in uscita. Dimensioni massime stringa: 2 KB Per un servizio o una risorsa di Azure, questa sintassi URI include l'ID risorsa e il percorso della risorsa a cui si vuole accedere.

Optional

Property	Value	Type	Description
headers	< header-content>	Oggetto JSON	Eventuali intestazioni da includere con la richiesta Ad esempio, per impostare la lingua e il tipo: "headers": { "Accept-Language": "en-us", "Content-Type": "application/json" }
queries	< parametri di query>	Oggetto JSON	Tutti i parametri di query che è necessario usare nella richiesta Ad esempio, l'oggetto "queries": { "api-version": "2018-01-01" } aggiunge ?api-version=2018-01-01 alla chiamata.
body	< body-content>	Oggetto JSON	Il contenuto del messaggio da inviare come payload con la richiesta
authentication	< authentication-type-and-property-values>	Oggetto JSON	Modello di autenticazione usato dalla richiesta per l'autenticazione delle richieste in uscita. Per altre informazioni, vedere Aggiungere l'autenticazione alle chiamate in uscita. Oltre all'Utilità di pianificazione, la proprietà authority è supportata. Se non specificato, il valore predefinito è https://management.azure.com/, ma è possibile usare un valore diverso.
retryPolicy > type	< comportamento di ripetizione dei tentativi>	Oggetto JSON	Consente di personalizzare il comportamento per la ripetizione degli errori intermittenti, che hanno il codice di stato 408, 429 e 5XX e tutte le eccezioni di connettività. Per altre informazioni, vedere il Criteri di ripetizione dei tentativi.
< other-action-specific-input-properties>	< input-property>	Oggetto JSON	Altre proprietà di input che si applicano a questa azione specifica
< altre proprietà specifiche dell'azione>	< property-value>	Oggetto JSON	Le altre proprietà che si applicano a questa azione specifica

Example

Questa definizione di azioni ottiene le notizie più recenti inviando una richiesta all'endpoint specificato:

"HTTP": {
   "type": "Http",
   "inputs": {
      "method": "GET",
      "uri": "https://mynews.example.com/latest"
   }
}

Azione di join

Questa azione crea una stringa da tutti gli elementi in una matrice e li separa con il carattere delimitatore specificato.

"Join": {
   "type": "Join",
   "inputs": {
      "from": <array>,
      "joinWith": "<delimiter>"
   },
   "runAfter": {}
}

Required

Value	Type	Description
< array>	Array	La matrice o l'espressione che fornisce gli elementi di origine. Se si specifica un'espressione, racchiuderla tra virgolette doppie.
< delimitatore>	Stringa di caratteri singoli	Il carattere che separa ciascun elemento nella stringa

Example

Si supponga di avere una variabile "myIntegerArray" creata in precedenza che contiene questa matrice di numeri interi:

[1,2,3,4]

Questa definizione di azione ottiene i valori dalla variabile usando la funzione variables() in un'espressione e crea la stringa con questi valori separati da virgole: "1,2,3,4"

"Join": {
   "type": "Join",
   "inputs": {
      "from": "@variables('myIntegerArray')",
      "joinWith": ","
   },
   "runAfter": {}
}

Azione Analizza JSON

Questa azione crea campi o token descrittivi dalle proprietà nel contenuto JSON. È quindi possibile accedere a tali proprietà nell'app per la logica usando i token. Ad esempio, quando si intende usare l'output JSON dei servizi come il bus di servizio di Azure e Azure Cosmos DB, è possibile includere questa azione nell'app per la logica in modo che si possa fa riferimento più facilmente ai dati nell'output.

"Parse_JSON": {
   "type": "ParseJson",
   "inputs": {
      "content": "<JSON-source>",
         "schema": { "<JSON-schema>" }
      },
      "runAfter": {}
},

Required

Value	Type	Description
< Origine JSON>	Oggetto JSON	Il contenuto JSON da analizzare
< Schema JSON>	Oggetto JSON	Lo schema JSON che descrive il contenuto JSON sottostante che l'azione usa per l'analisi dell'origine del contenuto JSON. Suggerimento: nella finestra di progettazione del flusso di lavoro è possibile specificare lo schema o fornire un payload di esempio in modo che l'azione possa generare lo schema.

Example

Questa definizione di azione crea questi token che è possibile usare nel flusso di lavoro, ma solo nelle azioni eseguite seguendo l'azione Analizza JSON :

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

In questo esempio, la proprietà "content" specifica il contenuto JSON per l'azione da analizzare. È anche possibile fornire il contenuto JSON come payload di esempio per la generazione dello schema.

"content": {
   "Member": { 
      "FirstName": "Sophie",
      "LastName": "Owen",
      "Email": "Sophie.Owen@contoso.com"
   }
},

La proprietà "schema" specifica lo schema JSON usato per descrivere il contenuto JSON:

"schema": {
   "type": "object",
   "properties": {
      "Member": {
         "type": "object",
         "properties": {
            "FirstName": {
               "type": "string"
            },
            "LastName": {
               "type": "string"
            },
            "Email": {
               "type": "string"
            }
         }
      }
   }
}

Azione query

Questa azione crea una matrice da elementi in un'altra matrice in base a una condizione o a un filtro specificati.

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": <array>,
      "where": "<condition-or-filter>"
   },
   "runAfter": {}
}

Required

Value	Type	Description
< array>	Array	La matrice o l'espressione che fornisce gli elementi di origine. Se si specifica un'espressione, racchiuderla tra virgolette doppie.
< condition-or-filter>	String	Condizione usata per filtrare gli elementi nella matrice di origine Nota: se nessun valore soddisfa la condizione, l'azione crea una matrice vuota.

Example

Questa definizione di azioni crea una matrice che contiene valori maggiori del valore specificato, ovvero due:

"Filter_array": {
   "type": "Query",
   "inputs": {
      "from": [ 1, 3, 0, 5, 4, 2 ],
      "where": "@greater(item(), 2)"
   }
}

Azione di risposta

Questa azione crea il payload per la risposta a una richiesta HTTP.

"Response" {
    "type": "Response",
    "kind": "http",
    "inputs": {
        "statusCode": 200,
        "headers": { <response-headers> },
        "body": { <response-body> }
    },
    "runAfter": {}
},

Required

Value	Type	Description
< response-status-code>	Integer	Codice di stato HTTP inviato per rispondere alla richiesta in ingresso. Il codice predefinito è "200 OK", ma può essere qualsiasi codice di stato valido che inizia con 2xx, 4xx o 5xx, ma non con 3xxx.

Optional

Value	Type	Description
< response-headers>	Oggetto JSON	Una o più intestazioni da includere con la risposta
< response-body>	Various	Il corpo della risposta, che può essere una stringa, un oggetto JSON o anche il contenuto binario di un'azione precedente

Example

Questa definizione di azioni crea una risposta a una richiesta HTTP con il codice di stato specificato, il corpo e le intestazioni del messaggio:

"Response": {
   "type": "Response",
   "inputs": {
      "statusCode": 200,
      "body": {
         "ProductID": 0,
         "Description": "Organic Apples"
      },
      "headers": {
         "x-ms-date": "@utcnow()",
         "content-type": "application/json"
      }
   },
   "runAfter": {}
}

Restrictions

A differenza di altre azioni, l'azione Risposta presenta restrizioni speciali:

• Il flusso di lavoro può usare l'azione Response solo quando il flusso di lavoro inizia con un trigger di richiesta HTTP, ovvero il flusso di lavoro deve essere attivato da una richiesta HTTP.

• Il flusso di lavoro può usare l'azione Risposta in qualsiasi punto , ad eccezione dei cicli Foreach , dei cicli Until , inclusi i cicli sequenziali e i rami paralleli.

• La richiesta originale ottiene la risposta del flusso di lavoro solo quando tutte le azioni richieste dall'azione Risposta vengono completate entro il limite di timeout HTTP.

  Tuttavia, se il flusso di lavoro chiama un'altra app per la logica come un flusso di lavoro annidato, il flusso di lavoro padre attende fino al termine del flusso di lavoro annidato, indipendentemente da quanto tempo passa prima che questo venga completato.

• Quando il flusso di lavoro usa l'azione Response e un modello di risposta sincrono, il flusso di lavoro non può usare anche il comando splitOn nella definizione del trigger perché questo comando crea più esecuzioni. Controllare questo caso quando viene usato il metodo PUT e, se è true, restituisce una risposta di "richiesta non valida".

  In caso contrario, se il flusso di lavoro usa il comando splitOn e un'azione Response , il flusso di lavoro viene eseguito in modo asincrono e restituisce immediatamente una risposta "202 ACCEPTED".

• Quando l'esecuzione del flusso di lavoro raggiunge l'azione Risposta , ma la richiesta in ingresso ha già ricevuto una risposta, l'azione Risposta viene contrassegnata come "Non riuscita" a causa del conflitto. E di conseguenza, l'esecuzione dell'app per la logica viene anche contrassegnata con lo stato "Failed".

Selezionare l'azione

Questa azione crea una matrice con gli oggetti JSON mediante la trasformazione degli elementi di un'altra matrice basata sul mapping specificato. La matrice di output e la matrice di origine hanno sempre lo stesso numero di elementi. Anche se è possibile modificare il numero di oggetti nella matrice di output, è possibile aggiungere o rimuovere proprietà e i relativi valori tra tali oggetti. La proprietà select consente di specificare almeno una coppia chiave-valore che definisce il mapping per trasformare gli elementi nella matrice di origine. Una coppia chiave-valore rappresenta una proprietà e il relativo valore tra tutti gli oggetti nella matrice di output.

"Select": {
   "type": "Select",
   "inputs": {
      "from": <array>,
      "select": { 
          "<key-name>": "<expression>",
          "<key-name>": "<expression>"        
      }
   },
   "runAfter": {}
},

Required

Value	Type	Description
< array>	Array	La matrice o l'espressione che fornisce gli elementi di origine. Assicurarsi di racchiudere un'espressione tra virgolette doppie. Nota: se la matrice di origine è vuota, l'azione crea una matrice vuota.
< key-name>	String	Nome della proprietà assegnato al risultato <> Per aggiungere una nuova proprietà in tutti gli oggetti nella matrice di output, specificare un <nome> chiave per tale proprietà e <> per il valore della proprietà. Per rimuovere una proprietà da tutti gli oggetti nella matrice, omettere il < della > chiave per tale proprietà.
< espressione>	String	Espressione che trasforma l'elemento nella matrice di origine e assegna il risultato a <key-name>

L'azione Seleziona crea una matrice come output, pertanto qualsiasi azione che vuole usare questo output deve accettare una matrice oppure è necessario convertire la matrice nel tipo accettato dall'azione del consumer. Ad esempio, per convertire la matrice di output in una stringa, è possibile passare tale matrice all'azione Compose e quindi fare riferimento all'output dell'azione Compose nelle altre azioni.

Example

Questa definizione di azioni crea una matrice di oggetti JSON da una matrice di numeri interi. L'azione esegue l'iterazione attraverso la matrice di origine, ottiene tutti i valori integer usando l'espressione @item() e assegna ogni valore alla proprietà "number" in ogni oggetto JSON:

"Select": {
   "type": "Select",
   "inputs": {
      "from": [ 1, 2, 3 ],
      "select": { 
         "number": "@item()" 
      }
   },
   "runAfter": {}
},

Ecco la matrice creata da questa azione:

[ { "number": 1 }, { "number": 2 }, { "number": 3 } ]

Per usare questo output di matrice in altre azioni, passare questo output in un'azione Compose :

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

È quindi possibile usare l'output dell'azione Componi nelle altre azioni, ad esempio Office 365 Outlook - Invia un messaggio di posta elettronica :

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

Azione tabella

Questa azione crea una tabella CSV o HTML da una matrice. Per le matrici con oggetti JSON, questa azione crea automaticamente le intestazioni di colonna dai nomi delle proprietà degli oggetti. Per le matrici con altri tipi di dati, è necessario specificare le intestazioni e i valori di colonna. Ad esempio, questa matrice include le proprietà "ID" e "Product_Name" che questa azione può usare per i nomi delle intestazioni di colonna:

[ {"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 o HTML>	String	Il formato della tabella da creare
< array>	Array	Matrice o espressione che fornisce gli elementi di origine per la tabella Nota: se la matrice di origine è vuota, l'azione crea una tabella vuota.

Optional

Per specificare o personalizzare le intestazioni e i valori di colonna usare la matrice columns. Quando le coppie header-value hanno lo stesso nome di intestazione, i relativi valori vengono visualizzati nella stessa colonna con quel nome di intestazione. In caso contrario, ogni intestazione univoca definisce una colonna univoca.

Value	Type	Description
< column-name>	String	Il nome dell'intestazione di una colonna
< column-value>	Any	Il valore nella colonna

Esempio 1

Si supponga di avere una variabile "myItemArray" creata in precedenza che attualmente contiene questa matrice:

[ {"ID": 0, "Product_Name": "Apples"}, {"ID": 1, "Product_Name": "Oranges"} ]

Questa definizione di azione crea una tabella CSV dalla variabile "myItemArray". L'espressione usata dalla proprietà from ottiene la matrice da "myItemArray" usando la funzione variables():

"Create_CSV_table": {
   "type": "Table",
   "inputs": {
      "format": "CSV",
      "from": "@variables('myItemArray')"
   },
   "runAfter": {}
}

Ecco la tabella CSV creata da questa azione:

ID,Product_Name 
0,Apples 
1,Oranges 

Esempio 2

Questa definizione di azione crea una tabella HTML dalla variabile "myItemArray". L'espressione usata dalla proprietà from ottiene la matrice da "myItemArray" usando la funzione variables():

"Create_HTML_table": {
   "type": "Table",
   "inputs": {
      "format": "HTML",
      "from": "@variables('myItemArray')"
   },
   "runAfter": {}
}

Ecco la tabella HTML creata da questa azione:

ID	Product_Name
0	Apples
1	Oranges

esempio 3

Questa definizione di azione crea una tabella HTML dalla variabile "myItemArray". Tuttavia, questo esempio sostituisce i nomi di intestazione di colonna predefiniti con "Stock_ID" e "Description" e aggiunge la parola "Organic" ai valori nella colonna "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": {}
},

Ecco la tabella HTML creata da questa azione:

Stock_ID	Description
0	Mele biologiche
1	Arance organiche

Termina azione

Questa azione arresta l'esecuzione per un'istanza del flusso di lavoro, annulla le azioni in corso, ignora le azioni rimanenti e restituisce lo stato specificato. Ad esempio, è possibile usare l'azione Termina quando l'app per la logica deve uscire completamente da uno stato di errore. Questa azione non influisce sulle azioni già completate e non può essere visualizzata all'interno dei cicli Foreach e Until , inclusi i cicli sequenziali.

"Terminate": {
   "type": "Terminate",
   "inputs": {
       "runStatus": "<status>",
       "runError": {
            "code": "<error-code-or-name>",
            "message": "<error-message>"
       }
   },
   "runAfter": {}
}

Required

Value	Type	Description
< stato>	String	Lo stato da restituire per l'esecuzione: "Failed", "Cancelled" o "Succeeded"

Optional

Le proprietà per l'oggetto "runError" si applicano solo quando la proprietà "runStatus" è impostata sullo stato "Failed".

Value	Type	Description
< error-code-or-name>	String	Il codice o il nome dell'errore
< error-message>	String	Il messaggio o il testo che descrive l'errore e le azioni che l'utente dell'app può eseguire

Example

Questa definizione di azione arresta un'esecuzione del flusso di lavoro, imposta lo stato di esecuzione su "Failed" e restituisce lo stato, un codice di errore e un messaggio di errore:

"Terminate": {
    "type": "Terminate",
    "inputs": {
        "runStatus": "Failed",
        "runError": {
            "code": "Unexpected response",
            "message": "The service received an unexpected response. Please try again."
        }
   },
   "runAfter": {}
}

Azione di attesa

Questa azione sospende l'esecuzione del flusso di lavoro per l'intervallo specificato o fino all'ora specificata, ma non entrambe le cose.

Intervallo specificato

"Delay": {
   "type": "Wait",
   "inputs": {
      "interval": {
         "count": <number-of-units>,
         "unit": "<interval>"
      }
   },
   "runAfter": {}
},

Ora specificata

"Delay_until": {
   "type": "Wait",
   "inputs": {
      "until": {
         "timestamp": "<date-time-stamp>"
      }
   },
   "runAfter": {}
},

Required

Value	Type	Description
< numero di unità>	Integer	Per l'azione Ritardo , numero di unità di attesa
< intervallo>	String	Per l'azione Ritardo , intervallo di attesa: "Second", "Minute", "Hour", "Day", "Week", "Month"
< data e ora>	String	Per l'azione Ritardo fino a , data e ora di ripresa dell'esecuzione. Questo valore deve usare la data e ora in formato UTC.

Esempio 1

Questa definizione di azione sospende il flusso di lavoro per 15 minuti:

"Delay": {
   "type": "Wait",
   "inputs": {
      "interval": {
         "count": 15,
         "unit": "Minute"
      }
   },
   "runAfter": {}
},

Esempio 2

Questa definizione di azione sospende il flusso di lavoro fino all'orario specificato:

"Delay_until": {
   "type": "Wait",
   "inputs": {
      "until": {
         "timestamp": "2017-10-01T00:00:00Z"
      }
   },
   "runAfter": {}
},

Azione flusso di lavoro

Questa azione chiama un'altra app per la logica creata in precedenza, ovvero è possibile includere e riusare altri flussi di lavoro di app per la logica. È anche possibile usare gli output dell'app per la logica figlio o annidata in azioni che seguono l'app per la logica nidificata, purché l'app per la logica figlio restituisca una risposta.

App per la logica di Azure controlla l'accesso al trigger che si vuole chiamare, quindi assicurarsi di poter accedere a tale trigger. Inoltre, l'app per la logica nidificata deve soddisfare questi criteri:

• Un trigger rende l'app per la logica annidata chiamabile, ad esempio un trigger Request o HTTP

• La stessa sottoscrizione di Azure dell'app per la logica padre

• Per usare gli output dell'app per la logica annidata nell'app per la logica padre, l'app per la logica annidata deve avere un'azione Response

"<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	Il nome dell'app per la logica che si vuole richiamare
< trigger-name>	String	Il nome del trigger nell'app per la logica nidificata che si vuole richiamare
< Azure-subscription-ID>	String	L'ID sottoscrizione di Azure per l'app per la logica nidificata
< Azure-resource-group>	String	Il nome del gruppo di risorse di Azure dell'app per la logica nidificata

Optional

Value	Type	Description
< header-content>	Oggetto JSON	Le eventuali intestazioni da inviare con la chiamata
< body-content>	Oggetto JSON	Gli eventuali messaggi da inviare con la chiamata

Outputs

Gli output di questa azione variano a seconda dell'azione Response dell'app per la logica nidificata. Se l'app per la logica nidificata non include un'azione Response, gli output sono vuoti.

Example

Dopo che l'azione "Start_search" viene completata correttamente, questa definizione di azioni del flusso di lavoro chiama un'altra app per la logica denominata "Get_product_information", che passa gli input specificati:

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

Dettagli delle azioni di controllo del flusso di lavoro

Azione Foreach

Questa azione di esecuzione a ciclo continuo scorre una matrice ed esegue azioni per ogni elemento. Per impostazione predefinita, il ciclo "for each" viene eseguito in parallelo fino a un numero massimo di cicli. Per questo valore massimo, vedere Limiti e configurazione. Informazioni su come creare cicli "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	I nomi delle azioni in esecuzione in ogni elemento della matrice
< action-definition-1... n>	Oggetto JSON	Le definizioni delle azioni in esecuzione
< for-each-expression>	String	L'espressione che fa riferimento a ogni elemento nella matrice specificata

Optional

Value	Type	Description
< contare>	Integer	Per impostazione predefinita, le iterazioni del ciclo "for each" vengono eseguite contemporaneamente (simultaneamente o in parallelo) fino al limite predefinito. Per modificare questo limite impostando un nuovo < valore di conteggio>, vedere Modificare la concorrenza del ciclo "for each".
< opzione operation>	String	Per eseguire un ciclo "for each" in sequenza, anziché in parallelo, impostare <operation-option> su Sequential o <count> su 1, ma non su entrambi. Per altre informazioni, vedere Eseguire il ciclo "for each" in modo sequenziale.

Example

Questo ciclo "for each" Invia un messaggio e-mail per ogni elemento della matrice, che contiene gli allegati da un messaggio e-mail in arrivo. Il ciclo invia un messaggio e-mail, incluso l'allegato, a una persona che esamina l'allegato.

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

Per specificare solo una matrice passata come output dal trigger, questa espressione ottiene la <matrice di nomi> di matrice dal corpo del trigger. Per evitare un errore se la matrice non esiste l'espressione usa l'operatore ?:

@triggerBody()?['<array-name>']

Azione if

Questa azione, che è un'istruzione condizionale, valuta un'espressione che rappresenta una condizione ed esegue un ramo diverso in base al fatto che la condizione sia true o false. Se la condizione è true, viene contrassegnata con lo stato "Succeeded". Informazioni su Come creare istruzioni condizionali.

"Condition": {
   "type": "If",
   "expression": { "<condition>" },
   "actions": {
      "<action-1>": { "<action-definition>" }
   },
   "else": {
      "actions": {
        "<action-2>": { "<action-definition" }
      }
   },
   "runAfter": {}
}

Value	Type	Description
< condizione>	Oggetto JSON	La condizione, che può essere un'espressione, da valutare
< action-1>	Oggetto JSON	Azione da eseguire quando <la condizione> restituisce true
< definizione di azione>	Oggetto JSON	La definizione dell'azione
< action-2>	Oggetto JSON	Azione da eseguire quando <la condizione> restituisce false

Le azioni negli oggetti actions o else ottengono questi stati:

• "Succeeded" quando vengono eseguite e riescono
• "Failed" quando vengono eseguite e non riescono
• "Skipped" quando il rispettivo ramo non viene eseguito

Example

Questa condizione specifica che quando la variabile integer ha un valore maggiore di zero, il flusso di lavoro controlla un sito Web. Se la variabile è zero o inferiore a zero, il flusso di lavoro controlla un altro sito 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": {}
}

In che modo le condizioni usano le espressioni

Ecco alcuni esempi che mostrano come è possibile usare espressioni nelle condizioni:

JSON	Result
"expression": "@parameters('<hasSpecialAction>')"	Solo per espressioni booleane, la condizione passa per qualsiasi valore che restituisce true. Per convertire altri tipi in valori in booleano, usare la funzione empty() o equals().
"expression": "@greater(actions('<action>').output.value, parameters('<threshold>'))"	Per le funzioni di confronto, l'azione viene eseguita solo quando l'output <> è maggiore del < valore soglia>.
"expression": "@or(greater(actions('<action>').output.value, parameters('<threshold>')), less(actions('<same-action>').output.value, 100))"	Per le funzioni logiche e la creazione di espressioni booleane annidate, l'azione viene eseguita quando l'output <> è maggiore del < valore soglia> o inferiore a 100.
"expression": "@equals(length(actions('<action>').outputs.errors), 0)"	È possibile usare funzioni di matrice per controllare se una matrice contiene elementi. L'azione viene eseguita quando la matrice errors è vuota.

Azione ambito

Questa azione raggruppa logicamente le azioni negli ambiti, che ottengono il proprio stato dopo che le azioni nell'ambito terminano l'esecuzione. È quindi possibile usare lo stato dell'ambito per determinare se sono in esecuzione altre azioni. Informazioni su come creare gli ambiti.

"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>	Oggetto JSON	Una o più azioni da eseguire all'interno dell'ambito
< input azione>	Oggetto JSON	Gli input per ogni azione

Azione switch

Questa azione, nota anche come istruzione switch, organizza altre azioni in casi e assegna un valore a ogni caso, ad eccezione del caso predefinito, se presente. Quando il flusso di lavoro viene eseguito, l'azione Switch confronta il valore di un'espressione, un oggetto o un token con i valori specificati per ogni caso. Se l'azione Cambia trova un caso corrispondente, il flusso di lavoro esegue solo le azioni per tale caso. Ogni volta che viene eseguita l'azione Switch , esiste solo un caso corrispondente o non esistono corrispondenze. Se non esistono corrispondenze, l'azione Cambia esegue le azioni predefinite. Informazioni su come creare le istruzioni 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	Espressione, oggetto JSON o token da valutare
< action-name>	String	Il nome dell'azione da eseguire per il caso corrispondente
< definizione di azione>	Oggetto JSON	La definizione dell'azione da eseguire per il caso corrispondente
< corrispondenza-valore>	Varies	Il valore da confrontare con il risultato valutato

Optional

Value	Type	Description
< default-action-name>	String	Il nome dell'azione predefinita da eseguire quando non è presente alcun caso corrispondente
< default-action-definition>	Oggetto JSON	La definizione dell'azione da eseguire quando non è presente alcun caso corrispondente

Example

Questa definizione di azione stabilisce se la persona che risponde all'e-mail di richiesta di approvazione ha selezionato l'opzione "Approve" o "Reject". In base a questa scelta, l'azione Cambia esegue le azioni per il caso corrispondente, ovvero inviare un altro messaggio di posta elettronica al risponditore, ma con parole diverse in ogni caso.

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

Fino all'azione

Questa azione del ciclo contiene azioni che vengono eseguite fino a che la condizione specificata è true. Il ciclo verifica la condizione come ultimo passaggio dopo l'esecuzione di tutte le altre azioni. È possibile includere più di un'azione nell'oggetto "actions" e l'azione deve definire almeno un limite. Informazioni su come creare cicli "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	Il nome per l'azione da eseguire all'interno del ciclo
< tipo di azione>	String	Il tipo di azione da eseguire
< input azione>	Various	Gli input per l'azione da eseguire
< condizione>	String	La condizione o espressione da valutare dopo completamento dell'esecuzione di tutte le azioni nel ciclo
< numero di cicli>	Integer	Limite sul numero massimo di cicli che l'azione può eseguire. Per altre informazioni sul limite predefinito e sul limite massimo, vedere Limiti e configurazione per App per la logica di Azure.
< loop-timeout>	String	Il limite sulla durata massima di esecuzione del ciclo. Il valore predefinito timeout è PT1H, che è il formato ISO 8601 obbligatorio.

Note

Se l'espressione dipende dall'output di qualsiasi azione all'interno del ciclo Until, assicurarsi di tenere conto di eventuali errori risultanti da tale azione.

Example

Questa definizione di azione del ciclo invia una richiesta HTTP all'URL specificato fino a quando non viene soddisfatta una delle seguenti condizioni:

• La richiesta ottiene una risposta con codice di stato "200 OK".
• Il ciclo è stato eseguito 60 volte.
• Il ciclo è stato eseguito per un'ora.

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

Webhook e sottoscrizioni

I trigger e le azioni basati su Webhook non controllano regolarmente gli endpoint, ma attendono invece eventi o dati specifici presso tali endpoint. Questi trigger e azioni sottoscrivono gli endpoint fornendo un URL di callback in cui l'endpoint può inviare risposte.

La chiamata subscribe viene effettuata ogni volta che il flusso di lavoro viene modificato, ad esempio quando vengono rinnovate le credenziali o cambiano i parametri di input di un trigger o di un'azione. Questa chiamata usa gli stessi parametri delle azioni HTTP standard.

La chiamata unsubscribe viene effettuata automaticamente quando un'operazione rende il trigger o l'azione non validi, ad esempio:

• Eliminazione o disabilitazione del trigger.
• Eliminazione o disabilitazione del flusso di lavoro.
• Eliminazione o disabilitazione della sottoscrizione.

Per supportare queste chiamate, l'espressione @listCallbackUrl() restituisce un "URL di callback" univoco per questo trigger o azione. Questo URL rappresenta un identificatore univoco per gli endpoint che usano l'API REST del servizio. I parametri per questa funzione sono gli stessi del trigger o dell'azione di webhook.

Modificare la durata asincrona

Per i trigger e azioni, è possibile limitare la durata del modello asincrono a un intervallo di tempo specifico aggiungendo la proprietà limit.timeout. In questo modo, se l'azione non è terminata quando è trascorso l'intervallo, lo stato dell'azione è contrassegnato come Cancelled con il codice ActionTimedOut. La proprietà timeout usa il formato ISO 8601.

"<trigger-or-action-name>": {
   "type": "Workflow | Webhook | Http | ApiConnectionWebhook | ApiConnection",
   "inputs": {},
   "limit": {
      "timeout": "PT10S"
   },
   "runAfter": {}
}

Impostazioni configurazione di runtime

È possibile modificare il comportamento di runtime predefinito per trigger e azioni aggiungendo queste runtimeConfiguration proprietà alla definizione del trigger o dell'azione.

Property	Type	Description	Trigger o azione
runtimeConfiguration.concurrency.runs	Integer	Modificare il limite predefinito per il numero di istanze del flusso di lavoro che possono essere eseguite contemporaneamente (simultaneamente o in parallelo). La modifica di questo valore consente di limitare il numero di richieste ricevute dai sistemi back-end. L'impostazione della proprietà runs su 1 funziona allo stesso modo dell'impostazione della proprietà operationOptions su SingleInstance. È possibile impostare una delle proprietà, ma non entrambe. Per modificare il limite predefinito, vedere Modificare la concorrenza dei trigger oppure Attivazione sequenziale delle istanze.	Tutti i trigger
runtimeConfiguration.concurrency.maximumWaitingRuns	Integer	Modificare il limite predefinito per il numero di istanze del flusso di lavoro che devono attendere l'esecuzione quando l'app per la logica esegue già il numero massimo di istanze simultanee. Per modificare il limite predefinito, vedere Modificare il limite delle esecuzioni in attesa.	Tutti i trigger
runtimeConfiguration.concurrency.repetitions	Integer	Modificare il limite predefinito per il numero di iterazioni del ciclo "for each" che possono essere eseguite contemporaneamente (simultaneamente o in parallelo). L'impostazione della proprietà repetitions su 1 funziona allo stesso modo dell'impostazione della proprietà operationOptions su SingleInstance. È possibile impostare una delle proprietà, ma non entrambe. Per modificare il limite predefinito, vedere Modificare la concorrenza "for each" oppure Eseguire i cicli "for each" in sequenza.	Action: Foreach
runtimeConfiguration.paginationPolicy.minimumItemCount	Integer	Per azioni specifiche che supportano e hanno l'impaginazione attivata, questo valore specifica il numero minimo di risultati da recuperare. Per attivare l'impaginazione, vedere Ottenere dati, elementi o risultati in blocco usando l'impaginazione	Azione: Vari
runtimeConfiguration.secureData.properties	Array	In molti trigger e azioni, queste impostazioni nascondono input, output o entrambi dalla cronologia di esecuzione dell'app per la logica. Per altre informazioni sulla protezione di questi dati, vedere Nascondere input e output dalla cronologia di esecuzione.	La maggior parte dei trigger e delle azioni
runtimeConfiguration.staticResult	Oggetto JSON	Per le azioni che supportano e hanno l'impostazione dei risultati statica attivata, l'oggetto staticResult ha questi attributi: - name, che fa riferimento al nome della definizione statica del risultato dell'azione corrente, visualizzato all'interno dell'attributo nell'attributo del flusso di lavoro dell'app staticResults per la definition logica. Per altre informazioni, vedere Risultati statici - Informazioni di riferimento sullo schema per Workflow Definition Language. - staticResultOptions, che specifica se i risultati statici sono Enabled o meno per l'azione corrente. Per attivare i risultati statici, vedere Testare le app per la logica con dati fittizi configurando i risultati statici	Azione: Vari

Opzioni dell'operazione

È possibile modificare il comportamento predefinito dei trigger e delle azioni con la proprietà operationOptions nella definizione del trigger o dell'azione.

Opzione operazione	Type	Description	Trigger o azione
DisableAsyncPattern	String	Eseguire le azioni basate su HTTP in modo sincrono, anziché in modo asincrono. Per impostare questa opzione, vedere Eseguire le azioni in modo sincrono.	Actions: ApiConnection, HTTP, Response
IncludeAuthorizationHeadersInOutputs	String	Per le app per la logica che consentono a OAuth con MICROSOFT Entra ID di autorizzare l'accesso per le chiamate in ingresso a un endpoint trigger basato su richiesta, includere l'intestazione Authorization del token di accesso OAuth negli output del trigger. Per altre informazioni, vedere Includere l'intestazione 'Authorization' negli output dei trigger di richiesta.	Triggers: Request, HTTP Webhook
Sequential	String	Esegue le iterazioni del ciclo "for each" una alla volta, anziché tutte contemporaneamente in parallelo. L'opzione funziona allo stesso modo dell'impostazione della proprietà runtimeConfiguration.concurrency.repetitions su 1. È possibile impostare una delle proprietà, ma non entrambe. Per impostare questa opzione, vedere Eseguire il ciclo "for each" in modo sequenziale.	Action: Foreach
SingleInstance	String	Esegue il trigger per ogni istanza dell'app per la logica in modo sequenziale e attende la fine dell'esecuzione attiva precedente prima di attivare la successiva istanza di app per la logica. L'opzione funziona allo stesso modo dell'impostazione della proprietà runtimeConfiguration.concurrency.runs su 1. È possibile impostare una delle proprietà, ma non entrambe. Per impostare questa opzione, vedere Attivazione delle istanze in modo sequenziale.	Tutti i trigger
SuppressWorkflowHeaders	String	Non inviare x-ms-* intestazioni di metadati nelle richieste in uscita. Per impostazione predefinita, App per la logica di Azure include intestazioni di metadati aggiuntive con il x-ms- prefisso nel nome dell'intestazione come parte delle richieste in uscita. Tuttavia, alcuni servizi legacy non accetterà le richieste con intestazioni sconosciute aggiuntive, causando richieste non riuscite.	Actions: HTTP, Function, APIManagement
SuppressWorkflowHeadersOnResponse	String	Non inviare x-ms-* intestazioni di metadati nelle risposte alle richieste di trigger in ingresso. Per impostazione predefinita, App per la logica di Azure invia risposte alle richieste in ingresso che includono intestazioni di metadati aggiuntive con il x-ms- prefisso nel nome dell'intestazione. Tuttavia, alcuni servizi legacy non accetterà richieste o risposte con intestazioni sconosciute aggiuntive, causando richieste non riuscite.	Triggers: Request, HTTP Webhook

Modificare la concorrenza dei trigger

Per impostazione predefinita, tutte le istanze del flusso di lavoro dell'app per la logica vengono eseguite contemporaneamente (simultaneamente o in parallelo). Questo comportamento indica che ogni istanza del trigger viene attivata prima che l'istanza del flusso di lavoro attiva in precedenza venga completata l'esecuzione. Tuttavia, il numero di istanze in esecuzione simultanea ha un limite predefinito. Quando il numero di istanze del flusso di lavoro in esecuzione simultanea raggiunge questo limite, tutte le altre nuove istanze devono attendere l'esecuzione. Questo limite consente di controllare il numero di richieste ricevute dai sistemi back-end.

Quando si attiva il controllo di concorrenza del trigger, le istanze del trigger vengono eseguite in parallelo fino al limite predefinito. Per modificare questo limite di concorrenza predefinito, è possibile usare l'editor della visualizzazione codice o la finestra di progettazione del flusso di lavoro perché la modifica dell'impostazione di concorrenza tramite la finestra di progettazione aggiunge o aggiorna la runtimeConfiguration.concurrency.runs proprietà nella definizione del trigger sottostante e viceversa. Questa proprietà controlla il numero massimo di nuove istanze del flusso di lavoro che possono essere eseguite in parallelo.

Prima di abilitare la concorrenza in un trigger, esaminare le considerazioni seguenti:

• Non è possibile disabilitare la concorrenza dopo aver abilitato il controllo della concorrenza.

• Se il numero massimo di esecuzioni di trigger simultanei raggiunge il massimo grado di parallelismo, le esecuzioni successive del trigger potrebbero riscontrare errori di limitazione o "429 - Troppe richieste". Se si configura un criterio di ripetizione dei tentativi che gestisce gli errori 429, il trigger potrebbe riscontrare un ciclo di tentativi e un comportamento di limitazione che causa lunghi ritardi nell'elaborazione di nuove richieste di trigger.

• Quando la concorrenza è abilitata, la divisione al limite viene notevolmente ridotta per le matrici di debatching. Se il numero di elementi supera questo limite, la funzionalità Split on è disabilitata.

• Quando la concorrenza è abilitata, un'istanza dell'app per la logica a esecuzione prolungata potrebbe causare l'immissione di nuove istanze dell'app per la logica in uno stato di attesa. Questo stato impedisce App per la logica di Azure di creare nuove istanze e si verifica anche quando il numero di esecuzioni simultanee è inferiore al numero massimo specificato di esecuzioni simultanee.

  • Per interrompere questo stato, annullare le prime istanze ancora in esecuzione.

    1. Nel menu dell'app per la logica selezionare Panoramica.

    2. Nella sezione Cronologia esecuzioni selezionare l'istanza meno recente ancora in esecuzione, ad esempio:

       

       Tip

       Per visualizzare solo le istanze ancora in esecuzione, aprire l'elenco Tutti e selezionare In esecuzione.

    3. In Esecuzione dell'app per la logica selezionare Annulla esecuzione.

       

  • Per ovviare a questa possibilità, aggiungere un timeout a qualsiasi azione che potrebbe contenere queste esecuzioni. Se si lavora nell'editor di codice, vedere Modificare la durata asincrona. In caso contrario, se si usa la finestra di progettazione, seguire questa procedura:

    1. Nel flusso di lavoro dell'app per la logica selezionare l'azione in cui si vuole aggiungere un timeout. Nell'angolo superiore destro dell'azione selezionare il pulsante con i puntini di sospensione (...) e quindi selezionare Impostazioni.

       

    2. In Timeout specificare la durata del timeout nel formato ISO 8601.

       

• Per eseguire l'app per la logica in sequenza, impostare la concorrenza del trigger su 1 usando l'editor della visualizzazione codice o la finestra di progettazione. Assicurarsi di non impostare anche la proprietà del operationOptions trigger su SingleInstance nell'editor di visualizzazione codice. Altrimenti si verifica un errore di convalida. Per altre informazioni, vedere Attivazione delle istanze in modo sequenziale.

Modifica in visualizzazione codice

Nella definizione del trigger sottostante aggiungere la runtimeConfiguration.concurrency.runs proprietà e impostare il valore in base ai limiti di concorrenza del trigger. Per eseguire il flusso di lavoro in sequenza, impostare il valore della proprietà su 1.

Questo esempio limita le esecuzioni simultanee a 10 istanze:

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

Per altre informazioni vedere Impostazioni di configurazione di runtime.

Modifica nella finestra di progettazione del flusso di lavoro

1. Nell'angolo superiore destro del trigger selezionare il pulsante con i puntini di sospensione (...) e quindi selezionare Impostazioni.

2. In Controllo concorrenza impostare Limite su Sì.

3. Trascinare il dispositivo di scorrimento Degree of Parallelism (Grado di parallelismo) sul valore desiderato. Per eseguire l'app per la logica in sequenza, trascinare il valore del dispositivo di scorrimento su 1.

Modifica della concorrenza "for each"

Per impostazione predefinita, le iterazioni del ciclo "for each" vengono eseguite contemporaneamente (simultaneamente o in parallelo). Questo comportamento significa che ogni iterazione viene avviata prima che l'iterazione precedente finisca l'esecuzione. Tuttavia, il numero di iterazioni in esecuzione simultanea ha un limite predefinito. Quando il numero di iterazioni in esecuzione simultanea raggiunge questo limite, tutte le altre iterazioni devono attendere l'esecuzione.

Per modificare il limite predefinito, è possibile usare l'editor della visualizzazione codice o la finestra di progettazione del flusso di lavoro perché la modifica dell'impostazione di concorrenza tramite la finestra di progettazione aggiunge o aggiorna la runtimeConfiguration.concurrency.repetitions proprietà nella definizione di azione "for each" sottostante e viceversa. Questa proprietà controlla il numero massimo di iterazioni che è possibile eseguire in parallelo.

Note

Se si imposta l'esecuzione sequenziale dell'azione "for each" tramite la finestra di progettazione o l'editor della visualizzazione codice, non impostare la proprietà operationOptions dell'azione su Sequential nell'editor della visualizzazione codice. Altrimenti si verifica un errore di convalida. Per altre informazioni, vedere Eseguire il ciclo "for each" in modo sequenziale.

Modifica in visualizzazione codice

Nella definizione "for each" sottostante aggiungere o aggiornare la runtimeConfiguration.concurrency.repetitions proprietà , che può avere un valore compreso tra 1 e 50.

Ecco un esempio che limita le esecuzioni simultanee a 10 iterazioni:

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

Per altre informazioni vedere Impostazioni di configurazione di runtime.

Modifica nella finestra di progettazione del flusso di lavoro

1. Nell'angolo in alto a destra dell'azione Per ogni azione selezionare i puntini di sospensione (...) e quindi selezionare Impostazioni.

2. In Controllo concorrenza impostare Controllo concorrenza su Sì.

3. Trascinare il dispositivo di scorrimento Degree of Parallelism (Grado di parallelismo) sul valore desiderato. Per eseguire l'app per la logica in sequenza, trascinare il valore del dispositivo di scorrimento su 1.

Modifica del limite delle esecuzioni in attesa

Per impostazione predefinita, tutte le istanze del flusso di lavoro dell'app per la logica vengono eseguite contemporaneamente (simultaneamente o in parallelo). Questo comportamento indica che ogni istanza del trigger viene attivata prima che l'istanza del flusso di lavoro attiva in precedenza venga completata l'esecuzione. Tuttavia, esiste un limite predefinito per il numero di istanze del flusso di lavoro in esecuzione simultanea. Quando il numero di esecuzioni simultanee raggiunge questo limite, tutte le altre nuove istanze del flusso di lavoro devono attendere l'esecuzione. Esiste anche un limite predefinito per il numero di istanze del flusso di lavoro in attesa. Quando il numero di istanze in attesa raggiunge questo limite, App per la logica di Azure non accetta più nuove istanze del flusso di lavoro da eseguire. I trigger di richiesta e webhook restituiscono 429 - Troppi errori di richiesta e trigger ricorrenti avviano il polling dei tentativi.

È possibile modificare il limite predefinito per la concorrenza dei trigger e il limite predefinito per le esecuzioni in attesa. Tuttavia, questa modifica rallenta principalmente il trigger per alleviare la pressione a causa della concorrenza. Ad esempio, se si dispone di un trigger di polling e la coda di esecuzioni in attesa è piena a causa delle esecuzioni in corso, App per la logica di Azure interrompe il polling. Se il flusso di lavoro usa un trigger basato su richiesta e la coda di esecuzioni in attesa è piena, App per la logica di Azure inizia a restituire l'errore 429. Esistono alcuni scenari in cui App per la logica di Azure non è in grado di arrestare il trigger dal polling senza introdurre errori e sceglie di aggiungere tali esecuzioni alla coda di esecuzioni in attesa comunque senza errori durante le esecuzioni chiamanti.

Nella definizione del trigger sottostante aggiungere la runtimeConfiguration.concurrency.maximumWaitingRuns proprietà , che può avere un valore compreso tra 1 e 100.

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

Per altre informazioni vedere Impostazioni di configurazione di runtime.

Attivare le istanze in sequenza

Per eseguire ogni istanza del flusso di lavoro dell'app per la logica solo al termine dell'esecuzione dell'istanza precedente, impostare il trigger per l'esecuzione sequenziale. È possibile usare l'editor della visualizzazione codice o la finestra di progettazione del flusso di lavoro perché la modifica dell'impostazione di concorrenza tramite la finestra di progettazione aggiunge o aggiorna anche la runtimeConfiguration.concurrency.runs proprietà nella definizione del trigger sottostante e viceversa.

Note

Quando si imposta l'esecuzione sequenziale di un trigger tramite la finestra di progettazione o l'editor della visualizzazione codice, non impostare la proprietà operationOptions del trigger su Sequential nell'editor della visualizzazione codice. Altrimenti si verifica un errore di convalida.

Modifica in visualizzazione codice

Nella definizione del trigger, impostare una di queste proprietà, ma non entrambe.

Impostare la proprietà runtimeConfiguration.concurrency.runs su 1:

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

-or-

Impostare la proprietà operationOptions su SingleInstance:

"<trigger-name>": {
   "type": "<trigger-name>",
   "recurrence": {
      "frequency": "<time-unit>",
      "interval": <number-of-time-units>,
   },
   "operationOptions": "SingleInstance"
}

Per altre informazioni, vedere Impostazioni di configurazione del runtime e Opzioni operative.

Modifica nella finestra di progettazione del flusso di lavoro

1. Nell'angolo superiore destro del trigger selezionare il pulsante con i puntini di sospensione (...) e quindi selezionare Impostazioni.

2. In Controllo concorrenza impostare Limite su Sì.

3. Trascinare il dispositivo di scorrimento Degree of Parallelism (Grado di parallelismo) sul numero 1.

Esecuzione dei cicli "for each" in modo sequenziale

Per eseguire un'iterazione del ciclo "for each" solo al termine dell'esecuzione dell'iterazione precedente, impostare l'azione "for each" per l'esecuzione sequenziale. È possibile usare l'editor della visualizzazione codice o la finestra di progettazione del flusso di lavoro perché la modifica della concorrenza dell'azione tramite la finestra di progettazione aggiunge o aggiorna anche la runtimeConfiguration.concurrency.repetitions proprietà nella definizione dell'azione sottostante e viceversa.

Note

Quando si imposta l'esecuzione sequenziale di un'azione "for each" tramite la finestra di progettazione o l'editor della visualizzazione codice, non impostare la proprietà operationOptions dell'azione su Sequential nell'editor della visualizzazione codice. Altrimenti si verifica un errore di convalida.

Modifica in visualizzazione codice

Nella definizione dell'azione impostare una di queste proprietà ma non entrambe.

Impostare la proprietà runtimeConfiguration.concurrency.repetitions su 1:

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

-or-

Impostare la proprietà operationOptions su Sequential:

"For_each" {
   "type": "Foreach",
   "actions": { "<actions-to-run>" },
   "foreach": "<for-each-expression>",
   "runAfter": {},
   "operationOptions": "Sequential"
}

Per altre informazioni, vedere Impostazioni di configurazione del runtime e Opzioni operative.

Modifica nella finestra di progettazione del flusso di lavoro

1. Nell'angolo in alto a destra di ogni azione selezionare il pulsante con i puntini di sospensione (...) e quindi selezionare Impostazioni.

2. In Controllo concorrenza impostare Controllo concorrenza su Sì.

3. Trascinare il dispositivo di scorrimento Degree of Parallelism (Grado di parallelismo) sul numero 1.

Eseguire azioni in un modello di operazione sincrona

Per impostazione predefinita, l'azione HTTP e le azioni APIConnection in App per la logica di Azure seguono il modello di operazione asincrona standard, mentre l'azione Risposta segue il modello di operazione sincrona. Il modello asincrono specifica che dopo che un'azione chiama o invia una richiesta all'endpoint, al servizio, al sistema o all'API specificati, il ricevitore restituisce immediatamente una risposta "202 ACCEPTED". Questo codice conferma che il destinatario ha accettato la richiesta ma non ha terminato l'elaborazione. La risposta può includere un'intestazione location che specifica l'URL e un ID di aggiornamento che il chiamante può usare per eseguire continuamente il polling o controllare lo stato della richiesta asincrona finché il ricevitore non interrompe l'elaborazione e restituisce una risposta di esito positivo "200 OK" o un'altra risposta non 202. Per altre informazioni, vedere Integrazione asincrona di microservizi applica l'autonomiadei microservizi.

• In Progettazione app per la logica l'azione HTTP, le azioni APIConnection e l'azione Risposta hanno l'impostazione Modello asincrono . Se abilitata, questa impostazione specifica che il chiamante non attende il completamento dell'elaborazione e può passare all'azione successiva, ma continua a controllare lo stato fino all'arresto dell'elaborazione. Se disabilitata, questa impostazione specifica che il chiamante attende il completamento dell'elaborazione prima di passare all'azione successiva. Per trovare questa impostazione, seguire questa procedura:

  1. Sulla barra del titolo dell'azione HTTP selezionare il pulsante con i puntini di sospensione (...) che apre le impostazioni dell'azione.

  2. Trovare l'impostazione Modello asincrono .

     

• Nella definizione JSON (JavaScript Object Notation) sottostante dell'azione, le azioni HTTP e APIConnection seguono in modo implicito il modello di operazione asincrona.

In alcuni scenari potrebbe essere necessario che un'azione segua invece il modello sincrono. Ad esempio, quando si usa l'azione HTTP, è possibile:

• Evitare timeout HTTP per le attività a esecuzione prolungata
• Disabilitare il controllo delle intestazioni dei percorsi

In questi casi, è possibile eseguire un'azione in modo sincrono usando queste opzioni:

• Sostituire la versione di polling di tale azione con una versione del webhook, se disponibile.

• Disabilitare il comportamento asincrono dell'azione seguendo questa opzione:

  • In Progettazione app per la logica disattivare l'impostazione Modello asincrono.

  • Nella definizione JSON sottostante dell'azione aggiungere l'opzione "DisableAsyncPattern"operation.

Disattiva impostazione modello asincrono

1. Nella barra del titolo dell'azione di Progettazione app per la logica selezionare il pulsante con i puntini di sospensione (...) che apre le impostazioni dell'azione.

2. Trovare l'impostazione Modello asincrono , disattivare l'impostazione su Disattivato se abilitata e selezionare Fine.

   

Disabilitare il modello asincrono nella definizione JSON dell'azione

Nella definizione JSON sottostante dell'azione aggiungere e impostare la proprietà "operationOptions" su "DisableAsyncPattern" nella sezione dell'azione "inputs" , ad esempio:

"<some-long-running-action>": {
   "type": "Http",
   "inputs": { "<action-inputs>" },
   "operationOptions": "DisableAsyncPattern",
   "runAfter": {}
}

Autenticare trigger e azioni

Gli endpoint HTTP e HTTPS supportano diversi tipi di autenticazione. In base al trigger o all'azione usata per effettuare chiamate o richieste in uscita per accedere a questi endpoint, è possibile selezionare da diversi intervalli di tipi di autenticazione. Per altre informazioni, vedere Aggiungere l'autenticazione alle chiamate in uscita.

Passaggi successivi

• Leggere altre informazioni sul linguaggio di definizione del flusso di lavoro