Cosa sono i connettori nei flussi di lavoro per App per la logica di Azure?

Quando si compila un flusso di lavoro usando App per la logica di Azure, è possibile usare un connettore per usare dati, eventi e risorse in altre app, servizi, sistemi e piattaforme, senza scrivere codice. Un connettore fornisce una o più operazioni predefinite, che vengono usate come passaggi del flusso di lavoro.

In un connettore ogni operazione è una condizione di trigger che avvia un flusso di lavoro o un'azione successiva che esegue un'attività specifica, insieme alle proprietà che è possibile configurare. Anche se molti connettori hanno trigger e azioni, alcuni connettori offrono solo trigger, mentre altri forniscono solo azioni.

In App per la logica di Azure i connettori sono disponibili in una versione predefinita, in una versione gestita o in entrambi. In genere, molti connettori richiedono prima la creazione e configurazione di una connessione al servizio o sistema sottostante, solitamente, in modo da poter autenticare l'accesso a un account utente. Se non è disponibile alcun connettore per il servizio o il sistema a cui si vuole accedere, è possibile inviare una richiesta usando l'operazione HTTP generica, oppure si può creare un connettore personalizzato.

Questa panoramica offre un'introduzione ai connettori ad alto livello e relativo funzionamento generale. Per maggiori informazioni sul connettore, vedere la documentazione seguente:

Connettori predefiniti e connettori gestiti

I connettori in App per la logica di Azure sono predefiniti o gestiti. Alcuni connettori hanno entrambe le versioni. Le versioni disponibili variano a seconda che si crei un flusso di lavoro dell'app per la logica A consumo eseguito in App per la logica di Azure multi-tenant, o un flusso di lavoro di app per la logica Standard eseguito in App per la logica di Azure a tenant singolo. Per maggiori informazioni sui tipi di risorse dell'app per la logica, vedere Tipi di risorse e differenze dell'ambiente host.

  • I connettori predefiniti sono progettati per l'esecuzione diretta e nativa in App per la logica di Azure.

    Nella finestra di progettazione tutti i connettori predefiniti vengono visualizzati nella raccolta connettori all'interno del gruppo In app .

  • I connettori gestiti vengono distribuiti, ospitati e gestiti in Azure da Microsoft. I connettori gestiti forniscono principalmente un proxy o un wrapper per un'API usata dal servizio o dal sistema sottostante per comunicare con App per la logica di Azure.

    Nel designer, tutti i connettori gestiti vengono visualizzati nella galleria dei connettori all'interno del gruppo Condiviso. Vengono fatturati a livello Standard o Enterprise.

Per altre informazioni, vedere la documentazione seguente:

Trigger

Un trigger specifica la condizione da soddisfare prima che il flusso di lavoro possa iniziare ed è sempre il primo passaggio in qualsiasi flusso di lavoro. Ogni trigger segue anche un modello di attivazione specifico che controlla il modo in cui il trigger monitora e risponde agli eventi. In genere, un trigger segue un modello di polling o un modello di push. In alcuni casi sono disponibili entrambe le versioni dei trigger.

  • I trigger di polling controllano regolarmente un servizio o un sistema specifico in base a una pianificazione specificata per verificare la presenza di nuovi dati o di un evento specifico. Se sono disponibili nuovi dati o si verifica l'evento specifico, questi trigger creano ed eseguono una nuova istanza del flusso di lavoro. Questa nuova istanza può quindi usare i dati passati come input.

    Note

    Per i connettori gestiti da Microsoft, ospitati ed eseguiti in Azure, i trigger di polling usano solo i valori Intervallo e Frequenza per calcolare la ricorrenza successiva. Non usano le opzioni di pianificazione avanzate, come ad esempio In queste ore e In questi giorni. Queste opzioni funzionano solo con trigger di polling predefiniti eseguiti direttamente con il runtime di App per la logica di Azure, ad esempio Ricorrenza,finestra temporale scorrevole e trigger HTTP.

  • I trigger push o webhook sono in ascolto dei nuovi dati o di un evento, senza eseguire il polling. Quando sono disponibili nuovi dati o quando si verifica l'evento, questi trigger creano ed eseguono una nuova istanza del flusso di lavoro. Questa nuova istanza può quindi usare i dati passati come input.

Si supponga, ad esempio, di voler compilare un flusso di lavoro che viene eseguito quando un file viene caricato nel server FTP. Come primo passaggio del flusso di lavoro, è possibile aggiungere il trigger FTP denominato Quando viene aggiunto o modificato un file, che segue un modello di polling. Specificare quindi la pianificazione per verificare regolarmente la presenza di eventi da caricare.

Quando il trigger viene attivato, il trigger passa in genere lungo gli output degli eventi per le azioni successive a cui fare riferimento e da utilizzare. Per l'esempio FTP, il trigger restituisce automaticamente informazioni quali il nome e il percorso del file. È anche possibile configurare il trigger per includere il contenuto del file. Per elaborare questi dati, è quindi necessario aggiungere azioni al flusso di lavoro.

Azioni

Un'azione specifica un'attività da eseguire e viene sempre visualizzata come passaggio successivo nel flusso di lavoro. È possibile usare più azioni nel flusso di lavoro. Ad esempio, è possibile avviare il flusso di lavoro con un trigger di SQL Server che verifica la presenza di nuovi dati dei clienti in un database SQL. Dopo il trigger, il flusso di lavoro può avere un'azione di SQL Server che ottiene i dati del cliente. Dopo questa azione di SQL Server, il flusso di lavoro può usare un'azione diversa che elabora i dati, ad esempio un'azione Operazioni dati che crea una tabella CSV.

Autorizzazioni di connessione

In un flusso di lavoro dell'app per la logica A consumo, prima di poter creare o gestire risorse, flussi di lavoro e connessioni dell'app per la logica, sono necessarie autorizzazioni specifiche. Per maggiori informazioni su queste autorizzazioni, vedere Proteggere le operazioni - Proteggere l'accesso e i dati in App per la logica di Azure.

Creazione, configurazione e autenticazione della connessione

Prima di poter usare le operazioni di un connettore nel flusso di lavoro, molti connettori richiedono prima la creazione di una connessione al servizio o al sistema di destinazione. Per creare una connessione dall'interno della finestra di progettazione del flusso di lavoro, è necessario autenticare l'identità con le credenziali dell'account e talvolta con altre informazioni di connessione.

Ad esempio, prima che il flusso di lavoro possa accedere e lavorare con l'account di posta elettronica di Office 365 Outlook, è necessario autorizzare una connessione a tale account. Per alcuni connettori predefiniti e connettori gestiti, è possibile configurare e usare un'identità gestita per l'autenticazione, anziché fornire le credenziali.

Per i connettori gestiti, le connessioni sono risorse Azure separate con le proprie definizioni di risorsa. Per i connettori integrati nei flussi di lavoro Standard, la configurazione della connessione viene memorizzata con la configurazione dell'app logica, inclusi il file connections.json e le impostazioni dell'app di riferimento. Per rivedere le informazioni di connessione, segui questi passaggi in base al fatto che tu abbia un flusso di lavoro Consumo o Standard:

Sicurezza e crittografia delle connessioni

I servizi Azure che memorizzano i dettagli di configurazione della connessione e i segreti li criptano a riposo. Lo storage e i controlli di accesso variano tra connessioni API gestite e connessioni integrate nei flussi di lavoro Standard. Le connessioni che utilizzano Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), come Office 365, Salesforce e GitHub, richiedono l'accesso, ma App per la logica di Azure memorizza token di accesso e aggiornamento invece delle password di accesso utente.

App per la logica di Azure può aggiornare i token di accesso OAuth mentre il token di aggiornamento rimane valido e il servizio target consente l'accesso. I token di aggiornamento possono scadere o essere revocati, il che potrebbe richiedere una riautorizzazione. Le modifiche alle credenziali possono anche invalidare i token, a seconda del fornitore di identità, del tipo di client e del flusso di autenticazione.

Note

Se l'organizzazione non consente di accedere a risorse specifiche tramite connettori in App per la logica di Azure, è possibile bloccare la funzionalità per creare tali connessioni usando Criteri di Azure.

Per maggiori informazioni sulla protezione dei flussi di lavoro e delle connessioni delle app per la logica, vedere Proteggere l'accesso e i dati in App per la logica di Azure.

Accesso al firewall per le connessioni

Se il tuo ambiente utilizza un firewall, consenti solo il traffico richiesto dai tuoi flussi di lavoro e dalle operazioni dei connettori:

Per maggiori informazioni, vedere l'articolo relativo alle configurazioni del firewall.

API e connettori personalizzati

Nei flussi di lavoro A consumo per App per la logica di Azure multi-tenant, è possibile chiamare API basate su Swagger o SOAP non disponibili come connettori preconfigurati. È anche possibile eseguire un codice personalizzato creando app per le API personalizzate. Per altre informazioni, vedere la documentazione seguente:

Nei flussi di lavoro Standard per App per la logica di Azure a tenant singolo, è possibile creare connettori predefiniti personalizzati basati su provider di servizi in esecuzione in modo nativo disponibili per qualsiasi flusso di lavoro dell'app per la logica Standard. Per altre informazioni, vedere la documentazione seguente:

Passaggi successivi

Creare un flusso di lavoro dell'app per la logica A consumo - Portale di Azure

Creare un flusso di lavoro dell'app per la logica Standard - Portale di Azure

  • Last updated on