Introduzione
Questo modulo descrive come espandere la funzionalità dei connettori personalizzati con le definizioni dei trigger.
Contenuto del modulo:
Informazioni sui trigger nei connettori personalizzati.
Descrizione degli scenari comuni in cui è possibile usare i trigger.
Definizione dei diversi tipi di trigger.
Scoprire come estendere una definizione del connettore personalizzato ai trigger definiti da un'API del servizio.
I trigger consentono di estendere la funzionalità del connettore in Microsoft Power Automate e App per la logica di Microsoft Azure, in cui un sistema deve rispondere alle modifiche nei dati o nei servizi sottostanti. Lo scenario più comune di utilizzo del trigger è la creazione di un flusso cloud che si avvia quando i dati sottostanti cambiano, ad esempio "Quando un record viene creato" o quando si verifica un determinato evento nel servizio definito dal connettore personalizzato, ad esempio " Quando viene dato l'allarme".
Trigger in Power Automate e App per la logica
Power Automate e App per la logica definiscono un trigger come un evento che avvia un flusso cloud o un flusso di lavoro di App per la logica. Questi eventi possono essere avviati da un utente, pianificati o generati da un connettore, anche personalizzato. Le definizioni dei trigger estendono i connettori personalizzati e consentono di usarli per avviare flussi cloud e flussi di lavoro di App per la logica.
La maggior parte dei connettori definisce un riepilogo dei trigger con il formato "Quando <object> è <verb>" e un'implementazione tipica di un connettore include un trigger per una o più azioni.
Tipi di trigger
Si prenda in considerazione un sistema di gestione dei messaggi vocali. Un trigger in questo sistema potrebbe essere un evento "nuovo messaggio vocale ricevuto". I due modi per definire un metodo per identificare se è stato ricevuto un nuovo messaggio vocale sono:
Chiamare periodicamente la cassetta vocale e verificare la presenza di nuovi messaggi. Questo comportamento descrive un trigger di polling, ovvero un'implementazione in cui i dati vengono interrogati dal servizio sottostante. Un trigger di polling è un'attività a tempo che avvia una chiamata all'API del servizio a intervalli regolari e configurabili per determinare se sono disponibili nuovi dati. Per supportare i trigger di polling, l'API può filtrare i risultati in base a uno stato. Lo stato in genere si base sull'orario, ad esempio "Restituisci tutti i messaggi vocali ricevuti da ieri".
Lasciare che il sistema vocale invii un messaggio e-mail quando viene ricevuto un nuovo messaggio vocale. Questo approccio definisce un trigger webhook o un'implementazione in cui il servizio esegue il push dei dati. Il servizio che supporta i trigger webhook deve essere in grado di mantenere un elenco di contatti da richiamare e sapere come richiamare. Nell'esempio dei messaggi vocali si tratta di un elenco di indirizzi e-mail e della capacità di inviare un messaggio e-mail di notifica.
La differenza tra questi due tipi di trigger, in sostanza, riguarda a chi è assegnata la responsabilità di gestire le operazioni.
| Polling | Webhook |
|---|---|
| Inizia impostando uno stato | Registrato con il servizio |
| Controlla periodicamente gli aggiornamenti | Segnala quando si verifica un evento |
| Richiede tutti i nuovi dati dall'ultimo aggiornamento dello stato | Viene eliminato automaticamente |
| Il servizio mantiene lo stato | Power Automate o App per la logica gestisce il processo di registrazione e annullamento della registrazione dei webhook |
Importante
La disponibilità di un'API REST per un servizio non implica che sia possibile definire i trigger dei connettori personalizzati. Il servizio sottostante deve essere in grado di restituire i dati in modo incrementale o fornire l'implementazione di un webhook. Se i trigger sono necessari, ma l'API del servizio non le capacità specificate, uno sviluppatore dovrebbe estendere il servizio per consentire agli utenti di definire un trigger.
Definizione di un trigger
Come per i connettori, entrambi i tipi di trigger vengono definiti da un documento OpenAPI (Swagger) che specifica gli endpoint, i parametri, le condizioni e le risposte. Tuttavia, la versione della specifica OpenAPI usata da Microsoft Power Platform non distingue tra azioni e trigger. Microsoft Power Platform aggiunge estensioni OpenAPI personalizzate per estendere le specifiche al fine di definire i trigger e il loro contenuto.
Trattandosi di un argomento che può generare confusione, si può ricorrere all'aiuto da parte di Copilot. Presentare a Copilot alcune semplici richieste, ad esempio:
"Come faccio a iniziare a creare un connettore personalizzato in Power Automate?"
"Qual è il modo migliore per definire l'autenticazione per il mio connettore personalizzato?"
Copilot può essere di aiuto suggerendo i passaggi per la creazione del connettore o addirittura esaminando le impostazioni del connettore per verificarne la completezza.
Se questa soluzione non dovesse funzionare, usare la procedura guidata dettagliata per i trigger. Segue lo stesso layout generale della procedura guidata per le azioni.
È importante selezionare un riepilogo trigger efficace, proprio come accade per le azioni del connettore personalizzato. Il riepilogo viene usato quando un creatore cerca i connettori e, quando viene selezionato un trigger, il relativo riepilogo diventa il titolo del passaggio predefinito in Power Automate e App per la logica.
A differenza delle azioni, la maggior parte delle quali può essere creata interamente nella finestra di progettazione del connettore personalizzato, i trigger possono essere più complessi e spesso richiedono modifiche manuali. Questo modulo descrive come creare definizioni dei trigger in scenari di polling e webhook.