Présentation des connecteurs pour les applications canevas

  • Article

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 :

Propriété Items d’une source de données simple.

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.

Propriété Items d’une source de données développée.

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

Notes

Pour vous connecter aux données d’un classeur Excel, celui-ci doit être hébergé dans un service de stockage cloud tel que OneDrive. Pour plus d’informations, consultez Se connecter au stockage cloud à partir de 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.

Propriété Items d’une source de données d’action.

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.

Notes

Pour les connecteurs basés sur des actions, les galeries et autres contrôles n’introduisent pas plus de données automatiquement, tout comme pour les tables. Par exemple, si vous liez une action à une galerie, elle récupérera le premier ensemble ou la première page d’enregistrements. Mais si les données demandées dépassent la taille d’une page de données, le contrôle ne récupère pas automatiquement la page suivante. Vous devez gérer cela directement avec les collections.

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

Patch
Collect
Update

Notes

Pour travailler avec un schéma dynamique, vous pouvez utiliser une fonctionnalité d’essai appelée Schéma dynamique. Le schéma dynamique fait référence à la possibilité que la même action renvoie une table différente avec des colonnes différentes. Les conditions susceptibles de faire différer les colonnes des tableaux sont notamment les paramètres d’entrée de l’action, 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. Pour travailler avec un schéma dynamique, la documentation du connecteur affiche Les sorties de cette opération sont dynamiques. comme valeur renvoyée. Pour plus d’informations sur l’utilisation du schéma dynamique dans Power Apps, voir travailler avec un schéma dynamique dans Power Apps (essai)

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.

   
Microsoft Dataverse Stockage dans le cloud **
Dynamics AX Excel
Microsoft Translator Office 365 Outlook
Office 365 Users Oracle
Power BI SharePoint
SQL Server Twitter

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

Notes

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.

Notes

Power Apps ne prend pas encore officiellement en charge les types d’authentification du principal de service. Pour en savoir plus, consultez Méthodes d’authentification avec Microsoft Entra ID.

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

Authentification du nom d’utilisateur et du mot de passe SQL

Ce type de connexion n’est pas sécurisé, car il ne repose pas sur l’authentification de l’utilisateur final. Il ne doit être utilisé que dans les cas où vous pouvez supposer en toute sécurité que toute personne ayant accès à cette connexion peut voir et utiliser toutes les données auxquelles la connexion donne accès. Vous ne pouvez pas verrouiller de manière fiable des parties des données accessibles au sein de la connexion. Par exemple, si la connexion permet l’accès à une seule table, vous ne pouvez pas compter sur un ID utilisateur pour filtrer uniquement pour afficher uniquement les données de cet utilisateur spécifique dans cette table. Pour une sécurité fiable, utilisez une connexion plus sécurisée telle que Microsoft Entra Intégré.

Dans SQL Server, ce type de connexion est appelé Authentification 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. Ils utilisent le nom d’utilisateur et le mot de passe que vous fournissez lorsque vous créez l’application. L’authentification de connexion à la source de données est Partagée implicitement avec vos utilisateurs. Une fois l’application publiée, la connexion est également publiée et disponible pour vos utilisateurs. Vos utilisateurs finaux peuvent également créer des applications à l’aide de n’importe quelle connexion utilisant l’authentification SQL Server partagée avec eux. Vos utilisateurs ne peuvent pas voir le nom d’utilisateur ou le mot de passe, mais la connexion reste disponible pour eux. Il existe des scénarios valides pour ce type de connexion. Par exemple, si vous disposez d’une base de données en lecture seule accessible à tous dans l’entreprise. Des scénarios de données de référence (par exemple, un calendrier d’entreprise) peuvent être utiles pour ce type de connexion. Plus d’informations : Utiliser Microsoft SQL Server en toute sécurité avec Power Apps

Connexions implicites sécurisées (version préliminaire)

[Cette section fait partie de la documentation en version préliminaire et peut faire l’objet de modifications.]

Power Apps a désormais une prise en charge complète de la version préliminaire pour les connexions implicites sécurisées. Le paramètre par défaut de cette fonction est défini sur Activé. Les connexions partagées implicites sécurisées sont plus sécurisées que les connexions implicites existantes. Power Apps Les connexions implicitement partagées sont celles qui utilisent des informations d’identification fixes telles qu’une chaîne de connexion SQL Server plutôt que les informations d’identification spécifiques de l’utilisateur final telles que Microsoft Entra ID. Grâce à cette fonctionnalité, les connexions ne sont plus partagées directement avec les utilisateurs de Power Apps. Au lieu de cela, un objet de connexion proxy qui accorde uniquement l’accès à la ressource sous-jacente telle qu’une table de serveur SQL spécifique est partagé. Les auteurs utilisateurs finaux ne peuvent pas créer des applications avec la connexion ou la connexion proxy. Cette fonctionnalité limite également l’utilisateur final à des actions telles que get, put/patch et delete définis dans l’application correspondante. Le résultat est que les utilisateurs finaux qui sont également auteurs ne peuvent pas créer des applications avec la connexion ou l’objet de connexion proxy.

Notes

Les connexions implicites sécurisées sont désormais activées par défaut pour les nouvelles applications.

Notification pour mettre à jour vos applications

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.

Notification pour mettre à jour vos applications.

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

Volet latéral.

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. Sur la barre de commandes, sélectionnez Paramètres > Fonctionnalités à venir.
  2. À partir de l’onglet Version préliminaire , définissez le basculement pour Connexions implicites sécurisées sur Activé.
  3. Enregistrez et publiez l’application.

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.

    Décocher le 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.

    Peut utiliser/révoquer.

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.

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) ?

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

Boîte de dialogue de consentement Power Apps

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.

Notes

Si un administrateur supprime la boîte de dialogue de consentement mais que la plateforme ne peut pas effectuer d’authentification unique pour un utilisateur final, la boîte de dialogue sera présentée à l’utilisateur lorsqu’il lancera l’application.

Type de connecteur Boîte de dialogue de consentement supprimable ? Référence
Connecteurs propriétaires Microsoft qui prennent en charge l’authentification unique (tels que SharePoint, Office 365 Users) Oui Applet de commande d’administration Power Apps
Connecteur accédant à un service tiers non Microsoft, tel que Salesforce No Non applicable
Connecteurs personnalisés utilisant OAuth avec Microsoft Entra ID en tant que fournisseur d’identité. Il s’agit de connecteurs personnalisés créés par des organisations et qui ne sont accessibles que par les utilisateurs au sein de l’organisation (par exemple, créés par Contoso pour les utilisateurs Contoso uniquement) Oui Gérer des connexions

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.

Notes

Pouvez-vous nous indiquer vos préférences de langue pour la documentation ? Répondez à un court questionnaire. (veuillez noter que ce questionnaire est en anglais)

Le questionnaire vous prendra environ sept minutes. Aucune donnée personnelle n’est collectée (déclaration de confidentialité).