Che cosa sono i connettori 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. Molti connettori richiedono in genere di creare e configurare una connessione al servizio o al sistema sottostante, in genere 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 creare un connettore personalizzato.

Questa panoramica offre un'introduzione generale ai connettori e il relativo funzionamento generale. Per altre informazioni sul connettore, vedere la documentazione seguente:

Connettori predefiniti e connettori gestiti

In App per la logica di Azure i connettori sono incorporati o gestiti. Alcuni connettori hanno entrambe le versioni. Le versioni disponibili dipendono dal fatto 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 in un flusso di lavoro di app per la logica Standard eseguito in App per la logica di Azure a tenant singolo. Per altre 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 all'interno di 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 intorno a 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.

    • In un flusso di lavoro Standard tutti i connettori gestiti vengono visualizzati nella finestra di progettazione sotto l'etichetta di 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.

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

Quando il trigger viene attivato, il trigger passa in genere lungo gli output degli eventi per le azioni successive a cui fare riferimento e usare. 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 altre informazioni su queste autorizzazioni, vedere Operazioni sicure - Proteggere l'accesso e i dati in App per la logica di Azure.

Connessione creazione, configurazione e autenticazione

Prima di poter usare le operazioni di un connettore nel flusso di lavoro, molti connettori richiedono di creare prima 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 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 di Connessione ion

Connessione dettagli di configurazione, 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. Connessione ions 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 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 con ID Microsoft Entra, 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 per quanto tempo App per la logica può usare un token senza aggiornare. Alcune azioni, ad esempio 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 possibilità di creare tali connessioni usando Criteri di Azure.

Per altre 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 in ingresso e 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 i flussi di lavoro usano anche connettori gestiti, ad esempio il connettore Di Office 365 Outlook o il connettore SQL, oppure usare connettori personalizzati, il firewall deve anche consentire l'accesso a tutti gli indirizzi IP in uscita del connettore gestito nell'area di Azure della risorsa dell'app per la logica. Per altre informazioni, vedere Configurazione del firewall.

API e connettori personalizzati

In 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 predefiniti. È anche possibile eseguire 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 nativa disponibili per qualsiasi flusso di lavoro di app per la logica Standard. Per altre informazioni, consultare la documentazione seguente:

I edizione Standard e connettori

Per i flussi di lavoro che richiedono l'accesso diretto alle risorse in una rete virtuale di Azure, è possibile creare un ambiente del servizio di integrazione dedicato (I edizione Standard) in cui è possibile compilare, distribuire ed eseguire i flussi di lavoro in risorse dedicate. Per altre informazioni sulla creazione di edizione Standard, vedere Connessione alle reti virtuali di Azure da App per la logica di Azure.

I connettori personalizzati creati all'interno di un edizione Standard non funzionano con il gateway dati locale. Tuttavia, questi connettori possono accedere direttamente alle origini dati locali connesse a una rete virtuale di Azure che ospita l edizione Standard. Pertanto, i flussi di lavoro dell'app per la logica in un I edizione Standard probabilmente non necessitano del gateway dati durante la comunicazione con tali risorse. Se sono presenti connettori personalizzati creati all'esterno di un edizione Standard che richiedono il gateway dati locale, i flussi di lavoro in un I edizione Standard possono usare tali connettori.

Nella finestra di progettazione del flusso di lavoro, quando si esplorano i connettori predefiniti o i connettori gestiti da usare per i flussi di lavoro in un I edizione Standard, l'etichetta CORE viene visualizzata nei connettori predefiniti, mentre l'etichetta I edizione Standard viene visualizzata sui connettori gestiti progettati per funzionare con un I edizione Standard.

Example CORE connector

NUCLEO

I connettori predefiniti con questa etichetta vengono eseguiti nello stesso I edizione Standard dei flussi di lavoro.

Example ISE connector

ISE

I connettori gestiti con questa etichetta vengono eseguiti nello stesso I edizione Standard dei flussi di lavoro.

Se si dispone di un sistema locale connesso a una rete virtuale di Azure, un'interfaccia I edizione Standard consente ai flussi di lavoro di accedere direttamente a tale sistema senza usare il gateway dati locale. È invece possibile usare il connettore I edizione Standard del sistema, se disponibile, un'azione HTTP o un connettore personalizzato.

Per i sistemi locali che non dispongono di connettori I edizione Standard, usare il gateway dati locale. Per trovare i connettori I edizione Standard disponibili, vedere Connettori I edizione Standard.

Example non-ISE connector

Nessuna etichetta

Tutti gli altri connettori senza etichetta, che è possibile continuare a usare, vengono eseguiti nel servizio app per la logica multi-tenant globale.

Problemi noti

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

Messaggio di errore Descrizione Risoluzione
Error: BadGateway. Client request id: '{GUID}' Questo errore causa l'aggiornamento dei tag in una risorsa dell'app per la logica in cui una o più connessioni non supportano l'autenticazione OAuth dell'ID Microsoft Entra, 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