Konfigurer tjenestekontohaverprofiler for programmer for fleretenancy

Denne artikkelen forklarer hvordan du konfigurerer og bruker tjenestekontohaverprofiler etter at du har valgt dem for en Power BI Embedded innebygging for kundenes løsning. Profiler støtter innholdsadministrasjon med kundeomfang og et stort antall arbeidsområder. Kundeseparasjon avhenger av riktig programruting, arbeidsområdetillatelser og nødvendige innebyggingstokener. profiler oppretter ikke en uavhengig Microsoft Entra identitet eller en kryptografisk kundegrense.

Merk

For nye løsninger for multitenancy starter du med dedikerte kundeservicekontohavere, ved hjelp av administrert identitet og forbundslegitimasjon der verts- og klareringskravene passer. Profiler forblir en gyldig, valgfri løsning for nye og eksisterende programmer med krav som passer deres fordeler og begrensninger. Du kan fortsette å bruke profiler hvis de oppfyller kravene dine.

Profiler er ikke Microsoft Entra identiteter og kan ikke brukes med Fabric REST-API-er. Hvis løsningen krever kundeidentiteter for nedstrømstjenester, uavhengige Microsoft Entra påloggingslogger, arbeidsbelastningsidentitet betinget tilgang eller funksjoner som ellers er begrenset av profilmodellen, bør du vurdere å erstatte tjenestekontohaverprofiler med tjenestekontohavere.

Merk

Ordet tenant i Power BI kan noen ganger referere til en Microsoft Entra-leier. I denne artikkelen bruker vi imidlertid begrepet multitenancy til å beskrive en løsning der en enkelt forekomst av et program betjener flere kunder eller organisasjoner (leiere) som krever fysisk og logisk fordeling av data. Power BI-appbyggeren kan for eksempel tildele et eget arbeidsområde for hver av sine kunder (eller leiere) som vi diskuterer i denne artikkelen. Disse kundene er ikke nødvendigvis Microsoft Entra-leiere, så ikke forveksle begrepet multitenant program som vi bruker her, med Microsoft Entra multitenant-programmet.

En tjenestekontohaverprofil er en profil opprettet av en tjenestekontohaver. ISV-appen kaller Power BI-API s ved hjelp av en tjenestekontohaverprofil, som forklart i denne artikkelen.

Isv-programtjenestekontohaveren oppretter en annen Power BI-profil for hver kunde eller leier. Når en kunde besøker ISV-appen, bruker appen den tilsvarende profilen til å generere et innebyggingstoken som brukes til å gjengi en rapport i nettleseren.

Ved hjelp av tjenestekontohaverprofiler kan ISV-appen være vert for flere kunder på én enkelt Power BI-leier. Hver profil representerer én kunde i Power BI. Med andre ord oppretter og administrerer hver profil Power BI-innhold for én bestemt kundes data.

Diagram over tjenestekontohaverprofiler og multitenancy.

Merk

Hvis du vil ha en oversikt over dette alternativet, kan du se Tjenestekontohaverprofiler: En valgfri løsning for multitenancy. Følgende konfigurasjonstrinn gjelder etter at du har valgt profilmodellen.

Konfigurasjon av Power BI-innhold omfatter følgende fremgangsmåte:

Alle trinnene ovenfor kan automatiseres ved hjelp av REST-API-er for Power BI.

Forutsetning

Før du kan opprette tjenestekontohaverprofiler, må du:

Skjermbilde av bryteren for administrasjonsportalen.

Opprett en profil

Profiler kan opprettes, oppdateres og slettes ved hjelp av REST-API-en for profiler.

Hvis du for eksempel vil opprette en profil:

POST https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…UUPA
Content-Type: application/json; charset=utf-8

{"displayName":"ContosoProfile"}

En tjenestekontohaver kan også kalle GET Profiles REST API for å få en liste over profilene. Eksempel:

GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA

Profiltillatelser

Alle API-er som gir en brukertillatelse til Power BI-elementer, kan også gi en profiltillatelse til Power BI-elementer. API for legg til gruppebruker kan for eksempel brukes til å gi en profiltillatelse til et arbeidsområde.

Følgende punkter er viktige å forstå når du bruker profiler:

  • En profil tilhører tjenestekontohaveren som opprettet den, og bare den tjenestekontohaveren kan bruke den.
  • En profileier kan ikke endres etter oppretting.
  • En profil er ikke en frittstående identitet. Det trenger tjenestekontohaveren Microsoft Entra-token for å kalle Power BI REST API-er.

ISV-apper kaller Power BI REST-API-er ved å gi tjenestekontohaveren Microsoft Entra-token i autorisasjonshodet og profil-ID-en i toppteksten X-PowerBI-Profile-ID . Eksempel:

  GET https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
  Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUz.....SXBwasfg
  X-PowerBI-Profile-Id: 5f1aa5ed-5983-46b5-bd05-999581d361a5

Opprette et arbeidsområde

Power BI-arbeidsområder brukes til å være vert for Power BI-elementer som rapporter og semantiske modeller.

Hver profil må:

  • Opprett minst ett Power BI-arbeidsområde 

    POST https://api.powerbi.com/v1.0/myorg/groups HTTP/1.1
Authorization: Bearer eyJ0eXA…ZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "name": "ContosoWorkspace"
}

  • Gi tilgangstillatelser til arbeidsområdet. Tjenestekontohaverprofilen må ha administratortilgang til arbeidsområdet.

  • Tilordne arbeidsområdet til en kapasitet

    POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/AssignToCapacity HTTP/1.1
Authorization: Bearer eyJ0eXAiOiJK…wNkZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "capacityId": "13f73071-d6d3-4d44-b9de-34590f3e3cf6"
}

Les mer om Power BI-arbeidsområder.

Importere rapporter og semantiske modeller

Bruk Power BI Desktop til å klargjøre rapporter som er koblet til kundens data eller eksempeldata. Deretter kan du bruke import-API-en til å importere innholdet til det opprettede arbeidsområdet.

POST https://api.powerbi.com/v1.0/myorg/groups/aaaabbbb-0000-cccc-1111-dddd2222eeee/imports?datasetDisplayName=ContosoSales HTTP/1.1
Authorization: Bearer eyJ...kZUiIsg
Content-Type: multipart/form-data; boundary="8b071895-b380-4769-9c62-7e586d717ed7"
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306
Fiddler-Encoding: base64

LS04YjA3MTg5NS1iMzgwLTQ3...Tg2ZDcxN2VkNy0tDQo=

Bruk datasettparametere til å opprette en semantisk modell som kan koble til ulike kunders datakilder. Bruk deretter API-en for oppdateringsparametere til å definere hvilke kunders data den semantiske modellen kobler til.

Angi semantisk modelltilkobling

ISV-er lagrer vanligvis kundenes data på én av to måter:

I begge tilfeller bør du ende opp med semantiske modeller med én leier (én semantisk modell per kunde) i Power BI.

En separat database for hver kunde

Hvis ISV-programmet har en egen database for hver kunde, oppretter du semantiske modeller for én leier i Power BI. Gi hver semantisk modell tilkoblingsdetaljer som peker til den samsvarende databasen. Bruk én av følgende metoder for å unngå å opprette flere identiske rapporter med ulike tilkoblingsdetaljer:

  • Semantiske modellparametere: Opprett en semantisk modell med parametere i tilkoblingsdetaljene (for eksempel SQL Server-navn, SQL-databasenavn). Deretter importerer du en rapport til kundens arbeidsområde og endrer parameterne slik at de samsvarer med kundens databasedetaljer.

  • Oppdater API-en for datakilde: Opprett en PBIX som peker til en datakilde med eksempelinnhold. Deretter importerer du PBIX-en til kundens arbeidsområde og endrer tilkoblingsdetaljene ved hjelp av API-en Oppdater datakilde.

Én enkelt flertenant database

Hvis ISV-programmet bruker én database for alle sine kunder, skiller du kundene i forskjellige semantiske modeller i Power BI på følgende måte:

Opprett en rapport ved hjelp av parametere som bare henter de relevante kundens data. Deretter importerer du en rapport til kundens arbeidsområde og endrer parameterne for å hente bare den aktuelle kundens data.

Bygge inn en rapport

Når installasjonen er fullført, kan du bygge inn kunderapporter og andre elementer i programmet ved hjelp av et innebyggingstoken.

Når en kunde besøker programmet, kan du bruke den tilsvarende profilen til å kalle GenerateToken-API-en. Bruk det genererte innebyggingstokenet til å bygge inn en rapport eller andre elementer i kundens nettleser.

Slik genererer du et innebyggingstoken:

POST https://api.powerbi.com/v1.0/myorg/GenerateToken HTTP/1.1
Authorization: Bearer eyJ0eXAiOi…kZUiIsg
Content-Type: application/json; charset=utf-8
X-PowerBI-Profile-Id: a4df5235-6f18-4141-9e99-0c3512f41306

{
  "datasets": [
    {
      "id": "3b1c8f74-fbbe-45e0-bf9d-19fce69262e3"
    }
  ],
  "reports": [
    {
      "id": "3d474b89-f2d5-43a2-a436-d24a6eb2dc8f"
    }
  ]
}

Utform aspekter

Før du konfigurerer en profilbasert flertenantløsning, bør du være oppmerksom på følgende problemer:

Skalerbarhet

Ved å skille dataene i separate semantiske modeller for hver kunde minimerer du behovet for store semantiske modeller. Når kapasiteten blir overbelastet, kan den kaste ut ubrukte semantiske modeller for å frigjøre minne for aktive semantiske modeller. Denne optimaliseringen er umulig for en enkelt stor semantisk modell. Ved å bruke flere semantiske modeller kan du også skille leiere i flere Power BI-kapasiteter om nødvendig.

Uten profiler er en tjenestekontohaver begrenset til 1000 arbeidsområder. Hvis du vil overvinne denne grensen, kan en tjenestekontohaver opprette flere profiler, der hver profil kan få tilgang til/opprette opptil 1000 arbeidsområder. Med flere profiler kan ISV-appen isolere hver kundes innhold ved hjelp av distinkte logiske beholdere.

Når en tjenestekontohaverprofil har tilgang til et arbeidsområde, kan den overordnede tjenestekontohaverens tilgang til arbeidsområdet fjernes for å unngå skalerbarhetsproblemer.

Selv med disse fordelene bør du vurdere den potensielle omfanget av programmet. Antallet arbeidsområdeelementer en profil kan få tilgang til, er for eksempel begrenset. I dag har en profil de samme grensene som en vanlig bruker. Hvis ISV-programmet tillater sluttbrukere å lagre en personlig kopi av de innebygde rapportene, har en kundeprofil tilgang til alle de opprettede rapportene til alle brukerne. Denne modellen kan etter hvert overskride grensen.

Automatisering og driftskompleksitet

Med profilbasert separasjon i Power BI må du kanskje administrere hundrevis eller tusenvis av elementer. Derfor er det viktig å definere prosessene som ofte skjer i programmets livssyklusbehandling, og sikre at du har riktig sett med verktøy for å utføre disse operasjonene i stor skala. Noen av disse operasjonene omfatter:

  • Legge til en ny leier
  • Oppdatere en rapport for noen eller alle leiere
  • Oppdatere det semantiske modellskjemaet for noen eller alle leiere
  • Aktivere ikke-planlagte tilpassinger for bestemte leiere
  • Angi hyppigheten for semantiske modelloppdateringer

Oppretting av en profil og et arbeidsområde for en ny leier er for eksempel en vanlig oppgave, som kan automatiseres fullstendig med REST-API-en for Power BI.

Multi-Geo-behov

Multi-Geo-støtte for Power BI Embedded betyr at ISV-er og organisasjoner som bygger programmer ved hjelp av Power BI Embedded for å bygge inn analyser i appene sine, nå kan distribuere dataene sine i forskjellige områder rundt om i verden. Hvis du vil støtte ulike kunder i forskjellige områder, tilordner du kundens arbeidsområde til en kapasitet i ønsket område. Denne aktiviteten er en enkel operasjon som ikke innebærer ekstra kostnader. Hvis du imidlertid har kunder som trenger data fra flere områder, bør leierprofilen duplisere alle elementer i flere arbeidsområder som er tilordnet ulike regionale kapasiteter. Denne dupliseringen kan øke både kostnads- og administrasjonskompleksiteten.

Av samsvarsårsaker vil du kanskje fortsatt opprette flere Power BI-leiere i forskjellige områder. Les mer om multi-geo.

Kostnadseffektivitet

Programutviklere som bruker Power BI Embedded, må kjøpe en Power BI Embedded-kapasitet. Den profilbaserte separasjonsmodellen fungerer bra med kapasiteter fordi:

  • Det minste objektet du uavhengig kan tilordne til en kapasitet, er et arbeidsområde (du kan for eksempel ikke tilordne en rapport). Ved å skille kunder etter profiler får du forskjellige arbeidsområder – én per kunde. På denne måten får du full fleksibilitet til å administrere hver kunde i henhold til deres ytelsesbehov, og optimalisere kapasitetsutnyttelsen ved å skalere opp eller ned. Du kan for eksempel administrere store og viktige kunder med høyt volum og volatilitet i en egen kapasitet for å sikre et konsekvent servicenivå, samtidig som du grupperer mindre kunder i en annen kapasitet for å optimalisere kostnadene.

  • Skille arbeidsområder betyr også å skille semantiske modeller mellom leiere slik at datamodeller er i mindre deler, i stedet for en enkelt stor semantisk modell. Disse mindre modellene gjør det mulig å administrere minnebruken mer effektivt. Små, ubrukte semantiske modeller kan utestenges etter en periode med inaktivitet, for å opprettholde god ytelse.

Når du kjøper en kapasitet, bør du vurdere grensen for antall parallelle oppdateringer, da oppdateringsprosesser kan trenge ekstra kapasitet når du har flere semantiske modeller.

Sikkerhet på radnivå

Denne artikkelen forklarer hvordan du bruker profiler til å opprette en egen semantisk modell for hver kunde. Alternativt kan ISV-programmer lagre alle kundenes data i én stor semantisk modell og bruke sikkerhet på radnivå (RLS) for å beskytte hver kundes data. Denne tilnærmingen kan være praktisk for uavhengige programvareleverandører som har relativt få kunder og små og mellomstore semantiske modeller fordi:

  • De trenger bare å vedlikeholde én rapport og én semantisk modell
  • Pålastingsprosessen for nye kunder kan forenkles

Før du bruker RLS, må du imidlertid sørge for at du forstår begrensningene. Alle dataene for alle kunder er i én stor Semantisk Power BI-modell. Denne semantiske modellen kjører i én enkelt kapasitet med egen skalering og andre begrensninger.

Selv om du bruker tjenestekontohaverprofiler til å skille kundenes data, kan du fortsatt bruke RLS i en enkelt kundes semantiske modell for å gi forskjellige grupper tilgang til ulike deler av dataene. Du kan for eksempel bruke RLS til å hindre at medlemmer av én avdeling får tilgang til data fra en annen avdeling i samme organisasjon.

Hensyn og begrensninger

Evaluer identitets-, API- og skalagrensene før du velger eller utvider profilmodellen.

Begrensninger for identitet og API

Se gjennom disse begrensningene før du tar i bruk profiler eller utvider en eksisterende profilbasert løsning:

Begrensning Hva det betyr for løsningen
Ikke en Microsoft Entra identitet En profil finnes bare i Power BI. Du kan ikke uavhengig styre eller se gjennom det gjennom Microsoft Entra verktøy, eller gi tillatelser som identitet i nedstrømstjenester. En profil kan for eksempel ikke være identiteten til en Direct Lake-tilkobling fra en semantisk modell til et lakehouse eller lager.
Ingen støtte for Fabric REST-API Profiler fungerer gjennom Power BI REST API, Power BI .NET SDK og støttede XMLA/TOM-grensesnitt. Fabric REST-API-er støtter dem ikke, og støtte er ikke planlagt.
Ingen uavhengig påloggingsidentitet Operasjoner med profilomfang produserer ikke uavhengige per kunde-Microsoft Entra påloggingsposter. Power BI aktivitetslogger kan fortsatt identifisere profiler.
Ingen betinget tilgang per profil En profil er ikke en hovedstol som arbeidsbelastningsidentiteten Betinget tilgang kan målrette mot. Policyer for kvalifiserte dedikerte tjenestekontohavere har separate lisensierings- og konfigurasjonskrav.
Bundet til oppretterkontohaver Du kan ikke overføre profiler mellom overordnede tjenestekontohavere. Hvis du endrer den overordnede, må du gjenopprette profiler, gjenopprette tilgang til arbeidsområdet og oppdatere kundetilordninger.
Administrasjon kun for API Profiler har ingen dedikert administrasjonsgrensesnitt for å undersøke og administrere dem. De er ikke representert i Microsoft Entra administrasjonssenter.

Hvis disse begrensningene begrenser løsningen, kan du se Erstatte tjenestekontohaverprofiler med tjenestekontohavere. For kunder som velger å overføre, anbefaler denne veiledningen administrert identitet og forbundslegitimasjon der verts- og klareringskravene passer. Direkte tjenestekontohavergodkjenning er fortsatt et alternativ.

Støttede grensesnitt og skalagrenser

  • Tjenestekontohaverprofiler støttes bare gjennom REST-API-en for Power BI, Power BI .NET SDK og gjennom XMLA-endepunktet og tabellobjektmodellen (TOM) når du bruker Analysis Services-klientbiblioteker versjon 16.0.139.27 eller nyere. Tjenestekontohaverprofiler støttes ikke i Power BI gjennom XMLA-endepunktet eller tabellobjektmodellen (TOM) med eldre klientbiblioteker.
  • Tjenestekontohaverprofiler støttes ikke med Azure Analysis Services (AAS) i live-tilkoblingsmodus.
  • Den maksimale profilen en enkelt tjenestekontohaver kan ha, er 100 000.

Kapasitetsbegrensninger for Power BI

Administrere tjenestekontohavere

Endre en tjenestekontohaver

I Power BI tilhører en profil tjenestekontohaveren som opprettet den. Det betyr at en profil ikke kan deles med andre hovedstoler. Med denne begrensningen, hvis du vil endre tjenestekontohaveren av en eller annen grunn, må du gjenopprette alle profilene og gi de nye profilene tilgang til de relevante arbeidsområdene. Isv-programmet må ofte lagre en tilordning mellom en profil-ID og en kunde-ID for å kunne velge riktig profil ved behov. Hvis du endrer tjenestekontohaveren og oppretter profilene på nytt, endres også ID-ene, og du må kanskje oppdatere tilordningen i ISV-programdatabasen.

Slette en tjenestekontohaver

Advarsel!

Vær forsiktig når du sletter en tjenestekontohaver. Du vil ikke ved et uhell miste data fra alle tilknyttede profiler.

Hvis du sletter tjenestekontohaveren i active directory, slettes alle profilene i Power BI. Power BI sletter imidlertid ikke innholdet umiddelbart, så leieradministratoren kan fortsatt få tilgang til arbeidsområdene. Vær forsiktig når du sletter en tjenestekontohaver som brukes i et produksjonssystem, spesielt når du opprettet profiler ved hjelp av denne tjenestekontohaveren i Power BI. Hvis du sletter en tjenestekontohaver som har opprettet profiler, må du gjenopprette alle profilene, gi de nye profilene tilgang til de relevante arbeidsområdene og oppdatere profil-ID-ene i ISV-programdatabasen.

Dataseparasjon

Når du bruker tjenestekontohaverprofiler, må programmet tilordne hver godkjente kunde til riktig profil og tillatte ressurser. Arbeidsområdetillatelser og nødvendige innebyggingstokener håndhever tilgang. En profil er ikke en uavhengig Microsoft Entra identitet, og den overordnede tjenestekontohaveren kan handle gjennom hvilken som helst profil den oppretter.

Vurder dedikerte tjenestekontohavere når løsningen krever Microsoft Entra styring, uavhengig påloggingsovervåking, kvalifiserte arbeidsbelastningsidentitetspolicyer for betinget tilgang, nedstrøms tjenesteidentiteter eller Fabric REST-API-tilgang. De er også et alternativ når profil-til-foreldre-kobling eller API-administrasjon bare skaper driftsproblemer. Hvis profiler oppfyller kravene dine, kan du fortsette å bruke dem.

Dedikerte tjenestekontohavere lar deg administrere kundetillatelser og godkjenning uavhengig av hverandre. Hvis du bruker lagrede sertifikater, kan du rotere dem separat for hver kunde. Virkningen av en legitimasjonslekkasje eller kjøretidskompromiss avhenger imidlertid av hvilken kundelegitimasjon eller klareringer som kjøretid kan bruke. Ingen arkitektur garanterer automatisk isolasjon på tvers av kunder.

Administrasjon av dedikerte identiteter introduserer begrensninger for katalogobjekter og livssyklusarbeid. Evaluer disse avveiningene, og følg Erstatt tjenestekontohaverprofiler med tjenestekontohavere hvis du velger å overføre. Behold konfigurasjonen av hvilke data som skal vises som sluttbruker i serverdelen når du genererer innebyggingstokenet. Valider kundemedlemskap før du velger en identitet, et arbeidsområde eller innhold.

Én rapport, flere semantiske modeller

Vanligvis har du én rapport og én semantisk modell per leier. Hvis du har hundrevis av rapporter, har du hundrevis av semantiske modeller. Noen ganger kan det hende du har ett rapportformat, med ulike semantiske modeller (for eksempel forskjellige parametere eller tilkoblingsdetaljer). Hver gang du har en ny versjon av rapporten, må du oppdatere alle rapportene for alle leiere. Selv om du kan automatisere denne prosessen, er det enklere å administrere hvis du bare har én kopi av rapporten. Opprett et arbeidsområde som inneholder rapporten som skal bygges inn. Under en øktkjøring binder du rapporten til den leierspesifikke semantiske modellen. Les dynamiske bindinger for mer informasjon.

Tilpasse og redigere innhold

Når du oppretter innhold, bør du vurdere hvem som har tillatelse til å redigere det. Hvis du tillater flere brukere i hver leier å redigere, er det enkelt å overskride semantiske modellbegrensninger. Hvis du bestemmer deg for å gi brukerne redigeringsfunksjonalitet, kan du overvåke innholdsgenereringen nøye og skalere opp etter behov. Av samme grunn anbefaler vi ikke å bruke denne funksjonen for innholdstilpassing, der hver bruker kan gjøre små endringer i en rapport og lagre den for seg selv. Hvis ISV-programmet tillater innholdstilpassing, bør du vurdere å innføre policyer for oppbevaring av arbeidsområder for brukerspesifikkt innhold. Oppbevaringspolicyer gjør det enklere å slette innhold når brukere flytter til en ny stilling, forlater firmaet eller slutter å bruke plattformen.

Systemadministrert identitet

I stedet for en tjenestekontohaver kan du bruke en brukertilordet eller systemtilordetadministrert identitet til å opprette profiler. Administrerte identiteter reduserer behovet for hemmeligheter og sertifikater.

Merk

En administrert identitet som oppretter og bruker profiler, gjør ikke disse profilene om til Microsoft Entra identiteter eller aktiverer bruken med Fabric REST-API-er. Denne betingelsen skiller seg fra å bruke administrert identitet og legitimasjon i forbund til å godkjennes som dedikerte kundeservicekontohavere. Se Erstatt tjenestekontohaverprofiler med tjenestekontohavere.

Vær forsiktig når du bruker en systemadministrert identitet fordi:

  • Hvis en systemtilknyttet administrert identitet ved et uhell er deaktivert, mister du tilgangen til profilene. Denne situasjonen ligner på en sak der en tjenestekontohaver slettes.
  • En systemtildelt administrert identitet er koblet til en ressurs i Azure (nettapp). Hvis du sletter ressursen, slettes også identiteten.
  • Bruk av flere ressurser (forskjellige nettapper i forskjellige områder) resulterer i flere identiteter som må administreres separat (hver identitet har sine egne profiler).

På grunn av de ovennevnte vurderingene anbefaler vi at du bruker en brukertilordet administrert identitet.

Eksempel

Hvis du vil ha et eksempel på hvordan du bruker tjenestekontohaverprofiler til å administrere et flertenantmiljø med Innebygging av Power BI og App-Owns-Data, kan du laste ned appen som eier datarepositoriet for flere enheter fra Power BI Dev Camp (tredjeparts nettsted).

Relatert innhold

  • Sist oppdatert