Utvikle skalerbare programmer for multitenancy med Power BI-innebygging

  • Artikkel

Denne artikkelen beskriver hvordan du utvikler et program for multitenancy som bygger inn Power BI-innhold, samtidig som de oppnår de høyeste nivåene av skalerbarhet, ytelse og sikkerhet. Ved å utforme og implementere et program med tjenestekontohaverprofiler kan du opprette og administrere en flertenningsløsning bestående av titusenvis av kundeleietakere som kan levere rapporter til målgrupper på over 100 000 brukere.

Tjenestekontohaverprofiler er en funksjon som gjør det enklere for deg å administrere organisatorisk innhold i Power BI og bruke kapasitetene mer effektivt. Hvis du bruker tjenestekontohaverprofiler, kan du imidlertid legge til kompleksitet i programutformingen. Derfor bør du bare bruke dem når det er behov for å oppnå betydelig skala. Vi anbefaler at du bruker tjenestekontohaverprofiler når du har mange arbeidsområder og mer enn 1000 programbrukere.

Merk

Verdien av å bruke tjenestekontohaverprofiler øker etter hvert som behovet for å skalere øker, i tillegg til behovet for å oppnå de høyeste nivåene av sikkerhet og leierisolasjon.

Du kan oppnå innebygging i Power BI ved hjelp av to ulike innebyggingsscenarioer: Bygg inn for organisasjonen og Bygg inn for kunden.

Innebygging for organisasjonsscenarioet gjelder når programgruppen består av interne brukere. Interne brukere har organisasjonskontoer og må godkjenne med Microsoft Entra ID (tidligere kalt Azure Active Directory). I dette scenarioet er Power BI software-as-a-service (SaaS). Det kalles noen ganger bruker eier data.

Bygg inn for kundescenarioet gjelder når programgruppen består av eksterne brukere. Programmet er ansvarlig for godkjenning av brukere. For å få tilgang til Power BI-innhold er programmet avhengig av en innebyggingsidentitet (Microsoft Entra-tjenestekontohaver eller hovedbrukerkonto) for å godkjenne med Microsoft Entra. I dette scenarioet er Power BI plattform-som-en-tjeneste (PaaS). Det kalles noen ganger at Appen eier data.

Merk

Det er viktig å forstå at funksjonen for tjenestekontohaverprofiler ble utformet for bruk med Bygg inn for kundescenarioet . Dette er fordi dette scenarioet gir UAVHENGIG-er og bedriftsorganisasjoner muligheten til å bygge inn i større skala til et stort antall brukere og til et stort antall kundeleietakere.

Utvikling av program for multitenancy

Hvis du er kjent med Microsoft Entra, kan ordet tenant føre til at du tenker på en Microsoft Entra-leier. Konseptet med en leier er imidlertid forskjellig i sammenheng med å bygge en flertenningsløsning som bygger inn Power BI-innhold. I denne sammenhengen opprettes en kundeleier på vegne av hver kunde som programmet bygger inn Power BI-innhold for, ved hjelp av Bygg inn for kundescenarioet . Du klargjør vanligvis hver kundeleier ved å opprette ett enkelt Power BI-arbeidsområde.

Hvis du vil opprette en skalerbar løsning for multitenancy, må du kunne automatisere opprettingen av nye kundeleiere. Klargjøring av en ny kundeleier innebærer vanligvis å skrive kode som bruker REST-API-en for Power BI til å opprette et nytt Power BI-arbeidsområde, opprette semantiske modeller (tidligere kjent som datasett) ved å importere Power BI Desktop-filer (PBIX), oppdatere datakildeparametere, angi legitimasjon for datakilder og konfigurere planlagt semantisk modelloppdatering. Diagrammet nedenfor viser hvordan du kan legge til Power BI-elementer, for eksempel rapporter og semantiske modeller, i arbeidsområder for å konfigurere kundeleieren.

Diagram som viser et oppsett for tre leiere. Hver leier har sin egen datakilde og arbeidsområde.

Når du utvikler et program som bruker Innebygging for kundescenarioet , er det mulig å foreta REST-API-anrop for Power BI ved hjelp av en innebyggingsidentitet som enten er en hovedbrukerkonto eller tjenestekontohaver. Vi anbefaler at du bruker en tjenestekontohaver for produksjonsprogrammer. Det gir den høyeste sikkerheten, og derfor er det tilnærmingen som anbefales av Microsoft Entra. Den støtter også bedre automatisering og skala, og det er mindre administrasjonskostnader. Det krever imidlertid administratorrettigheter for Power BI for å konfigurere og administrere.

Ved hjelp av en tjenestekontohaver kan du unngå vanlige problemer knyttet til hovedbrukerkontoer, for eksempel godkjenningsfeil i miljøer der brukere må logge på ved hjelp av godkjenning med flere faktorer (MFA). Bruk av en tjenestekontohaver er også i samsvar med ideen om at Innebygging for kundescenarioet er basert på innebygging av Power BI-innhold ved hjelp av et PaaS-tankesett i motsetning til en SaaS-tankegang.

Begrensning på 1000 arbeidsområder

Når du utformer et multitenancy-miljø som implementerer Innebygging for kundescenarioet , må du vurdere at innebyggingsidentiteten ikke kan gis tilgang til mer enn 1000 arbeidsområder. Den Power Bi-tjeneste pålegger denne begrensningen for å sikre god ytelse når du foretar REST API-kall. Årsaken til denne begrensningen er relatert til hvordan Power BI opprettholder sikkerhetsrelaterte metadata for hver identitet.

Power BI bruker metadata til å spore arbeidsområder og arbeidsområdeelementer som en identitet har tilgang til. I praksis må Power BI opprettholde en egen tilgangskontrolliste (ACL) for hver identitet i autorisasjonsdelsystemet. Når en identitet foretar et REST-API-kall for å få tilgang til et arbeidsområde, må Power BI utføre en sikkerhetskontroll mot identitetens ACL for å sikre at den er autorisert. Tiden det tar å avgjøre om målarbeidsområdet er innenfor ACL øker eksponentielt etter hvert som antall arbeidsområder øker.

Merk

Power BI håndhever ikke begrensningen på 1000 arbeidsområder gjennom kode. Hvis du prøver, legger du til en innebyggingsidentitet i mer enn 1000 arbeidsområder, og REST API-kall vil fortsatt kjøres. Programmet flyttes imidlertid til en tilstand som ikke støttes , noe som kan ha konsekvenser hvis du prøver å be om hjelp fra Microsoft-støtte.

Vurder et scenario der to programmer med flere leiere er konfigurert til å bruke én enkelt tjenestekontohaver. Tenk nå på at det første programmet har opprettet 990 arbeidsområder, mens det andre programmet har opprettet 1010 arbeidsområder. Fra et støtteperspektiv er det første programmet innenfor grensene som støttes, mens det andre programmet ikke er det.

Sammenlign disse to programmene rent fra et ytelsesperspektiv. Det er ikke så stor forskjell fordi acls for begge tjenestekontohavere har latt metadataene for deres ACLs vokse til et punkt der det vil redusere ytelsen til en viss grad.

Her er nøkkelobservasjonen: Antall arbeidsområder som opprettes av en tjenestekontohaver, har en direkte innvirkning på ytelse og skalerbarhet. En tjenestekontohaver som er medlem av 100 arbeidsområder, utfører REST API-kall raskere enn en tjenestekontohaver som er medlem av 1000 arbeidsområder. På samme måte utfører en tjenestekontohaver som er medlem av bare 10 arbeidsområder REST API-kall raskere enn en tjenestekontohaver som er medlem av 100 arbeidsområder.

Viktig

Fra perspektivet til ytelse og skalerbarhet er det optimale antallet arbeidsområder som en tjenestekontohaver er medlem av, nøyaktig ett.

Administrer isolasjon for semantiske modeller og datakildelegitimasjon

Et annet viktig aspekt når du utformer et program for multitenancy, er å isolere kundeleiere. Det er viktig at brukere fra én kundeleier ikke ser data som tilhører en annen kundeleier. Derfor må du forstå hvordan du administrerer semantisk modelleierskap og datakildelegitimasjon.

Semantisk modelleierskap

Hver Semantiske Power BI-modell har én enkelt eier, som enten kan være en brukerkonto eller en tjenestekontohaver. Semantisk modelleierskap kreves for å konfigurere planlagt oppdatering og angi semantiske modellparametere.

Tips

I Power Bi-tjeneste kan du bestemme hvem den semantiske modelleieren er ved å åpne innstillingene for semantisk modell.

Om nødvendig kan du overføre eierskapet til den semantiske modellen til en annen brukerkonto eller tjenestekontohaver. Du kan gjøre dette i Power Bi-tjeneste, eller ved hjelp av REST-API-operasjonenTakeOver. Når du importerer en Power BI Desktop-fil for å opprette en ny semantisk modell ved hjelp av en tjenestekontohaver, angis tjenestekontohaveren automatisk som semantisk modelleier.

Legitimasjon for datakilde

Hvis du vil koble en semantisk modell til den underliggende datakilden, må eieren av den semantiske modellen angi legitimasjon for datakilden. Legitimasjon for datakilder krypteres og bufres av Power BI. Fra dette tidspunktet bruker Power BI denne legitimasjonen til å godkjenne med den underliggende datakilden når du oppdaterer dataene (for importlagringstabeller) eller utfører direktevisningsspørringer (for DirectQuery-lagringstabeller).

Vi anbefaler at du bruker et vanlig utformingsmønster når du klargjør en ny kundeleier. Du kan utføre en rekke REST-API-kall ved hjelp av identiteten til tjenestekontohaveren:

  1. Opprett et nytt arbeidsområde.
  2. Knytt det nye arbeidsområdet til en dedikert kapasitet.
  3. Importer en Power BI Desktop-fil for å opprette en semantisk modell.
  4. Angi den semantiske modellkildelegitimasjonen for den semantiske modellen.

Ved fullføring av disse REST API-oppkallene vil tjenestekontohaveren være administrator for det nye arbeidsområdet og eieren av semantisk modell- og datakildelegitimasjon.

Viktig

Det er en vanlig misforståelse at legitimasjon for semantisk modelldatakilde er omfang på arbeidsområdenivå. Det er ikke sant. Legitimasjon for datakilder er begrenset til tjenestekontohaveren (eller brukerkontoen), og dette omfanget strekker seg til alle Power BI-arbeidsområder i Microsoft Entra-leieren.

Det er mulig for en tjenestekontohaver å opprette datakildelegitimasjon som deles av semantiske modeller i ulike arbeidsområder på tvers av kundeleiere, som vist i diagrammet nedenfor.

Diagram som viser et oppsett for to leiere. Hver leier deler samme legitimasjon for datakilde.

Når legitimasjon for datakilder deles av semantiske modeller som tilhører forskjellige kundeleiere, er ikke kundeleierne helt isolert.

Utformingsstrategier før tjenestekontohaverprofiler

Å forstå utformingsstrategier før funksjonen for tjenestekontohaverprofil ble tilgjengelig, kan hjelpe deg med å sette pris på behovet for funksjonen. Før denne tiden bygde utviklere programmer for multitenancy ved hjelp av én av følgende tre utformingsstrategier:

  • Én tjenestekontohaver
  • Tjenestekontohaverutvalg
  • Én tjenestekontohaver per arbeidsområde

Det finnes styrker og svakheter forbundet med hver av disse designstrategiene.

Utformingsstrategien for enkel tjenestekontohaver krever en engangsopprettelse av en Microsoft Entra-appregistrering. Det innebærer derfor mindre administrative kostnader enn de to andre utformingsstrategiene, fordi det ikke er noe krav om å opprette flere Microsoft Entra-appregistreringer. Denne strategien er også den enkleste å konfigurere fordi den ikke krever å skrive ekstra kode som bytter samtalekonteksten mellom tjenestekontohavere når du foretar REST API-kall. Et problem med denne utformingsstrategien er imidlertid at den ikke skaleres. Den støtter bare et miljø for fleretenancy som kan vokse opp til 1000 arbeidsområder. Ytelsen er også sikker på å bli redusert ettersom tjenestekontohaveren får tilgang til et større antall arbeidsområder. Det er også et problem med isolering av kundeleier fordi den ene tjenestekontohaveren blir eier av hver semantisk modell og all datalegitimasjon på tvers av alle kundeleiere.

Utformingsstrategien for tjenestekontohaverutvalg brukes vanligvis til å unngå begrensningen på 1000 arbeidsområder. Det gjør at programmet kan skalere til et hvilket som helst antall arbeidsområder ved å legge til riktig antall tjenestekontohavere i utvalget. Et utvalg med fem tjenestekontohavere gjør det for eksempel mulig å skalere opptil 5000 arbeidsområder. et utvalg på 80 tjenestekontohavere gjør det mulig å skalere opptil 80 000 arbeidsområder og så videre. Men selv om denne strategien kan skaleres til et stort antall arbeidsområder, har den flere ulemper. For det første krever det å skrive ekstra kode og lagre metadata for å tillate kontekstbytte mellom tjenestekontohavere når du foretar REST API-kall. For det andre innebærer det mer administrativ innsats fordi du må opprette Microsoft Entra-appregistreringer når du trenger å øke antall tjenestekontohavere i utvalget.

Dessuten er ikke tjenestekontohaverens samlingsstrategi optimalisert for ytelse fordi det gjør det mulig for tjenestekontohavere å bli medlemmer av hundrevis av arbeidsområder. Det er heller ikke ideelt fra perspektivet til kundens leierisolasjon fordi tjenestekontohaverne kan bli eiere av semantisk modell og datalegitimasjon som deles på tvers av kundeleiere.

Én tjenestekontohaver per strategi for arbeidsområdeutforming innebærer å opprette en tjenestekontohaver for hver kundeleier. Fra et teoretisk perspektiv tilbyr denne strategien den beste løsningen fordi den optimaliserer ytelsen til REST API-kall, samtidig som den gir sann isolasjon for semantiske modeller og datakildelegitimasjon på arbeidsområdenivå. Men det som fungerer best i teorien, fungerer ikke alltid best i praksis. Det er fordi kravet om å opprette en tjenestekontohaver for hver kundeleier er upraktisk for mange organisasjoner. Det er fordi noen organisasjoner har formelle godkjenningsprosesser, eller de involverer overdreven byråkrati for å opprette Microsoft Entra-appregistreringer. Disse årsakene kan gjøre det umulig å gi et egendefinert program myndigheten den trenger for å opprette Microsoft Entra-appregistreringer ved behov og på den automatiserte måten løsningen krever.

I mindre vanlige scenarioer der et egendefinert program har fått riktige tillatelser, kan det bruke Microsoft Graph API-en til å opprette Microsoft Entra-appregistreringer ved behov. Det egendefinerte programmet er imidlertid ofte komplisert å utvikle og distribuere fordi det på en eller annen måte må spore godkjenningslegitimasjon for hver Microsoft Entra-appregistrering. Den må også få tilgang til denne legitimasjonen når den trenger å godkjenne og skaffe tilgangstokener for individuelle tjenestekontohavere.

Tjenestekontohaverprofiler

Funksjonen for tjenestekontohaverprofiler ble utformet for å gjøre det enklere for deg å administrere organisatorisk innhold i Power BI og bruke kapasitetene mer effektivt. De bidrar til å løse tre spesifikke utfordringer som involverer den laveste mengden utviklerinnsats og overhead. Disse utfordringene omfatter:

  • Skalering til et stort antall arbeidsområder.
  • Optimaliserer ytelsen til REST-API-kall.
  • Isolere semantiske modeller og datakildelegitimasjon på kundeleietakernivå.

Når du utformer et program for multitenancy ved hjelp av tjenestekontohaverprofiler, kan du dra nytte av styrkene til de tre utformingsstrategiene (beskrevet i forrige del) samtidig som du unngår tilknyttede svakheter.

Tjenestekontohaverprofiler er lokale kontoer som opprettes i konteksten til Power BI. En tjenestekontohaver kan bruke Profiles REST-API-operasjonen til å opprette nye tjenestekontohaverprofiler. En tjenestekontohaver kan opprette og administrere sitt eget sett med tjenestekontohaverprofiler for et egendefinert program, som vist i diagrammet nedenfor.

Diagram som viser en tjenestekontohaver som oppretter tre tjenestekontohaverprofiler i Power BI.

Det er alltid en overordnet-underordnet-relasjon mellom en tjenestekontohaver og tjenestekontohaverprofilene den oppretter. Du kan ikke opprette en tjenestekontohaverprofil som en frittstående enhet. I stedet oppretter du en tjenestekontohaverprofil ved hjelp av en bestemt tjenestekontohaver, og tjenestekontohaveren fungerer som profilens overordnede. I tillegg er en tjenestekontohaverprofil aldri synlig for brukerkontoer eller andre tjenestekontohavere. En tjenestekontohaverprofil kan bare ses og brukes av tjenestekontohaveren som opprettet den.

Tjenestekontohaverprofiler er ikke kjent for Microsoft Entra

Selv om selve tjenestekontohaveren og den underliggende Microsoft Entra-appregistreringen er kjent for Microsoft Entra, vet ikke Microsoft Entra ID noe om tjenestekontohaverprofiler. Det er fordi tjenestekontohaverprofiler opprettes av Power BI, og de finnes bare i det Power Bi-tjeneste delsystemet som styrer Power BI-sikkerhet og -autorisasjon.

Det faktum at tjenestekontohaverprofiler ikke er kjent for Microsoft Entra ID, har både fordeler og ulemper. Den primære fordelen er at et bygg inn for kundescenarioprogrammet ikke trenger noen spesielle Microsoft Entra-tillatelser for å opprette tjenestekontohaverprofiler. Det betyr også at programmet kan opprette og administrere et sett med lokale identiteter som er atskilt fra Microsoft Entra.

Men det er også ulemper. Siden tjenestekontohaverprofiler ikke er kjent for Microsoft Entra, kan du ikke legge til en tjenestekontohaverprofil i en Microsoft Entra-gruppe for implisitt å gi den tilgang til et arbeidsområde. Eksterne datakilder, for eksempel en Azure SQL Database eller Azure Synapse Analytics, kan heller ikke gjenkjenne tjenestekontohaverprofiler som identiteten når du kobler til en database. Så én tjenestekontohaver per strategi for arbeidsområdeutforming (oppretting av en tjenestekontohaver for hver kundeleier) kan derfor være et bedre valg når det er et krav om å koble til disse datakildene ved hjelp av en egen tjenestekontohaver med unik godkjenningslegitimasjon for hver kundeleier.

Tjenestekontohaverprofiler er førsteklasses sikkerhetskontohavere

Selv om tjenestekontohaverprofiler ikke er kjent for Microsoft Entra, gjenkjenner Power BI dem som førsteklasses sikkerhetskontohavere. Akkurat som en brukerkonto eller tjenestekontohaver, kan du legge til tjenestekontohaverprofiler i en arbeidsområderolle (som administrator eller medlem). Du kan også gjøre den til en semantisk modelleier og eieren av datakildelegitimasjonen. Av disse grunnene er det en anbefalt fremgangsmåte å opprette en ny tjenestekontohaverprofil for hver nye kundeleier.

Diagram som viser flere kundeleiere, hver med sine egne tjenestekontohaverprofiler.

Tips

Når du utvikler et bygg inn for kundescenarioprogrammet ved hjelp av tjenestekontohaverprofiler, trenger du bare å opprette én enkelt Microsoft Entra-appregistrering for å gi programmet ditt én enkelt tjenestekontohaver. Denne tilnærmingen reduserer administrative kostnader betydelig sammenlignet med andre utformingsstrategier for multitenancy, der det er nødvendig å opprette flere Microsoft Entra-appregistreringer kontinuerlig etter at programmet er distribuert til produksjon.

Utfør REST-API-kall som tjenestekontohaverprofil

Programmet kan utføre REST API-kall ved hjelp av identiteten til en tjenestekontohaverprofil. Det betyr at den kan utføre en sekvens med REST-API-kall for å klargjøre og konfigurere en ny kundeleier.

  1. Når en tjenestekontohaverprofil oppretter et nytt arbeidsområde, legger Power BI automatisk til denne profilen som administrator for arbeidsområdet.
  2. Når en tjenestekontohaverprofil importerer en Power BI Desktop-fil for å opprette en semantisk modell, angir Power BI denne profilen som semantisk modelleier.
  3. Når en tjenestekontohaverprofil angir legitimasjon for datakilder, angir Power BI denne profilen som eier av datakildelegitimasjonen.

Det er viktig å forstå at en tjenestekontohaver har en identitet i Power BI som er atskilt og atskilt fra identiteten til profilene. Dette gir deg valget som utvikler. Du kan utføre REST API-kall ved hjelp av identiteten til en tjenestekontohaverprofil. Alternativt kan du utføre REST API-kall uten en profil, som bruker identiteten til den overordnede tjenestekontohaveren.

Vi anbefaler at du utfører REST-API-kall som overordnet tjenestekontohaver når du oppretter, viser eller sletter tjenestekontohaverprofiler. Du bør bruke tjenestekontohaverprofilen til å utføre alle andre REST API-kall. Disse andre anropene kan opprette arbeidsområder, importere Power BI Desktop-filer, oppdatere semantiske modellparametere og angi legitimasjon for datakilder. De kan også hente metadata for arbeidsområdeelement og generere innebyggingstokener.

Vurder et eksempel der du må konfigurere en kundeleier for en kunde som heter Contoso. Det første trinnet foretar et REST-API-kall for å opprette en tjenestekontohaverprofil med visningsnavnet satt til Contoso. Dette kallet foretas ved hjelp av identiteten til tjenestekontohaveren. Alle gjenværende konfigurasjonstrinn bruker tjenestekontohaverprofilen til å fullføre følgende oppgaver:

  1. Opprett et arbeidsområde.
  2. Knytt arbeidsområdet til en kapasitet.
  3. Importer en Power BI Desktop-fil.
  4. Angi semantiske modellparametere.
  5. Angi legitimasjon for datakilde.
  6. Konfigurer planlagt dataoppdatering.

Det er viktig å forstå at tilgang til arbeidsområdet og innholdet må gjøres ved hjelp av identiteten til tjenestekontohaverprofilen som ble brukt til å opprette kundeleieren. Det er også viktig å forstå at overordnet tjenestekontohaver ikke trenger tilgang til arbeidsområdet eller innholdet.

Tips

Husk: Når du foretar REST API-anrop, bruker du tjenestekontohaveren til å opprette og administrere tjenestekontohaverprofiler, og bruker tjenestekontohaverprofilen til å opprette, konfigurere og få tilgang til Power BI-innhold.

Bruke REST-API-operasjonene for profiler

Rest-API-operasjonsgruppen for profiler består av operasjoner som oppretter og administrerer tjenestekontohaverprofiler:

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

Opprette en tjenestekontohaverprofil

Bruk REST-API-operasjonen for oppretting av profil til å opprette en tjenestekontohaverprofil. Du må angi displayName egenskapen i forespørselsteksten for å angi et visningsnavn for den nye leieren. Verdien må være unik på tvers av alle profilene som eies av tjenestekontohaveren. Samtalen mislykkes hvis en annen profil med visningsnavnet allerede finnes for tjenestekontohaveren.

Et vellykket kall returnerer id egenskapen, som er en GUID som representerer profilen. Når du utvikler programmer som bruker tjenestekontohaverprofiler, anbefaler vi at du lagrer profilvisningsnavn og ID-verdier i en egendefinert database. På den måten er det enkelt for programmet å hente ID-ene.

Hvis du programmerer med Power BI .NET SDK, kan du bruke Profiles.CreateProfile metoden, som returnerer et ServicePrincipalProfile objekt som representerer den nye profilen. Det gjør det enkelt å bestemme egenskapsverdien id .

Her er et eksempel på hvordan du oppretter en tjenestekontohaverprofil og gir den tilgang til arbeidsområ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 bestemme hvilke identiteter, inkludert sikkerhetskontohavere, som har tilgang i Access-ruten for arbeidsområdet.

Skjermbilde som viser et skjermbilde av Access-ruten for arbeidsområdet. Den viser en tjenestekontohaverprofil med visningsnavnet Contoso som har administratortillatelse.

Slette en tjenestekontohaverprofil

Bruk REST-API-operasjonen sletting av profil til å slette en tjenestekontohaverprofil. Denne operasjonen kan bare kalles av overordnet tjenestekontohaver.

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

Hent alle tjenestekontohaverprofiler

Bruk REST-API-operasjonen Hent profiler til å hente en liste over tjenestekontohaverprofiler som tilhører tjenestekontohaveren for anropstjenesten. Denne operasjonen returnerer en JSON-nyttelast som inneholder id og displayName egenskapene til hver tjenestekontohaverprofil.

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

Utfør REST-API-kall ved hjelp av en tjenestekontohaverprofil

Det finnes to krav for å foreta REST-API-kall ved hjelp av en tjenestekontohaverprofil:

  • Du må sende tilgangstokenet for overordnet tjenestekontohaver i autorisasjonshodet .
  • Du må inkludere en topptekst med navnet X-PowerBI-profil-ID med verdien til tjenestekontohaverprofilens ID.

Hvis du bruker Power BI .NET SDK, kan du angi topptekstverdien for X-PowerBI-profil-ID eksplisitt ved å sende inn tjenestekontohaverprofilens ID.

// 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 eksemplet ovenfor, når du legger til toppteksten PowerBIClient X-PowerBI-profil-ID i objektet, er det enkelt å aktivere metoder, for eksempel , slik at Groups.GetGroupsde blir utført ved hjelp av tjenestekontohaverprofilen.

Det finnes en mer praktisk måte å angi X-PowerBI-profil-ID-toppteksten for et PowerBIClient objekt på. Du kan initialisere objektet ved å sende 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 program for multitenancy, er det sannsynlig at du må bytte mellom å utføre anrop som overordnet tjenestekontohaver og utføre anrop som en tjenestekontohaverprofil. En nyttig fremgangsmåte for å administrere kontekstbytte er å deklarere en klassenivåvariabel som lagrer PowerBIClient objektet. Deretter kan du opprette en hjelpemetode som angir variabelen med riktig 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 må opprette eller administrere en tjenestekontohaverprofil, kan du kalle SetCallingContext metoden uten parametere. På denne måten kan du opprette og administrere profiler ved hjelp av identiteten til tjenestekontohaveren.

// 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 må opprette og konfigurere et arbeidsområde for en ny kundeleier, vil du kjøre denne koden som en tjenestekontohaverprofil. Derfor bør du kalle SetCallingContext metoden ved å sende inn profilens ID. På denne måten kan du opprette arbeidsområdet ved hjelp av identiteten til tjenestekontohaverprofilen.

// 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 brukt en bestemt tjenestekontohaverprofil til å opprette og konfigurere et arbeidsområde, bør du fortsette å bruke den samme profilen til å opprette og konfigurere arbeidsområdeinnholdet. Det er ikke nødvendig å aktivere SetCallingContext metoden for å fullføre installasjonen.

Eksempel på utviklere

Vi oppfordrer deg til å laste ned et eksempelprogram kalt AppOwnsDataMultiTenant.

Dette eksempelprogrammet ble utviklet ved hjelp av .NET 6 og ASP.NET, og viser hvordan du bruker veiledningen og anbefalingene som er beskrevet i denne artikkelen. Du kan se gjennom koden for å lære hvordan du utvikler et program for multitenancy som implementerer Bygg inn for kundescenarioet ved hjelp av tjenestekontohaverprofiler.

Relatert innhold

Hvis du vil ha mer informasjon om denne artikkelen, kan du se følgende ressurser: