Panoramica dei connettori per app canvas

I dati sono il nucleo della maggior parte delle app, comprese le app create in Power Apps. I dati sono archiviati in un'origine dati e si inseriscono i dati nell'app creando una connessione. La connessione usa un connettore specifico per comunicare con l'origine dati. Power Apps include connettori per molti servizi tra i più diffusi e per origini dati locali, tra cui SharePoint, SQL Server, Office 365, Salesforce e Twitter. Per iniziare ad aggiungere dati a un'app, vedere Aggiungere una connessione dati a un'app canvas in Power Apps.

Un connettore potrebbe fornire tabelle di dati o azioni. Alcuni connettori offrono solo tabelle, alcuni solo azioni e alcuni entrambi. Il connettore potrebbe anche essere un connettore standard o personalizzato.

Nota

Mantenere il numero di connettori in un app canvas a un massimo di 10 e i riferimenti a una connessione a non più di 20. Superare questi limiti può causare tempi di caricamento più lunghi per gli utenti durante l'avvio dell'app e possono causare problemi durante il salvataggio dell'app.

Tabelle

Se il connettore offre tabelle, aggiungi l'origine dati e quindi seleziona la tabella nell'origine dati che vuoi gestire. Power Apps recupera i dati della tabella nell'app e li aggiorna automaticamente nell'origine dati. Ad esempio, puoi aggiungere un'origine dati che contiene una tabella denominata Lezioni e quindi impostare la proprietà Elementi di un controllo, come una raccolta o un modulo, su questo valore nella barra della formula:

Specifica i dati che l'app recupera personalizzando la proprietà Elementi del controllo che visualizza i dati. Se continui l'esempio precedente, puoi ordinare o filtrare i dati nella tabella Lessons con tale nome come argomento per le funzioni Ricerca e SortByColumn. In questo grafico la formula su cui è impostata la proprietà Items specifica che i dati vengono ordinati e filtrati in base al testo in TextSearchBox1.

Per altre informazioni su come personalizzare la formula con le tabelle, vedi gli articoli seguenti:

Informazioni sulle origini dati in Power Apps
Generare un'app da dati di Excel
Creare un'app da zero
Informazioni sulle tabelle e sui record in Power Apps

Nota

Per connettersi ai dati in una cartella di lavoro di Excel, è necessario che questa sia ospitata in un servizio di archiviazione cloud come OneDrive. Per altre informazioni, vedere Connettersi all'archiviazione cloud da Power Apps.

Azioni

Se il connettore offre azioni, è comunque necessario selezionare l'origine dati come descritto in precedenza. Invece di selezionare una tabella come passaggio successivo, tuttavia, devi connettere un controllo a un'azione manualmente modificando la proprietà Items del controllo che visualizzerà i dati. La formula su cui impostare la proprietà Items specifica l'azione che recupera i dati. Ad esempio, l'app non recupera dati se ti connetti a Yammer e imposti la proprietà Items sul nome dell'origine dati. Per popolare un controllo con i dati, specifica un'azione, ad esempio GetMessagesInGroup (5033622).messages.

Per gestire gli aggiornamenti dei dati personalizzati per i connettori di azione, compila una formula che include la funzione Patch. Nella formula identifica l'azione e i campi che vengono associati all'azione.

Nota

Per i connettori basati su azioni, le raccolte e gli altri controlli non caricano automaticamente altri dati come fanno per i connettori tabulari. Ad esempio, se associ un'origine dati tabulare a una raccolta, essa recupera il primo set o pagina di record (ad esempio 100 record) e quindi carica più dati man mano che il controllo li richiede. Per un connettore basato su azioni, recupera una "pagina" di dati, ma se i dati richiesti superano le dimensioni della pagina, il controllo non recupera automaticamente la pagina successiva.

Per altre informazioni su come personalizzare la formula per gli aggiornamenti personalizzati, vedi gli articoli seguenti:

Patch
Collect
Aggiorna

Lo schema dinamico è un tipo comune di risultato per i connettori basati su azioni. Lo schema dinamico si riferisce alla possibilità che la stessa azione possa restituire una tabella con colonne diverse a seconda di come viene chiamata. Le condizioni che potrebbero causare differenze tra le colonne della tabella includono parametri di input, l'utente o il ruolo che esegue l'azione e il gruppo in cui l'utente sta lavorando, tra gli altri. Ad esempio, le stored procedure di SQL Server potrebbero restituire colonne differenti se eseguite con input differenti o un'istanza Azure DevOps potrebbe utilizzare campi personalizzati che non sono disponibili per impostazione predefinita.

Nota

La documentazione del connettore mostra i risultati dello schema dinamico con questo messaggio "Gli output di questa operazione sono dinamici." come valore restituito

Per altre informazioni su come utilizzare lo schema dinamico in Power Apps, vedi Utilizzare i valori dinamici per una panoramica e Connettersi ad Azure DevOps da Power Apps per un esempio dettagliato.

Connettori più diffusi

La tabella seguente include collegamenti a informazioni aggiuntive sui connettori più diffusi. Per l'elenco completo, vedere Tutti i connettori.

Microsoft Dataverse	Archiviazione nel cloud **
Dynamics AX	Excel
Microsoft Translator	Office 365 Outlook
Utenti di Office 365	Oracle
Power BI	SharePoint
SQL Server	Twitter

** Si applica ad Azure Blob, Box, Dropbox, Google Drive e OneDrive.

Connettori standard e personalizzati

Power Apps fornisce i connettori standard per molte origini dati di uso comune. Se Power Apps offre un connettore standard per il tipo di origine dati che vuoi usare, è consigliabile usare tale connettore. Per connetterti ad altri tipi di origini dati, ad esempio un servizio creato, vedi Registrare e utilizzare connettori personalizzati.

Tutti i connettori standard

I connettori standard non richiedono licenze speciali. Per altre informazioni, vedere Piani di Power Apps.

Poni domande su un connettore specifico nei forum di Power Apps e suggerisci i connettori che desideri aggiungere o altri miglioramenti da apportare in Idee di Power Apps.

Sicurezza e tipi di autenticazione

Quando si crea l'app e si crea una connessione a un'origine dati, è possibile che la scelta del connettore offra diversi modi per l'autenticazione. Ad esempio, il connettore SQL Server ti consente di utilizzare Microsoft Entra integrato, Autenticazione di SQL Server e Autenticazione di Windows. Ogni tipo di autenticazione ha livelli di sicurezza diversi. Comprendi quali informazioni e diritti condividi con gli utenti che utilizzano la tua applicazione. L'esempio principale di questo articolo è SQL Server. Tuttavia, i principi si applicano a tutti i tipi di connessioni.

Nota

• Per informazioni dettagliate sulle considerazioni sulla sicurezza quando si utilizza un server di database relazionale (come Microsoft SQL Server o Oracle) come origine dati per un'app, vedi Utilizzare Microsoft SQL Server in modo sicuro con Power Apps.
• Power Apps non supporta le identità dei membri esterni. Per altre informazioni, vedi Proprietà di un utente di collaborazione B2B di Microsoft Entra.
• La selezione del gateway non è supportata per i connettori personalizzati che usano il tipo di autenticazione anonima.

Microsoft Entra ID

Questa autenticazione è un tipo sicuro di connessione. Per esempio, SharePoint utilizza questo tipo di autenticazione. Anche SQL Server consente questo tipo di autenticazione. Quando ti connetti, il servizio Microsoft Entra ti identifica separatamente in SharePoint per tuo conto. Non è necessario fornire un nome utente o una password. In qualità di autore, è possibile creare e usare l'origine dati usando le credenziali. Quando si pubblica l'applicazione, l'utente dell'applicazione accede usando le proprie credenziali. Se i dati sono adeguatamente protetti su un back-end, i tuoi utenti possono vedere solo ciò che sono autorizzati a vedere in base alle rispettive credenziali. Questo tipo di sicurezza consente di modificare i diritti per utenti specifici dell'applicazione sull'origine dati back-end dopo la pubblicazione dell'applicazione. Ad esempio, puoi concedere l'accesso, negare l'accesso o perfezionare ciò che un utente o un set di utenti può vedere tutto sull'origine dati back-end.

Autorizzazione open standard (Oauth)

Anche questo è un tipo sicuro di connessione. Ad esempio, Twitter utilizza questo tipo di autenticazione. Quando ci si connette, è necessario specificare il nome utente e la password. In qualità di autore, è possibile creare e usare l'origine dati usando le credenziali. Quando si pubblica l'applicazione e l'utente dell'applicazione accede, è necessario specificare anche le proprie credenziali. Pertanto, questo tipo di connessione è sicuro poiché gli utenti devono utilizzare le proprie credenziali per accedere al servizio dell'origine dati.

Connessioni condivise e connessioni implicite sicure

In una connessione condivisa, l'autore di Power Apps fornisce il nome utente e la password per la connessione durante la creazione dell'origine dati nell'applicazione. L'autenticazione di connessione all'origine dati viene quindi condivisa in modo implicito con gli utenti finali. Non appena l'applicazione viene pubblicata, anche la connessione viene pubblicata ed è disponibile per gli utenti.

Prima di gennaio 2024, gli utenti finali potrebbero prendere la connessione condivisa con loro e creare nuove applicazioni separate. Gli utenti non possono visualizzare il nome utente o la password, ma la connessione è disponibile. Tuttavia, dopo gennaio 2024, tutte le nuove connessioni condivise create vengono protette. Per proteggere le app esistenti, ripubblicarle. La connessione non è più condivisa con gli utenti finali. La Power App pubblicata comunica con un proxy di connessione. Il proxy della connessione comunica solo con la Power App specifica per la quale è collegata. Il proxy di connessione limita le azioni inviate alle connessioni a quelle in Power App {Get, Put/Patch, Delete} per una determinata origine dati. Se si dispone di un'app che usa le connessioni pubblicate prima di gennaio 2024, ripubblicare l'applicazione e annullare la condivisione delle connessioni con gli utenti finali che non devono avere tali connessioni.

In SQL Server, un esempio di questo tipo di connessione è l'autenticazione di SQL Server. Molte altre origini dati del database offrono funzionalità simili. Quando pubblichi la tua applicazione, i tuoi utenti non devono fornire un nome utente e una password univoci.

Nota

Gli utenti finali potrebbero riscontrare il messaggio di errore Non si dispone delle autorizzazioni corrette per usare questa connessione nella finestra di dialogo di consenso. Due situazioni possono causare questo errore. In primo luogo, l'applicazione potrebbe avere una connessione implicita condivisa che non è una connessione implicita sicura. La condivisione della connessione con l'utente finale risolve questo problema, ma non è consigliata perché tutte le connessioni condivise devono essere connessioni implicite sicure. Per risolvere questo problema, l'autore deve convertire tutte le connessioni nell'applicazione in connessioni implicite sicure. In secondo luogo, la connessione potrebbe essere già una connessione implicita sicura. La ripubblicazione potrebbe risolvere questo problema. In caso contrario, è necessario segnalare un bug del prodotto.

Notifica per aggiornare le tue app (connessioni implicite sicure)

Se si dispone di applicazioni che potrebbero essere aggiornate per usare questa funzionalità, viene visualizzato un messaggio nella pagina App . Indica il numero di app che richiedono la tua attenzione.

La selezione del collegamento apre un pannello laterale in cui sono elencate tutte le app che necessitano attenzione.

Seleziona l'icona Apri a destra del nome dell'app per aprirla e ripubblicarla. Prosegui con le seguenti indicazioni.

Abilita connessioni implicite sicure per un'app esistente

Apri un'app esistente aperta per la modifica con connessioni implicitamente condivise già pubblicate:

1. Sulla barra dei comandi, seleziona Impostazioni e cerca "Protetto".
2. Aggiorna l'interruttore della funzione in modo appropriato per abilitare connessioni implicite protette.
3. Salvare e pubblicare l'app.

Annullamento condivisione

Dopo aver pubblicato l'app, seguire questa procedura per verificare che la condivisione funzioni correttamente:

• Controlla se le connessioni sono condivise con i comproprietari. Se non desideri che un utente finale ottenga una connessione, deseleziona la casella di controllo Comproprietario.

• Per verificare che la funzionalità funzioni correttamente, condividi l'app con un altro utente che non è un proprietario. Dopo aver condiviso l'app, controlla l'elenco Connessioni nella scheda Dataverse in Power Apps per quell'utente. Verificare che l'utente non disponga di una connessione disponibile.

• Apri il pannello Condivisione per modificare il diritto dell'utente finale alla connessione. Scegliere la X per rimuovere l'accesso dell'utente alla connessione.

Usa le app con una nuova connessione implicita sicura

Quando ripubblici e condividi l'app, gli utenti finali non hanno accesso alla connessione, ma lavorano con la connessione proxy nascosta. Gli utenti non possono creare una nuova app in base alla connessione originale.

Limiti

1. Tutti i tipi di connessioni condivise in modo implicito funzionano, ad esempio azioni e tabulari.
2. I nomi di server e database sono nascosti nelle tracce di rete ma visibili nella finestra di dialogo del consenso. I nomi delle colonne non sono nascosti.
3. Per i connettori tabulari, la funzionalità limita solo le azioni CRUD come Get, Post, Put o Delete. Se disponi delle autorizzazioni per Put allora hai accesso a Post.
4. Limite dei connettori basati sull'azione in base all'API specifica utilizzata nell'applicazione.
5. Gli avvisi sono ancora abilitati nella condivisione. L'avviso relativo alle connessioni implicitamente condivise viene comunque visualizzato durante l'anteprima. Tuttavia, la tua connessione con questa funzione è sicura, nonostante l'avviso.
6. La pubblicazione in un intero tenant, anziché in gruppi o individui specifici, non è supportata.
7. Si verifica un problema noto durante l'importazione di una connessione protetta implicitamente condivisa tramite un riferimento a una connessione. La sicurezza non è impostata correttamente nell'ambiente di destinazione.
8. C'è un problema noto nell'importazione di una soluzione mediante un'entità di servizio, che impedisce l'esito positivo dell'importazione. Una soluzione alternativa consiste nel condividere la connessione con l'entità servizio.

Autenticazione di Windows

Questo tipo di connessione non è sicuro perché non si basa sull'autenticazione dell'utente finale. Utilizza l'autenticazione di Windows quando è necessario connettersi a un'origine dati locale. Un esempio di questo tipo di connessione è un server locale che dispone di un SQL Server. La connessione deve passare attraverso un gateway. Dal momento che passa attraverso un gateway, il connettore ha accesso a tutti i dati dell'origine dati. Di conseguenza, tutte le informazioni a cui è possibile accedere con le credenziali di Windows fornite sono disponibili per il connettore. Quando si pubblica l'applicazione, si pubblica anche la connessione e la si rende disponibile agli utenti. Questo comportamento significa che gli utenti finali possono creare applicazioni usando questa stessa connessione e accedere ai dati nel computer. Anche le connessioni all'origine dati sono implicitamente condivise con gli utenti con cui l'app è condivisa. Questo tipo di connessione potrebbe essere valido quando l'origine dati risiede solo su un server locale e i dati dell'origine sono liberamente condivisibili.

Origini dati nelle soluzioni

Le soluzioni semplificano la gestione del ciclo di vita delle applicazioni e offrono altri modi per gestire il ciclo di vita delle origini dati. Se un'app canvas si trova in una soluzione, è possibile creare riferimenti di connessione e variabili di ambiente per archiviare informazioni sulle origini dati. Questa configurazione semplifica la modifica o la riconnessione delle origini dati quando si spostano le soluzioni in ambienti diversi.

Rinominare origini dati nelle app

Scopri come rinominare le origini dati in un'app e comprendi la differenza tra origini dati tabulari e basate su azioni. Per altre informazioni, vedi Rinominare le origini dati basate su azioni di Power Apps.

Finestra di dialogo per consenso alla connessione

Quando gli utenti aprono un'app che usa i connettori per la prima volta, visualizzano una finestra di dialogo di consenso alla connessione per gli scopi seguenti.

1. Per informare gli utenti sulle origini dati a cui l'app accede.
2. Per delineare le azioni che un connettore potrebbe o meno eseguire in un'app. Ad esempio, per le app che utilizzano il connettore Utenti di Office 365:

• Questa app è in grado di:
  • Leggere il tuo profilo utente completo
  • Leggere il profilo completo di tutti gli utenti
• L'app non può:
  • Modificare o eliminare qualsiasi informazione del profilo utente

1. Acquisire il consenso dell'utente finale per connettersi alle origini dati utilizzate dall'app.
2. Per facilitare l'autenticazione manuale dell'utente finale, quando necessario.

Per alcune connessioni, Power Platform può autenticare automaticamente un utente per l'accesso a un'origine dati. Tuttavia, se l'accesso automatico non riesce, questa finestra di dialogo richiede agli utenti di correggere una connessione effettuando l'accesso manualmente. Power Platform può tentare l'accesso automatico per una connessione solo quando un'origine dati preautorizza l'entità servizio delle connessioni API Azure di Microsoft, concedendogli l'autorizzazione per eseguire il Single Sign-On per un utente quando viene creata una connessione. Per ulteriori informazioni sul Single Sign-On, vedi Cos'è il Single Sign-On (SSO)?

Per le app basate su modello che usano pagine personalizzate, quando sono presenti più pagine personalizzate in un'app, la finestra di dialogo di consenso richiede autorizzazioni per i dati per tutti i connettori in tutte le pagine personalizzate anche se gli utenti non li aprono.

L'immagine seguente è un esempio della finestra di dialogo del consenso alla connessione per un'app che si connette a un sito SharePoint.

Per i connettori selezionati, gli amministratori possono eliminare questa finestra di dialogo e fornire il consenso per conto degli utenti finali per connettersi a un'origine dati. La tabella seguente illustra per quali tipi di connettori la finestra di dialogo per il consenso potrebbe essere eliminata per un'app.

Nota

Se un amministratore elimina la finestra di dialogo di consenso ma la piattaforma non può eseguire l'accesso Single Sign-On per un utente finale, la finestra di dialogo viene presentata all'utente quando avvia l'app.

Tipo di connettore	Finestra di dialogo per il consenso eliminabile?	Riferimento
Connettori di Microsoft che supportano Single Sign-On (come SharePoint, Utenti di Office 365)	Sì	Cmdlet dell'amministratore di Power Apps
Connettore che accede a un servizio partner non Microsoft, come Salesforce	No	Non applicabile
Connettori personalizzati che utilizzano OAuth con Microsoft Entra ID come provider di identità. Questi connettori personalizzati sono creati dalle organizzazioni e sono accessibili solo dagli utenti all'interno dell'organizzazione (sono, ad esempio, creati da Contoso solo per gli utenti di Contoso)	Sì	Gestire le connessioni

Microsoft Power Platform può eliminare solo la finestra di dialogo di consenso per le connessioni alle origini dati in cui sono soddisfatte tutte le condizioni seguenti:

1. L'origine dati non richiede un'interfaccia utente di consenso esplicita.
2. L'origine dati preautorizza l'entità servizio delle connessioni API Azure di Microsoft per abilitare Single Sign-On.
3. Un amministratore configura un'app per eliminare il consenso per le connessioni precedenti.

La preautorizzazione dell'entità servizio delle connessioni API di Microsoft Azure è disponibile per le origini del produttore di Microsoft. Le applicazioni personalizzate registrate in un tenant di Microsoft Entra usate dai connettori personalizzati potrebbero configurare questa preautenticazione. Un amministratore gestisce l'eliminazione del consenso in base all'app (anziché su base connettore), quindi l'eliminazione viene gestita a livello di esperienza dell'app più granulare. Questo livello di granularità impedisce l'eliminazione del consenso per le "app approvate" di un'organizzazione dall'eliminazione accidentale del consenso per le app non approvate o esaminate.