Ricevere e rispondere alle chiamate HTTPS in ingresso ai flussi di lavoro in App per la logica di Azure

  • Articolo

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.

  1. Nella portale di Azure aprire l'app per la logica a consumo e il flusso di lavoro vuoto nella finestra di progettazione.

  2. Nella finestra di progettazione seguire questi passaggi generali per trovare e aggiungere il trigger predefinito Richiesta denominato Quando viene ricevuta una richiesta HTTP.

  3. 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:

    Screenshot showing Consumption workflow and Request trigger with example JSON schema.

    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.

    Screenshot showing Consumption workflow, Request trigger, and reminder to include

    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:

    1. Nel trigger di richiesta selezionare Usare il payload di esempio per generare lo schema.

      Screenshot showing Consumption workflow, Request trigger, and

    2. Immettere il payload di esempio e selezionare Fine.

      Screenshot showing Consumption workflow, Request trigger, and sample payload entered to generate schema.

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

  4. Per verificare che la chiamata in ingresso abbia un corpo della richiesta corrispondente allo schema specificato, seguire questa procedura:

    1. 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 la addtionalProperties proprietà e impostare il valore su false.

      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
}

    2. Nella barra del titolo del trigger di richiesta selezionare il pulsante con i puntini di sospensione (...).

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

  5. 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 :

    Screenshot showing Consumption workflow, Request trigger, and adding the

    La proprietà Metodo viene visualizzata nel trigger, in modo che sia possibile selezionare un metodo nell'elenco.

    Screenshot showing Consumption workflow, Request trigger, and the

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

  7. Per copiare l'URL generato, selezionare l'icona di copia accanto all'URL.

    Screenshot showing Consumption workflow, Request trigger, and URL copy button selected.

    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 di Content-Disposition, Content-Encodinge Content-Type quando si usano le operazioni POST e PUT, ma non sono incluse per le operazioni GET
    • Cookie
    • 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.

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

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

    Screenshot showing Azure portal, Consumption workflow, and Response action information.

    Per visualizzare le intestazioni in formato JSON, selezionare Passa alla visualizzazione Testo.

    Screenshot showing Azure portal, Consumption workflow, and Response action headers in

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

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