Dela via

Tjänsthuvudnamnsprofiler för appar med flera klientorganisationer i Power BI Embedded

  • Artikel

Den här artikeln beskriver hur en ISV eller någon annan Power BI Embedded-appägare med många kunder kan använda profiler för tjänstens huvudnamn för att mappa och hantera varje kunds data som en del av deras Power BI-inbäddning för dina kunders lösning. Med profiler för tjänstens huvudnamn kan ISV skapa skalbara program som möjliggör bättre isolering av kunddata och upprättar strängare säkerhetsgränser mellan kunder. I den här artikeln beskrivs fördelarna och begränsningarna med den här lösningen.

Kommentar

Ordet klientorganisation i Power BI kan ibland referera till en Microsoft Entra-klientorganisation. I den här artikeln använder vi dock termen multitenancy för att beskriva en lösning där en enda instans av ett program hanterar flera kunder eller organisationer (klienter) som kräver fysisk och logisk uppdelning av data. Power BI-appverktyget kan till exempel allokera en separat arbetsyta för var och en av sina kunder (eller klienter) som vi visar nedan. Dessa kunder är inte nödvändigtvis Microsoft Entra-klienter, så förväxla inte termen multitenantprogram som vi använder här med Microsoft Entra-programmet för flera klienter.

En profil för tjänstens huvudnamn är en profil som skapats av ett huvudnamn för tjänsten. ISV-appen anropar Power BI-API:erna med hjälp av en profil för tjänstens huvudnamn, enligt beskrivningen i den här artikeln.

TJÄNSTEN ISV-tjänstens huvudnamn skapar en annan Power BI-profil för varje kund eller klientorganisation. När en kund besöker ISV-appen använder appen motsvarande profil för att generera en inbäddningstoken som ska användas för att återge en rapport i webbläsaren.

Med hjälp av profiler för tjänstens huvudnamn kan ISV-appen vara värd för flera kunder i en enda Power BI-klientorganisation. Varje profil representerar en kund i Power BI. Med andra ord skapar och hanterar varje profil Power BI-innehåll för en specifik kunds data.

Diagram över SP-profiler och flera klientorganisationer.

Kommentar

Den här artikeln riktar sig till organisationer som vill konfigurera en app för flera klientorganisationer med hjälp av profiler för tjänstens huvudnamn. Om din organisation redan har en app som stöder flera klientorganisationer och du vill migrera till profilmodellen för tjänstens huvudnamn läser du Migrera till profilmodellen för tjänstens huvudnamn.

När du konfigurerar Ditt Power BI-innehåll ingår följande steg:

Alla ovanstående steg kan automatiseras helt med hjälp av Power BI REST-API:er.

Förutsättningar

Innan du kan skapa profiler för tjänstens huvudnamn måste du:

  • Konfigurera tjänstens huvudnamn genom att följa de tre första stegen i Bädda in Power BI-innehåll med tjänstens huvudnamn.
  • Från ett administratörskonto för Power BI-klientorganisationen aktiverar du skapandet av profiler i klientorganisationen med samma säkerhetsgrupp som du använde när du skapade tjänstens huvudnamn.

Skärmbild av administratörsportalväxeln.

Skapa en profil

Profiler kan skapas, uppdateras och tas bort med hjälp av PROFILER REST API.

Om du till exempel vill skapa 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"}

Ett huvudnamn för tjänsten kan också anropa REST API för GET-profiler för att hämta en lista över dess profiler. Till exempel:

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

Profilbehörigheter

Alla API:er som ger en användare behörighet till Power BI-objekt kan också ge en profilbehörighet till Power BI-objekt. Du kan till exempel använda API :et Lägg till gruppanvändare för att bevilja en profilbehörighet till en arbetsyta.

Följande punkter är viktiga att förstå när du använder profiler:

  • En profil tillhör tjänstens huvudnamn som skapade den och kan endast användas av tjänstens huvudnamn.
  • Det går inte att ändra en profilägare när den har skapats.
  • En profil är inte en fristående identitet. Tjänstens huvudnamn för Microsoft Entra-token krävs för att anropa Power BI REST-API:er.

ISV-appar anropar Power BI REST-API:er genom att ange tjänstens huvudnamn Microsoft Entra-token i auktoriseringshuvudet och profil-ID:t i rubriken X-PowerBI-Profile-Id . Till exempel:

  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

Skapa en arbetsyta

Power BI-arbetsytor används för att vara värd för Power BI-objekt som rapporter och semantiska modeller.

Varje profil måste:

  • Skapa minst en Power BI-arbetsyta

    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"
}

  • Bevilja åtkomstbehörigheter till arbetsytan. Profilen för tjänstens huvudnamn måste ha administratörsåtkomst till arbetsytan.

  • Tilldela arbetsytan till en kapacitet

    POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/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"
}

Läs mer om Power BI-arbetsytor.

Importera rapporter och semantiska modeller

Använd Power BI Desktop för att förbereda rapporter som är anslutna till kundens data eller exempeldata. Sedan kan du använda import-API:et för att importera innehållet till den skapade arbetsytan.

POST https://api.powerbi.com/v1.0/myorg/groups/f313e682-c86b-422c-a3e2-b1a05426c4a3/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=

Använd datauppsättningsparametrar för att skapa en semantisk modell som kan ansluta till olika kunders datakällor. Använd sedan API:et För uppdateringsparametrar för att definiera vilka kunders data som semantikmodellen ansluter till.

Ange semantisk modellanslutning

ISV:er lagrar vanligtvis sina kunders data på något av två sätt:

I båda fallen bör du få semantiska modeller med en enda klientorganisation (en semantisk modell per kund) i Power BI.

En separat databas för varje kund

Om ISV-programmet har en separat databas för varje kund skapar du semantiska modeller för en klientorganisation i Power BI. Ange varje semantisk modell med anslutningsinformation som pekar på dess matchande databas. Använd någon av följande metoder för att undvika att skapa flera identiska rapporter med olika anslutningsinformation:

  • Semantiska modellparametrar: Skapa en semantisk modell med parametrar i anslutningsinformationen (till exempel SQL-servernamn, SQL-databasnamn). Importera sedan en rapport till en kunds arbetsyta och ändra parametrarna så att de matchar kundens databasinformation.

  • Uppdatera Datasource API: Skapa en .pbix som pekar på en datakälla med exempelinnehåll. Importera sedan .pbix till en kunds arbetsyta och ändra anslutningsinformationen med api:et Uppdatera datakälla.

En enskild databas med flera klientorganisationer

Om ISV-programmet använder en databas för alla sina kunder, separerar du kunderna i olika semantiska modeller i Power BI på följande sätt:

Skapa en rapport med parametrar som bara hämtar relevant kunds data. Importera sedan en rapport till en kunds arbetsyta och ändra parametrarna för att endast hämta relevant kunds data.

Bädda in en rapport

När installationen är klar kan du bädda in kundrapporter och andra objekt i ditt program med hjälp av en inbäddningstoken.

När en kund besöker ditt program använder du motsvarande profil för att anropa GenerateToken-API:et. Använd den genererade inbäddningstoken för att bädda in en rapport eller andra objekt i kundens webbläsare.

Så här genererar du en inbäddningstoken:

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"
    }
  ]
}

Designaspekter

Innan du konfigurerar en profilbaserad lösning för flera klienter bör du vara medveten om följande problem:

Skalbarhet

Genom att separera data i separata semantiska modeller för varje kund minimerar du behovet av stora semantiska modeller. När kapaciteten överbelastas kan den avlägsna oanvända semantiska modeller för att frigöra minne för aktiva semantiska modeller. Den här optimeringen är omöjlig för en enda stor semantisk modell. Genom att använda flera semantiska modeller kan du också separera klienter i flera Power BI-kapaciteter om det behövs.

Utan profiler är tjänstens huvudnamn begränsat till 1 000 arbetsytor. För att övervinna den här gränsen kan ett huvudnamn för tjänsten skapa flera profiler, där varje profil kan komma åt/skapa upp till 1 000 arbetsytor. Med flera profiler kan ISV-appen isolera varje kunds innehåll med hjälp av distinkta logiska containrar.

När en profil för tjänstens huvudnamn har åtkomst till en arbetsyta kan dess överordnade tjänsthuvudnamns åtkomst till arbetsytan tas bort för att undvika skalbarhetsproblem.

Även med dessa fördelar bör du överväga programmets potentiella skala. Till exempel är antalet arbetsyteobjekt som en profil kan komma åt begränsat. Idag har en profil samma gränser som en vanlig användare. Om ISV-programmet tillåter slutanvändare att spara en anpassad kopia av sina inbäddade rapporter, har en kunds profil åtkomst till alla skapade rapporter för alla sina användare. Den här modellen kan så småningom överskrida gränsen.

Automatisering och driftskomplexitet

Med profilbaserad separation i Power BI kan du behöva hantera hundratals eller tusentals objekt. Därför är det viktigt att definiera de processer som ofta inträffar i programmets livscykelhantering och se till att du har rätt uppsättning verktyg för att utföra dessa åtgärder i stor skala. Några av dessa åtgärder är:

  • Lägga till en ny klientorganisation
  • Uppdatera en rapport för vissa eller alla klienter
  • Uppdatera semantikmodellschemat för vissa eller alla klienter
  • Oplanerade anpassningar för specifika klienter
  • Frekvens för uppdateringar av semantisk modell

Att till exempel skapa en profil och en arbetsyta för en ny klientorganisation är en vanlig uppgift som kan automatiseras helt med Power BI REST API.

Multi-Geo-behov

Multi-Geo-stöd för Power BI Embedded innebär att ISV:er och organisationer som skapar program med Hjälp av Power BI Embedded för att bädda in analys i sina appar nu kan distribuera sina data i olika regioner runt om i världen. Om du vill stödja olika kunder i olika regioner tilldelar du kundens arbetsyta till en kapacitet i önskad region. Den här uppgiften är en enkel åtgärd som inte medför extra kostnad. Men om du har kunder som behöver data från flera regioner bör klientprofilen duplicera alla objekt till flera arbetsytor som har tilldelats till olika regionala kapaciteter. Den här dupliceringen kan öka både kostnads- och hanteringskomplexiteten.

Av efterlevnadsskäl kanske du fortfarande vill skapa flera Power BI-klienter i olika regioner. Läs mer om multi-geo.

Kostnadseffektivitet

Programutvecklare som använder Power BI Embedded måste köpa en Power BI Embedded-kapacitet. Den profilbaserade separationsmodellen fungerar bra med kapaciteter eftersom:

  • Det minsta objekt som du kan tilldela oberoende till en kapacitet är en arbetsyta (du kan till exempel inte tilldela en rapport). Genom att separera kunder efter profiler får du olika arbetsytor – en per kund. På så sätt får du fullständig flexibilitet att hantera varje kund efter deras prestandabehov och optimera kapacitetsutnyttjandet genom att skala upp eller ned. Du kan till exempel hantera stora och viktiga kunder med hög volym och volatilitet i en separat kapacitet för att säkerställa en konsekvent servicenivå, samtidigt som du grupperar mindre kunder i en annan kapacitet för att optimera kostnaderna.

  • Att separera arbetsytor innebär också att separera semantiska modeller mellan klientorganisationer så att datamodeller finns i mindre segment i stället för en enda stor semantisk modell. Dessa mindre modeller gör det möjligt för kapaciteten att hantera minnesanvändningen mer effektivt. Små, oanvända semantiska modeller kan avlägsnas efter en period av inaktivitet, för att upprätthålla goda prestanda.

När du köper en kapacitet bör du överväga gränsen för antalet parallella uppdateringar, eftersom uppdateringsprocesser kan behöva extra kapacitet när du har flera semantiska modeller.

Säkerhet på radnivå

Den här artikeln beskriver hur du använder profiler för att skapa en separat semantisk modell för varje kund. Alternativt kan ISV-program lagra alla sina kunders data i en stor semantisk modell och använda säkerhet på radnivå (RLS) för att skydda varje kunds data. Den här metoden kan vara praktisk för ISV:er som har relativt få kunder och små till medelstora semantiska modeller eftersom:

  • Det finns bara en rapport och en semantisk modell att underhålla
  • Registreringsprocessen för nya kunder kan förenklas

Innan du använder RLS bör du dock se till att du förstår dess begränsningar. Alla data för alla kunder finns i en stor Power BI-semantisk modell. Den här semantiska modellen körs i en enda kapacitet med egen skalning och andra begränsningar.

Även om du använder profiler för tjänstens huvudnamn för att separera dina kunders data kan du fortfarande använda RLS i en enskild kunds semantiska modell för att ge olika grupper åtkomst till olika delar av data. Du kan till exempel använda RLS för att förhindra att medlemmar i en avdelning kommer åt data från en annan avdelning i samma organisation.

Beaktanden och begränsningar

  • Tjänstens huvudnamnprofiler stöds endast via Power BI REST API, Power BI .NET SDK och via XMLA-slutpunkten och tabellobjektmodellen (TOM) när du använder Analysis Services-klientbibliotek version 16.0.139.27 eller senare. Tjänstens huvudnamnprofiler stöds inte i Power BI via XMLA-slutpunkten eller TOM (Tabular Object Model) med äldre klientbibliotek.
  • Profiler för tjänstens huvudnamn stöds inte med Azure Analysis Services (AAS) i liveanslutningsläge.
  • Det maximala antalet profiler som ett enda huvudnamn för tjänsten kan ha är 100 000.

Kapacitetsbegränsningar för Power BI

Hantera tjänstens huvudnamn

Ändra tjänstens huvudnamn

I Power BI tillhör en profil tjänstens huvudnamn som skapade den. Det innebär att en profil inte kan delas med andra huvudnamn. Om du vill ändra tjänstens huvudnamn av någon anledning måste du återskapa alla profiler och ge de nya profilerna åtkomst till relevanta arbetsytor. Ofta måste ISV-programmet spara en mappning mellan ett profil-ID och ett kund-ID för att kunna välja rätt profil när det behövs. Om du ändrar tjänstens huvudnamn och återskapar profilerna ändras även ID:t och du kan behöva uppdatera mappningen i ISV-programdatabasen.

Ta bort ett huvudnamn för tjänsten

Varning

Var mycket försiktig när du tar bort ett huvudnamn för tjänsten. Du vill inte oavsiktligt förlora data från alla dess associerade profiler.

Om du tar bort tjänstens huvudnamn i active directory tas alla dess profiler i Power BI bort. Power BI tar dock inte bort innehållet omedelbart, så klientadministratören kan fortfarande komma åt arbetsytorna. Var försiktig när du tar bort ett huvudnamn för tjänsten som används i ett produktionssystem, särskilt när du har skapat profiler med tjänstens huvudnamn i Power BI. Om du tar bort ett huvudnamn för tjänsten som har skapat profiler måste du återskapa alla profiler, ge de nya profilerna åtkomst till relevanta arbetsytor och uppdatera profil-ID:n i ISV-programdatabasen.

Dataavgränsning

När data avgränsas med profiler för tjänstens huvudnamn hindrar en enkel mappning mellan en profil och kund en kund från att se en annan kunds innehåll. Att använda ett enda huvudnamn för tjänsten kräver att tjänstens huvudnamn har åtkomst till alla olika arbetsytor i alla profiler.

Om du vill lägga till extra separation tilldelar du ett separat huvudnamn för tjänsten till varje klientorganisation, i stället för att ha ett enda huvudnamn för tjänsten som har åtkomst till flera arbetsytor med olika profiler. Att tilldela separata tjänsthuvudnamn har flera fördelar, bland annat:

  • Mänskliga fel eller en läcka av autentiseringsuppgifter gör inte att flera klientorganisationers data exponeras.
  • Certifikatrotation kan göras separat för varje klientorganisation.

Men att använda flera tjänsthuvudnamn medför en hög hanteringskostnad. Välj endast den här sökvägen om du behöver den extra separationen. Tänk på att konfigurationen av vilka data som ska visa en slutanvändare definieras när du genererar inbäddningstoken, en process endast för serverdelen som slutanvändarna inte kan se eller ändra. Om du begär en inbäddningstoken med hjälp av en klientspecifik profil genereras en inbäddningstoken för den specifika profilen, vilket ger dig kundseparation i förbrukning.

En rapport, flera semantiska modeller

I allmänhet har du en rapport och en semantisk modell per klientorganisation. Om du har hundratals rapporter har du hundratals semantiska modeller. Ibland kan du ha ett rapportformat med olika semantiska modeller (till exempel olika parametrar eller anslutningsinformation). Varje gång du har en ny version av rapporten måste du uppdatera alla rapporter för alla klienter. Även om du kan automatisera detta är det enklare att hantera om du bara har en kopia av rapporten. Skapa en arbetsyta som innehåller rapporten som ska bäddas in. Under en sessionskörning binder du rapporten till den klientspecifika semantiska modellen. Läs dynamiska bindningar för mer information.

Anpassa och redigera innehåll

När du skapar innehåll bör du noga överväga vem som har behörighet att redigera det. Om du tillåter att flera användare i varje klientorganisation redigerar är det enkelt att överskrida begränsningarna för semantisk modell. Om du bestämmer dig för att ge användarna redigeringsfunktioner kan du övervaka deras innehållsgenerering noggrant och skala upp efter behov. Av samma anledning rekommenderar vi inte att du använder den här funktionen för innehållsanpassning, där varje användare kan göra små ändringar i en rapport och spara den själva. Om ISV-programmet tillåter innehållsanpassning kan du överväga att införa kvarhållningsprinciper för arbetsytor för användarspecifikt innehåll. Kvarhållningsprinciper gör det enklare att ta bort innehåll när användare flyttar till en ny position, lämnar företaget eller slutar använda plattformen.

Systemhanterad identitet

I stället för tjänstens huvudnamn kan du använda en användartilldelad eller systemtilldelad hanteradidentitet för att skapa profiler. Hanterade identiteter minskar behovet av hemligheter och certifikat.

Var försiktig när du använder en systemhanterad identitet eftersom:

  • Om en systemtilldelad hanterad identitet inaktiveras av misstag förlorar du åtkomsten till profilerna. Den här situationen liknar ett fall där ett huvudnamn för tjänsten tas bort.
  • En systemtilldelad hanterad identitet är ansluten till en resurs i Azure (webbapp). Om du tar bort resursen tas identiteten bort.
  • Om du använder flera resurser (olika webbappar i olika regioner) resulterar det i flera identiteter som måste hanteras separat (varje identitet har egna profiler).

På grund av ovanstående överväganden rekommenderar vi att du använder en användartilldelad hanterad identitet.

Exempel

Om du vill ha ett exempel på hur du använder profiler för tjänstens huvudnamn för att hantera en miljö med flera klienter med Power BI och inbäddning av App-Owns-Data kan du ladda ned appens lagringsplats för flera klientorganisationer från Power BI Dev Camp (tredje parts webbplats).

Relaterat innehåll