Développer des applications multilocataires évolutives avec l’incorporation de Power BI

Cet article explique comment développer une application multilocataire qui incorpore du contenu Power BI tout en atteignant les plus hauts niveaux de scalabilité, de performances et de sécurité. En concevant et en implémentant une application avec des profils de principal de service, vous pouvez créer et gérer une solution multilocataire comprenant des dizaines de milliers de locataires clients qui peuvent fournir des rapports à des audiences de plus de 100 000 utilisateurs.

Les profils de principal de service sont une fonctionnalité qui vous permet de gérer plus facilement le contenu organisationnel dans Power BI et d’utiliser plus efficacement vos capacités. Toutefois, l’utilisation de profils de principal de service peut compliquer la conception de votre application. C’est pourquoi vous ne devriez les utiliser que lorsqu’il est nécessaire d’atteindre une échelle significative. Nous vous recommandons d’utiliser des profils de principal de service lorsque vous avez un grand nombre d’espaces de travail et plus de 1 000 utilisateurs d’application.

Notes

La valeur de l’utilisation de profils de principal de service augmente à mesure que votre besoin de mise à l’échelle augmente, ainsi que votre besoin d’atteindre les plus hauts niveaux de sécurité et d’isolation des locataires.

Vous pouvez réaliser une incorporation de Power BI en utilisant deux scénarios d’incorporation différents : Incorporer pour votre organisation et Incorporer pour votre client.

Le scénario Incorporer pour votre organisation s’applique lorsque l’audience de l’application comprend des utilisateurs internes. Les utilisateurs internes ont des comptes de l’organisation et doivent s’authentifier avec Microsoft Entra ID (précédemment appelé Azure Active Directory). Dans ce scénario, Power BI est un SaaS (software as a service). Il est parfois appelé L’utilisateur est propriétaire des données.

Le scénario Incorporer pour votre client s’applique lorsque l’audience de l’application comprend des utilisateurs externes. L’application est responsable de l’authentification des utilisateurs. Pour accéder au contenu Power BI, l’application s’appuie sur une identité d’incorporation (principal de service ou compte d’utilisateur principal Microsoft Entra) pour s’authentifier auprès de Microsoft Entra. Dans ce scénario, Power BI est PaaS (platform-as-a-service). Il est parfois appelé L’application est propriétaire des données.

Notes

Il est important de comprendre que la fonctionnalité de profils de principal de service a été conçue pour être utilisée avec le scénario Incorporer pour votre client. En effet, ce scénario offre aux éditeurs de logiciels indépendants et aux organisations d’entreprise la possibilité d’incorporer une plus grande échelle à un grand nombre d’utilisateurs et à un grand nombre de locataires clients.

Développement d’applications multilocataires

Si vous êtes familiarisé avec Microsoft Entra, le mot tenant (locataire) peut vous amener à penser à un tenant Microsoft Entra. Toutefois, le concept de locataire est différent dans le contexte de création d’une solution multilocataire qui incorpore du contenu Power BI. Dans ce contexte, un locataire client est créé pour le compte de chaque client pour lequel l’application incorpore du contenu Power BI en utilisant le scénario Incorporer pour votre client. Vous provisionnez généralement chaque locataire client en créant un seul espace de travail Power BI.

Pour créer une solution multilocataire scalable, vous devez être en mesure d’automatiser la création de nouveaux locataires clients. Le provisionnement d'un nouveau client implique généralement l'écriture de code qui utilise l'API Power BI REST pour créer un nouvel espace de travail Power BI, créer des modèles sémantiques (anciennement appelés ensembles de données) en important des fichiers Power BI Desktop (.pbix), mettre à jour les paramètres de source de données, définir informations d'identification de la source de données et configurer l'actualisation planifiée du modèle sémantique. Le diagramme suivant montre comment ajouter des éléments Power BI, tels que des rapports et des modèles sémantiques, aux espaces de travail pour configurer des locataires clients.

Lorsque vous développez une application qui utilise le scénario Incorporer pour votre client, il est possible d’effectuer des appels de l’API REST Power BI à l’aide d’une identité d’incorporation qui est un compte d’utilisateur maître ou un principal de service. Nous vous recommandons d’utiliser un principal de service pour les applications de production. Il fournit la sécurité la plus élevée et c’est pour cette raison l’approche recommandée par Microsoft Entra. De même, il permet une meilleure automatisation et une meilleure mise à l’échelle et la surcharge de gestion est moindre. Cependant, il faut des droits d’administrateur Power BI pour la configuration et la gestion.

En utilisant un principal de service, vous pouvez éviter les problèmes courants associés aux comptes d’utilisateur maîtres, tels que les erreurs d’authentification dans les environnements où les utilisateurs doivent se connecter avec une authentification multifacteur (MFA). L’utilisation d’un principal de service est également cohérente avec l’idée que le scénario Incorporer pour votre client est basé sur l’incorporation de contenu Power BI en pensant PaaS et non SaaS.

Limitation de 1 000 espaces de travail

Lorsque vous concevez un environnement multilocataire qui implémente le scénario Incorporer pour votre client, n’oubliez pas que l’identité d’incorporation ne peut pas avoir accès à plus de 1 000 espaces de travail. Le service Power BI impose cette limitation pour garantir de bonnes performances lors des appels de l’API REST. La raison de cette limitation est liée à la façon dont Power BI gère les métadonnées liées à la sécurité pour chaque identité.

Power BI utilise des métadonnées pour suivre les espaces de travail et les éléments d’espace de travail auxquels une identité peut accéder. En effet, Power BI doit conserver une liste de contrôle d’accès (ACL) distincte pour chaque identité dans son sous-système d’autorisation. Lorsqu’une identité effectue un appel d’API REST pour accéder à un espace de travail, Power BI doit effectuer une vérification de sécurité dans la liste ACL de l’identité pour s’assurer qu’elle est autorisée. Le temps nécessaire pour déterminer si l’espace de travail cible se trouve dans la liste ACL augmente de façon exponentielle à mesure que le nombre d’espaces de travail augmente.

Notes

Power BI n’applique pas la limitation de 1 000 espaces de travail par le biais du code. Si vous essayez, ajoutez une identité d’incorporation à plus de 1 000 espaces de travail et vous verrez que les appels d’API REST s’exécutent toujours correctement. Toutefois, votre application passera à un état non pris en charge, ce qui peut avoir des implications si vous essayez de demander de l’aide auprès du support Microsoft.

Prenez un scénario où deux applications multilocataires ont chacune été configurées pour utiliser un seul principal de service. Considérez maintenant que la première application a créé 990 espaces de travail tandis que la seconde en a créé 1 010. Du point de vue du support, la première application se trouve dans les limites prises en charge, mais pas la seconde.

Comparez maintenant ces deux applications uniquement du point de vue des performances. Il n’y a pas beaucoup de différence, car les listes ACL des deux principaux de service ont laissé les métadonnées de leurs listes augmenter jusqu’à un point où elles dégradent les performances dans une certaine mesure.

Voici l’observation clé : le nombre d’espaces de travail créés par un principal de service a un impact direct sur les performances et la scalabilité. Un principal de service membre de 100 espaces de travail exécute les appels d’API REST plus rapidement qu’un principal de service qui est membre de 1 000 espaces de travail. De même, un principal de service membre de seulement 10 espaces de travail exécute les appels d’API REST plus rapidement qu’un principal de service qui est membre de 100 espaces de travail.

Important

Du point de vue des performances et de la scalabilité, le nombre optimal d’espaces de travail dont un principal de service est membre est exactement un.

Gérer l'isolation des modèles sémantiques et des informations d'identification des sources de données

Un autre aspect important lors de la conception d’une application multilocataire consiste à isoler les locataires clients. Il est impératif que les utilisateurs d’un locataire client ne voient pas les données qui appartiennent à un autre locataire client. Par conséquent, vous devez comprendre comment gérer la propriété du modèle sémantique et les informations d’identification de la source de données.

Propriété du modèle sémantique

Chaque modèle sémantique Power BI a un propriétaire unique, qui peut être un compte utilisateur ou un principal de service. La propriété du modèle sémantique est requise pour configurer l'actualisation planifiée et définir les paramètres du modèle sémantique.

Conseil

Dans le service Power BI, vous pouvez déterminer qui est le propriétaire du modèle sémantique en ouvrant les paramètres du modèle sémantique.

Si nécessaire, vous pouvez transférer la propriété du modèle sémantique vers un autre compte utilisateur ou principal de service. Vous pouvez le faire dans le service Power BI ou à l’aide de l’opération TakeOver de l’API REST. Lorsque vous importez un fichier Power BI Desktop pour créer un nouveau modèle sémantique à l’aide d’un principal de service, le principal de service est automatiquement défini comme propriétaire du modèle sémantique.

Informations d’identification de la source de données

Pour connecter un modèle sémantique à sa source de données sous-jacente, le propriétaire du modèle sémantique doit définir les informations d'identification de la source de données. Les informations d’identification de la source de données sont chiffrées et mises en cache par Power BI. À partir de là, Power BI utilise ces informations d’identification pour s’authentifier auprès de la source de données sous-jacente lors de l’actualisation des données (pour l’importation de tables de stockage) ou de l’exécution de requêtes directes (pour les tables de stockage DirectQuery).

Nous vous recommandons d’appliquer un modèle de conception courant lors du provisionnement d’un nouveau locataire. Vous pouvez exécuter une série d’appels d’API REST à l’aide de l’identité du principal de service :

1. Créez un espace de travail.
2. Associez le nouvel espace de travail à une capacité dédiée.
3. Importez un fichier Power BI Desktop pour créer un modèle sémantique.
4. Définissez les informations d'identification de la source du modèle sémantique pour ce modèle sémantique.

À la fin de ces appels d'API REST, le principal du service sera un administrateur du nouvel espace de travail et le propriétaire du modèle sémantique et des informations d'identification de la source de données.

Important

Il existe une idée fausse courante selon laquelle les informations d’identification de la source de données du modèle sémantique sont limitées au niveau de l’espace de travail. Ce n’est pas vrai. Les informations d’identification de la source de données sont étendues au principal du service (ou compte d’utilisateur), ce qui comprend tous les espaces de travail Power BI du tenant Microsoft Entra.

Il est possible pour un principal de service de créer des informations d’identification de source de données partagées par des modèles sémantiques dans différents espaces de travail entre locataires clients, comme illustré dans le diagramme suivant.

Lorsque les informations d’identification de la source de données sont partagées par des modèles sémantiques appartenant à différents locataires clients, ces derniers ne sont pas entièrement isolés.

Stratégies de conception avant les profils de principal de service

Comprendre les stratégies de conception avant que la fonctionnalité de profils de principal de service ne soit disponible peut vous aider à comprendre la nécessité de cette fonctionnalité. Avant, les développeurs créaient des applications multilocataires en utilisant l’une des trois stratégies de conception suivantes :

• Un principal de service unique
• Mise en pool des principaux de service
• Un principal de service par espace de travail

Chacune de ces stratégies de conception présente des points forts et des points faibles.

La stratégie de conception Principal de service unique nécessite la création unique d’une inscription d’application Microsoft Entra. Par conséquent, elle implique des frais généraux administratifs inférieurs aux deux autres stratégies de conception parce qu’il n’est pas nécessaire de créer d’autres inscriptions d’applications Microsoft Entra. Cette stratégie est également la plus simple à configurer, car elle ne demande pas d’écrire de code supplémentaire pour changer le contexte d’appel entre les principaux de service lors des appels d’API REST. Toutefois, le problème avec cette stratégie de conception est qu’elle n’est pas scalable. Elle prend uniquement en charge un environnement multilocataire qui peut aller jusqu’à 1 000 espaces de travail. Les performances se dégraderont à mesure que le principal de service se verra accorder l’accès à un plus grand nombre d’espaces de travail. Il existe également un problème avec l'isolation des locataires clients, car le principal de service unique devient propriétaire de chaque modèle sémantique et de toutes les informations d'identification des données sur tous les locataires clients.

La stratégie de conception Mise en pool des principaux de service est couramment utilisée pour éviter la limitation de 1 000 espaces de travail. Elle autorise l’application à se mettre à l’échelle avec n’importe quel nombre d’espaces de travail en ajoutant le nombre approprié de principaux de service au pool. Par exemple, un pool de cinq principaux de service permet d’effectuer un scale-up jusqu’à 5 000 espaces de travail, tandis qu’un pool de 80 principaux de service permet d’effectuer un scale-up jusqu’à 80 000 espaces de travail, et ainsi de suite. Toutefois, bien que cette stratégie puisse être mise à l’échelle avec un grand nombre d’espaces de travail, elle présente plusieurs inconvénients. Premièrement, elle demande d’écrire du code supplémentaire et de stocker des métadonnées pour permettre de changer de contexte entre les principaux de service lors des appels d’API REST. Deuxièmement, elle implique un effort administratif plus actif parce que vous devez créer des inscriptions d’applications Microsoft Entra chaque fois que vous devez augmenter le nombre de principaux de service dans le pool.

Par ailleurs, la stratégie de mise en pool de principaux de service n’est pas optimisée pour les performances, car elle permet aux principaux de service de devenir membres de centaines d’espaces de travail. Ce n’est pas non plus idéal du point de vue de l’isolement des locataires clients, car les principaux de service peuvent devenir propriétaires du modèle sémantique et des informations d’identification des données partagées entre les locataires clients.

La stratégie de conception Un principal de service par espace de travail implique la création d’un principal de service pour chaque locataire client. D'un point de vue théorique, cette stratégie offre la meilleure solution car elle optimise les performances des appels d'API REST tout en offrant une véritable isolation des modèles sémantiques et des informations d'identification des sources de données au niveau de l'espace de travail. Toutefois, ce qui fonctionne le mieux en théorie ne fonctionne pas toujours le mieux dans la pratique. C’est parce que la nécessité de créer un principal de service pour chaque locataire client n’est pas pratique pour de nombreuses organisations. En effet, certaines organisations ont des processus d’approbation stricts ou ils comportent des lourdeurs administratives pour créer des inscriptions d’applications Microsoft Entra. Pour toutes ces raisons, il peut devenir impossible d’accorder à une application personnalisée l’autorité nécessaire pour créer des inscriptions d’applications Microsoft Entra à la demande et de manière automatisée comme l’exige votre solution.

Dans des scénarios moins courants où une application personnalisée a obtenu les autorisations appropriées, celle-ci peut utiliser l’API Microsoft Graph pour créer des inscriptions d’applications Microsoft Entre à la demande. Toutefois, le développement et le déploiement de l’application personnalisée est souvent complexe parce que celle-ci doit d’une façon ou d’une autre suivre les informations d’identification d’authentification de chaque inscription d’application Microsoft Entra. Elle doit également accéder à ces informations d’identification chaque fois qu’elle doit s’authentifier et acquérir des jetons d’accès pour des principaux de service individuels.

Profils des principaux de services

La fonctionnalité de profils de principal de service est conçue pour vous permettre de gérer plus facilement le contenu organisationnel dans Power BI et d’utiliser plus efficacement vos capacités. Ils permettent de relever trois défis spécifiques qui impliquent le moins d’effort et de charge possible pour les développeurs. Ces défis sont les suivants :

• Mise à l’échelle avec un grand nombre d’espaces de travail.
• Optimisation des performances des appels d’API REST.
• Isoler les modèles sémantiques et les informations d'identification des sources de données au niveau du client.

Lorsque vous concevez une application multilocataire à l’aide de profils de principal de service, vous pouvez tirer parti des points forts des trois stratégies de conception (décrites dans la section précédente) tout en évitant leurs points faibles associés.

Les profils de principal de service sont des comptes locaux créés dans le contexte de Power BI. Un principal de service peut utiliser l’opération Profiles de l’API REST pour créer des profils de principal de service. Un principal de service peut créer et gérer son propre ensemble de profils de principal de service pour une application personnalisée, comme illustré dans le schéma suivant.

Il existe toujours une relation parent-enfant entre un principal de service et les profils de principal de service qu’il crée. Vous ne pouvez pas créer un profil de principal de service en tant qu’entité autonome. Au lieu de cela, vous créez un profil de principal de service à l’aide d’un principal de service spécifique, et celui-ci sert de parent du profil. De plus, un profil de principal de service n’est jamais visible par les comptes d’utilisateur ni par les autres principaux de service. Un profil de principal de service ne peut être vu et utilisé que par le principal de service qui l’a créé.

Les profils de principal de service ne sont pas connus de Microsoft Entra

Bien que le principal de service lui-même et son inscription d’application Microsoft Entra sous-jacente soient connus de Microsoft Entra, l’application Microsoft Entra ID ne connaît rien des profils du principal de service. C’est parce que les profils de principal de service sont créés par Power BI et qu’ils existent uniquement dans le sous-système du service Power BI qui contrôle la sécurité et les autorisations Power BI.

Le fait que les profils de principal de service ne soient pas connus de Microsoft Entra ID comporte à la fois des avantages et des inconvénients. Le principal avantage est qu’une application du scénario Incorporer pour votre client n’a pas besoin d’autorisations Microsoft Entra spéciales pour créer des profils de principal de service. Cela signifie également que l’application peut créer et gérer un ensemble d’identités locales distinctes à partir de Microsoft Entra.

Il y a néanmoins des inconvénients. Étant donné que les profils de principal de service ne sont pas connus de Microsoft Entra, vous ne pouvez pas ajouter de profil de principal de service à un groupe Microsoft Entra pour lui accorder implicitement l’accès à un espace de travail. De plus, les sources de données externes, comme Azure SQL Database ou Azure Synapse Analytics, ne peuvent pas reconnaître les profils de principal de service comme identité lors de la connexion à une base de données. Par conséquent, la stratégie de conception Un principal de service par espace de travail (création d’un principal de service pour chaque locataire client) est probablement un meilleur choix lorsqu’il est nécessaire de se connecter à ces sources de données à l’aide d’un principal de service distinct avec des informations d’identification d’authentification uniques pour chaque locataire client.

Les profils de principal de service sont des principaux de sécurité de première classe

Bien que les profils de principal de service ne soient pas connus de Microsoft Entra, Power BI les reconnaît comme étant des principaux de sécurité de premier ordre. Tout comme un compte d’utilisateur ou un principal de service, vous pouvez ajouter des profils de principal de service à un rôle d’espace de travail (Administrateur ou Membre). Vous pouvez également en faire le propriétaire du modèle sémantique et le propriétaire des informations d'identification de la source de données. Pour ces raisons, la création d’un profil de principal de service pour chaque nouveau locataire client est une bonne pratique.

Conseil

Lorsque vous développez une application du scénario Incorporer pour votre client en utilisant des profils de principal de service, vous ne devez créer qu’une seule inscription d’application Microsoft Entra pour fournir un seul principal de service à votre application. Cette approche diminue considérablement les frais généraux administratifs par rapport à d’autres stratégies de conception multilocataire, où il est nécessaire de créer des inscriptions d’applications Microsoft Entra supplémentaires de manière permanente après le déploiement de l’application en production.

Exécuter des appels d’API REST en tant que profil de principal de service

Votre application peut exécuter des appels d’API REST en utilisant l’identité d’un profil de principal de service. Cela signifie qu’elle peut exécuter une séquence d’appels d’API REST pour provisionner et configurer un nouveau locataire client.

1. Lorsqu’un profil de principal de service crée un espace de travail, Power BI ajoute automatiquement ce profil comme administrateur d’espace de travail.
2. Lorsqu’un profil de principal de service importe un fichier Power BI Desktop pour créer un modèle sémantique, Power BI définit ce profil comme propriétaire du modèle sémantique.
3. Lorsqu’un profil de principal de service définit les informations d’identification de la source de données, Power BI définit ce profil comme propriétaire des informations d’identification de la source de données.

Il est important de comprendre qu’un principal de service a dans Power BI une identité séparée et distincte des identités de ses profils. Cela vous donne le choix en tant que développeur. Vous pouvez exécuter des appels d’API REST en utilisant l’identité d’un profil de principal de service. Vous pouvez sinon exécuter des appels d’API REST sans profil, qui utilisent l’identité du principal de service parent.

Nous vous recommandons d’exécuter des appels d’API REST en tant que principal de service parent lorsque vous créez, affichez ou supprimez des profils de principal de service. Il est préférable d’utiliser le profil de principal de service pour exécuter tous les autres appels d’API REST. Ces autres appels peuvent créer des espaces de travail, importer des fichiers Power BI Desktop, mettre à jour les paramètres du modèle sémantique et définir les informations d'identification de la source de données. Ils peuvent également récupérer des métadonnées d’élément d’espace de travail et générer des jetons intégrés.

Prenons un exemple où vous devez configurer un locataire client pour un client qui s’appelle Contoso. La première étape consiste à effectuer un appel d’API REST pour créer un profil de principal de service avec son nom d’affichage défini sur Contoso. Cet appel est effectué en utilisant l’identité du principal de service. Toutes les étapes de configuration restantes utilisent le profil de principal de service pour effectuer les tâches suivantes :

1. Créez un espace de travail.
2. Associer l’espace de travail à une capacité.
3. Importer un fichier Power BI Desktop.
4. Définissez les paramètres du modèle sémantique.
5. Définir les informations d’identification de la source de données.
6. Configurer l’actualisation planifiée des données.

Il est important de comprendre que l’accès à l’espace de travail et à son contenu doit être effectué en utilisant l’identité du profil de principal de service qui a été utilisé pour créer le locataire client. Il est également important de comprendre que le principal de service parent n’a pas besoin d’accéder à l’espace de travail ou à son contenu.

Conseil

À garder en tête : lorsque vous effectuez des appels d’API REST, utilisez le principal de service pour créer et gérer des profils de principal de service, et utilisez le profil de principal de service pour créer, configurer et accéder au contenu Power BI.

Utiliser les opérations de l’API REST Profils

Le groupe d’opérations de l’API REST Profils comprend des opérations qui créent et gèrent des profils de principal de service :

• Create Profile
• Delete Profile
• Get Profile
• Get Profiles
• Update Profile

Créer un profil de principal de service

Utilisez l’opération de l’API REST Créer un profil pour créer un profil de principal de service. Vous devez définir la propriété displayName dans le corps de la requête pour fournir un nom d’affichage pour le nouveau locataire. La valeur doit être unique entre tous les profils appartenant au principal de service. L’appel échoue si un autre profil portant ce nom d’affichage existe déjà pour le principal de service.

Un appel réussi retourne la propriété id, qui est un GUID qui représente le profil. Lorsque vous développez des applications qui utilisent des profils de principal de service, nous vous recommandons de stocker les noms d’affichage des profils et leurs valeurs d’ID dans une base de données personnalisée. De cette façon, il est simple pour votre application de récupérer les ID.

Si vous programmez avec le SDK .NET Power BI, vous pouvez utiliser la méthode Profiles.CreateProfile, qui retourne un objet ServicePrincipalProfile représentant le nouveau profil. Cela permet de déterminer facilement la valeur de la propriété id.

Voici un exemple de création d’un profil de principal de service et de l’octroi de l’accès à l’espace de travail.

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

// Retrieve the ID of the new profile
Guid profileId = profile.Id;

// Grant workspace access
var groupUser = new GroupUser {
    GroupUserAccessRight = "Admin",
    PrincipalType = "App",
    Identifier = ServicePrincipalId,
    Profile = new ServicePrincipalProfile {
        Id = profileId
    }
};

pbiClient.Groups.AddGroupUser(workspaceId, groupUser);

Dans le service Power BI, dans le volet Accès de l’espace de travail, vous pouvez déterminer quelles identités, y compris les principaux de sécurité, y ont accès.

Supprimer un profil de principal de service

Utilisez l’opération de l’API REST Supprimer un profil pour supprimer un profil de principal de service. Cette opération ne peut être appelée que par le principal de service parent.

Si vous programmez avec le SDK. NET Power BI, vous pouvez utiliser la méthode Profiles.DeleteProfile.

Récupérer tous les profils de principal de service

Utilisez l’opération Obtenir les profils de l’API REST pour récupérer une liste de profils de principal de service qui appartiennent au principal de service appelant. Cette opération retourne une charge utile JSON qui contient les propriétés id et displayName de chaque profil de principal de service.

Si vous programmez avec le SDK .NET Power BI, vous pouvez utiliser la méthode Profiles.GetProfiles.

Exécuter des appels d’API REST en utilisant un profil de principal de service

Il existe deux conditions requises pour effectuer des appels d’API REST en utilisant un profil de principal de service :

• Vous devez passer le jeton d’accès du principal de service parent dans l’en-tête Authorization.
• Vous devez inclure un en-tête appelé X-PowerBI-profile-id avec la valeur de l’ID du profil de principal de service.

Si vous utilisez le SDK .NET Power BI, vous pouvez définir explicitement la valeur de l’en-tête X-PowerBI-profile-id en passant l’ID du profil de principal de service.

// Create the Power BI client
var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBIClient(uriPowerBiServiceApiRoot, tokenCredentials);

// Add X-PowerBI-profile-id header for service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
pbiClient.HttpClient.DefaultRequestHeaders.Add("X-PowerBI-profile-id", profileId);

// Retrieve workspaces by using the identity of service principal profile
var workspaces = pbiClient.Groups.GetGroups();

Comme indiqué dans l’exemple ci-dessus, une fois que vous avez ajouté l’en-tête X-PowerBI-profile-id à l’objet PowerBIClient, il est simple d’appeler des méthodes, telles que Groups.GetGroups, afin qu’elles soient exécutées en utilisant le profil de principal de service.

Il existe un moyen plus pratique de définir l’en-tête X-PowerBI-profile-id pour un objet PowerBIClient. Vous pouvez initialiser l’objet en passant l’ID du profil au constructeur.

// Create the Power BI client
string profileId = "11111111-1111-1111-1111-111111111111";

var tokenCredentials = new TokenCredentials(GetACcessToken(). "Bearer");
var uriPowerBiServiceApiRoot = new Uri(uriPowerBiServiceApiRoot);
var pbiClient = new PowerBiClient(uriPowerBiServiceApiRoot, tokenCredentials, profileId);

Lorsque vous programmez une application multilocataire, vous devrez probablement basculer entre l’exécution d’appels en tant que principal de service parent et l’exécution d’appels en tant que profil de principal de service. Une approche utile pour gérer le changement de contexte consiste à déclarer une variable de niveau classe qui stocke l’objet PowerBIClient. Vous pouvez ensuite créer une méthode d’assistance qui définit la variable avec l’objet approprié.

// Class-level variable that stores the PowerBIClient object
private PowerBIClient pbiClient;

// Helper method that sets the correct PowerBIClient object
private void SetCallingContext(string profileId = "") {

    if (profileId.Equals("")) {
        pbiClient = GetPowerBIClient();    
    }
    else {
        pbiClient = GetPowerBIClientForProfile(new Guid(profileId));
    }
}

Lorsque vous avez besoin de créer ou de gérer un profil de principal de service, vous pouvez appeler la méthode SetCallingContext sans aucun paramètre. De cette façon, vous pouvez créer et gérer des profils en utilisant l’identité du principal de service.

// Always create and manage profiles as the service principal
SetCallingContext();

// Create a service principal profile
string profileName = "Contoso";

var createRequest = new CreateOrUpdateProfileRequest(profileName);
var profile = pbiClient.Profiles.CreateProfile(createRequest);

Lorsque vous avez besoin de créer et de configurer un espace de travail pour un nouveau locataire client, vous voulez exécuter ce code en tant que profil de principal de service. Par conséquent, vous devrez appeler la méthode SetCallingContext en passant l’ID du profil. De cette façon, vous pouvez créer l’espace de travail en utilisant l’identité du profil de principal de service.

// Always create and set up workspaces as a service principal profile
string profileId = "11111111-1111-1111-1111-111111111111";
SetCallingContext(profileId);

// Create a workspace
GroupCreationRequest request = new GroupCreationRequest(workspaceName);
Group workspace = pbiClient.Groups.CreateGroup(request);

Après avoir utilisé un profil de principal de service spécifique pour créer et configurer un espace de travail, vous devrez continuer à utiliser ce même profil pour créer et configurer le contenu de l’espace de travail. Il n’est pas nécessaire d’appeler la méthode SetCallingContext pour procéder à la configuration.

Exemple pour les développeurs

Nous vous encourageons à télécharger un exemple d’application qui s’appelle AppOwnsDataMultiTenant.

Cet exemple d’application a été développé avec .NET 6 et ASP.NET. Il montre comment appliquer les recommandations et les conseils décrits dans cet article. Vous pouvez passer en revue le code pour apprendre à développer une application multilocataire qui implémente le scénario Incorporer pour votre client en utilisant des profils de principal de service.

Contenu connexe

Pour plus d’informations sur cet article, consultez les ressources suivantes :

• Profils des principaux services pour les applications multi-locataire dans Power BI Embedded
• Migrer des applications multi-clients vers le modèle de profils de principal de service
• Groupe d’opérations de l’API REST Power BI Profils
• • Exemple d’application AppOwnsDataMultiTenant
• Des questions ? Essayez d’interroger la communauté Power BI
• Vous avez des suggestions ? Envoyez-nous vos idées pour améliorer Power BI