Profily služebního objektu pro víceklientské aplikace v Power BI Embedded

Tento článek vysvětluje, jak ISV nebo jiný vlastník aplikace Power BI Embedded s mnoha zákazníky může používat profily instančních objektů ke zmapování a správě dat jednotlivých zákazníků jako součást svého řešení Power BI embed pro vaše zákazníky. Profily služby principal umožňují ISV vytvářet škálovatelné aplikace, které umožňují lepší izolaci zákaznických dat a stanovují užší hranice zabezpečení mezi zákazníky. Tento článek popisuje výhody a omezení tohoto řešení.

Profil služebního principálu je profil vytvořený služebním principálem. ISV aplikace volá Power BI API pomocí profilu služby principal, jak je popsáno v tomto článku.

Instanční objekt služby aplikace ISV vytvoří pro každého zákazníka nebo nájemce jiný profil Power BI. Když zákazník navštíví aplikaci ISV, aplikace použije odpovídající profil k vygenerování tokenu pro vložení, který se použije k vykreslení sestavy v prohlížeči.

Použití profilů služebních objektů umožňuje aplikaci ISV hostovat více zákazníků na jediném tenantu Power BI. Každý profil představuje jednoho zákazníka v Power BI. Jinými slovy, každý profil vytváří a spravuje obsah Power BI pro data jednoho konkrétního zákazníka.

Nastavení obsahu Power BI zahrnuje následující kroky:

• Vytvoření profilu
• Nastavení oprávnění profilu
• Vytvoření pracovního prostoru pro každého zákazníka
• Import sestav a sémantických modelů do pracovního prostoru
• Nastavení podrobností připojení k sémantickému modelu pro připojení k datům zákazníka
• Odebrat oprávnění ze služebního principálu (volitelné, ale pomáhá se škálovatelností)
• Vložte sestavu do aplikace

Všechny výše uvedené kroky je možné plně automatizovat pomocí rozhraní REST API Power BI.

Požadavky

Než budete moct vytvořit profily aplikační identity, musíte:

• Instanční objekt nastavte podle prvních tří krokůvložení obsahu Power BI s instančním objektem.
• Z účtu správce tenanta Power BI povolte vytváření profilů v tenantovi pomocí stejné skupiny zabezpečení, kterou jste použili při vytváření služebního principála.

Vytvoření profilu

Profily je možné vytvářet, aktualizovat a odstraňovat pomocí rozhraní REST API profilů.

Pokud například chcete vytvořit 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"}

Instanční objekt může také volat rozhraní REST API profilů GET, aby získal seznam svých profilů. Příklad:

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

Oprávnění profilu

Jakékoli rozhraní API, které uděluje uživateli oprávnění k položkám Power BI, může také udělit oprávnění profilu k položkám Power BI. Například můžete použít Přidat Group User API k udělení oprávnění profilu pracovnímu prostoru.

Při používání profilů je důležité porozumět následujícím bodům:

• Profil patří k instančnímu objektu, který ho vytvořil, a může ho používat pouze tento instanční objekt.
• Vlastník profilu se po vytvoření nedá změnit.
• Profil není samostatná identita. Potřebuje token služby Microsoft Entra k volání rozhraní Power BI REST API.

Aplikace nezávislých výrobců softwaru volají rozhraní Power BI REST API tím, že poskytují token hlavního objektu služby Microsoft Entra v hlavičce Authorization a ID profilu v hlavičce X-PowerBI-Profile-Id. Příklad:

  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

Vytvoření pracovního prostoru

Pracovní prostory Power BI slouží k hostování položek Power BI, jako jsou sestavy a sémantické modely.

Každý profil musí:

• Vytvoření aspoň jednoho pracovního prostoru Power BI

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

• Udělte pracovnímu prostoru přístupová oprávnění . Profil služebního principálu musí mít přístup správce k pracovnímu prostoru.

• Přiřazení pracovního prostoru ke kapacitě

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

Přečtěte si další informace o pracovních prostorech Power BI.

Import sestav a sémantických modelů

Pomocí Power BI Desktopu můžete připravit sestavy, které jsou připojené k datům zákazníka nebo ukázkovým datům. Pak můžete pomocí rozhraní API importu importovat obsah do vytvořeného pracovního prostoru.

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=

Pomocí parametrů datové sady vytvořte sémantický model, který se může připojit k různým zdrojům dat zákazníků. Pak použijte API Aktualizovat parametry k definování, ke kterým datům zákazníků se sémantický model připojuje.

Nastavení sémantického připojení modelu

Nezávislí výrobci softwaru obvykle ukládají data svých zákazníků jedním ze dvou způsobů:

• Samostatná databáze pro každého zákazníka
• Jedna víceklientová databáze

V obou případech byste v Power BI měli mít sémantické modely s jednoho tenanta (jeden sémantický model na zákazníka).

Samostatná databáze pro každého zákazníka

Pokud má aplikace ISV samostatnou databázi pro každého zákazníka, vytvořte v Power BI sémantické modely s jedním tenantem. Zadejte každý sémantický model s podrobnostmi o připojení, které odkazují na odpovídající databázi. Pomocí jedné z následujících metod se vyhněte vytváření více identických sestav s různými podrobnostmi připojení:

• Parametry sémantického modelu: Vytvořte sémantický model s parametry v podrobnostech o připojení (například název serveru SQL, název databáze SQL). Potom naimportujte sestavu do pracovního prostoru zákazníka a změňte parametry tak, aby odpovídaly podrobnostem databáze zákazníka.

• Aktualizace rozhraní API zdroje dat: Vytvořte soubor .pbix, který odkazuje na zdroj dat s ukázkovým obsahem. Potom importujte soubor .pbix do pracovního prostoru zákazníka a změňte podrobnosti připojení pomocí Update Datasource API.

Jedna víceklientová databáze

Pokud aplikace isV používá jednu databázi pro všechny své zákazníky, oddělte zákazníky do různých sémantických modelů v Power BI následujícím způsobem:

Vytvořte sestavu pomocí parametrů , které načítají jenom relevantní data zákazníka. Potom naimportujte sestavu do pracovního prostoru zákazníka a změňte parametry tak, aby načítaly pouze data relevantního zákazníka.

Vložte sestavu

Po dokončení nastavení můžete do aplikace vložit sestavy zákazníků a další položky pomocí vložného tokenu.

Když zákazník navštíví vaši aplikaci, použijte odpovídající profil k volání rozhraní GenerateToken API. Vygenerovaný token pro vložení použijte k vložení sestavy nebo jiných položek v prohlížeči zákazníka.

Generování tokenu pro vložení:

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

Aspekty návrhu

Před nastavením víceklientských řešení založených na profilu byste měli vědět o následujících problémech:

• Škálovatelnost
• Automatizace a provozní složitost
• Potřeby multi-Geo
• Nákladová efektivita
• Zabezpečení na úrovni řádků

Škálovatelnost

Rozdělením dat do samostatných sémantických modelů pro každého zákazníka minimalizujete potřebu velkých sémantických modelů. Když se kapacita přetíží, může vyřadit nepoužité sémantické modely, aby uvolnila paměť pro aktivní sémantické modely. Tato optimalizace není pro jeden velký sémantický model možný. Pomocí několika sémantických modelů můžete v případě potřeby také tenanty oddělit do několika kapacit Power BI.

Bez profilů je servisní účet omezen na 1 000 pracovních prostorů. Aby byl tento limit překonán, může služba principal vytvořit více profilů, kde každý profil může přistupovat k až 1 000 pracovním prostorům nebo je vytvářet. Díky více profilům může aplikace ISV izolovat obsah jednotlivých zákazníků pomocí jedinečných logických kontejnerů.

Jakmile má profil služebního principálu přístup k pracovnímu prostoru, poté lze přístup nadřazeného služebního principálu k pracovnímu prostoru odebrat, aby nedocházelo k problémům se škálovatelností.

I s těmito výhodami byste měli zvážit potenciální škálování vaší aplikace. Například počet položek pracovního prostoru, ke které má profil přístup, je omezený. V současné chvíli má profil stejné limity jako běžný uživatel. Pokud aplikace nezávislých výrobců softwaru umožňuje koncovým uživatelům uložit přizpůsobenou kopii svých vložených sestav, bude mít profil zákazníka přístup ke všem vytvořeným sestavám všech jeho uživatelů. Tento model může nakonec překročit limit.

Automatizace a provozní složitost

V případě oddělení založeného na profilu Power BI možná budete muset spravovat stovky nebo tisíce položek. Proto je důležité definovat procesy, ke kterým často dochází ve správě životního cyklu aplikace, a zajistit, abyste měli správnou sadu nástrojů pro tyto operace ve velkém měřítku. Mezi tyto operace patří:

• Přidání nového tenanta
• Aktualizace sestavy pro některé nebo všechny nájemce
• Aktualizace schématu sémantického modelu pro některé nebo všechny tenanty
• Neplánovaná přizpůsobení pro konkrétní tenanty
• Frekvence sémantických aktualizací modelu

Například vytvoření profilu a pracovního prostoru pro nového tenanta je běžnou úlohou, která se dá plně automatizovat pomocí rozhraní REST API Power BI.

Potřeby Multi-Geo

Podpora funkce Multi-Geo pro Power BI Embedded znamená, že nezávislí výrobci softwaru a organizace vytvářející aplikace využívající Power BI Embedded k vložení analýz do svých aplikací teď můžou nasadit svá data v různých oblastech po celém světě. Pokud chcete podporovat různé zákazníky v různých oblastech, přiřaďte pracovní prostor zákazníka ke kapacitě v požadované oblasti. Tento úkol je jednoduchá operace, která nezahrnuje další náklady. Pokud ale máte zákazníky, kteří potřebují data z více oblastí, profil tenanta by měl duplikovat všechny položky do více pracovních prostorů, které jsou přiřazené k různým oblastním kapacitám. Tato duplicita může zvýšit složitost nákladů i správy.

Z důvodů dodržování předpisů můžete stále chtít vytvořit několik tenantů Power BI v různých oblastech. Přečtěte si další informace o multi-geo.

Nákladová efektivita

Vývojáři aplikací, kteří používají Power BI Embedded, potřebují zakoupit kapacitu Power BI Embedded. Model oddělení založený na profilu funguje dobře s kapacitami, protože:

• Nejmenší objekt, který můžete nezávisle přiřadit ke kapacitě, je pracovní prostor (například nemůžete přiřadit sestavu). Oddělením zákazníků podle profilů získáte různé pracovní prostory – jeden na zákazníka. Díky tomu získáte plnou flexibilitu při správě jednotlivých zákazníků v závislosti na jejich požadavcích na výkon a optimalizujete využití kapacity vertikálním navýšením nebo snížením kapacity. Můžete například spravovat velké a důležité zákazníky s velkým objemem a nestálostí v samostatné kapacitě, abyste zajistili konzistentní úroveň služeb a zároveň seskupili menší zákazníky do jiné kapacity za účelem optimalizace nákladů.

• Oddělení pracovních prostorů také znamená oddělení sémantických modelů mezi tenanty, aby datové modely byly v menších blocích, nikoli v jednom velkém sémantickém modelu. Tyto menší modely umožňují kapacitu efektivněji spravovat využití paměti. Malé, nepoužité sémantické modely je možné vyřadit po určité době nečinnosti, aby se zachoval dobrý výkon.

Při nákupu kapacity zvažte limit počtu paralelních aktualizací, protože procesy aktualizace můžou potřebovat dodatečnou kapacitu, pokud máte více sémantických modelů.

Zabezpečení na úrovni řádků

Tento článek vysvětluje, jak pomocí profilů vytvořit samostatný sémantický model pro každého zákazníka. Aplikace nezávislých výrobců softwaru můžou také ukládat všechna data svých zákazníků do jednoho velkého sémantického modelu a k ochraně dat jednotlivých zákazníků použít zabezpečení na úrovni řádků (RLS ). Tento přístup může být vhodný pro nezávislé výrobce softwaru, kteří mají relativně málo zákazníků a malých až středně velkých sémantických modelů, protože:

• Existuje pouze jedna sestava a jeden sémantický model, který je potřeba udržovat.
• Proces onboardingu pro nové zákazníky je možné zjednodušit.

Před použitím RLS se ale ujistěte, že rozumíte jeho omezením. Všechna data pro všechny zákazníky jsou v jednom velkém sémantickém modelu Power BI. Tento sémantický model běží v jedné kapacitě s vlastním škálováním a dalšími omezeními.

I když používáte profily instančních objektů k oddělení dat svých zákazníků, můžete ve sémantickém modelu jednoho zákazníka stále použít RLS (zabezpečení na úrovni řádků) k tomu, abyste různým skupinám umožnili přístup k různým částem dat. Pomocí RLS můžete například zabránit členům jednoho oddělení v přístupu k datům jiného oddělení ve stejné organizaci.

Úvahy a omezení

• Profily služebního principu jsou podporovány pouze prostřednictvím rozhraní Power BI REST API, sady Power BI .NET SDK, a také přes koncový bod XMLA a tabulkový objektový model (TOM), když se používají klientské knihovny služby Analysis Services ve verzi 16.0.139.27 nebo vyšší. Profily hlavní služby nejsou v Power BI podporovány prostřednictvím koncového bodu XMLA nebo modelu tabulárních objektů (TOM) se staršími klientskými knihovnami.
• Profily hlavních služeb se u služby Azure Analysis Services (AAS) v režimu živého připojení nepodporují.
• Maximální počet profilů, které může mít jeden klient služeb, je 100 000.

Omezení kapacity Power BI

• Každá kapacita může podle zakoupené skladové položky používat pouze přidělenou paměť a virtuální jádra. Pro doporučenou velikost sémantického modelu pro každou SKU nahlédněte do Velké sémantické modely Premium.
• Pokud chcete použít sémantický model větší než 10 GB, použijte kapacitu Premium a povolte nastavení velkých sémantických modelů .
• Počet aktualizací, které se dají spustit souběžně na kapacitě, najdete v referenčních informacích ke správě prostředků a optimalizaci.

Správa servisních principálů

Změna servisního principálu

V Power BI profil patří service principal, který ho vytvořil. To znamená, že profil nemůže být sdílen s jinými hlavními uživateli. S tímto omezením, pokud chcete z nějakého důvodu změnit služební účet, budete muset znovu vytvořit všechny profily a poskytnout novým profilům přístup k příslušným pracovním prostorům. Aplikace ISV často potřebuje uložit mapování mezi ID profilu a ID zákazníka, aby v případě potřeby vybrala správný profil. Pokud změníte služební principál a znovu vytvoříte profily, ID se také změní a možná budete muset aktualizovat mapování v databázi ISV aplikace.

Odstranit objekt služby

Pokud odstraníte hlavní službu v adresáři Active Directory, odstraní se všechny její profily v Power BI. Power BI ale obsah neodstraní okamžitě, takže správce tenanta bude mít přístup k pracovním prostorům. Při odstraňování instančního objektu používaného v produkčním systému buďte opatrní, zejména při vytváření profilů pomocí tohoto instančního objektu v Power BI. Pokud odstraníte služební hlavní objekt, který vytvořil profily, mějte na paměti, že budete muset znovu vytvořit všechny profily, poskytnout novým profilům přístup k příslušným pracovním prostorům a aktualizovat ID profilů v databázi aplikací nezávislých výrobců softwaru.

Oddělení dat

Když jsou data oddělená profily instančních objektů, jednoduché mapování mezi profilem a zákazníkem brání jednomu zákazníkovi v zobrazení obsahu jiného zákazníka. Použití jednoho instančního objektu vyžaduje, aby instanční objekt získal přístup ke všem různým pracovním prostorům ve všech profilech.

Pokud chcete přidat další oddělení, přiřaďte každému tenantovi samostatný systémový identifikátor, místo abyste používali jeden systémový identifikátor pro přístup k více pracovním prostorům s různými profily. Přiřazení samostatných služebních účtů má několik výhod, mezi které patří:

• Chyba člověka nebo únik přihlašovacích údajů nezpůsobí zveřejnění dat více tenantů.
• Obměně certifikátů je možné provádět zvlášť pro každého tenanta.

Použití více služebních účtů však přináší vysoké náklady na správu. Tuto cestu vyberte pouze v případě, že potřebujete další oddělení. Mějte na paměti, že konfigurace dat, která se mají zobrazit koncovému uživateli, je definována při generování tokenu pro vložení, což je back-endový proces, který koncoví uživatelé nemůžou zobrazit nebo změnit. Vyžádání tokenu pro vložení pomocí profilu specifického pro tenanta vygeneruje token pro vložení pro tento konkrétní profil, který vám poskytne oddělení zákazníků ve spotřebě.

Jeden výkaz, několik sémantických modelů

Obecně platí, že máte jednu sestavu a jeden sémantický model na nájemce. Pokud máte stovky sestav, budete mít stovky sémantických modelů. Někdy můžete mít jeden formát zprávy s různými sémantickými modely (například různé parametry nebo podrobnosti připojení). Pokaždé, když budete mít novou verzi reportu, budete muset aktualizovat všechny reporty pro všechny tenanty. I když to můžete automatizovat, je jednodušší ji spravovat, pokud máte jenom jednu kopii sestavy. Vytvořte pracovní prostor, který obsahuje sestavu pro vložení. Během běhu relace připojte sestavu k sémantickému modelu, který je specifický pro nájemce. Další podrobnosti najdete v dynamických vazbách .

Přizpůsobení a vytváření obsahu

Při vytváření obsahu pečlivě zvažte, kdo má oprávnění ho upravovat. Pokud v každém tenantovi povolíte úpravy více uživatelů, je snadné překročit sémantická omezení modelu. Pokud se rozhodnete uživatelům poskytnout možnosti úprav, pečlivě sledujte jejich generování obsahu a podle potřeby vertikálně navyšte kapacitu. Ze stejného důvodu nedoporučujeme tuto funkci používat pro přizpůsobení obsahu, kde každý uživatel může provádět malé změny v sestavě a ukládat ji pro sebe. Pokud aplikace ISV umožňuje přizpůsobení obsahu, zvažte zavedení zásad uchovávání informací o pracovním prostoru pro obsah specifický pro uživatele. Zásady uchovávání informací usnadňují odstranění obsahu, když se uživatelé přesunou na novou pozici, opustí společnost nebo přestanou používat platformu.

Identita spravovaná systémem

Místo aplikačního objektu můžete k vytvoření profilů použít uživatelsky přiřazenou nebo systémově přiřazenou spravovanou identitu. Spravované identity snižují potřebu tajných kódů a certifikátů.

Při použití identity spravované systémem buďte opatrní, protože:

• Pokud je spravovaná identita přiřazená systémem omylem vypnutá, ztratíte přístup k profilům. Tato situace se podobá případu, kdy je odstraněn service principal.
• Spravovaná identita přiřazená systémem je připojená k prostředku v Azure (webová aplikace). Pokud odstraníte prostředek, bude odstraněna i identita.
• Použití více prostředků (různých webových aplikací v různých oblastech) bude mít za následek několik identit, které je potřeba spravovat samostatně (každá identita bude mít vlastní profily).

Vzhledem k výše uvedeným aspektům doporučujeme použít spravovanou identitu přiřazenou uživatelem.

Příklad

Příklad, jak používat profily aplikačních identit ke správě multitenantních prostředí s pomocí Power BI a vkládání dat pomocí App-Owns-Data, najdete v úložišti App owns data multitenant, které si můžete stáhnout z webu Power BI Dev Camp (stránka třetí strany).

Související obsah

• Použití sady Power BI SDK s instančními objekty
• Přenos víceklientských aplikací do modelu profilů entitního objektu služby
• Vývoj škálovatelných víceklientských aplikací pomocí vkládání Power BI