Trigger di polling
Un trigger di polling è un'implementazione che chiama regolarmente il servizio API REST e verifica la presenza di nuovi dati. Una volta che la piattaforma determina che sono disponibili nuovi dati, il trigger si attiva e trasmette i nuovi dati raccolti a un flusso cloud o a un flusso di lavoro di App per la logica.
Il diagramma seguente mostra un flusso di processo di base indicante il modo in cui un trigger di polling acquisisce nuovi dati.
Un trigger di polling per prima cosa recupera i dati e imposta uno stato. Quindi, controlla periodicamente la presenza di aggiornamenti richiedendo tutti i dati dopo l'ultimo aggiornamento dello stato. Dopo che i nuovi dati sono stati recuperati, il nuovo stato viene impostato e il processo continua. L'API deve essere in grado di restituire i dati in modo incrementale, in base al valore di un parametro. Power Automate oppure App per la logica di Azure gestisce lo stato in modo che l'API non abbia requisiti speciali per la gestione dello stesso.
A differenza di un trigger webhook, il trigger di polling non ha requisiti di configurazione o chiusura e l'elaborazione può essere arrestata in qualsiasi momento. La semplicità dei requisiti è uno dei principali vantaggi del trigger di polling.
Requisiti API
Un trigger di polling richiede solo che l'API disponga di un metodo di recupero dei dati in grado di filtrare i dati usando un parametro della stringa di query. Deve essere presente anche un modo per estrarre il valore successivo del parametro dai dati restituiti. L'implementazione può essere fornita tramite un metodo di azione dedicato o esistente.
Ad esempio, si consideri l'implementazione di un negozio online in cui gli ordini hanno numeri in ordine crescente. L'API del negozio può includere il metodo chiamato ListOrders che restituisce gli ordini che sono stati creati nel negozio.
ListOrders restituisce gli ordini disposti per numero di ordine in ordine decrescente. Di conseguenza, il numero di ordine più alto appartiene al primo ordine nell'elenco.
ListOrders accetta un parametro della stringa di query per recuperare gli ordini in cui il numero d'ordine è maggiore del valore del parametro.
Queste due qualità consentono di usare l'azione come trigger di polling. La piattaforma può estrarre il numero d'ordine più alto dai dati restituiti e passarlo come parametro nella richiesta successiva. In effetti, il metodo "seleziona tutti gli ordini che sono stati creati dopo l'ultimo".
Implementazione
Un trigger di polling viene creato usando una procedura guidata in Power Automate. Il processo include i seguenti passaggi:
Definire la richiesta HTTP che viene usata per recuperare i dati.
La stringa di query della richiesta include il parametro fromWidget che consente la pre-generazione della definizione del parametro. Questo parametro garantisce che i dati restituiti siano incrementali e che "vengono restituiti tutti i widget che sono stati creati dopo quello specificato dal parametro".
Modificare la visibilità dei parametri in Interno per impedire agli utenti di apportare modifiche a questo parametro che viene usato solo internamente dal connettore.
Definire i dati restituiti dal servizio. Questi dati devono includere la proprietà da usare come valore per fromWidget nelle richieste consecutive.
In questo esempio, la proprietà viene chiamata ID.
Completare la configurazione del trigger. Selezionare il parametro di query, definire un valore o un'espressione che restituisca un valore, quindi selezionare una raccolta contenente i dati del trigger.
Questo esempio include i seguenti parametri:
fromWidget è selezionato come parametro di query e riceve il valore estratto dai risultati del lab.
L'espressione @{triggerBody().widgets[0].id} estrae il valore di ID widget attualmente più alto. Poiché la raccolta restituita è ordinata in base al valore ID decrescente, l'estrazione del valore dal primo elemento garantisce che sia l'ID corrente con il valore più alto.
L'espressione @triggerBody().widgets definisce la raccolta dei dati.
I parametri devono essere estratti ed elaborati e questa trasformazione può essere implementata solo usando i criteri del connettore. Di conseguenza, la configurazione del trigger di polling viene archiviata come modello di criteri separato dalla definizione del connettore OpenAPI. Un'implicazione è che non è possibile modificare manualmente tutte le configurazioni dei trigger di polling nell'editor Swagger.
Una limitazione da tenere presente è che il corpo del trigger non può essere una matrice. Ad esempio, considera un metodo chiamato ListOrders che restituisce i seguenti dati:
[
{"value" : 42.00, "id" : "2", ... },
{"value" : 10.00, "id" : "1", ... }
]
Questo corpo del trigger non viene elaborato e il trigger genera un errore nel flusso Power Automate o nel flusso di lavoro di App per la logica in fase di esecuzione.
Il metodo deve restituire una proprietà che contiene la matrice di record, ad esempio:
{
"orders": [
{ "value" : 42.00, "id" : "2", ... },
{ "value" : 10.00, "id" : "1", ... }
]
}
Questa struttura di dati può essere usata come parte dell'implementazione del trigger di polling.
Elaborazione batch
Simile al trigger webhook, il trigger di polling è definito dall'estensione x-ms-trigger a OpenAPI. Il valore definito da un trigger di polling è un batch, a indicare che il metodo restituisce un array anziché un singolo oggetto, come avviene in una risposta di webhook.
/trigger/ListInvoices:
post:
x-ms-trigger: batch
Questo processo si verifica perché è possibile avere più record restituiti da una singola chiamata al servizio. Quando viene usato un trigger di polling in Power Automate o in App per la logica, l'impostazione SplitOn del trigger consente di configurare la modalità di elaborazione.
La suddivisione della matrice in ingresso in più implementazioni parallele viene eseguita per motivi di prestazioni. Ogni istanza del flusso cloud in questo scenario riceve un singolo oggetto. Se l'opzione SplitOn non è impostata, una singola istanza del flusso cloud ricever una matrice di valori.
I trigger di polling sono più facili da definire rispetto ai trigger webhook, ma sono meno granulari e spesso non funzionano altrettanto bene. La decisione di creare e usare un tipo di trigger o un altro è guidata dalle funzioni, dalla struttura e dalla funzionalità dell'API del servizio.