Condividi tramite

Cosa sono i connettori gestiti in App per la logica di Azure

  • Articolo

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.

  • 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.

    • In un flusso di lavoro A consumo, i connettori gestiti vengono visualizzati nella finestra di progettazione sotto le etichette Standard o Enterprise, in base al livello di prezzo.

    • Nel flusso di lavoro Standard, tutti i connettori gestiti vengono visualizzati nella finestra di progettazione sotto l'etichetta Azure.

Per altre informazioni, consultare 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.

    Nota

    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 delle connessioni

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.

Anche se si creano connessioni all'interno di un flusso di lavoro, queste connessioni sono in realtà separate da risorse di Azure con le proprie definizioni di risorse. Per esaminare queste definizioni di risorse di connessione, seguire questa procedura in base al fatto che si disponga di un flusso di lavoro A consumo o Standard:

Sicurezza e crittografia delle connessioni

I dettagli di configurazione della connessione, ad esempio l'indirizzo del server, il nome utente e la password, le credenziali e i segreti vengono crittografati e archiviati nell'ambiente Azure protetto. Queste informazioni possono essere usate solo nelle risorse dell'app per la logica e dai client che dispongono delle autorizzazioni per la risorsa di connessione, che viene applicata usando i controlli di accesso collegati. Le connessioni che usano Microsoft Entra ID Open Authentication (Microsoft Entra ID OAuth), ad esempio Office 365, Salesforce e GitHub, richiedono l'accesso, ma app per la logica di Azure archivia solo i token di accesso e di aggiornamento come segreti, non le credenziali di accesso.

Le connessioni stabilite possono accedere al servizio o al sistema di destinazione per tutto il tempo consentito dal servizio o dal sistema. Per i servizi che usano connessioni OAuth di Microsoft Entra ID, ad esempio Office 365 e Dynamics, App per la logica di Azure aggiorna i token di accesso per un periodo illimitato. Altri servizi potrebbero avere limiti in merito al tempo durante il quale App per la logica può usare un token senza aggiornare. Alcune azioni, come la modifica della password, invalidano tutti i token di accesso.

Nota

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 si usa un firewall che limita il traffico e i flussi di lavoro dell'app per la logica devono comunicare tramite tale firewall, è necessario configurare il firewall per consentire l'accesso agli indirizzi IP sia in ingresso che in uscita usati dalla piattaforma o dal runtime di App per la logica di Azure nell'area di Azure in cui sono presenti i flussi di lavoro dell'app per la logica.

Se il flusso di lavoro usa anche connettori gestiti, ad esempio il connettore Outlook di Office 365 o il connettore SQL, oppure usa connettori personalizzati, il firewall deve consentire l'accesso anche a tutti gli indirizzi IP in uscita del connettore gestito nell'area di Azure della risorsa dell'app per la logica. 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, consultare 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, consultare la documentazione seguente:

Problemi noti

La tabella seguente include problemi noti per i connettori in App per la logica di Azure:

Error message Descrizione Risoluzione
Error: BadGateway. Client request id: '{GUID}' Questo errore è dovuto dall'aggiornamento dei tag in una risorsa dell'app per la logica in cui una o più connessioni non supportano l'autenticazione OAuth di Microsoft Entra ID, come ad esempio SFTP ad SQL, interrompendo tali connessioni. Per evitare questo comportamento, evitare di aggiornare tali tag.

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