Dela via

Utveckla skalbara program för flera klientorganisationer med Power BI-inbäddning

  • Artikel

Den här artikeln beskriver hur du utvecklar ett program för flera innehavare som bäddar in Power BI-innehåll samtidigt som de högsta nivåerna av skalbarhet, prestanda och säkerhet uppnås. Genom att utforma och implementera ett program med profiler för tjänstens huvudnamn kan du skapa och hantera en lösning för flera innehavare som består av tiotusentals kundklientorganisationer som kan leverera rapporter till målgrupper med över 100 000 användare.

Profiler för tjänstens huvudnamn är en funktion som gör det enklare för dig att hantera organisationsinnehåll i Power BI och använda dina kapaciteter mer effektivt. Om du använder profiler för tjänstens huvudnamn kan du dock lägga till komplexitet i programdesignen. Därför bör du bara använda dem när det finns ett behov av att uppnå betydande skalning. Vi rekommenderar att du använder profiler för tjänstens huvudnamn när du har många arbetsytor och fler än 1 000 programanvändare.

Kommentar

Värdet för att använda profiler för tjänstens huvudnamn ökar när behovet av att skala ökar samt ditt behov av att uppnå de högsta nivåerna av säkerhet och klientisolering.

Du kan uppnå Power BI-inbäddning med hjälp av två olika inbäddningsscenarier: Bädda in för din organisation och Bädda in för din kund.

Scenariot Bädda in för din organisation gäller när programpubliken består av interna användare. Interna användare har organisationskonton och måste autentisera med Microsoft Entra-ID. I det här scenariot är Power BI saaS (software-as-a-service). Det kallas ibland användar äger data.

Scenariot Bädda in för din kund gäller när programpubliken består av externa användare. Programmet ansvarar för att autentisera användare. För att få åtkomst till Power BI-innehåll förlitar sig programmet på en inbäddningsidentitet (Microsoft Entra-tjänstens huvudnamn eller huvudanvändarkonto) för att autentisera med Microsoft Entra. I det här scenariot är Power BI paaS (platform-as-a-service). Det kallas ibland app äger data.

Kommentar

Det är viktigt att förstå att funktionen profiler för tjänstens huvudnamn har utformats för användning med scenariot Bädda in för din kund . Det beror på att det här scenariot ger ISV:er och företagsorganisationer möjlighet att bädda in med större skala till ett stort antal användare och till ett stort antal kundklientorganisationer.

Utveckling av program för flera klientorganisationer

Om du är bekant med Microsoft Entra kan ordet klientorganisation leda till att du tänker på en Microsoft Entra-klientorganisation. Begreppet klientorganisation skiljer sig dock åt när det gäller att skapa en lösning för flera klientorganisationer som bäddar in Power BI-innehåll. I det här sammanhanget skapas en kundklientorganisation för varje kund som programmet bäddar in Power BI-innehåll för med hjälp av scenariot Bädda in för kunden . Du etablerar vanligtvis varje kundklient genom att skapa en enda Power BI-arbetsyta.

Om du vill skapa en skalbar lösning för flera innehavare måste du kunna automatisera skapandet av nya kundklientorganisationer. Etablering av en ny kundklientorganisation innebär vanligtvis att skriva kod som använder Power BI REST API för att skapa en ny Power BI-arbetsyta, skapa semantiska modeller genom att importera Power BI Desktop-filer (.pbix), uppdatera datakällparametrar, ange autentiseringsuppgifter för datakälla och konfigurera schemalagd semantisk modelluppdatering. Följande diagram visar hur du kan lägga till Power BI-objekt, till exempel rapporter och semantiska modeller, till arbetsytor för att konfigurera kundklientorganisationer.

Diagram som visar en konfiguration för tre klienter. Varje klientorganisation har sin egen datakälla och arbetsyta.

När du utvecklar ett program som använder scenariot Bädda in för din kund är det möjligt att göra Power BI REST API-anrop med hjälp av en inbäddningsidentitet som antingen är ett huvudanvändarkonto eller ett huvudnamn för tjänsten. Vi rekommenderar att du använder tjänstens huvudnamn för produktionsprogram. Det ger högsta säkerhet och därför är det den metod som rekommenderas av Microsoft Entra. Dessutom har den stöd för bättre automatisering och skalning och det finns mindre hanteringskostnader. Det kräver dock Power BI-administratörsbehörighet för att konfigurera och hantera.

Genom att använda tjänstens huvudnamn kan du undvika vanliga problem som är associerade med huvudanvändarkonton, till exempel autentiseringsfel i miljöer där användare måste logga in med hjälp av multifaktorautentisering (MFA). Att använda ett huvudnamn för tjänsten stämmer också överens med tanken att scenariot Bädda in för din kund baseras på inbäddning av Power BI-innehåll med hjälp av ett PaaS-tänkesätt i stället för ett SaaS-tänkesätt.

Begränsning på 1 000 arbetsytor

När du utformar en miljö för flera klientorganisationer som implementerar scenariot Bädda in för kunden bör du tänka på att inbäddningsidentiteten inte kan beviljas åtkomst till fler än 1 000 arbetsytor. Den Power BI-tjänst inför den här begränsningen för att säkerställa bra prestanda när du gör REST API-anrop. Orsaken till den här begränsningen är relaterad till hur Power BI underhåller säkerhetsrelaterade metadata för varje identitet.

Power BI använder metadata för att spåra de arbetsytor och arbetsyteobjekt som en identitet kan komma åt. I själva verket måste Power BI ha en separat åtkomstkontrollista (ACL) för varje identitet i dess auktoriseringsundersystem. När en identitet gör ett REST API-anrop för att få åtkomst till en arbetsyta måste Power BI göra en säkerhetskontroll mot identitetens ACL för att säkerställa att den är auktoriserad. Den tid det tar att avgöra om målarbetsytan finns i ACL ökar exponentiellt när antalet arbetsytor ökar.

Kommentar

Power BI tillämpar inte begränsningen på 1 000 arbetsytor via kod. Om du försöker lägger du till en inbäddningsidentitet till fler än 1 000 arbetsytor, och REST API-anrop körs fortfarande. Ditt program övergår dock till ett tillstånd som inte stöds , vilket kan få konsekvenser om du försöker begära hjälp från Microsoft-supporten.

Tänk dig ett scenario där två program för flera klientorganisationer har konfigurerats för att använda ett enda huvudnamn för tjänsten. Tänk nu på att det första programmet har skapat 990 arbetsytor medan det andra programmet har skapat 1 010 arbetsytor. Ur ett supportperspektiv ligger det första programmet inom de gränser som stöds medan det andra programmet inte är det.

Jämför nu dessa två program enbart ur ett prestandaperspektiv. Det är inte så stor skillnad eftersom ACL:erna för båda tjänstens huvudnamn har gjort att metadata för deras ACL:er har utökats till en punkt där prestandan försämras till viss del.

Här är den viktigaste observationen: Antalet arbetsytor som skapats av ett huvudnamn för tjänsten har en direkt inverkan på prestanda och skalbarhet. Ett huvudnamn för tjänsten som är medlem i 100 arbetsytor kör REST API-anrop snabbare än ett huvudnamn för tjänsten som är medlem i 1 000 arbetsytor. På samma sätt kör ett huvudnamn för tjänsten som är medlem i endast 10 arbetsytor REST API-anrop snabbare än ett huvudnamn för tjänsten som är medlem i 100 arbetsytor.

Viktigt!

När det gäller prestanda och skalbarhet är det optimala antalet arbetsytor för vilka tjänstens huvudnamn är medlem exakt en.

Hantera isolering för semantiska modeller och autentiseringsuppgifter för datakälla

En annan viktig aspekt när du utformar ett program för flera klientorganisationer är att isolera kundklientorganisationer. Det är viktigt att användare från en kundklientorganisation inte ser data som tillhör en annan kundklientorganisation. Därför måste du förstå hur du hanterar semantisk modellägarskap och autentiseringsuppgifter för datakällan.

Semantisk modellägarskap

Varje Power BI-semantisk modell har en enda ägare, som kan vara antingen ett användarkonto eller ett huvudnamn för tjänsten. Semantisk modellägarskap krävs för att konfigurera schemalagd uppdatering och ange semantiska modellparametrar.

Dricks

I Power BI-tjänst kan du avgöra vem som äger semantikmodellen genom att öppna inställningarna för semantisk modell.

Om det behövs kan du överföra ägarskapet för den semantiska modellen till ett annat användarkonto eller tjänstens huvudnamn. Du kan göra det i Power BI-tjänst eller med hjälp av REST API-åtgärdenTakeOver. När du importerar en Power BI Desktop-fil för att skapa en ny semantisk modell med hjälp av tjänstens huvudnamn anges tjänstens huvudnamn automatiskt som semantisk modellägare.

Autentiseringsuppgifter för datakälla

Om du vill ansluta en semantisk modell till dess underliggande datakälla måste den semantiska modellägaren ange autentiseringsuppgifter för datakällan. Autentiseringsuppgifter för datakällor krypteras och cachelagras av Power BI. Från den tidpunkten använder Power BI dessa autentiseringsuppgifter för att autentisera med den underliggande datakällan när du uppdaterar data (för att importera lagringstabeller) eller köra genomströmningsfrågor (för DirectQuery-lagringstabeller).

Vi rekommenderar att du använder ett vanligt designmönster när du etablerar en ny kundklientorganisation. Du kan köra en serie REST API-anrop med hjälp av identiteten för tjänstens huvudnamn:

  1. Skapa en ny arbetsyta.
  2. Associera den nya arbetsytan med en dedikerad kapacitet.
  3. Importera en Power BI Desktop-fil för att skapa en semantisk modell.
  4. Ange autentiseringsuppgifterna för semantisk modellkälla för den semantiska modellen.

När dessa REST API-anrop har slutförts är tjänstens huvudnamn administratör för den nya arbetsytan och ägare till semantikmodellen och autentiseringsuppgifterna för datakällan.

Viktigt!

Det finns en vanlig missuppfattning om att semantiska modelldatakällans autentiseringsuppgifter är omfång på arbetsytenivå. Det är inte sant. Autentiseringsuppgifterna för datakällan är begränsade till tjänstens huvudnamn (eller användarkonto) och det omfånget sträcker sig till alla Power BI-arbetsytor i Microsoft Entra-klientorganisationen.

Det är möjligt för ett huvudnamn för tjänsten att skapa autentiseringsuppgifter för datakällan som delas av semantiska modeller på olika arbetsytor mellan kundklientorganisationer, enligt följande diagram.

Diagram som visar en konfiguration för två klienter. Varje klientorganisation delar samma autentiseringsuppgifter för datakällan.

När autentiseringsuppgifterna för datakällan delas av semantiska modeller som tillhör olika kundklientorganisationer är kundklienterna inte helt isolerade.

Designstrategier före profiler för tjänstens huvudnamn

Att förstå designstrategier innan profilfunktionen för tjänstens huvudnamn blev tillgänglig kan hjälpa dig att uppskatta behovet av funktionen. Innan dess skapade utvecklare program för flera klientorganisationer med någon av följande tre designstrategier:

  • Huvudnamn för enskild tjänst
  • Tjänsthuvudnamnspooler
  • Ett huvudnamn för tjänsten per arbetsyta

Det finns styrkor och svaghet som är associerade med var och en av dessa designstrategier.

Designstrategin för huvudnamn för den enskilda tjänsten kräver en engångsskapande av en Microsoft Entra-appregistrering. Därför innebär det mindre administrativa kostnader än de andra två designstrategierna eftersom det inte finns något krav på att skapa fler Microsoft Entra-appregistreringar. Den här strategin är också den enklaste att konfigurera eftersom den inte kräver att du skriver extra kod som växlar samtalskontexten mellan tjänstens huvudnamn när du gör REST API-anrop. Ett problem med den här designstrategin är dock att den inte skalas. Den stöder bara en miljö med flera innehavare som kan växa upp till 1 000 arbetsytor. Dessutom kommer prestandan att försämras eftersom tjänstens huvudnamn beviljas åtkomst till ett större antal arbetsytor. Det finns också ett problem med kundens klientisolering eftersom det enskilda tjänstens huvudnamn blir ägare till varje semantisk modell och alla autentiseringsuppgifter för data i alla kundklientorganisationer.

Designstrategin för pooler med tjänstens huvudnamn används ofta för att undvika begränsningen på 1 000 arbetsytor. Det gör att programmet kan skalas till valfritt antal arbetsytor genom att lägga till rätt antal tjänsthuvudnamn i poolen. En pool med fem huvudnamn för tjänsten gör det till exempel möjligt att skala upp till 5 000 arbetsytor. en pool med 80 huvudnamn för tjänsten gör det möjligt att skala upp till 80 000 arbetsytor och så vidare. Men även om den här strategin kan skalas till ett stort antal arbetsytor har den flera nackdelar. För det första kräver det att du skriver extra kod och lagrar metadata för att tillåta kontextväxling mellan tjänstens huvudnamn när du gör REST API-anrop. För det andra innebär det mer administrativt arbete eftersom du måste skapa Microsoft Entra-appregistreringar när du behöver öka antalet tjänsthuvudnamn i poolen.

Dessutom är poolstrategin för tjänstens huvudnamn inte optimerad för prestanda eftersom tjänstens huvudnamn kan bli medlemmar i hundratals arbetsytor. Det är inte heller idealiskt ur kundens klientisoleringsperspektiv eftersom tjänstens huvudnamn kan bli ägare till semantisk modell och dataautentiseringsuppgifter som delas mellan kundklientorganisationer.

Den enda designstrategin för tjänstens huvudnamn per arbetsyta innebär att skapa ett huvudnamn för tjänsten för varje kundklientorganisation. Ur ett teoretiskt perspektiv erbjuder den här strategin den bästa lösningen eftersom den optimerar prestandan för REST API-anrop samtidigt som den ger sann isolering för semantiska modeller och autentiseringsuppgifter för datakällor på arbetsytenivå. Men det som fungerar bäst i teorin fungerar inte alltid bäst i praktiken. Det beror på att kravet på att skapa ett huvudnamn för tjänsten för varje kundklientorganisation är opraktiskt för många organisationer. Det beror på att vissa organisationer har formella godkännandeprocesser eller att de innebär överdriven byråkrati för att skapa Microsoft Entra-appregistreringar. Dessa orsaker kan göra det omöjligt att bevilja ett anpassat program den auktoritet som krävs för att skapa Microsoft Entra-appregistreringar på begäran och på det automatiserade sätt som din lösning kräver.

I mindre vanliga scenarier där ett anpassat program har beviljats rätt behörigheter kan det använda Microsoft Graph API för att skapa Microsoft Entra-appregistreringar på begäran. Det anpassade programmet är dock ofta komplext att utveckla och distribuera eftersom det på något sätt måste spåra autentiseringsuppgifter för varje Microsoft Entra-appregistrering. Den måste också få åtkomst till dessa autentiseringsuppgifter när den behöver autentisera och hämta åtkomsttoken för enskilda tjänsthuvudnamn.

Profiler för tjänstens huvudnamn

Funktionen profiler för tjänstens huvudnamn har utformats för att göra det enklare för dig att hantera organisationsinnehåll i Power BI och använda dina kapaciteter mer effektivt. De hjälper dig att hantera tre specifika utmaningar som omfattar den lägsta mängden utvecklararbete och omkostnader. Dessa utmaningar omfattar:

  • Skala till ett stort antal arbetsytor.
  • Optimera prestanda för REST API-anrop.
  • Isolera semantiska modeller och autentiseringsuppgifter för datakällor på kundklientnivå.

När du utformar ett program för flera klientorganisationer med hjälp av profiler för tjänstens huvudnamn kan du dra nytta av fördelarna med de tre designstrategierna (beskrivs i föregående avsnitt) samtidigt som du undviker deras associerade svagheter.

Profiler för tjänstens huvudnamn är lokala konton som skapas inom ramen för Power BI. Ett huvudnamn för tjänsten kan använda Profiles REST API-åtgärden för att skapa nya profiler för tjänstens huvudnamn. Ett huvudnamn för tjänsten kan skapa och hantera en egen uppsättning tjänsthuvudnamnsprofiler för ett anpassat program, enligt följande diagram.

Diagram som visar ett huvudnamn för tjänsten som skapar tre profiler för tjänstens huvudnamn i Power BI.

Det finns alltid en överordnad-underordnad relation mellan tjänstens huvudnamn och de profiler för tjänstens huvudnamn som skapas. Du kan inte skapa en profil för tjänstens huvudnamn som en fristående entitet. I stället skapar du en profil för tjänstens huvudnamn med hjälp av ett specifikt huvudnamn för tjänsten och tjänstens huvudnamn fungerar som profilens överordnade. Dessutom är en profil för tjänstens huvudnamn aldrig synlig för användarkonton eller andra tjänsthuvudnamn. En profil för tjänstens huvudnamn kan bara visas och användas av tjänstens huvudnamn som skapade den.

Profiler för tjänstens huvudnamn är inte kända för Microsoft Entra

Tjänstens huvudnamn och dess underliggande Microsoft Entra-appregistrering är kända för Microsoft Entra, men Microsoft Entra ID vet ingenting om profiler för tjänstens huvudnamn. Det beror på att profiler för tjänstens huvudnamn skapas av Power BI och att de bara finns i Power BI-tjänst undersystem som styr Power BI-säkerhet och -auktorisering.

Det faktum att profiler för tjänstens huvudnamn inte är kända för Microsoft Entra-ID:t har både fördelar och nackdelar. Den främsta fördelen är att en Inbäddning för ditt kundscenarioprogram inte behöver några särskilda Microsoft Entra-behörigheter för att skapa profiler för tjänstens huvudnamn. Det innebär också att programmet kan skapa och hantera en uppsättning lokala identiteter som är separata från Microsoft Entra.

Det finns dock också nackdelar. Eftersom profiler för tjänstens huvudnamn inte är kända för Microsoft Entra kan du inte lägga till en profil för tjänstens huvudnamn i en Microsoft Entra-grupp för att implicit ge den åtkomst till en arbetsyta. Externa datakällor, till exempel en Azure SQL Database eller Azure Synapse Analytics, kan inte heller identifiera profiler för tjänstens huvudnamn som identitet vid anslutning till en databas. Därför kan designstrategin för ett huvudnamn för tjänsten per arbetsyta (skapa ett huvudnamn för tjänsten för varje kundklient) vara ett bättre val när det finns ett krav på att ansluta till dessa datakällor med hjälp av ett separat tjänsthuvudnamn med unika autentiseringsuppgifter för varje kundklientorganisation.

Profiler för tjänstens huvudnamn är förstklassiga säkerhetsobjekt

Även om tjänstens huvudnamnsprofiler inte är kända för Microsoft Entra, identifierar Power BI dem som förstklassiga säkerhetsobjekt. Precis som ett användarkonto eller ett huvudnamn för tjänsten kan du lägga till profiler för tjänstens huvudnamn i en arbetsyteroll (som administratör eller medlem). Du kan också göra den till en semantisk modellägare och ägare av autentiseringsuppgifter för datakällan. Därför är det bästa praxis att skapa en ny profil för tjänstens huvudnamn för varje ny kundklientorganisation.

Diagram som visar flera kundklientorganisationer, var och en med sina egna profiler för tjänstens huvudnamn.

Dricks

När du utvecklar en inbäddning för ditt kundscenarioprogram med hjälp av profiler för tjänstens huvudnamn behöver du bara skapa en enda Microsoft Entra-appregistrering för att ge ditt program ett enda huvudnamn för tjänsten. Den här metoden sänker avsevärt de administrativa kostnaderna jämfört med andra designstrategier för flera innehavare, där det är nödvändigt att skapa ytterligare Microsoft Entra-appregistreringar kontinuerligt efter att programmet har distribuerats till produktion.

Köra REST API-anrop som en profil för tjänstens huvudnamn

Ditt program kan köra REST API-anrop med hjälp av identiteten för en tjänsthuvudnamnsprofil. Det innebär att den kan köra en sekvens med REST API-anrop för att etablera och konfigurera en ny kundklientorganisation.

  1. När en profil för tjänstens huvudnamn skapar en ny arbetsyta lägger Power BI automatiskt till profilen som arbetsyteadministratör.
  2. När en profil för tjänstens huvudnamn importerar en Power BI Desktop-fil för att skapa en semantisk modell anger Power BI profilen som ägare av semantikmodellen.
  3. När en profil för tjänstens huvudnamn anger autentiseringsuppgifter för datakällan anger Power BI den profilen som ägare till autentiseringsuppgifterna för datakällan.

Det är viktigt att förstå att ett huvudnamn för tjänsten har en identitet i Power BI som är separat och skiljer sig från profilernas identiteter. Det ger dig valmöjligheter som utvecklare. Du kan köra REST API-anrop med hjälp av identiteten för en tjänsthuvudnamnsprofil. Du kan också köra REST API-anrop utan en profil, som använder identiteten för huvudnamnet för den överordnade tjänsten.

Vi rekommenderar att du kör REST API-anrop som huvudnamn för den överordnade tjänsten när du skapar, visar eller tar bort profiler för tjänstens huvudnamn. Du bör använda tjänstens huvudnamnsprofil för att köra alla andra REST API-anrop. Dessa andra anrop kan skapa arbetsytor, importera Power BI Desktop-filer, uppdatera semantiska modellparametrar och ange autentiseringsuppgifter för datakällan. De kan också hämta metadata för arbetsytans objekt och generera inbäddningstoken.

Tänk dig ett exempel där du behöver konfigurera en kundklientorganisation för en kund med namnet Contoso. Det första steget gör ett REST API-anrop för att skapa en profil för tjänstens huvudnamn med dess visningsnamn inställt på Contoso. Det här anropet görs med hjälp av identiteten för tjänstens huvudnamn. Alla återstående konfigurationssteg använder profilen för tjänstens huvudnamn för att utföra följande uppgifter:

  1. Skapa en arbetsyta.
  2. Associera arbetsytan med en kapacitet.
  3. Importera en Power BI Desktop-fil.
  4. Ange semantiska modellparametrar.
  5. Ange autentiseringsuppgifter för datakällan.
  6. Konfigurera schemalagd datauppdatering.

Det är viktigt att förstå att åtkomsten till arbetsytan och dess innehåll måste göras med hjälp av identiteten för tjänstens huvudnamnsprofil som användes för att skapa kundklientorganisationen. Det är också viktigt att förstå att huvudnamnet för den överordnade tjänsten inte behöver åtkomst till arbetsytan eller dess innehåll.

Dricks

Kom ihåg: När du gör REST API-anrop använder du tjänstens huvudnamn för att skapa och hantera profiler för tjänstens huvudnamn och använder profilen för tjänstens huvudnamn för att skapa, konfigurera och komma åt Power BI-innehåll.

Använda REST API-åtgärder för profiler

Rest API-åtgärdsgruppen Profiler består av åtgärder som skapar och hanterar profiler för tjänstens huvudnamn:

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

Skapa en profil för tjänstens huvudnamn

Använd rest-API-åtgärden Skapa profil för att skapa en profil för tjänstens huvudnamn. Du måste ange displayName egenskapen i begärandetexten för att ange ett visningsnamn för den nya klientorganisationen. Värdet måste vara unikt för alla profiler som ägs av tjänstens huvudnamn. Anropet misslyckas om det redan finns en annan profil med det visningsnamnet för tjänstens huvudnamn.

Ett lyckat anrop returnerar id egenskapen, som är ett GUID som representerar profilen. När du utvecklar program som använder profiler för tjänstens huvudnamn rekommenderar vi att du lagrar profilvisningsnamn och deras ID-värden i en anpassad databas. På så sätt är det enkelt för ditt program att hämta ID:t.

Om du programmerar med Power BI .NET SDK kan du använda Profiles.CreateProfile metoden som returnerar ett ServicePrincipalProfile objekt som representerar den nya profilen. Det gör det enkelt att fastställa egenskapsvärdet id .

Här är ett exempel på hur du skapar en profil för tjänstens huvudnamn och ger den åtkomst till arbetsytan.

// 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-tjänst i fönstret Åtkomst till arbetsyta kan du avgöra vilka identiteter, inklusive säkerhetsobjekt, som har åtkomst.

Skärmbild som visar en skärmbild av arbetsytans åtkomstfönster. Den visar en profil för tjänstens huvudnamn med visningsnamnet Contoso som har administratörsbehörighet.

Ta bort en profil för tjänstens huvudnamn

Använd REST API-åtgärden Ta bort profil för att ta bort en profil för tjänstens huvudnamn. Den här åtgärden kan bara anropas av huvudnamnet för den överordnade tjänsten.

Om du programmerar med Power BI .NET SDK kan du använda Profiles.DeleteProfile metoden.

Hämta alla profiler för tjänstens huvudnamn

Använd rest-API-åtgärden Hämta profiler för att hämta en lista över profiler för tjänstens huvudnamn som tillhör tjänstens huvudnamn. Den här åtgärden returnerar en JSON-nyttolast som innehåller id egenskaperna och displayName för varje profil för tjänstens huvudnamn.

Om du programmerar med Power BI .NET SDK kan du använda metoden Profiles.GetProfiles .

Köra REST API-anrop med hjälp av en profil för tjänstens huvudnamn

Det finns två krav för att göra REST API-anrop med hjälp av en tjänsthuvudnamnsprofil:

  • Du måste skicka åtkomsttoken för huvudnamnet för den överordnade tjänsten i auktoriseringshuvudet.
  • Du måste inkludera en rubrik med namnet X-PowerBI-profile-id med värdet för tjänstens huvudnamnsprofils ID.

Om du använder Power BI .NET SDK kan du ange huvudvärdet X-PowerBI-profile-id explicit genom att skicka in profilens ID för tjänstens huvudnamn.

// 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 du ser i exemplet ovan, när du lägger till rubriken X-PowerBI-profile-id i PowerBIClient objektet, är det enkelt att anropa metoder, till exempel Groups.GetGroups, så att de körs med hjälp av profilen för tjänstens huvudnamn.

Det finns ett enklare sätt att ange X-PowerBI-profile-id-huvudet för ett PowerBIClient objekt. Du kan initiera objektet genom att skicka profilens ID till konstruktorn.

// 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 programmerar ett program för flera klientorganisationer är det troligt att du måste växla mellan att köra anrop som huvudnamn för den överordnade tjänsten och köra anrop som en profil för tjänstens huvudnamn. En användbar metod för att hantera kontextväxling är att deklarera en variabel på klassnivå som lagrar PowerBIClient objektet. Du kan sedan skapa en hjälpmetod som anger variabeln med rätt 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 behöver skapa eller hantera en profil för tjänstens huvudnamn kan du anropa SetCallingContext metoden utan några parametrar. På så sätt kan du skapa och hantera profiler med hjälp av tjänstens huvudnamns identitet.

// 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 behöver skapa och konfigurera en arbetsyta för en ny kundklientorganisation vill du köra koden som en profil för tjänstens huvudnamn. Därför bör du anropa SetCallingContext metoden genom att skicka in profilens ID. På så sätt kan du skapa arbetsytan med hjälp av identiteten för tjänstens huvudnamnsprofil.

// 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 använt en specifik profil för tjänstens huvudnamn för att skapa och konfigurera en arbetsyta bör du fortsätta att använda samma profil för att skapa och konfigurera arbetsytans innehåll. Du behöver inte anropa SetCallingContext metoden för att slutföra installationen.

Exempel på utvecklare

Vi rekommenderar att du laddar ned ett exempelprogram med namnet AppOwnsDataMultiTenant.

Det här exempelprogrammet har utvecklats med hjälp av .NET 6 och ASP.NET och visar hur du använder vägledningen och rekommendationerna som beskrivs i den här artikeln. Du kan granska koden för att lära dig hur du utvecklar ett program för flera klientorganisationer som implementerar scenariot Bädda in för kunden med hjälp av profiler för tjänstens huvudnamn.

Relaterat innehåll

Mer information om den här artikeln finns i följande resurser: