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.

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:

• Parametri del trigger HTTP
• Parametri dell'azione HTTP

Aggiungere un trigger HTTP

Questo trigger predefinito effettua una chiamata HTTP all'URL specificato per un endpoint e restituisce una risposta.

Aggiungere un'azione HTTP

Questa azione predefinita effettua una chiamata HTTP all'URL specificato per un endpoint e restituisce una risposta.

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:

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 su 1.

Autenticazione del certificato TLS/SSL

1. Nelle impostazioni dell'app per l'app per la logica aggiungere o aggiornare l'impostazione dell'app. WEBSITE_LOAD_ROOT_CERTIFICATES

2. Per 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:

1. Aprire il file di local.settings.json del progetto dell'app per la logica.

2. Nell'oggetto Values JSON aggiungere o aggiornare l'impostazione WEBSITE_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:

   1. 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).)

   2. 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"

1. Nelle impostazioni dell'app per l'app per la logica aggiungere o aggiornare l'impostazione dell'app. WEBSITE_LOAD_USER_PROFILE

2. Per il valore dell'impostazione, specificare 1.

   "WEBSITE_LOAD_USER_PROFILE": "1"

Ad esempio, se si lavora in Visual Studio Code, seguire questa procedura:

1. Aprire il file di local.settings.json del progetto dell'app per la logica.

2. Nell'oggetto Values JSON aggiungere o aggiornare l'impostazione WEBSITE_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*

  1. Nella finestra di progettazione del flusso di lavoro selezionare l'azione HTTP. Nel riquadro informazioni visualizzato selezionare Impostazioni.

  2. In Rete trovare l'impostazione Modello asincrono.

  Flusso di lavoro a consumo

  1. 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.

  2. 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

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 di Accept-version
• Allow
• Content-* intestazioni ad eccezione di Content-Disposition, Content-Encodinge Content-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.
• Expires
• Host
• Last-Modified
• Origin
• Set-Cookie
• Transfer-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.

Passaggi successivi

• Connettori gestiti per App per la logica di Azure
• Connettori predefiniti per App per la logica di Azure