Présentation des connecteurs pour les applications canevas

Les données sont au cœur de la plupart des applications, y compris celles que vous créez dans Power Apps. Les données sont stockées dans une source de données et vous importez ces données dans votre application en créant une connexion. La connexion utilise un connecteur spécifique pour parler à la source de données. Power Apps a des connecteurs pour de nombreux services populaires et les sources de données sur site, y compris SharePoint, SQL Server, Office 365, Salesforce et Twitter. Pour commencer à ajouter des données à une application canevas, consultez Ajouter une connexion de données dans Power Apps.

Un connecteur peut fournir des tableaux de données ou des actions. Certains connecteurs ne fournissent que des tableaux, certains ne fournissent que des actions et certains fournissent les deux. De plus, votre connecteur peut être un connecteur standard ou personnalisé.

Tables

Si votre connecteur fournit des tables, ajoutez votre source de données, puis sélectionnez la table dans la source de données à gérer. Power Apps récupère les données de la table dans votre application, et met automatiquement à jour les données de votre source de données pour vous. Par exemple, vous pouvez ajouter une source de données contenant une table nommée Lessons, puis affecter cette valeur à la propriété Items d’un contrôle, par exemple Gallery ou Form, dans la barre de formule :

Vous pouvez spécifier les données récupérées par votre application en personnalisant la propriété Items du contrôle qui affiche vos données. En reprenant l’exemple précédent, vous pouvez trier ou filtrer les données de la table Lessons en utilisant ce nom en tant qu’argument pour les fonctions Search et SortByColumn. Dans cette image, la formule où est définie la propriété Items indique que les données sont triées et filtrées en fonction du texte contenu dans TextSearchBox1.

Pour plus d’informations sur la personnalisation de votre formule avec des tables, consultez les articles suivants :

Comprendre les sources de données dans Power Apps
Générer une application à partir de données Excel
Créer une application à partir de zéro
Comprendre les tables et les enregistrements dans Power Apps

Actions

Si votre connecteur fournit des actions, vous devez continuer à sélectionner la source de données, comme auparavant. Toutefois, au lieu de sélectionner une table à l’étape suivante, vous devez connecter manuellement un contrôle à une action en modifiant la propriété Items du contrôle qui affiche vos données. La formule où vous définissez la propriété Items spécifie l’action qui récupère les données. Par exemple, l’application ne doit pas récupérer de données si vous vous connectez à Yammer, et si vous affectez ensuite le nom de la source de données à la propriété Items. Pour remplir un contrôle avec des données, spécifiez une action telle que GetMessagesInGroup(5033622).messages.

Si vous devez prendre en charge des mises à jour de données personnalisées pour des connecteurs d’action, créez une formule qui inclut la fonction Patch. Dans la formule, identifiez l’action et les champs à lier à l’action.

Pour plus d’informations sur la personnalisation de votre formule pour des mises à jour personnalisées, consultez les articles suivants :

Patch
Collect
Update

Le schéma dynamique est un type de résultat courant pour les connecteurs basés sur des actions. Le schéma dynamique fait référence à la possibilité que la même action puisse renvoyer une table avec des colonnes différentes, selon la façon dont elle est appelée. Les conditions pouvant entraîner des différences dans les colonnes de la table sont notamment les paramètres d’entrée, l’utilisateur ou le rôle qui exécute l’action et le groupe dans lequel l’utilisateur travaille, entre autres. Par exemple, les procédures stockées SQL Server peuvent renvoyer des colonnes différentes si elles sont exécutées avec des entrées différentes, ou une instance Azure DevOps peut utiliser des champs personnalisés qui ne sont pas disponibles par défaut. Notez que la documentation du connecteur affiche les résultats du schéma dynamique avec ce message Les sorties de cette opération sont dynamiques. comme valeur renvoyée.

Pour plus d’informations sur l’utilisation d’un schéma dynamique dans Power Apps, consultez Travailler avec des objets sans type et dynamiques pour obtenir un aperçu et Se connecter à Azure DevOps depuis Power Apps pour obtenir un exemple détaillé.

Connecteurs les plus courants

Le tableau suivant contient des liens vers plus d’informations sur nos connecteurs les plus populaires. Pour obtenir la liste complète des connecteurs, consultez Tous les connecteurs.

** S’applique à Azure Blob, Box, Dropbox, Google Drive, OneDrive et OneDrive Entreprise

Connecteurs standard et personnalisés

Power Apps fournit les connecteurs standard pour de nombreuses sources de données couramment utilisées. Si Power Apps a un connecteur standard pour le type de source de données à utiliser, vous devez vous en servir. Si vous souhaitez vous connecter à d’autres types de source de données, par exemple un service que vous avez créé, consultez S’inscrire et utiliser des connecteurs personnalisés.

Tous les connecteurs standard

Les connecteurs standard ne nécessitent pas de licence spéciale. Pour plus d’informations, voir Plans Power Apps.

Vous pouvez poser des questions relatives à un connecteur spécifique sur les forums Power Apps. De plus, vous pouvez suggérer des connecteurs à ajouter ou des améliorations à apporter dans Power Apps Ideas.

Sécurité et types d’authentification

Lorsque vous créez votre application et une connexion à une source de données, vous pouvez constater que votre choix de connecteur vous permet d’utiliser différentes méthodes d’authentification. Par exemple, le connecteur SQL Server vous permet d’utiliser Microsoft Entra intégré, l’authentification SQL Server et l’authentification Windows. Chaque type d’authentification a différents niveaux de sécurité associés. Il est important de comprendre les informations et les droits que vous partagez avec les utilisateurs qui utilisent votre application. Le principal exemple de cet article est SQL Server, mais les principes s’appliquent à tous les types de connexions.

ID Microsoft Entra

Il s’agit d’un type de connexion sécurisé. Par exemple, SharePoint utilise ce type d’authentification. SQL Server permet également ce type d’authentification. Lorsque vous vous connectez, le service Microsoft Entra vous identifie séparément SharePoint en votre nom. Vous n’avez pas à fournir de nom d’utilisateur ou de mot de passe. En tant qu’auteur, vous pouvez créer et travailler avec le source de données avec vos informations d’identification. Lorsque vous publiez votre application et que vos utilisateurs d’application se connectent, ils le font avec leurs informations d’identification. Si les données sont correctement sécurisées sur un serveur principal, vos utilisateurs ne peuvent voir ce qu’ils sont autorisés à voir qu’en fonction de leurs informations d’identification. Ce type de sécurité vous permet de modifier les droits d’utilisateurs spécifiques de l’application sur la principale source de données après la publication de l’application. Par exemple, vous pouvez accorder l’accès, refuser l’accès ou affiner ce qu’un utilisateur ou un ensemble d’utilisateurs peut voir sur la principale source de données.

Autorisation standard ouverte (OAuth)

Il s’agit d’un type de connexion également sécurisé. Par exemple, Twitter utilise ce type d’authentification. Lorsque vous vous connectez, vous devez fournir votre nom d’utilisateur et votre mot de passe. En tant qu’auteur, vous pouvez créer et travailler avec la source de données avec vos informations d’identification. Lorsque vous publiez votre application et que vos utilisateurs d’application se connectent, ils doivent également fournir leurs informations d’identification. Par conséquent, ce type de connexion est sécurisé, car vos utilisateurs doivent utiliser leurs propres informations d’identification pour accéder au service de la source de données.

Connexions partagées/Connexions implicites sécurisées

Dans une connexion partagée, le nom d’utilisateur et le mot de passe pour la connexion sont fournis par le créateur de Power Apps au moment de la création de la source de données dans l’application. L’authentification de la connexion à la source de données est ensuite Partagée implicitement avec les utilisateurs finaux. Une fois l’application publiée, la connexion est également publiée et disponible pour vos utilisateurs.

Avant janvier 2024, vos utilisateurs finaux pouvaient utiliser la connexion partagée avec eux et créer de nouvelles applications distinctes. Vos utilisateurs ne peuvent pas voir le nom d’utilisateur ou le mot de passe, mais la connexion est disponible pour eux. Cependant, après janvier 2024, toutes les connexions partagées nouvellement créées sont sécurisées. Notez que les anciennes applications doivent être republiées pour être sécurisées. Cela signifie que la connexion n’est plus partagée avec les utilisateurs finaux. La Power App publiée communique avec un proxy de connexion. Le proxy de connexion communiquera uniquement avec la Power App spécifique à laquelle il est lié. Le proxy de connexion limite les actions envoyées aux connexions à celles de la Power App {Get, Put/Patch, Delete} pour une source de données déterminée. Si vous disposez d’une application qui utilise les connexions publiées avant janvier 2024, vous devez republier votre application et annuler le partage de toutes les connexions avec les utilisateurs finaux qui ne devraient pas les avoir.

Dans SQL Server, un exemple de ce type de connexion est Authentification de SQL Server. De nombreuses autres sources de données de la base de données offrent une capacité similaire. Lorsque vous publiez votre application, vos utilisateurs n’ont pas besoin de fournir un nom d’utilisateur et un mot de passe uniques.

Notification de mise à jour de vos applications (connexions implicites sécurisées)

Si vous avez des applications qui peuvent être mises à niveau pour utiliser cette fonctionnalité, vous verrez un message sur la page des applications. Il indique le nombre d’applications qui nécessitent votre attention.

Sélectionnez le lien et il ouvre un volet latéral qui répertorie toutes les applications nécessitant une attention particulière.

Sélectionnez l’icône Ouvrir à droite du nom de l’application pour l’ouvrir et la republier. Consultez les directions ci-dessous.

Activer les connexions implicites sécurisées pour l’application existante

Ouvrez une application existante ouverte pour modification avec des connexions partagées implicitement qui a déjà été publiée :

1. Dans la barre de commandes, sélectionnez Paramètres et recherchez Sécurisé.
2. Mettez à jour le commutateur de fonctionnalité de manière appropriée pour activer les connexions implicites sécurisées.
3. Enregistrez et publiez l’application.

Annulation du partage

Une fois l’application publiée, suivez ces étapes pour vérifier que le partage fonctionne correctement :

• Vérifiez si les connexions sont partagées avec les copropriétaires. Si vous ne souhaitez pas qu’un utilisateur final obtienne une connexion, décochez la case Copropriétaire.

  

• Pour vérifier que la fonctionnalité fonctionne correctement, partagez l’application avec un autre utilisateur qui n’est pas propriétaire. Une fois que vous avez partagé l’application, consultez la liste Connexions dans l’onglet Dataverse dans Power Apps pour cet utilisateur. Vérifiez que l’utilisateur n’a pas de connexion disponible.

• Ouvrez le volet Partage pour modifier le droit de l’utilisateur final à la connexion. Choisir le X supprimera l’accès de l’utilisateur à la connexion.

  

Utiliser des applications avec une nouvelle connexion implicite sécurisée

Quand votre application est republiée et partagée, les utilisateurs finaux n’auront pas accès à la connexion mais travailleront avec la connexion proxy masquée. Ils ne pourront pas créer une application basée sur votre connexion d’origine.

Limitations

1. Tous les types de connexions implicitement partagées fonctionnent, telles que l’action et la tabulation.
2. Les noms de serveur et de base de données sont masqués dans les traces réseau mais visibles dans la boîte de dialogue de consentement. Les noms de colonne ne sont pas masqués.
3. Pour les connecteurs tabulaires, nous limitons uniquement les actions CRUD telles que Get, Post, Put ou Delete. Si vous êtes autorisé à Put alors vous avez accès à Post.
4. Limite des connecteurs basés sur l’action en fonction de l’API spécifique utilisée dans l’application.
5. Les avertissements sont toujours activés dans le partage. L’avertissement concernant les connexions partagées implicitement avertit toujours dans la préversion privée. Cependant, votre connexion avec cette fonctionnalité est sécurisée, malgré l’avertissement.
6. La publication sur un client entier, par opposition à des groupes ou des individus spécifiques, n’est pas prise en charge.
7. Il existe un problème connu lors de l’importation d’une connexion sécurisée implicitement partagée via une référence de connexion. La sécurité n’est pas définie correctement dans l’environnement cible.
8. Il existe un problème connu lors de l’importation d’une solution à l’aide d’un principal de service, entraînant un échec de l’importation. Une solution de contournement consiste à partager la connexion avec le principal du service.

Authentification Windows

Ce type de connexion n’est pas sécurisé, car il ne repose pas sur l’authentification de l’utilisateur final. Utilisez l’authentification Windows lorsque vous devez vous connecter à une source de données qui est locale. Un exemple de ce type de connexion n’est autre qu’une connexion à un serveur local doté d’un serveur SQL. La connexion doit passer par une passerelle. Puisqu’il passe par une passerelle, le connecteur a accès à toutes les données sur cette source de données. Par conséquent, toutes les informations auxquelles vous pouvez accéder avec les informations d’identification Windows que vous fournissez sont disponibles pour le connecteur. Une fois l’application publiée, la connexion est également publiée et disponible pour vos utilisateurs. Ce comportement signifie que vos utilisateurs finaux peuvent également créer des applications en utilisant cette même connexion et accéder aux données sur cette machine. Les connexions à la source de données sont également Partagées implicitement avec les utilisateurs avec lesquels l’application est partagée. Ce type de connexion peut être valide si votre source de données ne se trouve que sur un serveur local et si les données de cette source sont librement partageables.

Sources de données dans les solutions

Les solutions sont utilisées pour la gestion du cycle de vie des applications et fournissent des fonctionnalités supplémentaires pour gérer le cycle de vie des sources de données. Si une application canevas se trouve dans une solution, les références de connexion et les variables d’environnement peuvent être créés pour stocker des informations sur les sources de données. Cela garantit que les sources de données peuvent être modifiées ou rétablies lorsque les solutions sont migrées vers différents environnements.

Renommer des sources de données dans des applications

Pour en savoir plus sur le renommage des sources de données dans une application et la différence entre les sources de données tabulaires et basées sur des actions, accédez à Renommer les sources de données Power Apps basées sur l’action.

Boîte de dialogue de consentement de connexion

Lorsque les utilisateurs ouvrent une application qui utilise des connecteurs pour la première fois, ils voient une boîte de dialogue « consentement à la connexion » aux fins suivantes.

1. Informer les utilisateurs sur les sources de données accessibles par l’application.

2. Décrire les actions qu’un connecteur peut ou ne peut pas effectuer dans une application. Par exemple, pour les applications utilisant le connecteur Office 365 Users, cela pourrait ce qui suit.

   • Cette application peut :
     • Lire votre profil d’utilisateur complet
     • Lire le profil complet de tous les utilisateurs
   • Elle ne pourra pas :
     • Modifier ou supprimer toute information de profil utilisateur

3. Obtenir le consentement de l’utilisateur final à se connecter aux sources de données utilisées par l’application

4. Faciliter l’authentification manuelle de l’utilisateur final, si nécessaire

Pour certaines connexions, Power Platform peut authentifier automatiquement un utilisateur pour accéder à une source de données. Cependant, si la connexion automatique échoue, cette boîte de dialogue invite les utilisateurs à réparer une connexion en se connectant manuellement. Power Platform peut uniquement tenter la connexion automatique pour une connexion lorsqu’une source de données pré-autorise le principal du service de connexions Azure API de Microsoft, en lui accordant l’autorisation d’effectuer une connexion unique pour un utilisateur lorsqu’une connexion est créée. Pour plus d’informations sur l’authentification unique, consultez Qu’est-ce que l’authentification unique (SSO) ?

Notez que pour les applications pilotées par modèle qui utilisent des pages personnalisées, lorsqu’une application contient plusieurs pages personnalisées, la boîte de dialogue de consentement demande les autorisations de données pour tous les connecteurs dans toutes les pages personnalisées même si elles n’ont pas encore été ouvertes.

L’image suivante est un exemple de la boîte de dialogue d’autorisation de connexion pour une application se connectant à un site SharePoint.

Pour certains connecteurs, les administrateurs peuvent supprimer cette boîte de dialogue et consentir au nom des utilisateurs finaux à se connecter à une source de données. Le tableau suivant explique quels types de connecteurs la boîte de dialogue de consentement peuvent être supprimés pour une application.

Microsoft Power Platform ne peut supprimer la boîte de dialogue de consentement que pour les connexions aux sources de données où :

1. La source de données n’oblige pas à afficher une interface utilisateur de consentement explicite.
2. La source de données pré-autorise le principal du service de connexions d’API Azure de Microsoft à activer l’authentification unique.
3. Un administrateur configure une application pour supprimer le consentement pour les connexions précédentes.

La pré-autorisation du principal du service de connexions d’API Azure de Microsoft existe pour les sources de données propriétaires de Microsoft et peut être configurée par des applications personnalisées enregistrées dans un locataire Microsoft Entra qui sont utilisées par les connecteurs personnalisés. Un administrateur gère la suppression du consentement par application (par opposition à la base du connecteur), de sorte que la suppression est gérée au niveau d’expérience de l’application le plus granulaire — Ce niveau de granularité empêche la suppression du consentement pour les « applications approuvées » d’une organisation qui risqueraient de supprimer par inadvertance le consentement pour les applications qui ne sont pas approuvées ou examinées.