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

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. Microsoft Dataverse   Stockage dans le cloud Stockage dans le cloud **
Dynamics AX. Dynamics AX   Microsoft Excel Excel
Microsoft Translator. Microsoft Translator   Office 365 Outlook Office 365 Outlook
Utilisateurs d’Office 365. Office 365 Users   Oracle Oracle
Power BI. Power BI   Logo de SharePoint SharePoint
SQL Server. SQL Server   Logo Twitter 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 Azure AD 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

Pour des informations détaillées sur les considérations de sécurité à l’utilisation d’un serveur de base de données relationnelle (comme Microsoft SQL Server, ou Oracle) comme source de données pour une application, voir Utiliser Microsoft SQL Server en toute sécurité avec Power Apps.

Azure AD intégré

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 Azure AD 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 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 Azure AD 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

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 pourra :
      • 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 Non Non applicable
Connecteurs personnalisés utilisant OAuth avec Azure Active Directory 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 Azure AD 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é).