Eseguire flussi di lavoro o azioni in base agli eventi dell'endpoint di servizio usando webhook HTTP in App per la logica di Azure

Si applica a: App per la logica di Azure (Consumo + Standard)

Quando si vuole che un trigger o un'azione del flusso di lavoro attenda che gli eventi o i dati arrivino a un endpoint del servizio di destinazione prima dell'esecuzione, usare il trigger o l'azione webhook HTTP , anziché controllare in modo proattivo l'endpoint in base a una pianificazione. Il trigger o l'azione webhook HTTP sottoscrive l'endpoint del servizio e attende nuovi eventi o dati prima dell'esecuzione. È possibile usare il modello webhook per le attività a esecuzione prolungata e l'elaborazione asincrona.

L'elenco seguente descrive i flussi di lavoro basati su webhook di esempio:

• Un trigger HTTP Webhook attende l'arrivo di un evento da Hub eventi di Azure prima di eseguire il flusso di lavoro.
• Un'azione HTTP Webhook attende un'approvazione in Office 365 Outlook prima di continuare l'azione successiva nel flusso di lavoro.

Questa guida illustra come configurare il trigger Webhook HTTP e l'azione webhook HTTP in modo che il flusso di lavoro possa ricevere e rispondere a nuovi eventi o dati in un endpoint del servizio.

Come funzionano i webhook?

Un trigger o un'azione webhook non esegue il polling né controlla attivamente la presenza di nuovi eventi o dati presso l'endpoint di destinazione del servizio. Il trigger o l'azione attende invece che nuovi eventi o dati arrivino all'endpoint del servizio prima dell'esecuzione. Dopo aver aggiunto un trigger o un'azione webhook al flusso di lavoro e quindi salvato il flusso di lavoro, oppure dopo aver riabilitato una risorsa dell'app per la logica disabilitata, il trigger o l'azione webhook si sottoscrive all'endpoint del servizio generando e registrando un URL di callback presso l'endpoint. Il trigger o l'azione attende quindi che l'endpoint del servizio chiami l'URL, facendo eseguire il trigger o l'azione. Analogamente al trigger request, un trigger webhook HTTP viene attivato immediatamente.

Ad esempio, l'azione connettore Office 365 Outlook denominata Send approval email segue il modello webhook, ma funziona solo con Office 365 Outlook. È possibile estendere il modello webhook in qualsiasi servizio usando il trigger o l'azione webhook HTTP con l'endpoint di servizio desiderato.

Un trigger webhook rimane sottoscritto a un endpoint di servizio fino a quando non si esegue manualmente una delle azioni seguenti:

• Modificare i valori dei parametri del trigger.
• Eliminare il trigger e quindi salvare il flusso di lavoro.
• Disabilitare la risorsa dell'app per la logica.

Un'azione webhook rimane sottoscritta a un endpoint di servizio a meno che non si verifichi una delle condizioni seguenti:

• L'azione webhook viene completata correttamente.
• Viene annullata l'esecuzione del flusso di lavoro mentre si attende una risposta.
• Timeout del flusso di lavoro.
• È possibile modificare i valori dei parametri dell'azione webhook usati da un trigger webhook come dati di input.

Per ulteriori informazioni, vedere:

• Webhook e sottoscrizioni
• Creare API personalizzate che supportano un webhook
• Accesso alle chiamate in uscita ad altri servizi e sistemi

Prerequisiti

• Un account e una sottoscrizione Azure. Get a free Azure account.

• L'URL di un endpoint di servizio o di un'API distribuita.

  Questo elemento deve supportare il modello "subscribe and unsubscribe" per i trigger webhook nei flussi di lavoro o nelle azioni webhook nei flussi di lavoro.

• Flusso di lavoro dell'app per la logica standard o a consumo in cui si vuole usare il trigger o l'azione webhook HTTP .

  • Per utilizzare il trigger Webhook HTTP, crea una risorsa di app logica con un flusso di lavoro vuoto.
  • Per usare l'azione Webhook HTTP, avviare il flusso di lavoro con qualsiasi trigger che meglio si adatta al tuo scenario. Negli esempi viene usato il trigger webhook HTTP .

Aggiungere un trigger webhook HTTP

Questo trigger predefinito chiama l'endpoint di sottoscrizione nel servizio di destinazione e registra un URL di callback con il servizio di destinazione. Il flusso di lavoro attende quindi che il servizio di destinazione invii una richiesta HTTP POST all'URL di callback. Quando si verifica questo evento, il trigger viene attivato e passa tutti i dati nella richiesta insieme al flusso di lavoro.

1. Nel portale Azure, apri la risorsa dell'app per la logica. Nella finestra di progettazione aprire il flusso di lavoro vuoto.

2. Seguire la procedura generale per aggiungere il trigger denominato Webhook HTTP al flusso di lavoro.

   In questo esempio il trigger Run HTTP Webhook trigger viene rinominato con un nome più descrittivo. L'esempio aggiunge successivamente anche un'azione webhook HTTP . Entrambi i nomi devono essere univoci.

3. Per i parametri del trigger webhook HTTP, specificare i valori per le chiamate di sottoscrizione e annullamento della sottoscrizione:

   Parametro	Obbligatoria	Descrizione
   Metodo di Sottoscrizione	Sì	Metodo da usare per la sottoscrizione all'endpoint di destinazione.
   URI di sottoscrizione	Sì	URL da usare per la sottoscrizione all'endpoint di destinazione.
   Corpo del messaggio	NO	Qualsiasi corpo del messaggio da includere nella richiesta di sottoscrizione. Questo esempio include l'URL di callback che identifica in modo univoco il flusso di lavoro, che è il tuo sottoscrittore, utilizzando la funzione di espressione per recuperare l'URL di callback del trigger.
   Contenuto per annullare l'iscrizione	NO	Qualsiasi corpo del messaggio da includere nella richiesta di annullamento della sottoscrizione. È possibile usare la listCallbackUrl() funzione di espressione per recuperare l'URL di callback dell'azione. Tuttavia, il trigger include automaticamente e invia anche le intestazioni x-ms-client-tracking-id e x-ms-workflow-operation-name, che il servizio di destinazione può usare per identificare in modo univoco il sottoscrittore.

4. Per aggiungere altri parametri di trigger, aprire l'elenco Parametri avanzati .

   Ad esempio, per usare i parametri Unsubscribe Method e Unsubscribe URI , aggiungerli dall'elenco Parametri avanzati .

   L'esempio seguente mostra un trigger che include i metodi, gli URI e i corpi dei messaggi da usare per i metodi di sottoscrizione e annullamento della sottoscrizione:

   

5. Se è necessario usare l'autenticazione, aggiungere i parametri Subscribe Authentication and Unsubscribe Authentication dall'elenco Advanced parameters (Parametri avanzati ).

   Per altre informazioni sui tipi di autenticazione disponibili per webhook HTTP, vedere Aggiungere l'autenticazione alle chiamate in uscita.

6. Aggiungere eventuali altre azioni necessarie per lo scenario.

7. Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione selezionare Salva.

Il salvataggio del flusso di lavoro chiama l'endpoint di sottoscrizione nel servizio di destinazione e registra l'URL di callback. Il flusso di lavoro attende che il servizio di destinazione invii una HTTP POST richiesta all'URL di callback. Quando si verifica questo evento, il trigger viene attivato e passa tutti i dati nella richiesta al flusso di lavoro. Se questa operazione viene completata correttamente, il trigger annulla la sottoscrizione all'endpoint e il flusso di lavoro continua con l'azione successiva.

Aggiungere un'azione webhook HTTP

Questa azione predefinita chiama l'endpoint di sottoscrizione nel servizio di destinazione e registra un URL di callback con il servizio di destinazione. Il flusso di lavoro viene quindi sospeso e attende che il servizio di destinazione invii una HTTP POST richiesta all'URL di callback. Quando si verifica questo evento, l'azione passa tutti i dati nella richiesta al flusso di lavoro. Se l'operazione viene completata correttamente, l'azione annulla la sottoscrizione all'endpoint e il flusso di lavoro continua con l'azione successiva.

1. Nel portale Azure, apri la risorsa dell'app per la logica. Nella finestra di progettazione aprire il flusso di lavoro.

2. Seguire i passaggi generali per aggiungere l'azione denominata Webhook HTTP al flusso di lavoro.

   In questo esempio l'azione Run HTTP Webhook action viene rinominata come nome più descrittivo. Se il flusso di lavoro usa anche il trigger Webhook HTTP , entrambi i nomi devono essere univoci.

3. Per i parametri di azione webhook HTTP, specificare i valori da usare per le chiamate di sottoscrizione e annullamento della sottoscrizione:

   Parametro	Obbligatoria	Descrizione
   Metodo di Sottoscrizione	Sì	Metodo da usare per la sottoscrizione all'endpoint di destinazione.
   URI di sottoscrizione	Sì	URL da usare per la sottoscrizione all'endpoint di destinazione.
   Corpo del messaggio	NO	Qualsiasi corpo del messaggio da includere nella richiesta di sottoscrizione. Questo esempio include l'URL di callback che identifica in modo univoco il sottoscrittore, ovvero il tuo flusso di lavoro, utilizzando la funzione di espressione per recuperare l'URL di callback della tua azione.
   Contenuto per annullare l'iscrizione	NO	Qualsiasi corpo del messaggio da includere nella richiesta di annullamento della sottoscrizione. È possibile usare la listCallbackUrl() funzione di espressione per recuperare l'URL di callback dell'azione. Tuttavia, l'azione include automaticamente e invia anche le intestazioni x-ms-client-tracking-id e x-ms-workflow-operation-name, che il servizio di destinazione può usare per identificare in modo univoco il sottoscrittore.

4. Per aggiungere altri parametri di azione, aprire l'elenco Parametri avanzati .

   Ad esempio, per usare i parametri Unsubscribe Method e Unsubscribe URI , aggiungerli dall'elenco Parametri avanzati .

   Nell'esempio seguente viene illustrata un'azione che include i metodi, gli URI e i corpi dei messaggi da usare per i metodi di sottoscrizione e annullamento della sottoscrizione:

   

5. Se è necessario usare l'autenticazione, aggiungere i parametri Subscribe Authentication and Unsubscribe Authentication dall'elenco Advanced parameters (Parametri avanzati ).

   Per altre informazioni sui tipi di autenticazione disponibili per webhook HTTP, vedere Aggiungere l'autenticazione alle chiamate in uscita.

6. Aggiungere eventuali altre azioni necessarie per lo scenario.

7. Al termine, salvare il flusso di lavoro. Sulla barra degli strumenti della finestra di progettazione selezionare Salva.

Quando viene eseguita questa azione, il flusso di lavoro chiama l'endpoint di sottoscrizione nel servizio di destinazione e registra l'URL di callback. Il flusso di lavoro sospende e attende che il servizio di destinazione invii una HTTP POST richiesta all'URL di callback. Quando si verifica questo evento, l'azione passa tutti i dati nella richiesta al flusso di lavoro. Se l'operazione viene completata correttamente, l'azione annulla la sottoscrizione all'endpoint e il flusso di lavoro continua con l'azione successiva.

Informazioni tecniche sul connettore

Per ulteriori informazioni sui parametri del trigger e dell'azione Webhook HTTP, consultare i parametri webhook HTTP. Il trigger e l'azione hanno gli stessi parametri.

Scadenza del token di firma di accesso condiviso

L'URL di callback per il trigger o l'azione webhook HTTP vengono generati automaticamente dal metodo API REST List Callback Url. Per impostazione predefinita, il token SAS nell'URL di callback non ha una scadenza basata sul tempo. L'URL di callback rimane valido per la durata dell'esecuzione del flusso di lavoro.

Limiti di timeout

La tabella seguente descrive i limiti di timeout per l'azione Webhook HTTP, a seconda dell'opzione di hosting dell'applicazione logica.

L'URL di callback dell'azione Webhook HTTP non è valido quando si verificano gli eventi seguenti:

• Annulla il flusso di lavoro.
• Elimini o disattivi la risorsa del flusso di lavoro o dell'app logica.
• Si ruotano le chiavi di accesso del flusso di lavoro.
• Timeout del flusso di lavoro.

Per altri limiti HTTP, vedere limiti HTTP in App per la logica di Azure.

Modificare il limite di timeout

Per modificare questo limite per l'azione HTTP Webhook nei flussi di lavoro con stato tramite il portale di Azure, vedere la tabella di durata Timeout per le richieste HTTP in uscita. In alternativa, nella definizione JSON dell'azione aggiungere l'oggetto limit.timeout e impostare il valore sulla durata desiderata, ad esempio:

{
   "actions": {
      "Run_HTTP_Webhook_action": {
         "type": "HttpWebhook",
         "inputs": {
            "subscribe": {
               "method": "POST",
               "uri": "https://<external-service>.com/subscribe",
               "body": {
                  "callbackUrl": "@{listCallBackUrl()}"
               }
            },
            "unsubscribe": {}
         },
         "limit": {
            "timeout": "PT1H"
         }
      }
   }
}

Output di trigger e azioni

Le tabelle seguenti forniscono altre informazioni sugli output restituiti da un trigger o un'azione webhook HTTP :

Generare l'URL di callback con la chiave di accesso secondaria

Un flusso di lavoro di un'app di logica ha due chiavi di accesso: primaria e secondaria. Per impostazione predefinita, App per la logica di Azure usa la chiave primaria per generare l'URL di callback per il trigger webhook HTTP.

Per usare invece la chiave secondaria per la generazione di URL di callback, seguire questa procedura:

1. Se ti trovi nella finestra di progettazione del flusso di lavoro, passa alla visualizzazione del codice.

2. Nella definizione del HttpWebhook trigger, trova il parametro accessKeyType.

3. Immettere la parola Secondary come valore del parametro.

4. Salvare le modifiche.

L'esempio seguente mostra la definizione del trigger webhook con il accessKeyType parametro impostato su Secondary:

{
  "type": "HttpWebhook",
  "inputs": {
    "subscribe": {
      "method": "POST",
      "uri": "<subscription-URL>",
      "body": "@listCallbackUrl()"
    },
    "accessKeyType": "Secondary"
  },
  "runAfter": {}
}

Contenuti correlati

• Accesso per le chiamate in ingresso ai trigger basati su richiesta
• Elenco di tutti i connettori per le app per la logica
• Connettori integrati in App per la logica di Azure