Condividi tramite

Ricevere e rispondere a 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 (a consumo e standard)

Questa guida pratica illustra come creare un flusso di lavoro di 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 di richiesta predefinito. Quando il flusso di lavoro usa questo trigger, è quindi possibile rispondere alla richiesta HTTPS usando l'azione di risposta predefinita.

Nota

L'azione di risposta funziona solo quando si usa il trigger di richiesta.

Ad esempio, questo elenco descrive alcune attività che il flusso di lavoro può eseguire quando si usano il trigger di richiesta e l’azione di 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’esecuzione di un flusso di lavoro quando si verifica un evento webhook esterno.

Per eseguire il flusso di lavoro inviando invece una richiesta in uscita, usare il trigger HTTP o l'azione HTTP predefiniti.

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 di risposta, il flusso di lavoro deve iniziare con il trigger Richiesta.

Aggiungere un trigger di richiesta

Il trigger di richiesta crea un endpoint che può essere chiamato manualmente e che gestisce solo 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. Nel 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 di richiesta predefinito denominato Quando viene ricevuta una richiesta HTTP.

  3. Dopo che la casella delle informazioni sul trigger è apparse, specificare le informazioni seguenti come richiesto:

    Nome della proprietà Nome proprietà JSON Obbligatorio Descrizione
    URL POST HTTP {none} Sì L'URL dell'endpoint generato dopo il salvataggio del flusso di lavoro 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 di richiesta al flusso di lavoro.

    Se non si dispone di uno schema JSON, è possibile generarlo da un payload di esempio tramite Usa payload di esempio per generare la funzionalità dello schema.

    L'esempio seguente mostra uno schema JSON campione:

    Screenshot che mostra il flusso di lavoro a consumo e il trigger di richiesta con schema JSON di esempio.

    L'esempio seguente mostra lo schema JSON campione 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 Tipo di contenuto nella richiesta e impostare il valore dell'intestazione su application/json. Per altre informazioni, vedere Gestire i tipi di contenuti.

    Screenshot che mostra il flusso di lavoro a consumo, il trigger di richiesta e il promemoria per includere l'intestazione

    L'esempio seguente mostra come l'intestazione Content-Type viene visualizzata 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 che mostra il flusso di lavoro a consumo, il trigger di richiesta e l'opzione

    2. Immettere il payload di esempio e selezionare Fine.

      Screenshot che mostra il flusso di lavoro a consumo, il trigger di richiesta e il payload di esempio immesso per generare lo schema.

      L'esempio seguente mostra il payload campione:

      {
   "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 imporre al messaggio in ingresso di avere gli stessi campi descritti nello schema, aggiungere la proprietà required nello schema e specificare i campi necessari. Aggiungere la proprietà addtionalProperties e impostare il valore su false.

      Ad esempio, lo schema seguente specifica che il messaggio in ingresso deve avere il campo msg e nessun altro campo:

      {
   "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 della proprietà Nome proprietà JSON Obbligatorio Descrizione
    Metodo 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à Metodo:

    Screenshot che mostra il flusso di lavoro a consumo, il trigger di richiesta e l'aggiunta del parametro

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

    Screenshot che mostra il flusso di lavoro a consumo, il trigger di richiesta e l'elenco

  6. Una volta pronti, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione seleziona Salva.

    Questo passaggio genera l'URL che può essere usato 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 che mostra il flusso di lavoro a consumo, il trigger di richiesta e il pulsante Copia URL selezionato.

    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 di risposta, che può essere usata 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 di risposta, se il flusso di lavoro non restituisce una risposta al chiamante dopo la scadenza di questo periodo di tempo, il flusso di lavoro restituisce lo stato 504 GATEWAY TIMEOUT al chiamante. Se il flusso di lavoro non include un'azione di risposta, restituisce immediatamente lo stato 202 ACCEPTED al chiamante.

Per informazioni su sicurezza, autorizzazione e crittografia per le chiamate in ingresso al flusso di lavoro, ad esempio Transport Layer Security (TLS), precedentemente noto come Secure Sockets Layer (SSL), Microsoft Entra ID OAuth, esponendo la risorsa dell'app per la logica con Gestione API di Azure, o limitando gli indirizzi IP che originano chiamate in ingresso, vedere Proteggere l'accesso e i dati: accesso per 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 Object Oggetto JSON che descrive le intestazioni della richiesta
body Object Oggetto JSON che descrive il contenuto del corpo della richiesta

Aggiungere un'azione di risposta

Quando si usa il trigger di richiesta per ricevere richieste in ingresso, è possibile modellare la risposta e inviare nuovamente i risultati del payload al chiamante usando l'azione di risposta predefinita, che funziona solo con il trigger di richiesta. Questa combinazione del trigger di richiesta con l'azione di risposta crea il motivo richiesta-risposta. Ad eccezione di all’interno di cicli Foreach e cicli Until, nonché dei rami paralleli, è possibile aggiungere l'azione di risposta in qualsiasi punto del flusso di lavoro.

Importante

  • Se l'azione di risposta include le intestazioni seguenti, App per la logica di Azure rimuove automaticamente le intestazioni dal messaggio di risposta generato senza mostrare 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 che hanno un'azione di risposta con queste intestazioni.

    • Allow
    • Intestazioni Content-* ad eccezione di Content-Disposition, Content-Encoding e Content-Type quando si usano operazioni POST e PUT, ma non sono incluse per operazioni GET
    • Cookie
    • Expires
    • Last-Modified
    • Set-Cookie
    • Transfer-Encoding

  • Se si dispone di una o più azioni di risposta in un flusso di lavoro complesso con rami, assicurarsi che il flusso di lavoro elabori almeno un'azione di risposta durante il runtime. Altrimenti, se tutte le azioni di risposta vengono ignorate, il chiamante riceve un errore 502 Gateway non valido, anche se il flusso di lavoro è completato correttamente.

  • In un flusso di lavoro senza stato di un’App per la logica Standard, l'azione di risposta deve apparire per ultima nel flusso di lavoro. Se l'azione appare altrove, App per la logica di Azure la eseguirà comunque finché tutte le altre azioni non avranno terminato l'esecuzione.

  1. Nella finestra di progettazione del flusso di lavoro , seguire questi passaggi generali per trovare e aggiungere l'azione predefinita di risposta denominata Risposta.

    Per semplicità, gli esempi seguenti mostrano un trigger di richiesta compresso.

  2. Nella casella di informazioni sull'azione aggiungere i valori necessari per il messaggio di risposta.

    Nome della proprietà Nome proprietà JSON Obbligatorio 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 effettua una selezione all'interno di un qualsiasi campo di testo, l'elenco di contenuto dinamico viene aperto automaticamente. È 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à per usarle 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 che mostra il portale di Azure, il flusso di lavoro a consumo e le informazioni sulle azioni di risposta.

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

    Screenshot che mostra le intestazioni del portale di Azure, il flusso di lavoro a consumo e l’azione di risposta nella visualizzazione

  3. Per aggiungere altre proprietà per l'azione, ad esempio uno schema JSON per il corpo della risposta, selezionare i parametri da aggiungere nell'elenco Aggiungi nuovo parametro.

  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 strumenti o app locali come Insonnia o Bruno 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 Richiesta (ma non con un trigger Webhook), è possibile usare il provisioning di 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 in app per la logica Standard con Easy Auth

Per altre informazioni su sicurezza, autorizzazione e crittografia per le chiamate in ingresso al flusso di lavoro dell’App per la logica, ad esempio Transport Layer Security (TLS), precedentemente noto come Secure Sockets Layer (SSL), Microsoft Entra ID OAuth, esponendo il flusso di lavoro dell'app per la logica con Gestione API di Azure, o limitando gli indirizzi IP che originano chiamate in ingresso, vedere Proteggere l'accesso e i dati: accesso per le chiamate in ingresso ai trigger basati su richiesta.

Passaggi successivi