Sdílet prostřednictvím

Vývoj škálovatelných víceklientských aplikací pomocí vkládání Power BI

  • Článek

Tento článek popisuje, jak vyvíjet víceklientská aplikace, která vkládá obsah Power BI při dosažení nejvyšší úrovně škálovatelnosti, výkonu a zabezpečení. Návrhem a implementací aplikace s profily instančního objektu můžete vytvořit a spravovat víceklientské řešení, které obsahuje desítky tisíc tenantů zákazníků, kteří můžou poskytovat sestavy cílovým skupinám více než 100 000 uživatelů.

Profily instančních objektů jsou funkce, která usnadňuje správu obsahu organizace v Power BI a efektivnější používání kapacit. Použití profilů instančních objektů ale může komplikat návrhu aplikace. Proto byste je měli použít pouze v případě, že je potřeba dosáhnout významného škálování. Doporučujeme používat profily instančního objektu, pokud máte mnoho pracovních prostorů a více než 1 000 uživatelů aplikací.

Poznámka:

Hodnota použití profilů instančních objektů se zvyšuje s tím, jak je potřeba škálovat, a také nutnost dosáhnout nejvyšší úrovně zabezpečení a izolace tenanta.

Vkládání v Power BI můžete dosáhnout pomocí dvou různých scénářů vkládání: Vložení pro vaši organizaci a Vložení pro zákazníka.

Scénář Vložení pro vaši organizaci platí, když cílová skupina aplikací zahrnuje interní uživatele. Interní uživatelé mají účty organizace a musí se ověřovat pomocí Microsoft Entra ID (dříve označovaného jako Azure Active Directory). V tomto scénáři je Power BI software jako služba (SaaS). Někdy se označuje jako uživatel vlastní data.

Vložení pro scénář zákazníka platí, když cílová skupina aplikací zahrnuje externí uživatele. Aplikace zodpovídá za ověřování uživatelů. Aby aplikace získala přístup k obsahu Power BI, spoléhá na vloženou identitu (instanční objekt Microsoft Entra nebo hlavní uživatelský účet) k ověření pomocí Microsoft Entra. V tomto scénáři je Power BI platforma jako služba (PaaS). Někdy se označuje jako aplikace vlastní data.

Poznámka:

Je důležité si uvědomit, že funkce profilů instančních objektů byla navržená pro použití se scénářem vložení pro zákazníka . Je to proto, že tento scénář nabízí nezávislé výrobce softwaru a podnikové organizace možnost vkládat s větším škálováním na velký počet uživatelů a pro velký počet zákaznických tenantů.

Vývoj víceklientských aplikací

Pokud znáte Microsoft Entra, může vás slovo tenant vést k tenantovi Microsoft Entra. Koncept tenanta se ale v kontextu vytváření víceklientských řešení, které vkládá obsah Power BI, liší. V tomto kontextu se vytvoří tenant zákazníka jménem každého zákazníka, pro kterého aplikace vkládá obsah Power BI pomocí možnosti Vložit pro váš scénář zákazníka. Obvykle zřídíte každého tenanta zákazníka vytvořením jednoho pracovního prostoru Power BI.

Pokud chcete vytvořit škálovatelné víceklientské řešení, musíte být schopni automatizovat vytváření nových tenantů zákazníků. Zřízení nového tenanta zákazníka obvykle zahrnuje psaní kódu, který používá rozhraní REST API Power BI k vytvoření nového pracovního prostoru Power BI, vytvoření sémantických modelů (dříve označovaných jako datové sady) importem souborů Power BI Desktopu (.pbix), aktualizaci parametrů zdroje dat, nastavení přihlašovacích údajů ke zdroji dat a nastavení plánované sémantické aktualizace modelu. Následující diagram ukazuje, jak můžete do pracovních prostorů přidat položky Power BI, jako jsou sestavy a sémantické modely, a nastavit tak tenanty zákazníků.

Diagram znázorňující nastavení pro tři tenanty Každý tenant má vlastní zdroj dat a pracovní prostor.

Při vývoji aplikace, která používá vložení pro váš scénář zákazníka , je možné provádět volání rozhraní REST API Power BI pomocí vložené identity, která je hlavním uživatelským účtem nebo instančním objektem. Pro produkční aplikace doporučujeme použít instanční objekt. Poskytuje nejvyšší zabezpečení a z tohoto důvodu se jedná o přístup, který doporučuje Microsoft Entra. Podporuje také lepší automatizaci a škálování a má menší režii na správu. K nastavení a správě ale vyžaduje oprávnění správce Power BI.

Pomocí instančního objektu se můžete vyhnout běžným problémům spojeným s hlavními uživatelskými účty, jako jsou chyby ověřování v prostředích, kde se uživatelé musí přihlásit pomocí vícefaktorového ověřování (MFA). Použití instančního objektu je také konzistentní s myšlenkou, že vložení pro váš scénář zákazníka je založené na vkládání obsahu Power BI pomocí myšlení PaaS, a nikoli na základě myšlení SaaS.

Omezení 1 000 pracovních prostorů

Při návrhu prostředí s více tenanty, které implementuje vložení pro váš scénář zákazníka , nezapomeňte zvážit, že identita pro vložení nemůže být udělena přístup k více než 1 000 pracovním prostorům. Služba Power BI toto omezení omezuje, aby se zajistil dobrý výkon při volání rozhraní REST API. Důvodem tohoto omezení je způsob, jakým Power BI udržuje metadata související se zabezpečením pro každou identitu.

Power BI používá metadata ke sledování pracovních prostorů a položek pracovního prostoru, ke které má identita přístup. Power BI musí udržovat samostatný seznam řízení přístupu (ACL) pro každou identitu v jeho autorizačním subsystému. Když identita volá rozhraní REST API pro přístup k pracovnímu prostoru, musí Power BI provést kontrolu zabezpečení v seznamu ACL identity, aby se zajistilo, že je autorizovaný. Čas potřebný k určení, jestli se cílový pracovní prostor nachází v seznamu ACL, se exponenciálně zvyšuje při nárůstu počtu pracovních prostorů.

Poznámka:

Power BI nevynucuje omezení 1 000 pracovních prostorů prostřednictvím kódu. Pokud se pokusíte, přidáte do více než 1 000 pracovních prostorů identitu pro vložení a volání rozhraní REST API se bude i nadále úspěšně spouštět. Vaše aplikace se ale přesune do nepodporovaného stavu, což může mít důsledky v případě, že se pokusíte požádat o pomoc od podpory Microsoftu.

Představte si scénář, ve kterém jsou pro použití jednoho instančního objektu nastavené dvě aplikace s více tenanty. Teď zvažte, že první aplikace vytvořila 990 pracovních prostorů, zatímco druhá aplikace vytvořila 1 010 pracovních prostorů. Z pohledu podpory je první aplikace v rámci podporovaných hranic, zatímco druhá aplikace není.

Nyní porovnejte tyto dvě aplikace čistě z hlediska výkonu. Není to moc rozdílu, protože seznamy ACL obou instančních objektů umožňují zvýšit metadata pro jejich seznamy ACL až do bodu, kdy sníží výkon do určité míry.

Tady je klíčové pozorování: Počet pracovních prostorů vytvořených instančním objektem má přímý vliv na výkon a škálovatelnost. Instanční objekt, který je členem 100 pracovních prostorů, bude spouštět volání rozhraní REST API rychleji než instanční objekt, který je členem 1 000 pracovních prostorů. Podobně instanční objekt, který je členem pouze 10 pracovních prostorů, spustí volání rozhraní REST API rychleji než instanční objekt, který je členem 100 pracovních prostorů.

Důležité

Z hlediska výkonu a škálovatelnosti je optimální počet pracovních prostorů, pro které je instanční objekt členem, přesně jeden.

Správa izolace pro sémantické modely a přihlašovací údaje ke zdroji dat

Dalším důležitým aspektem při návrhu víceklientské aplikace je izolace tenantů zákazníků. Je důležité, aby uživatelé z jednoho tenanta zákazníka neviděli data, která patří do jiného tenanta zákazníka. Proto musíte pochopit, jak spravovat sémantické vlastnictví modelu a přihlašovací údaje ke zdroji dat.

Sémantické vlastnictví modelu

Každý sémantický model Power BI má jednoho vlastníka, což může být uživatelský účet nebo instanční objekt. K nastavení plánované aktualizace a nastavení sémantických parametrů modelu se vyžaduje sémantické vlastnictví modelu.

Tip

V služba Power BI můžete určit, kdo je vlastník sémantického modelu, otevřením nastavení sémantického modelu.

V případě potřeby můžete vlastnictví sémantického modelu převést na jiný uživatelský účet nebo instanční objekt. Můžete to udělat v služba Power BI nebo pomocí operace rozhraní REST APITakeOver. Při importu souboru Power BI Desktopu pro vytvoření nového sémantického modelu pomocí instančního objektu se instanční objekt automaticky nastaví jako vlastník sémantického modelu.

Přihlašovací údaje ke zdroji dat

Pokud chcete připojit sémantický model k podkladovému zdroji dat, musí vlastník sémantického modelu nastavit přihlašovací údaje ke zdroji dat. Přihlašovací údaje ke zdroji dat jsou zašifrované a uložené v mezipaměti v Power BI. Z tohoto okamžiku Power BI tyto přihlašovací údaje používá k ověření u podkladového zdroje dat při aktualizaci dat (pro import tabulek úložiště) nebo spouštění předávacích dotazů (pro tabulky úložiště DirectQuery).

Při zřizování nového tenanta zákazníka doporučujeme použít běžný vzor návrhu. Pomocí identity instančního objektu můžete spustit řadu volání rozhraní REST API:

  1. Vytvořte nový pracovní prostor.
  2. Přidružte nový pracovní prostor k vyhrazené kapacitě.
  3. Naimportujte soubor Power BI Desktopu a vytvořte sémantický model.
  4. Nastavte přihlašovací údaje ke zdroji sémantických modelů pro tento sémantický model.

Po dokončení těchto volání rozhraní REST API bude instanční objekt správcem nového pracovního prostoru a vlastníkem sémantického modelu a přihlašovacích údajů ke zdroji dat.

Důležité

Existují běžné omyly, že přihlašovací údaje ke zdroji dat sémantického modelu jsou vymezeny na úrovni pracovního prostoru. To není pravda. Přihlašovací údaje ke zdroji dat jsou vymezeny na instanční objekt (nebo uživatelský účet) a tento obor se vztahuje na všechny pracovní prostory Power BI v tenantovi Microsoft Entra.

Instanční objekt může vytvořit přihlašovací údaje ke zdroji dat, které sdílí sémantické modely v různých pracovních prostorech napříč tenanty zákazníků, jak je znázorněno v následujícím diagramu.

Diagram znázorňující nastavení pro dva tenanty Každý tenant sdílí stejné přihlašovací údaje ke zdroji dat.

Pokud přihlašovací údaje ke zdroji dat sdílí sémantické modely, které patří do různých tenantů zákazníků, nejsou tenanti zákazníka plně izolovaní.

Strategie návrhu před profily instančního objektu

Pochopení strategií návrhu před zpřístupněním funkce instančního profilu vám může pomoct ocenit potřebu této funkce. Před tímto časem vývojáři vytvořili víceklientské aplikace pomocí jedné z následujících tří strategií návrhu:

  • Jeden instanční objekt
  • Sdružování instančních objektů
  • Jeden instanční objekt na pracovní prostor

Každá z těchto strategií návrhu má silné stránky a slabost.

Strategie návrhu jednoho instančního objektu vyžaduje jednorázové vytvoření registrace aplikace Microsoft Entra. Proto zahrnuje menší administrativní režii než ostatní dvě strategie návrhu, protože není nutné vytvářet více registrací aplikací Microsoft Entra. Tato strategie je také nejjednodušší nastavit, protože nevyžaduje zápis dalšího kódu, který při volání rozhraní REST API přepne kontext volání mezi instančními objekty. Problém s touto strategií návrhu ale spočívá v tom, že se škáluje. Podporuje pouze víceklientské prostředí, které může růst až o 1 000 pracovních prostorů. Výkon se také může snížit, protože instančnímu objektu je udělen přístup k většímu počtu pracovních prostorů. Došlo také k potížím s izolací tenanta zákazníka, protože se jeden instanční objekt stává vlastníkem každého sémantického modelu a všech přihlašovacích údajů k datům napříč všemi tenanty zákazníka.

Strategie návrhu sdružování instančních objektů se běžně používá, aby nedocházelo k omezení 1 000 pracovních prostorů. Umožňuje aplikaci škálovat na libovolný počet pracovních prostorů přidáním správného počtu instančních objektů do fondu. Například fond pěti instančních objektů umožňuje vertikálně navýšit kapacitu až na 5 000 pracovních prostorů; Fond 80 instančních objektů umožňuje vertikálně navýšit kapacitu až na 80 000 pracovních prostorů atd. I když se ale tato strategie může škálovat na velký počet pracovních prostorů, má několik nevýhod. Nejprve vyžaduje zápis dalšího kódu a ukládání metadat, aby bylo možné přepínání kontextu mezi instančními objekty při volání rozhraní REST API. Za druhé se vyžaduje větší administrativní úsilí, protože při každém zvýšení počtu instančních objektů ve fondu musíte vytvořit registrace aplikací Microsoft Entra.

Navíc strategie sdružování instančních objektů není optimalizovaná pro výkon, protože instanční objekty umožňují stát se členy stovek pracovních prostorů. Není také ideální z hlediska izolace tenanta zákazníka, protože instanční objekty se mohou stát vlastníky sémantického modelu a přihlašovacích údajů k datům sdíleným napříč tenanty zákazníka.

Jedna strategie návrhu instančního objektu na pracovní prostor zahrnuje vytvoření instančního objektu pro každého tenanta zákazníka. Z teoretické perspektivy tato strategie nabízí nejlepší řešení, protože optimalizuje výkon volání rozhraní REST API a současně poskytuje skutečnou izolaci pro sémantické modely a přihlašovací údaje ke zdroji dat na úrovni pracovního prostoru. Co ale funguje nejlépe teoreticky, nefunguje v praxi vždy nejlépe. Důvodem je to, že požadavek na vytvoření instančního objektu pro každého tenanta zákazníka je pro mnoho organizací nepraktický. Je to proto, že některé organizace mají formální schvalovací procesy nebo zahrnují nadměrnou administrativu při vytváření registrací aplikací Microsoft Entra. Tyto důvody můžou znemožnit udělení vlastní aplikace autoritě, kterou potřebuje k vytvoření registrací aplikací Microsoft Entra na vyžádání, a automatizovaným způsobem, který vaše řešení vyžaduje.

V méně běžných scénářích, kdy vlastní aplikace má udělená správná oprávnění, může pomocí rozhraní Microsoft Graph API vytvářet registrace aplikací Microsoft Entra na vyžádání. Vlastní aplikace je ale často složitá pro vývoj a nasazení, protože musí nějak sledovat přihlašovací údaje pro ověřování pro každou registraci aplikace Microsoft Entra. Musí také získat přístup k těmto přihlašovacím údajům, kdykoli potřebuje ověřovat a získávat přístupové tokeny pro jednotlivé instanční objekty.

Profily instančního objektu

Funkce profilů instančních objektů byla navržena tak, aby vám usnadnila správu obsahu organizace v Power BI a efektivnější používání kapacit. Pomáhají řešit tři specifické výzvy, které zahrnují nejnižší množství úsilí a režie vývojářů. Mezi tyto výzvy patří:

  • Škálování na velký počet pracovních prostorů
  • Optimalizace výkonu volání rozhraní REST API
  • Izolování sémantických modelů a přihlašovacích údajů ke zdroji dat na úrovni tenanta zákazníka

Při návrhu víceklientské aplikace pomocí profilů instančních objektů můžete využít výhod výhod tří strategií návrhu (popsaných v předchozí části) a vyhnout se jejich přidruženým slabým stránkám.

Profily instančního objektu jsou místní účty, které se vytvářejí v kontextu Power BI. Instanční objekt může použít Profiles operaci REST API k vytvoření nových profilů instančního objektu. Instanční objekt může vytvořit a spravovat vlastní sadu profilů instančního objektu pro vlastní aplikaci, jak je znázorněno v následujícím diagramu.

Diagram znázorňující instanční objekt vytvářející tři profily instančního objektu v Power BI

Mezi instančním objektem a profily instančního objektu, který vytvoří, je vždy vztah nadřazený-podřízený. Jako samostatnou entitu nemůžete vytvořit profil instančního objektu. Místo toho vytvoříte instanční profil pomocí konkrétního instančního objektu a tento instanční objekt slouží jako nadřazený objekt profilu. Kromě toho není profil instančního objektu nikdy viditelný pro uživatelské účty ani jiné instanční objekty. Profil instančního objektu je možné zobrazit a používat pouze instanční objekt, který ho vytvořil.

Profily instančního objektu nejsou známé pro Microsoft Entra

Zatímco samotný instanční objekt a jeho základní registrace aplikace Microsoft Entra jsou známé pro Microsoft Entra, Microsoft Entra ID nezná nic o profilech instančního objektu. Je to proto, že power BI vytváří profily instančních objektů a existují jenom v subsystému služba Power BI, který řídí zabezpečení a autorizaci Power BI.

Skutečnost, že profily instančního objektu nejsou známé pro ID Microsoft Entra, mají výhody i nevýhody. Hlavní výhodou je, že aplikace pro vložení pro scénář zákazníka nepotřebuje k vytváření profilů instančních objektů žádná speciální oprávnění Microsoft Entra. Také to znamená, že aplikace může vytvořit a spravovat sadu místních identit, které jsou oddělené od Microsoft Entra.

Existují však i nevýhody. Vzhledem k tomu, že profily instančního objektu nejsou známé pro Microsoft Entra, nemůžete do skupiny Microsoft Entra přidat instanční profil, abyste mu implicitně udělili přístup k pracovnímu prostoru. Externí zdroje dat, jako je Azure SQL Database nebo Azure Synapse Analytics, také nemůžou rozpoznat profily instančního objektu jako identitu při připojování k databázi. Jeden instanční objekt na strategii návrhu pracovního prostoru (vytvoření instančního objektu pro každého tenanta zákazníka) proto může být lepší volbou, pokud je potřeba se k těmto zdrojům dat připojit pomocí samostatného instančního objektu s jedinečnými přihlašovacími údaji pro každého tenanta zákazníka.

Profily instančního objektu jsou prvotřídní objekty zabezpečení.

I když Se službou Microsoft Entra nejsou známé profily instančního objektu, Power BI je rozpozná jako prvotřídní objekty zabezpečení. Stejně jako u uživatelského účtu nebo instančního objektu můžete přidat profily instančního objektu do role pracovního prostoru (jako Správa nebo člen). Můžete ho také nastavit jako vlastníka sémantického modelu a vlastníka přihlašovacích údajů ke zdroji dat. Z těchto důvodů je osvědčeným postupem vytvoření nového profilu instančního objektu pro každého nového tenanta zákazníka.

Diagram znázorňující více tenantů zákazníků, z nichž každý má vlastní profily instančního objektu

Tip

Při vývoji aplikace pro vložení pro scénář zákazníka pomocí profilů instančních objektů stačí vytvořit jedinou registraci aplikace Microsoft Entra, která aplikaci poskytne jeden instanční objekt. Tento přístup výrazně snižuje režijní náklady na správu v porovnání s jinými strategiemi návrhu s více tenanty, kde je nutné průběžně vytvářet další registrace aplikací Microsoft Entra po nasazení aplikace do produkčního prostředí.

Spouštění volání rozhraní REST API jako instančního profilu

Aplikace může spouštět volání rozhraní REST API pomocí identity instančního profilu. To znamená, že může spustit posloupnost volání rozhraní REST API pro zřízení a nastavení nového tenanta zákazníka.

  1. Když instanční profil vytvoří nový pracovní prostor, Power BI tento profil automaticky přidá jako správce pracovního prostoru.
  2. Když instanční profil naimportuje soubor Power BI Desktopu k vytvoření sémantického modelu, Nastaví Power BI tento profil jako vlastník sémantického modelu.
  3. Když profil instančního objektu nastaví přihlašovací údaje ke zdroji dat, Nastaví Power BI tento profil jako vlastník přihlašovacích údajů ke zdroji dat.

Je důležité si uvědomit, že instanční objekt má identitu v Power BI, která je oddělená a odlišná od identit svých profilů. To vám poskytne výběr jako vývojář. Volání rozhraní REST API můžete spustit pomocí identity instančního profilu. Alternativně můžete spouštět volání rozhraní REST API bez profilu, který používá identitu nadřazeného instančního objektu.

Při vytváření, prohlížení nebo odstraňování profilů instančních objektů doporučujeme spouštět volání rozhraní REST API jako nadřazený instanční objekt. K provedení všech dalších volání rozhraní REST API byste měli použít profil instančního objektu. Tato další volání můžou vytvářet pracovní prostory, importovat soubory Power BI Desktopu, aktualizovat parametry sémantického modelu a nastavit přihlašovací údaje ke zdroji dat. Můžou také načíst metadata položky pracovního prostoru a generovat tokeny pro vložení.

Představte si příklad, kdy potřebujete pro zákazníka s názvem Contoso nastavit tenanta zákazníka. Prvním krokem je volání rozhraní REST API, které vytvoří profil instančního objektu s jeho zobrazovaným názvem nastaveným na Contoso. Toto volání se provádí pomocí identity instančního objektu. Všechny zbývající kroky nastavení používají k dokončení následujících úloh profil instančního objektu:

  1. Vytvořte pracovní prostor.
  2. Přidružte pracovní prostor ke kapacitě.
  3. Importujte soubor Power BI Desktopu.
  4. Nastavte sémantické parametry modelu.
  5. Nastavení přihlašovacích údajů ke zdroji dat
  6. Nastavte plánovanou aktualizaci dat.

Je důležité pochopit, že přístup k pracovnímu prostoru a jeho obsahu se musí provádět pomocí identity instančního profilu, který byl použit k vytvoření tenanta zákazníka. Je také důležité vědět, že nadřazený instanční objekt nepotřebuje přístup k pracovnímu prostoru nebo jeho obsahu.

Tip

Mějte na paměti: Při volání rozhraní REST API použijte instanční objekt k vytvoření a správě profilů instančních objektů a k vytváření, nastavení a přístupu k obsahu Power BI použijte profil instančního objektu.

Použití operací rozhraní REST API profilů

Skupina operací rozhraní REST API profilů se skládá z operací, které vytvářejí a spravují profily instančních objektů:

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

Vytvoření profilu instančního objektu

K vytvoření instančního profilu použijte operaci vytvořit profil rozhraní REST API pro vytvoření profilu profilu. Vlastnost v textu požadavku musíte nastavit displayName tak, aby se zobrazovaný název nového tenanta zobrazil. Hodnota musí být jedinečná ve všech profilech vlastněných instančním objektem. Volání selže, pokud pro instanční objekt již existuje jiný profil s tímto zobrazovaným názvem.

Úspěšné volání vrátí id vlastnost, což je GUID představující profil. Při vývoji aplikací, které používají profily instančního objektu, doporučujeme ukládat zobrazované názvy profilů a jejich HODNOTY ID ve vlastní databázi. Díky tomu je pro vaši aplikaci jednoduché načíst ID.

Pokud programujete pomocí sady Power BI .NET SDK, můžete použít metodu Profiles.CreateProfileServicePrincipalProfile , která vrátí objekt představující nový profil. Usnadňuje určení id hodnoty vlastnosti.

Tady je příklad vytvoření profilu instančního objektu a udělení přístupu k pracovnímu prostoru.

// 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);

V služba Power BI v podokně Access pracovního prostoru můžete určit, ke kterým identitám, včetně objektů zabezpečení, mají přístup.

Snímek obrazovky znázorňující snímek obrazovky s podoknem Access pracovního prostoru Zobrazuje profil instančního objektu se zobrazovaným názvem společnosti Contoso, který má oprávnění správce.

Odstranění profilu instančního objektu

K odstranění profilu instančního objektu použijte operaci rozhraní REST API pro odstranění profilu. Tuto operaci může volat pouze nadřazený instanční objekt.

Pokud programujete pomocí sady Power BI .NET SDK, můžete použít tuto metodu Profiles.DeleteProfile .

Načtení všech profilů instančního objektu

Pomocí operace Get Profiles REST API načtěte seznam profilů instančních objektů, které patří do volajícího instančního objektu. Tato operace vrátí datovou část JSON, která obsahuje id vlastnosti displayName jednotlivých profilů instančního objektu.

Pokud programujete pomocí sady Power BI .NET SDK, můžete použít metodu Profiles.GetProfiles .

Spouštění volání rozhraní REST API pomocí instančního profilu

Pro volání rozhraní REST API pomocí profilu instančního objektu existují dva požadavky:

  • V autorizační hlavičce musíte předat přístupový token pro nadřazený instanční objekt.
  • Musíte zahrnout hlavičku X-PowerBI-profile-id s hodnotou ID instančního profilu.

Pokud používáte sadu Power BI .NET SDK, můžete nastavit hodnotu hlavičky X-PowerBI-profile-id explicitně předáním ID instančního profilu.

// 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();

Jak je znázorněno v předchozím příkladu, jakmile do PowerBIClient objektu přidáte hlavičku X-PowerBI-profile-id, je jednoduché vyvolat metody, například Groups.GetGroups, aby se spustily pomocí profilu instančního objektu.

Existuje pohodlnější způsob, jak nastavit záhlaví X-PowerBI-profile-id objektu PowerBIClient . Objekt můžete inicializovat předáním ID profilu konstruktoru.

// 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);

Při programování víceklientské aplikace je pravděpodobné, že budete muset přepínat mezi prováděním volání jako nadřazeného instančního objektu a spouštěním volání jako instančního profilu. Užitečným přístupem ke správě přepínání kontextu je deklarování proměnné na úrovni třídy, která objekt ukládá PowerBIClient . Pak můžete vytvořit pomocnou metodu, která nastaví proměnnou správným objektem.

// 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));
    }
}

Pokud potřebujete vytvořit nebo spravovat profil instančního objektu, můžete metodu SetCallingContext volat bez jakýchkoli parametrů. Tímto způsobem můžete vytvářet a spravovat profily pomocí identity instančního objektu.

// 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);

Pokud potřebujete vytvořit a nastavit pracovní prostor pro nového tenanta zákazníka, chcete tento kód spustit jako profil instančního objektu. Proto byste měli volat metodu SetCallingContext předáním ID profilu. Tímto způsobem můžete vytvořit pracovní prostor pomocí identity instančního profilu.

// 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);

Po použití konkrétního profilu instančního objektu k vytvoření a konfiguraci pracovního prostoru byste měli dál používat stejný profil k vytvoření a nastavení obsahu pracovního prostoru. K dokončení instalace není nutné vyvolat SetCallingContext metodu.

Ukázka pro vývojáře

Doporučujeme stáhnout si ukázkovou aplikaci s názvem AppOwnsDataMultiTenant.

Tato ukázková aplikace byla vyvinuta pomocí .NET 6 a ASP.NET a ukazuje, jak použít pokyny a doporučení popsaná v tomto článku. V kódu se dozvíte, jak vyvíjet víceklientská aplikace, která implementuje vložení pro váš scénář zákazníka pomocí profilů instančního objektu.

Související obsah

Další informace o tomto článku najdete v následujících zdrojích informací: