Migrer des applications multi-clients vers le modèle de profils de principal de service

Cet article explique comment obtenir une meilleure scalabilité en migrant vos applications multi-clients d’analytique incorporée Power BI vers le modèle de profils de principal de service.

Les profils de principal de service facilitent la gestion du contenu organisationnel dans Power BI et utilisent vos capacités plus efficacement.

Notes

Cet article est destiné aux organisations disposant déjà d’une application qui prend en charge plusieurs clients à partir d’un locataire Power BI unique.

Toutes les applications ne tirent pas profit du modèle de principal de service. Par exemple, les applications suivantes ne doivent pas être migrées :

• Petites applications qui gèrent un principal de service avec un petit nombre d’objets
• Applications qui utilisent un principal de service multiple par client

Prérequis

Il est important de consulter les informations sur les profils de principal de service avant de commencer la migration.

Vous devez également procéder comme suit :

• Configurez le principal de service en suivant les trois premières étapes de Incorporer du contenu Power BI avec un principal de service et un secret d’application.
• À partir d’un compte d’administrateur de locataire Power BI, activez la création de profils dans le locataire.

Migrer vers des profils de principal de service

La migration vers des profils de principal de service implique les étapes suivantes :

1. Créer des profils (un par client)
2. Organiser vos espaces de travail
3. Modifier le code de l’application de façon à utiliser des profils
4. Tester votre application avec le modèle de profils
5. Nettoyer les autorisations redondantes

Créer des profils (obligatoire)

Utilisez l’API REST Profils avec le principal de service que vous avez créé afin de créer un profil pour chaque client.

Il est judicieux d’enregistrer un mappage de chaque ID client de données avec son ID de profil correspondant dans votre base de données. Vous aurez besoin de ce mappage ultérieurement pour effectuer des appels d’API avec le profil de locataire.

Organiser vos espaces de travail

Le moyen le plus simple de gérer vos données consiste à tenir à jour un espace de travail par client. Si votre application utilise déjà ce modèle, vous n’avez pas besoin de créer d’espaces de travail. Toutefois, vous devez quand même fournir à chaque profil un accès Admin à l’espace de travail correspondant à l’aide de l’API Ajouter un utilisateur de groupe.

Si vous n’avez pas un espace de travail par client, utilisez le profil correspondant pour appeler l’API Créer un utilisateur de groupe afin de créer un espace de travail pour chaque client.

Organiser les éléments dans les espaces de travail

Vous devez maintenant avoir un profil et un espace de travail pour chaque client. Si vous avez créé de nouveaux espaces de travail à l’étape précédente, vous devez importer des éléments (comme des rapports et des modèles sémantiques) dans ces espaces de travail. Les modèles sémantiques que vous importez dépendent de votre solution actuelle :

• Si votre application utilise un modèle sémantique distinct pour chaque client, la conception du modèle sémantique peut fonctionner comme c’est le cas.

• Si votre application utilise un modèle sémantique avec sécurité au niveau des lignes (RLS) pour fournir des données différentes à différents clients, vous pouvez obtenir une meilleure scalabilité en créant un modèle sémantique distinct pour chaque client et en utilisant des profils comme décrit dans cet article.

• Après avoir surmonté les limitations de scalabilité au moyen de profils et de sources de données distinctes, vous pouvez obtenir davantage de séparation des données en utilisant la RLS avec des profils.

  • Si vous vous appuyez sur la RLS dynamique, le nom du profil sera retourné dans la fonction DAX UserName().
  • Si vous utilisez la RLS statique et substituez les rôles lors de la génération du jeton incorporé, vous pouvez continuer à le faire.

Une fois les éléments prêts, importez-les dans les espaces de travail pertinents. Pour automatiser le processus, vous pouvez utiliser l’API Importation.

Modifier le code d’application de façon à utiliser des profils

Une fois que vous avez des profils ayant un accès Admin aux espaces de travail pertinents et une base de données avec un mappage qui indique quel profil représente quel client, vous pouvez apporter les modifications de code nécessaires. Nous vous recommandons de conserver deux flux de code côte à côte, et d’exposer progressivement le flux de code des profils à vos clients.

Apportez les modifications de code suivantes :

• Modification du code d’autorisation

  • Si vous utilisez un utilisateur maître dans l’application Microsoft Entra ID, modifiez le code d’acquisition de jeton. Lisez Incorporer avec un principal de service pour en savoir plus sur la création d’un jeton Microsoft Entra d’application uniquement.
  • Si vous utilisez un principal de service et que vous en avez créé un nouveau pour les profils, ajustez le code de façon à utiliser l’ID de principal de service et les secrets corrects.

• Modification du code de gestion

  Certaines applications ont du code de gestion qui automatise l’intégration d’un nouveau client lors de l’inscription. Souvent, le code de gestion utilise des API REST Power BI pour créer des espaces de travail et importer du contenu. La plupart de ce code doit rester inchangé, mais vous devrez peut-être adapter les détails suivants :

  • Chaque fois que vous créez un locataire client, créez un profil de service devant être le créateur et l’administrateur de l’espace de travail pour ce locataire.
  • Si vous décidez de réorganiser votre contenu Power BI, modifiez le code de façon à refléter les modifications.

• Modification du code d’incorporation de jeton

  Remplacez l’appelant d’API. Vérifiez qu’un profil appelle l’API GenerateToken, car dans le modèle de profils, seul le profil spécifique a accès au contenu du client.

Valider

Nous vous recommandons de tester soigneusement votre application avant de la déplacer vers le modèle de profils. Les rapports peuvent se charger même s’il existe des bogues dans le code de l’application SaaS car vous n’avez pas supprimé les anciennes autorisations sur les espaces de travail.

Nettoyer après la migration

Maintenant que vous avez terminé la migration et validé les résultats, supprimez ce dont vous n’avez plus besoin.

• Nettoyez le code : vous souhaiterez peut-être désactiver les anciens chemins de code pour être certain d’exécuter uniquement le nouveau code qui s’appuie sur des profils.
• Nettoyez les espaces de travail et les autorisations dans Power BI : si vous avez créé des espaces de travail, vous pouvez supprimer les anciens espaces de travail qui ne sont plus utilisés. Si vous avez réutilisé les mêmes espaces de travail, vous pouvez supprimer les anciennes autorisations (telles que les autorisations d’utilisateur maître) sur l’espace de travail.

Contenu connexe

Gérer les profils de principal de service

D’autres questions ? Essayez d’interroger la communauté Power BI