Chiamare endpoint HTTP o HTTPS esterni dai flussi di lavoro in App per la logica di Azure
Si applica a: App per la logica di Azure (consumo + standard)
Alcuni scenari potrebbero richiedere la creazione di un flusso di lavoro dell'app per la logica che invia richieste in uscita agli endpoint in altri servizi o sistemi tramite HTTP o HTTPS. Si supponga, ad esempio, di voler monitorare un endpoint di servizio per il sito Web controllando tale endpoint in base a una pianificazione specifica. Quando si verifica un evento specifico in tale endpoint, ad esempio il sito Web inattivo, tale evento attiva il flusso di lavoro ed esegue le azioni in tale flusso di lavoro.
Nota
Per creare invece un flusso di lavoro che riceve e risponde alle chiamate HTTPS in ingresso, vedere Creare flussi di lavoro che è possibile chiamare, attivare o annidare usando gli endpoint HTTPS in App per la logica di Azure e l'azione di richiesta e risposta predefinita.
Questa guida illustra come usare il trigger HTTP e l'azione HTTP in modo che il flusso di lavoro possa inviare chiamate in uscita ad altri servizi e sistemi, ad esempio:
Per controllare o eseguire il polling di un endpoint in base a una pianificazione ricorrente, aggiungere il trigger HTTP come primo passaggio del flusso di lavoro. Ogni volta che il trigger controlla l'endpoint, il trigger chiama o invia una richiesta all'endpoint. La risposta dell'endpoint determina se il flusso di lavoro viene eseguito. Il trigger passa qualsiasi contenuto dalla risposta dell'endpoint alle azioni nel flusso di lavoro.
Per chiamare un endpoint da qualsiasi altra posizione del flusso di lavoro, aggiungere l'azione HTTP. La risposta dell'endpoint determina l'esecuzione delle azioni rimanenti del flusso di lavoro.
Prerequisiti
Account e sottoscrizione di Azure. Se non si ha una sottoscrizione di Azure, iscriversi per creare un account Azure gratuito.
URL per l'endpoint di destinazione che si desidera chiamare
Flusso di lavoro dell'app per la logica da cui si vuole chiamare l'endpoint di destinazione. Per iniziare con il trigger HTTP, è necessario un flusso di lavoro vuoto. Per usare l'azione HTTP, avviare il flusso di lavoro con qualsiasi trigger desiderato. Questo esempio usa il trigger HTTP come primo passaggio.
Riferimento tecnico Connessione or
Per informazioni tecniche sui parametri di trigger e azione, vedere le sezioni seguenti:
Aggiungere un trigger HTTP
Questo trigger predefinito effettua una chiamata HTTP all'URL specificato per un endpoint e restituisce una risposta.
Nella portale di Azure aprire la risorsa dell'app per la logica Standard e il flusso di lavoro vuoto nella finestra di progettazione.
-
In questo esempio il trigger viene rinominato in TRIGGER HTTP - URL dell'endpoint di chiamata in modo che il trigger abbia un nome più descrittivo. L'esempio aggiunge successivamente anche un'azione HTTP e i nomi delle operazioni nel flusso di lavoro devono essere univoci.
Specificare i valori per i parametri del trigger HTTP da includere nella chiamata all'endpoint di destinazione. Configurare la ricorrenza per la frequenza con cui si vuole che il trigger controlli l'endpoint di destinazione.
Se si seleziona un tipo di autenticazione diverso da Nessuno, le impostazioni di autenticazione differiscono in base alla selezione. Per altre informazioni sui tipi di autenticazione disponibili per HTTP, vedere gli argomenti seguenti:
Per aggiungere altri parametri disponibili, aprire l'elenco Parametri avanzati e selezionare i parametri desiderati.
Aggiungere eventuali altre azioni che si desidera eseguire quando viene attivato il trigger.
Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.
Aggiungere un'azione HTTP
Questa azione predefinita effettua una chiamata HTTP all'URL specificato per un endpoint e restituisce una risposta.
Nella portale di Azure aprire l'app per la logica a consumo e il flusso di lavoro nella finestra di progettazione.
Questo esempio usa il trigger HTTP aggiunto nella sezione precedente come primo passaggio.
-
In questo esempio l'azione viene rinominata in Azione HTTP - URL dell'endpoint di chiamata in modo che il passaggio abbia un nome più descrittivo. Inoltre, i nomi delle operazioni nel flusso di lavoro devono essere univoci.
Specificare i valori per i parametri dell'azione HTTP da includere nella chiamata all'endpoint di destinazione.
Se si seleziona un tipo di autenticazione diverso da Nessuno, le impostazioni di autenticazione differiscono in base alla selezione. Per altre informazioni sui tipi di autenticazione disponibili per HTTP, vedere gli argomenti seguenti:
Per aggiungere altri parametri disponibili, aprire l'elenco Parametri avanzati e selezionare i parametri desiderati.
Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.
Output di trigger e azioni
Di seguito sono riportate altre informazioni sugli output di un trigger o di un'azione HTTP, che restituisce le informazioni seguenti:
| Proprietà | Type | Descrizione |
|---|---|---|
headers |
Oggetto JSON | Intestazioni della richiesta |
body |
Oggetto JSON | Oggetto con il contenuto del corpo della richiesta |
status code |
Intero | Codice di stato della risposta |
| Codice di stato | Descrizione |
|---|---|
| 200 | OK |
| 202 | Accettata |
| 400 | Richiesta non valida |
| 401 | Non autorizzata |
| 403 | Non consentito |
| 404 | Non trovato |
| 500 | Errore interno del server. Si è verificato un errore sconosciuto. |
Sicurezza degli URL per le chiamate in uscita
Per informazioni sulla crittografia, la sicurezza e l'autorizzazione per le chiamate in uscita dal flusso di lavoro, ad esempio Transport Layer Security (TLS), precedentemente noto come Secure Sockets Layer (SSL), certificati autofirmato o Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), vedere Proteggere l'accesso e i dati - Accesso per chiamate in uscita ad altri servizi e sistemi.
Autenticazione per l'ambiente a tenant singolo
Se si dispone di una risorsa dell'app per la logica Standard in App per la logica di Azure a tenant singolo e si vuole usare un'operazione HTTP con uno dei tipi di autenticazione seguenti, assicurarsi di completare i passaggi di configurazione aggiuntivi per il tipo di autenticazione corrispondente. In caso contrario, la chiamata non riesce.
Certificato TLS/SSL: aggiungere l'impostazione dell'app,
WEBSITE_LOAD_ROOT_CERTIFICATESe impostare il valore sull'identificazione personale per il certificato TLS/SSL.Certificato client o Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth) con il tipo di credenziale "Certificato": aggiungere l'impostazione dell'app,
WEBSITE_LOAD_USER_PROFILEe impostare il valore su1.
Autenticazione del certificato TLS/SSL
Nelle impostazioni dell'app per l'app per la logica aggiungere o aggiornare l'impostazione dell'app.
WEBSITE_LOAD_ROOT_CERTIFICATESPer il valore dell'impostazione, specificare l'identificazione personale per il certificato TLS/SSL come certificato radice da considerare attendibile.
"WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>"
Ad esempio, se si lavora in Visual Studio Code, seguire questa procedura:
Aprire il file di local.settings.json del progetto dell'app per la logica.
Nell'oggetto
ValuesJSON aggiungere o aggiornare l'impostazioneWEBSITE_LOAD_ROOT_CERTIFICATES:{ "IsEncrypted": false, "Values": { <...> "AzureWebJobsStorage": "UseDevelopmentStorage=true", "WEBSITE_LOAD_ROOT_CERTIFICATES": "<thumbprint-for-TLS/SSL-certificate>", <...> } }Nota
Per trovare l'identificazione personale, seguire questa procedura:
Nel menu delle risorse dell'app per la logica, in Impostazioni, selezionare Impostazioni>TLS/SSL Certificati chiave privata (con estensione pfx) o Certificati a chiave pubblica (.cer).)
Trovare il certificato da usare e copiare l'identificazione personale.
Per altre informazioni, vedere Trovare l'identificazione personale - servizio app Azure.
Per altre informazioni, vedere la documentazione seguente:
- Modificare le impostazioni dell'host e dell'app per le app per la logica in App per la logica di Azure a tenant singolo
- Certificati client privati - servizio app Azure
Certificato client o Microsoft Entra ID OAuth con autenticazione del tipo di credenziale "Certificato"
Nelle impostazioni dell'app per l'app per la logica aggiungere o aggiornare l'impostazione dell'app.
WEBSITE_LOAD_USER_PROFILEPer il valore dell'impostazione, specificare
1."WEBSITE_LOAD_USER_PROFILE": "1"
Ad esempio, se si lavora in Visual Studio Code, seguire questa procedura:
Aprire il file di local.settings.json del progetto dell'app per la logica.
Nell'oggetto
ValuesJSON aggiungere o aggiornare l'impostazioneWEBSITE_LOAD_USER_PROFILE:{ "IsEncrypted": false, "Values": { <...> "AzureWebJobsStorage": "UseDevelopmentStorage=true", "WEBSITE_LOAD_USER_PROFILE": "1", <...> } }
Per altre informazioni, vedere la documentazione seguente:
- Modificare le impostazioni dell'host e dell'app per le app per la logica in App per la logica di Azure a tenant singolo
- Certificati client privati - servizio app Azure
Contenuto con tipo di dati multipart/form
Per gestire il contenuto con multipart/form-data tipo nelle richieste HTTP, è possibile aggiungere un oggetto JSON che include gli $content-type attributi e $multipart al corpo della richiesta HTTP usando questo formato.
"body": {
"$content-type": "multipart/form-data",
"$multipart": [
{
"body": "<output-from-trigger-or-previous-action>",
"headers": {
"Content-Disposition": "form-data; name=file; filename=<file-name>"
}
}
]
}
Si supponga, ad esempio, di disporre di un flusso di lavoro che invia una richiesta HTTP POST per un file di Excel a un sito Web usando l'API del sito, che supporta il multipart/form-data tipo . L'esempio seguente mostra come può essere visualizzata questa azione:
Flusso di lavoro standard
Flusso di lavoro a consumo
Ecco lo stesso esempio che mostra la definizione JSON dell'azione HTTP nella definizione del flusso di lavoro sottostante:
"HTTP_action": {
"inputs": {
"body": {
"$content-type": "multipart/form-data",
"$multipart": [
{
"body": "@trigger()",
"headers": {
"Content-Disposition": "form-data; name=file; filename=myExcelFile.xlsx"
}
}
]
},
"method": "POST",
"uri": "https://finance.contoso.com"
},
"runAfter": {},
"type": "Http"
}
Contenuto con tipo application/x-www-form-urlencoded
Per fornire dati form-urlencoded nel corpo di una richiesta HTTP, è necessario specificare che i dati hanno il application/x-www-form-urlencoded tipo di contenuto. Nel trigger o nell'azione HTTP aggiungere l'intestazione content-type . Impostare il valore dell'intestazione su application/x-www-form-urlencoded.
Si supponga, ad esempio, di avere un'app per la logica che invia una richiesta HTTP POST a un sito Web, che supporta il application/x-www-form-urlencoded tipo . Ecco come potrebbe apparire questa azione:
Flusso di lavoro standard
Flusso di lavoro a consumo
Comportamento asincrono di richiesta-risposta
Per i flussi di lavoro con stato in App per la logica di Azure multi-tenant e a tenant singolo, tutte le azioni basate su HTTP seguono il modello di operazione asincrona standard come comportamento predefinito. Questo modello specifica che dopo che un'azione HTTP chiama o invia una richiesta a un endpoint, un servizio, un sistema o un'API, il ricevitore restituisce immediatamente una risposta "202 ACCEPTED". Questo codice conferma che il ricevitore ha accettato la richiesta ma non ha terminato l'elaborazione. La risposta può includere un'intestazione location che specifica l'URI e un ID di aggiornamento che il chiamante può usare per eseguire 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. Tuttavia, il chiamante non deve attendere il completamento dell'elaborazione della richiesta e può continuare a eseguire l'azione successiva. Per altre informazioni, vedere Integrazione asincrona di microservizi applica l'autonomia dei microservizi.
Per i flussi di lavoro senza stato in App per la logica di Azure a tenant singolo, le azioni basate su HTTP non usano il modello di operazione asincrona. Vengono invece eseguiti solo in modo sincrono, restituiscono la risposta "202 ACCEPTED" così come sono e procedere al passaggio successivo nell'esecuzione del flusso di lavoro. Se la risposta include un'intestazione location , un flusso di lavoro senza stato non eseguirà il polling dell'URI specificato per controllare lo stato. Per seguire il modello di operazione asincrona standard, usare invece un flusso di lavoro con stato.
La definizione JSON (JavaScript Object Notation) sottostante dell'azione HTTP segue in modo implicito il modello di operazione asincrona.
L'azione HTTP, ma non il trigger, ha un'impostazione Asincrona Pattern , che è abilitata per impostazione predefinita. 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 l'impostazione Modello asincrono, seguire questa procedura, in base al fatto che si disponga di un flusso di lavoro Standard o a consumo:
Flusso di lavoro standard*
Nella finestra di progettazione del flusso di lavoro selezionare l'azione HTTP. Nel riquadro informazioni visualizzato selezionare Impostazioni.
In Rete trovare l'impostazione Modello asincrono.
Flusso di lavoro a consumo
Nella finestra di progettazione del flusso di lavoro, sulla barra del titolo dell'azione HTTP, selezionare il pulsante con i puntini di sospensione (...), che apre le impostazioni dell'azione.
Trovare l'impostazione Modello asincrono.
Disabilitare le operazioni asincrone
In alcuni casi, è possibile disabilitare il comportamento asincrono dell'azione HTTP in scenari specifici, ad esempio, quando si vuole:
- Evitare timeout HTTP per le attività a esecuzione prolungata
- Disabilitare il controllo delle intestazioni dei percorsi
Disattiva impostazione modello asincrono
Nella finestra di progettazione del flusso di lavoro selezionare l'azione HTTP e nel riquadro delle informazioni visualizzato selezionare Impostazioni.
In Rete trovare l'impostazione Modello asincrono. Se abilitata, disattivare l'impostazione .
Disabilitare il modello asincrono nella definizione JSON dell'azione
Nella definizione JSON sottostante dell'azione HTTP aggiungere l'opzione "DisableAsyncPattern" operation alla definizione dell'azione in modo che l'azione segua invece il modello di operazione sincrono. Per altre informazioni, vedere anche Eseguire azioni in un modello di operazione sincrona.
Evitare timeout HTTP per le attività a esecuzione prolungata
Le richieste HTTP hanno un limite di timeout. Se si dispone di un'azione HTTP a esecuzione prolungata che scade a causa di questo limite, sono disponibili queste opzioni:
Disabilitare il modello di operazione asincrona dell'azione HTTP in modo che l'azione non esegua continuamente il polling o controlli lo stato della richiesta. L'azione attende invece che il ricevitore risponda con lo stato e i risultati al termine dell'elaborazione della richiesta.
Sostituire l'azione HTTP con l'azione Webhook HTTP, che attende che il ricevitore risponda con lo stato e i risultati al termine dell'elaborazione della richiesta.
Impostare l'intervallo tra i tentativi con l'intestazione Retry-After
Per specificare il numero di secondi tra i tentativi, è possibile aggiungere l'intestazione Retry-After alla risposta all'azione HTTP. Ad esempio, se l'endpoint di destinazione restituisce il 429 - Too many requests codice di stato, è possibile specificare un intervallo più lungo tra i tentativi. L'intestazione Retry-After funziona anche con il 202 - Accepted codice di stato.
Di seguito è riportato lo stesso esempio che mostra la risposta all'azione HTTP che contiene Retry-After:
{
"statusCode": 429,
"headers": {
"Retry-After": "300"
}
}
Supporto per l'impaginazione
In alcuni casi, il servizio di destinazione risponde restituendo i risultati una pagina alla volta. Se la risposta specifica la pagina successiva con la proprietà nextLink o @odata.nextLink , è possibile attivare l'impostazione Paginazione sull'azione HTTP. Questa impostazione fa sì che l'azione HTTP segua automaticamente questi collegamenti e ottenga la pagina successiva. Tuttavia, se la risposta specifica la pagina successiva con qualsiasi altro tag, potrebbe essere necessario aggiungere un ciclo al flusso di lavoro. Fare in modo che questo ciclo segua tale tag e ottenere manualmente ogni pagina fino a quando il tag non è Null.
Disabilitare il controllo delle intestazioni dei percorsi
Alcuni endpoint, servizi, sistemi o API restituiscono una 202 ACCEPTED risposta che non ha un'intestazione location . Per evitare che un'azione HTTP controlli continuamente lo stato della richiesta quando l'intestazione location non esiste, è possibile avere queste opzioni:
Disabilitare il modello di operazione asincrona dell'azione HTTP in modo che l'azione non esegua continuamente il polling o controlli lo stato della richiesta. L'azione attende invece che il ricevitore risponda con lo stato e i risultati al termine dell'elaborazione della richiesta.
Sostituire l'azione HTTP con l'azione Webhook HTTP, che attende che il ricevitore risponda con lo stato e i risultati al termine dell'elaborazione della richiesta.
Problemi noti
Intestazioni HTTP omesse
Se un trigger o un'azione HTTP include queste intestazioni, App per la logica di Azure rimuove queste intestazioni dal messaggio di richiesta generato senza visualizzare alcun avviso o errore:
Accept-*intestazioni ad eccezione diAccept-versionAllowContent-*intestazioni ad eccezione diContent-Disposition,Content-EncodingeContent-Type, che vengono rispettate quando si usano le operazioni POST e PUT. Tuttavia, App per la logica di Azure elimina queste intestazioni quando si usa l'operazione GET.Cookieintestazione, ma App per la logica di Azure rispetta qualsiasi valore specificato usando la proprietà Cookie.ExpiresHostLast-ModifiedOriginSet-CookieTransfer-Encoding
Sebbene App per la logica di Azure non impedisca di salvare le app per la logica che usano un trigger HTTP o un'azione con queste intestazioni, App per la logica di Azure ignora queste intestazioni.
Il contenuto della risposta non corrisponde al tipo di contenuto previsto
L'azione HTTP genera un errore BadRequest se l'azione HTTP chiama l'API back-end con l'intestazione Content-Type impostata su application/json, ma la risposta del back-end non contiene effettivamente contenuto in formato JSON, che non riesce a convalidare il formato JSON interno.