Profily instančního objektu pro víceklientské aplikace v Power BI Embedded

  • Článek

Tento článek vysvětluje, jak poskytovatel softwaru nebo jiný vlastník aplikace Power BI Embedded s mnoha zákazníky může pomocí profilů instančních objektů namapovat a spravovat data jednotlivých zákazníků jako součást jejich vkládání do Power BI pro vaše řešení zákazníků . Profily instančních objektů umožňují isV vytvářet škálovatelné aplikace, které umožňují lepší izolaci zákaznických dat a navazují užší hranice zabezpečení mezi zákazníky. Tento článek popisuje výhody a omezení tohoto řešení.

Poznámka:

Slovo tenant v Power BI může někdy odkazovat na tenanta Microsoft Entra. V tomto článku ale používáme termín víceklientská architektura k popisu řešení, ve kterém jedna instance softwarové aplikace obsluhuje více zákazníků nebo organizací (tenantů), které vyžadují fyzické a logické oddělení dat. Tvůrce aplikací Power BI může například přidělit samostatný pracovní prostor pro každého zákazníka (nebo tenanty), jak je znázorněno níže. Tito zákazníci nemusí být nutně tenanti Microsoft Entra, proto si neměňte termín víceklientských aplikací , které zde používáme, s víceklientských aplikací Microsoft Entra.

Profil instančního objektu je profil vytvořený instančním objektem. Aplikace nezávislých výrobců softwaru volá API Power BI pomocí profilu instančního objektu, jak je vysvětleno v tomto článku.

Instanční objekt aplikace ISV vytvoří pro každého zákazníka nebo tenanta 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ů instančních objektů umožňuje aplikaci ISV hostovat více zákazníků v jednom tenantovi 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.

Diagram profilů sp a víceklientské architektury

Poznámka:

Tento článek je zaměřený na organizace, které chtějí nastavit víceklientní aplikaci pomocí profilů instančních objektů. Pokud už vaše organizace má aplikaci, která podporuje víceklientské prostředí a chcete migrovat na model profilu instančního objektu, přečtěte si téma Migrace na model profilů instančních objektů.

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

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 instančního objektu, 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í instančního objektu.

Snímek obrazovky s přepínačem portálu Správa

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. Můžete například použít rozhraní API pro přidání uživatele skupiny 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 Microsoft Entra instančního objektu pro volání rozhraní REST API Power BI.

Aplikace nezávislých výrobců softwaru volají rozhraní REST API Power BI tím, že v hlavičce autorizace poskytují token Microsoft Entra instančního objektu 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 instančního objektu musí mít Správa přístup 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 pomocí rozhraní API parametrů aktualizace definujte, 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ů:

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í rozhraní API update Datasource.

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žení sestavy

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

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

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 instanční objekt omezen na 1 000 pracovních prostorů. Aby se tento limit vyřešil, může instanční objekt vytvořit více profilů, kde každý profil může přistupovat k pracovním prostorům nebo vytvářet až 1 000 pracovních prostorů. 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 instančního objektu přístup k pracovnímu prostoru, je možné přístup nadřazeného instančního objektu 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 tenanty
  • 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 zabezpečení na úrovni řádků 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ž k oddělení dat zákazníků používáte profily instančních objektů, můžete zabezpečení na úrovni řádků v sémantickém modelu jednoho zákazníka použít k tomu, abyste různým skupinám poskytli přístup k různým částem dat. Pomocí zabezpečení na úrovni řádků 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 instančního objektu se podporují jenom prostřednictvím rozhraní REST API Power BI a sady Power BI .NET SDK. Profily instančního objektu nejsou v Power BI podporovány prostřednictvím koncového bodu XMLA nebo tabulkového objektového modelu (TOM).
  • Profily instančních objektů se v režimu živého připojení nepodporují ve službě Azure Analysis Services (AAS).

Omezení kapacity Power BI

Správa instančních objektů

Změna instančního objektu

V Power BI profil patří instančnímu objektu, který ho vytvořil. To znamená, že profil nejde sdílet s jinými objekty zabezpečení. Pokud chcete instanční objekt z nějakého důvodu změnit, budete muset znovu vytvořit všechny profily a poskytnout nový 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 instanční objekt a znovu vytvoříte profily, ID se také změní a možná budete muset aktualizovat mapování v aplikační databázi nezávislých výrobců softwaru.

Odstranění instančního objektu

Upozorňující

Při odstraňování instančního objektu buďte velmi opatrní. Nechcete náhodou ztratit data ze všech přidružených profilů.

Pokud odstraníte instanční objekt ve službě Active Directory, odstraní se všechny jeho 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 instanční objekt, který vytvořil profily, mějte na paměti, že budete muset znovu vytvořit všechny profily, poskytnout přístup k novým profilům relevantní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ý instanční objekt místo toho, aby jeden instanční objekt přistupoval k více pracovním prostorům pomocí různých profilů. Přiřazení samostatných instančních objektů 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 instančních objektů ale 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ě.

Jedna sestava, několik sémantických modelů

Obecně platí, že máte jednu sestavu a jeden sémantický model na tenanta. Pokud máte stovky sestav, budete mít stovky sémantických modelů. Někdy můžete mít jeden formát sestavy s různými sémantickými modely (například různé parametry nebo podrobnosti připojení). Pokaždé, když máte novou verzi sestavy, budete muset aktualizovat všechny sestavy 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 modulu runtime relace vytvořte vazbu sestavy na sémantický model specifický pro tenanta. 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 může každý uživatel v sestavě provádět malé změny a ukládat si 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 instančního objektu můžete k vytvoření profilů použít spravovanou identitu přiřazenouuživatelem nebo systémem. 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 se instanční objekt odstraní.
  • Spravovaná identita přiřazená systémem je připojená k prostředku v Azure (webová aplikace). Pokud prostředek odstraníte, identita se odstraní.
  • 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 použití profilů instančního objektu ke správě víceklientských prostředí pomocí vkládání dat Power BI a App-Owns-Data, stáhněte si z webu Power BI Dev Camp (web třetí strany) úložiště aplikace vlastní data s více tenanty.

Související obsah