Partager via

Utiliser SQL Server avec les applications canevas

SQL Server est une solution largement utilisée pour stocker des données d’entreprise. Cet article propose les meilleures pratiques pour vous aider à créer et à publier une application canevas de niveau professionnel avec SQL Server.

Astuce

Cet article fournit un exemple de scénario et une représentation visuelle de l’utilisation de SQL Server avec une application canevas. Cette solution est un exemple d’architecture généralisé, qui peut être utilisé pour de nombreux scénarios et secteurs différents. SQL Server et Power Apps prennent en charge de nombreuses approches d’authentification héritées. Cet article se limite aux meilleures pratiques.

Diagramme d’architecture

Diagramme d’architecture qui montre le workflow d’utilisation de SQL Server avec les applications canevas.

Flux de travail

Alors que de nombreuses implémentations précédentes de Power Apps avec SQL Server utilisaient une passerelle, cet exemple d’architecture met en évidence l’architecture de réseau privé virtuel (VNET) avec SQL Server. Une instance de SQL Server peut être Azure SQL ou une base de données SQL locale exposée au cloud via Azure Arc. Dans les deux cas, la communication est privée et sécurisée.

  • Contoso VNET est un réseau privé virtuel que vous créez dans votre client.
  • Azure Ressources/Contoso Ressources sont des ressources que vous rendez disponibles dans le réseau virtuel à partir de votre client. Ces ressources incluent des services tels qu’une base de données Azure SQL ou une base de données SQL Server locale mise à disposition via Azure Arc.
  • Un sous-réseau délégué se trouve au sein de votre réseau virtuel et fournit un conteneur pour Power Platform pour laisser des services tels que le connecteur SQL ou un plug-in Dataverse de fonctionner avec vos ressources.

Composants

Cette section décrit les composants qui prennent en charge l’intégration de SQL Server avec les applications canevas dans cette architecture.

Application canevas et tables SQL

Les tables et les vues SQL Server s’affichent dans Power Apps sous forme de sources de données tabulaires. Vous pouvez lier une source de données tabulaire à la propriété de table ou la propriété Items de galerie à l’aide d’une expression Power Fx. Pour les sources de données tabulaires, les expressions Power Fx sont traduites en expressions OData, qui sont ensuite converties en expressions SQL. Cependant, Power Fx et OData ne représentent pas entièrement toutes les fonctionnalités d’une expression SQL.

Astuce

Utilisez Power Fx pour les requêtes simples et basiques et utilisez des procédures stockées pour les expressions SQL plus complexes.

Application canevas et procédures stockées SQL

Les procédures stockées SQL Server apparaissent dans Power Apps en tant que sources de données d’action. En règle générale, les sources de données d’action ne peuvent pas être liées à une table ou à une galerie en raison de leurs effets secondaires potentiels. Cependant, vous pouvez marquer une select stored procedure comme Safe for Tables and Galleries et l’utiliser avec une table ou une galerie. Cette approche récupère toutes les données renvoyées par la procédure stockée, mais soyez prudent, car la récupération d’un trop grand nombre de données peut surcharger la mémoire du client. Pour contrôler la quantité de données récupérées, utilisez les arguments de pagination des paramètres généralement présents dans ces types de procédures stockées.

Assignez les résultats à une variable Power Fx et utilisez cette variable dans la propriété Items pour remplir la table ou la galerie. N’oubliez pas d’actualiser la variable Power Fx lors des opérations de création, de mise à jour et de suppression (CUD). Des procédures stockées plus complexes, telles que celles utilisant des tables temporaires, peuvent renvoyer un dynamic schema. Vous pouvez utiliser les résultats de ces procédures stockées en définissant les résultats attendus sur un Power Fx User defined type.

- Connecteur SQL Server

Les applications Power Apps utilisent le connecteur SQL Server pour accéder aux données dans SQL Server. Bien qu’il existe de nombreux types d’authentification SQL disponibles, Microsoft Entra ID et le SPN partageable (nom principal du service) sont deux des meilleurs choix.

Si vous souhaitez utiliser Microsoft Entra ID, configurez d’abord la base de données SQL Server pour assurer la sécurité via Microsoft Entra ID. Le SPN partageable est une méthode d’accès activée par l’administrateur et doit être accordée avec soin, car tous les utilisateurs ont les mêmes droits d’accès à la base de données. Il est sécurisé par des connexions implicites sécurisées qui restreignent l’accès aux tables et aux actions utilisées dans l’application (c’est-à-dire Get, Post, Put et Delete).

VNET (réseau privé virtuel)

Il existe plusieurs façons d’acheminer les appels vers SQL Server. Le réseau virtuel est une solution cloud Azure qui rend tous les points de terminaison privés. Pour l’implémenter, approvisionnez un réseau virtuel au sein de votre client, configurez la stratégie d’entreprise et configurez votre environnement Power Platform pour la prendre en charge. Cette configuration garantit qu’aucun trafic SQL n’est exposé publiquement sur le réseau.

ALM (Application Lifecycle Management)

Power Platform prend en charge la transition en douceur d’une application Power Apps sur SQL entre les environnements de développement, de test et de production. Les références de connexion prennent en charge la modification des chaînes de connexion entre les environnements, ce qui est important pour l’authentification SQL de base. Les variables d’environnement prennent en charge le scénario de Microsoft Entra ID en modifiant le serveur et la base de données entre les environnements.

Cas d’utilisation

Power Apps offre aux organisations un moyen flexible et intuitif de créer des expériences utilisateur personnalisées.

  • Si vous créez une application et un stockage, envisagez d’utiliser Dataverse. Ses fonctionnalités sont conçues pour faciliter la création d’applications d’entreprise.
  • Si vous avez des données dans SQL Server qui ne peuvent pas être déplacées, ou si votre organisation a besoin de SQL Server, envisagez d’utiliser Power Apps plutôt que SQL Server.
  • Si les données ne peuvent pas être déplacées, utilisez Power Apps plutôt que SQL Server. Les applications existantes dépendent toujours de ces données, vous devez donc déplacer ces applications vers le cloud pour les moderniser.

Considérations

Ces considérations mettent en œuvre les piliers de Power Platform Well-Architected, un ensemble de principes directeurs qui améliorent la qualité d’une charge de travail. Pour en savoir plus, consultez Microsoft Power Platform Well-Architected.

Fiabilité

Concevez votre charge de travail de manière à éviter toute complexité inutile : Power Apps fonctionne bien avec des requêtes simples que vous pouvez déléguer au serveur. Déléguez des tâches complexes à des vues et à des procédures stockées. Ensuite, utilisez ces procédures stockées directement pour les actions synchrones. Utilisez Power Automate pour les actions asynchrones, y compris les appels à des procédures stockées de longue durée.

Sécurité

Utilisez des connexions implicites sécurisées : utilisez des connexions implicites sécurisées pour toutes les connexions partagées. Convertissez toutes les applications plus anciennes pour utiliser des connexions implicites sécurisées selon les besoins. Avec les connexions implicites sécurisées, le connecteur reste à l’intérieur du service de cloud Power Apps et ne réside pas sur le client. L’application se connecte uniquement au connecteur proxy, qui se trouve également dans le service du cloud Power Apps. L’application et le connecteur proxy se connaissent. Cependant, l’application ne connaît pas le connecteur. Le connecteur proxy a une stratégie qui restreint les types de requête aux requêtes dans l’application.

Diagramme d’architecture illustrant comment les composants de connexion implicitement partagés sont liés les uns aux autres.

Créez une segmentation et des périmètres intentionnels : utilisez des environnements distincts Power Platform pour les phases du cycle de vie des applications et assurez-vous que seuls les utilisateurs appropriés ont accès à chaque phase pour prendre en charge les stratégies de segmentation.

Excellence opérationnelle

Adoptez des pratiques de déploiement sécurisées : standardisez le déploiement de toutes les modifications de l’application à l’aide de l’application Power Apps avec des processus de déploiement automatisés tels que des pipelines. Ne promouvez l’application en production qu’après avoir testé ces modifications.

Efficacité des performances

Concevez pour répondre aux exigences de performance : évaluez les performances de votre solution et les exigences en matière de volume de données pour vous assurer que la conception de votre table, vue et procédure stockée SQL Server est appropriée. Dans votre évaluation, incluez la manière dont les données sont consultées et la manière dont Power Apps délègue les opérations à SQL Server. Pensez aux limitations lors de la recherche et du filtrage des données en raison de la prise en charge de la délégation offerte par SQL Server. Passez en revue les limites documentées pour les applications de canevas dans Comprendre la délégation et doivent être prises en compte lors du choix de la bonne source de données ou du backend approprié pour votre application.

Optimiser la logique : les applications canevas utilisent Power Fx pour exécuter le travail. Chaque opération Power Fx est indépendante et n’est pas traitée comme une transaction atomique. Par exemple, si une application crée une ligne de détails de la commande client mais ne crée pas d’enregistrement d’en-tête de commande client, la ligne des détails de la commande client est conservée. Ne laissez pas ces étapes procédurales obligatoires dans Power Fx. Utilisez les procédures stockées SQL Server avec prise en charge des transactions.

Optimisation de l’expérience

Concevoir pour l’efficacité : les applications qui permettent aux utilisateurs d’accéder à d’autres sources de données en plus des tables SQL Server à partir d’une seule application Power Apps, sans nécessiter d’interaction avec plusieurs applications individuelles, améliorent l’efficacité et offrent une meilleure expérience visuelle personnalisée. Évitez de créer une application pour créer une application : l’application doit offrir une certaine efficacité à l’utilisateur ou un autre avantage de l’architecture par rapport à l’utilisation d’une expérience pilotée par modèle Power Apps.

Power Apps :

Connecteurs :

Application Lifecycle Management (ALM) :

  • Last updated on