Udvikl skalerbare multitenancy-programmer med Power BI-integrering

I denne artikel beskrives det, hvordan du udvikler et multitenancy-program, der integrerer Power BI-indhold, samtidig med at du opnår de højeste niveauer af skalerbarhed, ydeevne og sikkerhed. Ved at designe og implementere et program med tjenesteprincipalprofiler kan du oprette og administrere en flerdimensionel løsning, der består af titusinder af kundelejere, der kan levere rapporter til målgrupper på over 100.000 brugere.

Tjenesteprincipalprofiler er en funktion, der gør det nemmere for dig at administrere organisationsindhold i Power BI og bruge dine kapaciteter mere effektivt. Brug af tjenesteprincipalprofiler kan dog føje kompleksitet til dit programdesign. Derfor bør du kun bruge dem, når der er behov for at opnå stor skala. Vi anbefaler, at du bruger profiler for tjenesteprincipaler, når du har mange arbejdsområder og mere end 1.000 programbrugere.

Bemærk

Værdien af at bruge tjenesteprincipalprofiler øges, efterhånden som dit behov for skalering øges, samt dit behov for at opnå det højeste niveau af sikkerhed og lejerisolation.

Du kan opnå Power BI-integration ved hjælp af to forskellige integreringsscenarier: Integrer for din organisation og Integrer for din kunde.

Scenariet Integrer for din organisation gælder, når programmålgruppen består af interne brugere. Interne brugere har organisationskonti og skal godkende med Microsoft Entra ID (tidligere kendt som Azure Active Directory). I dette scenarie er Power BI SaaS (software-as-a-service). Det kaldes også brugeren ejer data.

Scenariet Integrer for din kunde gælder, når programmålgruppen består af eksterne brugere. Programmet er ansvarligt for godkendelse af brugere. For at få adgang til Power BI-indhold er programmet afhængig af en integreringsidentitet (Microsoft Entra-tjenesteprincipal eller masterbrugerkonto) for at godkende med Microsoft Entra. I dette scenarie er Power BI PaaS (platform-as-a-service). Det kaldes nogle gange appen ejer data.

Bemærk

Det er vigtigt at forstå, at funktionen med tjenesteprincipalprofiler er designet til brug sammen med scenariet Integrer for din kunde . Det skyldes, at dette scenarie giver ISV'er og virksomhedsorganisationer mulighed for at integrere med større skala til et stort antal brugere og til et stort antal kundelejere.

Udvikling af multitenancy-program

Hvis du er fortrolig med Microsoft Entra, kan ordet lejer få dig til at tænke på en Microsoft Entra-lejer. Begrebet lejer er dog anderledes i forbindelse med oprettelse af en løsning med flere egenskaber, der integrerer Power BI-indhold. I denne kontekst oprettes en kundelejer på vegne af hver kunde, hvor programmet integrerer Power BI-indhold ved hjælp af scenariet Integrer for din kunde . Du klargør typisk hver kundelejer ved at oprette et enkelt Power BI-arbejdsområde.

Hvis du vil oprette en skalerbar multitenancy-løsning, skal du kunne automatisere oprettelsen af nye kundelejere. Klargøring af en ny kundelejer omfatter typisk skrivning af kode, der bruger Power BI REST-API'en til at oprette et nyt Power BI-arbejdsområde, oprette semantiske modeller (tidligere kaldet datasæt) ved at importere Power BI Desktop-filer (.pbix), opdatere datakildeparametre, angive legitimationsoplysninger for datakilden og konfigurere planlagt opdatering af semantisk model. I følgende diagram kan du se, hvordan du kan føje Power BI-elementer, f.eks. rapporter og semantiske modeller, til arbejdsområder for at konfigurere kundelejere.

Når du udvikler et program, der bruger scenariet Integrer for din kunde , er det muligt at foretage Power BI REST API-kald ved hjælp af en integreringsidentitet, der enten er en masterbrugerkonto eller en tjenesteprincipal. Vi anbefaler, at du bruger en tjenesteprincipal til produktionsprogrammer. Det giver den højeste sikkerhed, og derfor er det den fremgangsmåde, der anbefales af Microsoft Entra. Det understøtter også bedre automatisering og skalering, og der er mindre administrationsomkostninger. Det kræver dog Power BI-administratorrettigheder for at konfigurere og administrere.

Når du bruger en tjenesteprincipal, kan du undgå almindelige problemer, der er knyttet til masterbrugerkonti, f.eks. godkendelsesfejl i miljøer, hvor brugerne skal logge på ved hjælp af multifaktorgodkendelse (MFA). Brug af en tjenesteprincipal er også i overensstemmelse med idéen om, at scenariet Integrer for din kunde er baseret på integrering af Power BI-indhold ved hjælp af et PaaS-mindset i modsætning til et SaaS-mindset.

Begrænsning på 1.000 arbejdsområder

Når du designer et multitenancy-miljø, der implementerer scenariet Integrer for din kunde , skal du huske at overveje, at integrerings-id'et ikke kan tildeles adgang til mere end 1.000 arbejdsområder. Power BI-tjeneste pålægger denne begrænsning for at sikre god ydeevne, når du foretager REST API-kald. Årsagen til denne begrænsning er relateret til, hvordan Power BI vedligeholder sikkerhedsrelaterede metadata for hver identitet.

Power BI bruger metadata til at spore de arbejdsområder og arbejdsområdeelementer, som en identitet kan få adgang til. Power BI skal faktisk vedligeholde en separat adgangskontrolliste (ACL) for hver identitet i dets godkendelsesundersystem. Når en identitet foretager et REST API-kald for at få adgang til et arbejdsområde, skal Power BI udføre en sikkerhedskontrol af identitetens ACL for at sikre, at den er godkendt. Den tid, det tager at afgøre, om målarbejdsområdet er inden for ACL'en, øges eksponentielt, efterhånden som antallet af arbejdsområder øges.

Bemærk

Power BI gennemtvinger ikke begrænsningen på 1.000 arbejdsområder via kode. Hvis du forsøger, føjer du en integreringsidentitet til mere end 1.000 arbejdsområder, og REST API-kald udføres stadig. Dit program skifter dog til en tilstand, der ikke understøttes , hvilket kan have konsekvenser, hvis du forsøger at anmode om hjælp fra Microsoft Support.

Overvej et scenarie, hvor to programmer med flere lejere hver især er konfigureret til at bruge en enkelt tjenesteprincipal. Tænk nu på, at det første program har oprettet 990 arbejdsområder, mens det andet program har oprettet 1.010 arbejdsområder. Fra et supportperspektiv er det første program inden for de understøttede grænser, mens det andet program ikke er.

Sammenlign nu disse to programmer udelukkende ud fra et ydeevneperspektiv. Der er ikke så stor forskel, fordi ACL'erne for begge tjenesteprincipaler har ladet metadataene for deres ACL'er vokse til et punkt, hvor det vil forringe ydeevnen til en vis grad.

Her er nøgleobservationen: Antallet af arbejdsområder, der er oprettet af en tjenesteprincipal, har en direkte indvirkning på ydeevnen og skalerbarheden. En tjenesteprincipal, der er medlem af 100 arbejdsområder, udfører REST API-kald hurtigere end en tjenesteprincipal, der er medlem af 1.000 arbejdsområder. På samme måde vil en tjenesteprincipal, der kun er medlem af 10 arbejdsområder, udføre REST API-kald hurtigere end en tjenesteprincipal, der er medlem af 100 arbejdsområder.

Vigtigt

Med hensyn til ydeevne og skalerbarhed er det optimale antal arbejdsområder, som en tjenesteprincipal er medlem af, nøjagtigt ét.

Administrer isolation for semantiske modeller og legitimationsoplysninger for datakilden

Et andet vigtigt aspekt ved design af et multitenancy-program er at isolere kundelejere. Det er vigtigt, at brugere fra én kundelejer ikke kan se data, der tilhører en anden kundelejer. Du skal derfor forstå, hvordan du administrerer semantisk modelejerskab og legitimationsoplysninger for datakilden.

Semantisk modelejerskab

Hver semantiske Power BI-model har en enkelt ejer, som enten kan være en brugerkonto eller en tjenesteprincipal. Semantisk modelejerskab er påkrævet for at konfigurere planlagte opdaterings- og semantiske modelparametre.

Tip

I Power BI-tjeneste kan du bestemme, hvem ejeren af den semantiske model er, ved at åbne indstillingerne for den semantiske model.

Hvis det er nødvendigt, kan du overføre ejerskabet af den semantiske model til en anden brugerkonto eller tjenesteprincipal. Det kan du gøre i Power BI-tjeneste eller ved hjælp af REST API-handlingenTakeOver. Når du importerer en Power BI Desktop-fil for at oprette en ny semantisk model ved hjælp af en tjenesteprincipal, angives tjenesteprincipalen automatisk som ejeren af den semantiske model.

Legitimationsoplysninger for datakilde

Hvis du vil forbinde en semantisk model med den underliggende datakilde, skal ejeren af den semantiske model angive legitimationsoplysninger for datakilden. Legitimationsoplysningerne for datakilden krypteres og cachelagres af Power BI. Fra dette tidspunkt bruger Power BI disse legitimationsoplysninger til at godkende med den underliggende datakilde, når dataene opdateres (til import af lagertabeller) eller udføres passthrough-forespørgsler (for DirectQuery-lagertabeller).

Vi anbefaler, at du anvender et almindeligt designmønster, når du klargør en ny kundelejer. Du kan udføre en række REST API-kald ved hjælp af identiteten for tjenesteprincipalen:

1. Opret et nyt arbejdsområde.
2. Knyt det nye arbejdsområde til en dedikeret kapacitet.
3. Importér en Power BI Desktop-fil for at oprette en semantisk model.
4. Angiv legitimationsoplysningerne for den semantiske modelkilde for den semantiske model.

Når disse REST API-kald er fuldført, vil tjenesteprincipalen være administrator af det nye arbejdsområde og ejeren af legitimationsoplysningerne for den semantiske model og datakilden.

Vigtigt

Der er en almindelig misforståelse om, at legitimationsoplysninger for semantiske modeldatakilder er begrænset på arbejdsområdeniveau. Det er ikke sandt. Legitimationsoplysningerne for datakilden er begrænset til tjenesteprincipalen (eller brugerkontoen), og dette område omfatter alle Power BI-arbejdsområder i Microsoft Entra-lejeren.

Det er muligt for en tjenesteprincipal at oprette legitimationsoplysninger for datakilden, der deles af semantiske modeller i forskellige arbejdsområder på tværs af kundelejere, som vist i følgende diagram.

Når legitimationsoplysninger for datakilden deles af semantiske modeller, der tilhører forskellige kundelejere, er kundelejerne ikke fuldt isoleret.

Designstrategier før tjenesteprincipalprofiler

Hvis du forstår designstrategier, før profilfunktionen for tjenesteprincipalen blev tilgængelig, kan det hjælpe dig med at forstå behovet for funktionen. Inden da byggede udviklere flerdimensionel programmer ved hjælp af en af følgende tre designstrategier:

• Enkelt tjenesteprincipal
• Gruppering af tjenesteprincipaler
• Én tjenesteprincipal pr. arbejdsområde

Der er styrker og svagheder forbundet med hver af disse designstrategier.

Designstrategien for en enkelt tjenesteprincipal kræver en engangsoprettelse af en Microsoft Entra-appregistrering. Det medfører derfor mindre administrative omkostninger end de to andre designstrategier, fordi der ikke er noget krav om at oprette flere Microsoft Entra-appregistreringer. Denne strategi er også den mest enkle at konfigurere, fordi den ikke kræver skrivning af ekstra kode, der ændrer opkaldskonteksten mellem tjenesteprincipaler, når der foretages REST API-kald. Et problem med denne designstrategi er dog, at den ikke skaleres. Det understøtter kun et multitenancy-miljø, der kan vokse op til 1.000 arbejdsområder. Ydeevnen forringes også, da tjenesteprincipalen tildeles adgang til et større antal arbejdsområder. Der er også et problem med kundens lejerisolation, fordi den enkelte tjenesteprincipal bliver ejer af hver semantisk model og alle datalegitimationsoplysninger på tværs af alle kundelejere.

Den tjenesteprincipal, der samler designstrategien, bruges ofte til at undgå begrænsningen på 1.000 arbejdsområder. Det gør det muligt for programmet at skalere til et vilkårligt antal arbejdsområder ved at føje det korrekte antal tjenesteprincipaler til gruppen. En pulje på fem tjenesteprincipaler gør det f.eks. muligt at skalere op til 5.000 arbejdsområder. en pulje på 80 tjenesteprincipaler gør det muligt at skalere op til 80.000 arbejdsområder osv. Selvom denne strategi kan skaleres til et stort antal arbejdsområder, har den dog flere ulemper. For det første kræver det, at der skrives ekstra kode og gemmes metadata for at tillade kontekstskift mellem tjenesteprincipaler, når der foretages REST API-kald. For det andet indebærer det en større administrativ indsats, fordi du skal oprette Microsoft Entra-appregistreringer, når du har brug for at øge antallet af tjenesteprincipaler i puljen.

Derudover er puljestrategien for tjenesteprincipalen ikke optimeret til ydeevne, fordi den gør det muligt for tjenesteprincipaler at blive medlem af hundredvis af arbejdsområder. Det er heller ikke ideelt set fra kundens lejerisolation, fordi tjenesteprincipalerne kan blive ejere af semantisk model og datalegitimationsoplysninger, der deles på tværs af kundelejere.

Den ene tjenesteprincipal pr. designstrategi for arbejdsområdet omfatter oprettelse af en tjenesteprincipal for hver kundelejer. Fra et teoretisk perspektiv tilbyder denne strategi den bedste løsning, fordi den optimerer ydeevnen af REST API-kald, samtidig med at den giver ægte isolation for semantiske modeller og legitimationsoplysninger for datakilden på arbejdsområdeniveau. Men det, der fungerer bedst i teorien, fungerer ikke altid bedst i praksis. Det skyldes, at kravet om at oprette en tjenesteprincipal for hver kundelejer er upraktisk for mange organisationer. Det skyldes, at nogle organisationer har formelle godkendelsesprocesser, eller at de involverer overdrevent bureaukrati for at oprette Microsoft Entra-appregistreringer. Disse årsager kan gøre det umuligt at tildele et brugerdefineret program den autoritet, det har brug for til at oprette Microsoft Entra-appregistreringer efter behov og på den automatiserede måde, som din løsning kræver.

I mindre almindelige scenarier, hvor et brugerdefineret program er blevet tildelt de rette tilladelser, kan det bruge Microsoft Graph API til at oprette Microsoft Entra-appregistreringer efter behov. Det brugerdefinerede program er dog ofte komplekst at udvikle og udrulle, fordi det på en eller anden måde skal spore godkendelseslegitimationsoplysninger for hver Microsoft Entra-appregistrering. Den skal også have adgang til disse legitimationsoplysninger, når den skal godkende og hente adgangstokens for individuelle tjenesteprincipaler.

Profiler for tjenesteprincipaler

Funktionen med tjenesteprincipalprofiler er udviklet til at gøre det nemmere for dig at administrere organisationsindhold i Power BI og bruge dine kapaciteter mere effektivt. De hjælper med at håndtere tre specifikke udfordringer, der involverer den laveste mængde udviklerindsats og -omkostninger. Disse udfordringer omfatter:

• Skalering til et stort antal arbejdsområder.
• Optimering af ydeevnen for REST API-kald.
• Isolerer semantiske modeller og legitimationsoplysninger for datakilden på kundelejerniveau.

Når du designer et multitenancy-program ved hjælp af tjenesteprincipalprofiler, kan du drage fordel af styrkerne ved de tre designstrategier (beskrevet i forrige afsnit), samtidig med at du undgår deres tilknyttede svagheder.

Tjenesteprincipalprofiler er lokale konti, der oprettes i forbindelse med Power BI. En tjenesteprincipal kan bruge Profiles REST API-handlingen til at oprette nye tjenesteprincipalprofiler. En tjenesteprincipal kan oprette og administrere sit eget sæt tjenesteprincipalprofiler for et brugerdefineret program, som vist i følgende diagram.

Der er altid en overordnet/underordnet-relation mellem en tjenesteprincipal og de profiler for tjenesteprincipalen, den opretter. Du kan ikke oprette en tjenesteprincipalprofil som et separat objekt. Du opretter i stedet en profil for en tjenesteprincipal ved hjælp af en bestemt tjenesteprincipal, og denne tjenesteprincipal fungerer som profilens overordnede. Desuden er en tjenesteprincipalprofil aldrig synlig for brugerkonti eller andre tjenesteprincipaler. En tjenesteprincipalprofil kan kun ses og bruges af den tjenesteprincipal, der oprettede den.

Profiler for tjenesteprincipaler er ikke kendt af Microsoft Entra

Selvom selve tjenesteprincipalen og den underliggende Microsoft Entra-appregistrering er kendt af Microsoft Entra, ved Microsoft Entra-id ikke noget om tjenesteprincipalprofiler. Det skyldes, at tjenesteprincipalprofiler oprettes af Power BI, og de findes kun i det Power BI-tjeneste undersystem, der styrer Power BI-sikkerhed og -autorisation.

Det faktum, at tjenesteprincipalprofiler ikke er kendt af Microsoft Entra ID, har både fordele og ulemper. Den primære fordel er, at et program til integrering for dit kundescenarie ikke har brug for særlige Microsoft Entra-tilladelser til at oprette profiler for tjenesteprincipaler. Det betyder også, at programmet kan oprette og administrere et sæt lokale identiteter, der er adskilt fra Microsoft Entra.

Der er dog også ulemper. Da profiler for tjenesteprincipaler ikke er kendt af Microsoft Entra, kan du ikke føje en tjenesteprincipalprofil til en Microsoft Entra-gruppe for implicit at give den adgang til et arbejdsområde. Eksterne datakilder, f.eks. en Azure SQL Database eller Azure Synapse Analytics, kan heller ikke genkende tjenesteprincipalprofiler som identiteten, når der oprettes forbindelse til en database. Så den ene tjenesteprincipal pr. designstrategi for arbejdsområdet (oprettelse af en tjenesteprincipal for hver kundelejer) kan være et bedre valg, når der er et krav om at oprette forbindelse til disse datakilder ved hjælp af en separat tjenesteprincipal med entydige legitimationsoplysninger til godkendelse for hver kundelejer.

Tjenesteprincipalprofiler er førsteklasses sikkerhedsprincipaler

Selvom Microsoft Entra ikke kender profilerne for tjenesteprincipaler, genkender Power BI dem som førsteklasses sikkerhedsprincipaler. På samme måde som med en brugerkonto eller en tjenesteprincipal kan du føje profiler for tjenesteprincipaler til en rolle i arbejdsområdet (som Administration eller medlem). Du kan også gøre den til semantisk modelejer og ejer af legitimationsoplysninger for datakilden. Af disse årsager er oprettelse af en ny tjenesteprincipalprofil for hver ny kundelejer en bedste praksis.

Tip

Når du udvikler et program til integrering for dit kundescenarie ved hjælp af profiler for tjenesteprincipaler, skal du kun oprette en enkelt Microsoft Entra-appregistrering for at give dit program en enkelt tjenesteprincipal. Denne fremgangsmåde reducerer de administrative omkostninger betydeligt sammenlignet med andre designstrategier for flere områder, hvor det er nødvendigt løbende at oprette yderligere Microsoft Entra-appregistreringer, når programmet er udrullet til produktion.

Udfør REST API-kald som en tjenesteprincipalprofil

Dit program kan udføre REST API-kald ved hjælp af identiteten for en tjenesteprincipalprofil. Det betyder, at den kan udføre en sekvens af REST API-kald for at klargøre og konfigurere en ny kundelejer.

1. Når en tjenesteprincipalprofil opretter et nyt arbejdsområde, tilføjer Power BI automatisk denne profil som administrator af arbejdsområdet.
2. Når en tjenesteprincipalprofil importerer en Power BI Desktop-fil for at oprette en semantisk model, angiver Power BI denne profil som ejeren af den semantiske model.
3. Når en tjenesteprincipalprofil angiver legitimationsoplysninger for datakilden, angiver Power BI denne profil som ejer af legitimationsoplysningerne for datakilden.

Det er vigtigt at forstå, at en tjenesteprincipal har en identitet i Power BI, der er adskilt fra og adskiller sig fra identiteterne for dens profiler. Det giver dig mulighed for at vælge som udvikler. Du kan udføre REST API-kald ved hjælp af identiteten for en tjenesteprincipalprofil. Du kan også udføre REST API-kald uden en profil, som bruger identiteten for den overordnede tjenesteprincipal.

Vi anbefaler, at du udfører REST API-kald som den overordnede tjenesteprincipal, når du opretter, får vist eller sletter profiler for tjenesteprincipaler. Du skal bruge tjenesteprincipalprofilen til at udføre alle andre REST API-kald. Disse andre kald kan oprette arbejdsområder, importere Power BI Desktop-filer, opdatere semantiske modelparametre og angive legitimationsoplysninger for datakilden. De kan også hente metadata for arbejdsområdeelementet og generere integreringstokens.

Overvej et eksempel, hvor du skal konfigurere en kundelejer for en kunde med navnet Contoso. Det første trin foretager et REST API-kald for at oprette en tjenesteprincipalprofil med det viste navn angivet til Contoso. Dette kald foretages ved hjælp af identiteten for tjenesteprincipalen. Alle resterende konfigureringstrin bruger tjenesteprincipalprofilen til at udføre følgende opgaver:

1. Opret et arbejdsområde.
2. Knyt arbejdsområdet til en kapacitet.
3. Importér en Power BI Desktop-fil.
4. Angiv semantiske modelparametre.
5. Angiv legitimationsoplysninger for datakilden.
6. Konfigurer planlagt dataopdatering.

Det er vigtigt at forstå, at adgang til arbejdsområdet og dets indhold skal gøres ved hjælp af identiteten for den tjenesteprincipalprofil, der blev brugt til at oprette kundelejeren. Det er også vigtigt at forstå, at den overordnede tjenesteprincipal ikke har brug for adgang til arbejdsområdet eller dets indhold.

Tip

Husk: Når du foretager REST API-kald, skal du bruge tjenesteprincipalen til at oprette og administrere profiler for tjenesteprincipaler og bruge profilen for tjenesteprincipalen til at oprette, konfigurere og få adgang til Power BI-indhold.

Brug REST API-handlingerne profiler

Rest API-handlingsgruppen Profiler omfatter handlinger, der opretter og administrerer profiler for tjenesteprincipaler:

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

Opret en tjenesteprincipalprofil

Brug handlingen Create Profile REST API til at oprette en tjenesteprincipalprofil. Du skal angive egenskaben displayName i anmodningens brødtekst for at angive et vist navn for den nye lejer. Værdien skal være entydig på tværs af alle de profiler, der ejes af tjenesteprincipalen. Kaldet mislykkes, hvis der allerede findes en anden profil med det viste navn for tjenesteprincipalen.

Et vellykket kald returnerer egenskaben id , som er et GUID, der repræsenterer profilen. Når du udvikler programmer, der bruger tjenesteprincipalprofiler, anbefaler vi, at du gemmer profilvisningsnavne og deres id-værdier i en brugerdefineret database. På den måde er det ligetil for dit program at hente id'erne.

Hvis du programmerer med Power BI .NET SDK, kan du bruge metoden Profiles.CreateProfile , som returnerer et ServicePrincipalProfile objekt, der repræsenterer den nye profil. Det gør det nemt at bestemme egenskabsværdien id .

Her er et eksempel på, hvordan du opretter en tjenesteprincipalprofil og tildeler den adgang til arbejdsområdet.

// 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);

I Power BI-tjeneste kan du i ruden Adgang til arbejdsområde bestemme, hvilke identiteter, herunder sikkerhedsprincipaler, der har adgang.

Slet en tjenesteprincipalprofil

Brug handlingen Delete Profile REST API til at slette en tjenesteprincipalprofil. Denne handling kan kun kaldes af den overordnede tjenesteprincipal.

Hvis du programmerer med Power BI .NET SDK, kan du bruge Profiles.DeleteProfile metoden .

Hent alle profiler for tjenesteprincipaler

Brug REST API-handlingen Hent profiler til at hente en liste over tjenesteprincipalprofiler, der tilhører den kaldende tjenesteprincipal. Denne handling returnerer en JSON-nyttedata, der indeholder id egenskaberne og displayName for hver tjenesteprincipalprofil.

Hvis du programmerer med Power BI .NET SDK, kan du bruge metoden Profiles.GetProfiles .

Udfør REST API-kald ved hjælp af en tjenesteprincipalprofil

Der er to krav til at foretage REST API-kald ved hjælp af en tjenesteprincipalprofil:

• Du skal overføre adgangstokenet for den overordnede tjenesteprincipal i godkendelsesheaderen.
• Du skal inkludere en header med navnet X-PowerBI-profile-id med værdien af id'et for tjenesteprincipalens profil.

Hvis du bruger Power BI .NET SDK, kan du angive værdien for X-PowerBI-profile-id-headeren eksplicit ved at angive id'et for tjenesteprincipalens profil.

// 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();

Som vist i ovenstående eksempel er det nemt at aktivere metoder, f.eksGroups.GetGroups. , når du føjer X-PowerBI-profile-id-headerenPowerBIClient til objektet, så de udføres ved hjælp af tjenesteprincipalprofilen.

Du kan angive X-PowerBI-profil-id-headeren for et PowerBIClient objekt på en mere praktisk måde. Du kan initialisere objektet ved at overføre profilens id til konstruktøren.

// 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);

Når du programmerer et multitenancy-program, er det sandsynligt, at du skal skifte mellem at udføre kald som den overordnede tjenesteprincipal og udføre kald som en tjenesteprincipalprofil. En nyttig metode til at administrere kontekstskift er at deklarere en variabel på klasseniveau, der gemmer objektet PowerBIClient . Du kan derefter oprette en hjælpemetode, der angiver variablen med det korrekte objekt.

// 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));
    }
}

Når du har brug for at oprette eller administrere en tjenesteprincipalprofil, kan du kalde SetCallingContext metoden uden nogen parametre. På denne måde kan du oprette og administrere profiler ved hjælp af identiteten for tjenesteprincipalen.

// 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);

Når du har brug for at oprette og konfigurere et arbejdsområde for en ny kundelejer, skal du udføre denne kode som en tjenesteprincipalprofil. Du skal derfor kalde SetCallingContext metoden ved at angive profilens id. På denne måde kan du oprette arbejdsområdet ved hjælp af identiteten for tjenesteprincipalprofilen.

// 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);

Når du har brugt en bestemt tjenesteprincipalprofil til at oprette og konfigurere et arbejdsområde, skal du fortsætte med at bruge den samme profil til at oprette og konfigurere indholdet i arbejdsområdet. Det er ikke nødvendigt at aktivere SetCallingContext metoden for at fuldføre konfigurationen.

Udviklereksempel

Vi opfordrer dig til at downloade et eksempelprogram med navnet AppOwnsDataMultiTenant.

Dette eksempelprogram blev udviklet ved hjælp af .NET 6 og ASP.NET, og det viser, hvordan du anvender den vejledning og de anbefalinger, der er beskrevet i denne artikel. Du kan gennemse koden for at få mere at vide om, hvordan du udvikler et multitenancy-program, der implementerer scenariet Integrer for din kunde ved hjælp af profiler for tjenesteprincipaler.

Relateret indhold

Du kan få flere oplysninger om denne artikel i følgende ressourcer:

• Tjenesteprincipalprofiler til apps med flere brugere i Power BI Embedded
• Overfør programmer med flere kunder til profilmodellen for tjenesteprincipaler
• Profiler Power BI REST API-handlingsgruppe
• • AppOwnsDataMultiTenant-eksempelprogram
• Spørgsmål? Prøv at spørge Power BI-community'et
• Forslag? Bidrag med idéer til forbedring af Power BI