Ricevere e rispondere alle chiamate HTTPS in ingresso ai flussi di lavoro in App per la logica di Azure
Si applica a: App per la logica di Azure (consumo + standard)
Questa guida pratica illustra come creare un flusso di lavoro dell'app per la logica in grado di ricevere e gestire una richiesta HTTPS in ingresso o una chiamata da un altro servizio usando il trigger predefinito Richiesta. Quando il flusso di lavoro usa questo trigger, è quindi possibile rispondere alla richiesta HTTPS usando l'azione predefinita Risposta.
Nota
L'azione Risposta funziona solo quando si usa il trigger Richiesta.
Questo elenco, ad esempio, descrive alcune attività che il flusso di lavoro può eseguire quando si usa l'azione Richiesta trigger e risposta:
Riceva e risponda a una richiesta HTTPS di dati in un database locale.
Ricevere e rispondere a una richiesta HTTPS inviata da un altro flusso di lavoro dell'app per la logica.
Attivare un flusso di lavoro eseguito quando si verifica un evento webhook esterno.
Per eseguire il flusso di lavoro inviando invece una richiesta in uscita o in uscita, usare il trigger predefinito HTTP o l'azione predefinita HTTP.
Prerequisiti
Account e sottoscrizione di Azure. Se non si ha una sottoscrizione, è possibile iscriversi per creare un account Azure gratuito.
Flusso di lavoro dell'app per la logica in cui si vuole ricevere la richiesta HTTPS in ingresso. Per avviare il flusso di lavoro con un trigger di richiesta, è necessario iniziare con un flusso di lavoro vuoto. Per usare l'azione Risposta, il flusso di lavoro deve iniziare con il trigger Richiesta.
Aggiungere un trigger di richiesta
Il trigger Request crea un endpoint chiamabile manualmente che gestisce solo le richieste in ingresso su HTTPS. Quando il chiamante invia una richiesta a questo endpoint, il trigger di richiesta viene attivato ed esegue il flusso di lavoro. Per informazioni su come chiamare questo trigger, vedere Chiamare, attivare o annidare flussi di lavoro con endpoint HTTPS in App per la logica di Azure.
Nella portale di Azure aprire l'app per la logica a consumo e il flusso di lavoro vuoto nella finestra di progettazione.
Nella finestra di progettazione seguire questi passaggi generali per trovare e aggiungere il trigger predefinito Richiesta denominato Quando viene ricevuta una richiesta HTTP.
Dopo aver visualizzato la casella delle informazioni sul trigger, specificare le informazioni seguenti in base alle esigenze:
Nome proprietà Nome proprietà JSON Richiesto Descrizione URL POST HTTP {none} Sì L'URL dell'endpoint generato dopo il salvataggio del flusso di lavoro e viene usato per inviare una richiesta che attiva il flusso di lavoro. Corpo della richiesta: Schema JSON schema
No Schema JSON che descrive le proprietà e i valori nel corpo della richiesta in ingresso. La finestra di progettazione usa questo schema per generare token per le proprietà nella richiesta. In questo modo, il flusso di lavoro può analizzare, utilizzare e passare output dal trigger Richiesta al flusso di lavoro.
Se non si ha uno schema JSON, è possibile generare lo schema da un payload di esempio usando il payload Di esempio per generare la funzionalità dello schema .L'esempio seguente mostra uno schema JSON di esempio:
L'esempio seguente mostra lo schema JSON di esempio completo:
{ "type": "object", "properties": { "account": { "type": "object", "properties": { "name": { "type": "string" }, "ID": { "type": "string" }, "address": { "type": "object", "properties": { "number": { "type": "string" }, "street": { "type": "string" }, "city": { "type": "string" }, "state": { "type": "string" }, "country": { "type": "string" }, "postalCode": { "type": "string" } } } } } } }
Quando si immette uno schema JSON, la finestra di progettazione mostra un promemoria per includere l'intestazione Content-Type nella richiesta e impostare tale valore di intestazione su application/json. Per altre informazioni, vedere Gestire i tipi di contenuti.
L'esempio seguente mostra come viene visualizzata l'intestazione Content-Type in formato JSON:
{ "Content-Type": "application/json" }
Per generare uno schema JSON basato sul payload previsto (dati), è possibile usare uno strumento come JSONSchema.netoppure seguire questa procedura:
Nel trigger di richiesta selezionare Usare il payload di esempio per generare lo schema.
Immettere il payload di esempio e selezionare Fine.
L'esempio seguente mostra il payload di esempio:
{ "account": { "name": "Contoso", "ID": "12345", "address": { "number": "1234", "street": "Anywhere Street", "city": "AnyTown", "state": "AnyState", "country": "USA", "postalCode": "11111" } } }
Per verificare che la chiamata in ingresso abbia un corpo della richiesta corrispondente allo schema specificato, seguire questa procedura:
Per applicare il messaggio in ingresso per avere gli stessi campi dello schema descritti nello schema, aggiungere la
required
proprietà e specificare i campi obbligatori. Aggiungere laaddtionalProperties
proprietà e impostare il valore sufalse
.Ad esempio, lo schema seguente specifica che il messaggio in ingresso deve avere il
msg
campo e non altri campi:{ "properties": { "msg": { "type": "string" } }, "type": "object", "required": ["msg"], "additionalProperties": false }
Nella barra del titolo del trigger di richiesta selezionare il pulsante con i puntini di sospensione (...).
Nelle impostazioni del trigger attivare Convalida dello schema e selezionare Fine.
Se il corpo della richiesta della chiamata in ingresso non corrisponde allo schema, il trigger restituisce un errore HTTP 400 Richiesta non valida.
Per aggiungere altre proprietà o parametri al trigger, aprire l'elenco Aggiungi nuovo parametro e selezionare i parametri da aggiungere.
Nome proprietà Nome proprietà JSON Richiesto Descrizione Method method
No Metodo che le richieste in ingresso devono usare per chiamare l'app per la logica Percorso relativo relativePath
No Percorso relativo per il parametro che l'URL dell'endpoint dell'app per la logica può accettare Nell'esempio seguente viene aggiunta la proprietà Method :
La proprietà Metodo viene visualizzata nel trigger, in modo che sia possibile selezionare un metodo nell'elenco.
Quando si è pronti, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.
Questo passaggio genera l'URL che è possibile usare per inviare una richiesta che attiva il flusso di lavoro.
Per copiare l'URL generato, selezionare l'icona di copia accanto all'URL.
Nota
Se si vuole includere il simbolo hash o cancelletto (#) nell'URI quando si effettua una chiamata al trigger di richiesta, usare invece questa versione codificata:
%25%23
Continuare a creare il flusso di lavoro aggiungendo un'altra azione come passaggio successivo. Ad esempio, è possibile rispondere alla richiesta aggiungendo un'azione Risposta, che è possibile usare per restituire una risposta personalizzata ed è descritta più avanti in questo articolo.
Nota
Il flusso di lavoro mantiene aperta una richiesta in ingresso solo per un periodo di tempo limitato. Supponendo che il flusso di lavoro includa anche un'azione Risposta, se il flusso di lavoro non restituisce una risposta al chiamante dopo questa scadenza, il flusso di lavoro restituisce lo stato 504 GATEWAY TIMEOUT al chiamante. Se il flusso di lavoro non include un'azione Risposta, il flusso di lavoro restituisce immediatamente lo stato 202 ACCEPTED al chiamante.
Per informazioni sulla sicurezza, l'autorizzazione e la crittografia per le chiamate in ingresso al flusso di lavoro, ad esempio Transport Layer Security (TLS), noto in precedenza come Secure Sockets Layer (SSL), Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), esporre la risorsa dell'app per la logica con Azure Gestione API o limitare gli indirizzi IP che hanno origine chiamate in ingresso, vedere Accesso sicuro e dati: accesso per le chiamate in ingresso ai trigger basati su richiesta.
Output dei trigger
La tabella seguente elenca gli output del trigger di richiesta:
Nome proprietà JSON | Tipo di dati | Descrizione |
---|---|---|
headers | Oggetto | Oggetto JSON che descrive le intestazioni della richiesta |
body | Oggetto | Oggetto JSON che descrive il contenuto del corpo della richiesta |
Aggiungere un'azione di risposta
Quando si usa il trigger Richiesta per ricevere richieste in ingresso, è possibile modellare la risposta e inviare di nuovo i risultati del payload al chiamante usando l'azione predefinita Risposta, che funziona solo con il trigger Richiesta. Questa combinazione con il trigger di richiesta e l'azione Risposta crea il modello request-response. Ad eccezione dei cicli Foreach e dei cicli Until e dei rami paralleli, è possibile aggiungere l'azione Response in qualsiasi punto del flusso di lavoro.
Importante
Se l'azione Risposta include le intestazioni seguenti, App per la logica di Azure rimuove automaticamente queste intestazioni dal messaggio di risposta generato senza visualizzare alcun avviso o errore. App per la logica di Azure non includerà queste intestazioni, anche se il servizio non impedirà di salvare i flussi di lavoro con un'azione Response con queste intestazioni.
Allow
Content-*
intestazioni ad eccezione diContent-Disposition
,Content-Encoding
eContent-Type
quando si usano le operazioni POST e PUT, ma non sono incluse per le operazioni GETCookie
Expires
Last-Modified
Set-Cookie
Transfer-Encoding
Se si dispone di una o più azioni response in un flusso di lavoro complesso con rami, assicurarsi che il flusso di lavoro elabori almeno un'azione Response durante il runtime. In caso contrario, se tutte le azioni Response vengono ignorate, il chiamante riceve un errore 502 Gateway non valido, anche se il flusso di lavoro termina correttamente.
In un flusso di lavoro senza stato dell'app per la logica Standard, l'azione Risposta deve essere visualizzata per ultimo nel flusso di lavoro. Se l'azione viene visualizzata altrove, App per la logica di Azure comunque non eseguirà l'azione finché tutte le altre azioni non terminano l'esecuzione.
Nella finestra di progettazione del flusso di lavoro seguire questi passaggi generali per trovare e aggiungere l'azione predefinita Response denominata Response( Risposta predefinita).
Per semplicità, gli esempi seguenti mostrano un trigger di richiesta compresso.
Nella casella informazioni sull'azione aggiungere i valori necessari per il messaggio di risposta.
Nome proprietà Nome proprietà JSON Richiesto Descrizione Codice di stato statusCode
Sì Codice di stato da restituire nella risposta Intestazioni headers
No Oggetto JSON che descrive una o più intestazioni da includere nella risposta Testo body
No Il corpo della risposta Quando si seleziona all'interno di qualsiasi campo di testo, viene aperto automaticamente l'elenco di contenuto dinamico. È quindi possibile selezionare i token che rappresentano gli output disponibili dei passaggi precedenti nel flusso di lavoro. Le proprietà dello schema specificate vengono visualizzate anche in questo elenco di contenuto dinamico. È possibile selezionare queste proprietà da usare nel flusso di lavoro.
Ad esempio, nel campo Intestazioni includere Content-Type come nome della chiave e impostare il valore della chiave su application/json come indicato in precedenza in questo articolo. Per la casella Corpo, è possibile selezionare l'output del corpo del trigger dall'elenco dei contenuti dinamici.
Per visualizzare le intestazioni in formato JSON, selezionare Passa alla visualizzazione Testo.
Per aggiungere altre proprietà per l'azione, ad esempio uno schema JSON per il corpo della risposta, nell'elenco Aggiungi nuovo parametro selezionare i parametri da aggiungere.
Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.
Testare il flusso di lavoro
Per testare il flusso di lavoro, inviare una richiesta HTTP all'URL generato. Ad esempio, è possibile usare uno strumento come Postman per inviare la richiesta HTTP. Per altre informazioni sulla definizione JSON sottostante al trigger e su come chiamare questo trigger, vedere gli argomenti Tipo di trigger di richiesta e Chiamare, attivare o annidare flussi di lavoro con endpoint HTTP in App per la logica di Azure.
Sicurezza e autenticazione
In un flusso di lavoro dell'app per la logica Standard che inizia con il trigger di richiesta (ma non con un trigger webhook), è possibile usare il provisioning Funzioni di Azure per autenticare le chiamate in ingresso inviate all'endpoint creato da tale trigger usando un'identità gestita. Questo provisioning è noto anche come "Easy Auth". Per altre informazioni, vedere Attivare flussi di lavoro nelle app per la logica Standard con Easy Auth.
Per altre informazioni sulla sicurezza, l'autorizzazione e la crittografia per le chiamate in ingresso al flusso di lavoro dell'app per la logica, ad esempio Transport Layer Security (TLS), noto in precedenza come Secure Sockets Layer (SSL), Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), esporre l'app per la logica con Azure Gestione API o limitare gli indirizzi IP che hanno origine chiamate in ingresso, vedere Accesso sicuro e dati: accesso per le chiamate in ingresso ai trigger basati su richiesta.
Passaggi successivi
Commenti e suggerimenti
https://aka.ms/ContentUserFeedback.
Presto disponibile: Nel corso del 2024 verranno gradualmente disattivati i problemi di GitHub come meccanismo di feedback per il contenuto e ciò verrà sostituito con un nuovo sistema di feedback. Per altre informazioni, vedereInvia e visualizza il feedback per