Sdílet prostřednictvím

Migrace více zákaznických aplikací do modelu profilů instančních objektů

  • Článek

Tento článek popisuje, jak můžete dosáhnout lepší škálovatelnosti migrací aplikací Power BI Embedded Analytics s více zákazníky do modelu profilů instančních objektů.

Profily instančního objektu usnadňují správu obsahu organizace v Power BI a efektivnější používání kapacit.

Poznámka:

Tento článek je zaměřený na organizace, které už mají aplikaci, která podporuje více zákazníků z jednoho tenanta Power BI.

Ne všechny aplikace využívají model instančního objektu. Například následující aplikace by se neměly migrovat:

  • Malé aplikace, které udržují jeden instanční objekt s malým počtem objektů
  • Aplikace, které používají jeden více instančních objektů na zákazníka

Požadavky

Před zahájením migrace je důležité si přečíst o profilech instančního objektu.

Musíte také provést následující kroky:

Snímek obrazovky s přepínačem portálu pro správu

Migrace na profily instančního objektu

Migrace na profily instančního objektu zahrnuje následující kroky:

  1. Vytvořte profily, jeden profil pro každého zákazníka.
  2. Uspořádejte pracovní prostory.
  3. Změňte kód aplikace tak, aby používal profily.
  4. Otestujte aplikaci pomocí modelu profilů.
  5. Vyčistěte redundantní oprávnění.

Vytvoření profilů (povinné)

K vytvoření jednoho profilu pro každého zákazníka použijte rozhraní REST API profilů s instančním objektem, který jste vytvořili.

Je vhodné uložit mapování jednotlivých ID zákazníka dat s odpovídajícím ID profilu ve vaší databázi. Toto mapování budete později potřebovat k volání rozhraní API s profilem tenanta.

Uspořádání pracovních prostorů

Nejjednodušší způsob, jak spravovat data, je údržba jednoho pracovního prostoru na zákazníka. Pokud už vaše aplikace tento model používá, nemusíte vytvářet nové pracovní prostory. Přesto ale musíte každému profilu poskytnout přístup správce k odpovídajícímu pracovnímu prostoru pomocí rozhraní API pro přidání uživatele skupiny.

Pokud nemáte jeden pracovní prostor pro každého zákazníka, použijte odpovídající profil pro volání rozhraní API pro vytvoření uživatele skupiny a vytvořte pro každého zákazníka nový pracovní prostor.

Uspořádání položek v pracovních prostorech

Teď byste měli mít profil a pracovní prostor pro každého zákazníka. Pokud jste v předchozím kroku vytvořili nové pracovní prostory, musíte do těchto pracovních prostorů importovat položky (například sestavy a sémantické modely). Sémantické modely, které importujete, závisí na aktuálním řešení:

  • Pokud vaše aplikace pro každého zákazníka používá samostatný sémantický model, může návrh sémantického modelu fungovat tak, jak je.

  • Pokud vaše aplikace používá jeden sémantický model se zabezpečením na úrovni řádků (RLS) k poskytování různých dat různým zákazníkům, můžete získat lepší škálovatelnost vytvořením samostatného sémantického modelu pro každého zákazníka a použitím profilů popsaných v tomto článku.

  • Po překonání omezení škálovatelnosti pomocí profilů a samostatných zdrojů dat můžete získat ještě více oddělení dat pomocí zabezpečení na úrovni řádků s profily.

    • Pokud spoléháte na dynamické zabezpečení na úrovni řádků, vrátí se název profilu ve funkci UserName()DAX .
    • Pokud při generování tokenu pro vložení použijete statické zabezpečení na úrovni řádků a přepíšete role, můžete pokračovat.

Jakmile jsou položky připravené, naimportujte je do příslušných pracovních prostorů. Pokud chcete proces automatizovat, zvažte použití rozhraní API pro import.

Změna kódů aplikací tak, aby používaly profily

Jakmile budete mít profily s přístupem správce k příslušným pracovním prostorům a databázi s mapováním, která ukazuje, který profil představuje zákazníka, můžete provést potřebné změny kódu. Doporučujeme zachovat dva toky kódu vedle sebe a postupně vystavit tok kódu profilů vašim zákazníkům.

Proveďte následující změny kódu:

  • Změna autorizačního kódu

    • Pokud používáte hlavního uživatele v aplikaci Microsoft Entra ID , změňte kód získání tokenu. Přečtěte si vložení pomocí instančního objektu , abyste se dozvěděli o vytvoření tokenu Microsoft Entra jen pro aplikaci.
    • Pokud používáte instanční objekt a pro profily jste vytvořili nový, upravte kód tak, aby používal správné ID instančního objektu a tajné kódy.

  • Změna kódu správy

    Některé aplikace mají kód pro správu, který automatizuje onboarding nového zákazníka při registraci. Kód pro správu často používá rozhraní REST API Power BI k vytváření pracovních prostorů a importu obsahu. Většina tohoto kódu by měla zůstat stejná, ale možná budete muset přizpůsobit následující podrobnosti:

    • Pokaždé, když vytvoříte nového tenanta zákazníka, vytvořte nový profil služby, který bude tvůrcem a správcem pracovního prostoru pro tohoto tenanta.
    • Pokud se rozhodnete změnit uspořádání obsahu Power BI, upravte kód tak, aby odrážel změny.

  • Změna kódu tokenu pro vložení

    Nahraďte volajícího rozhraní API. Ujistěte se, že profil volá rozhraní GenerateToken API , protože v modelu profilů má přístup k obsahu zákazníka pouze konkrétní profil.

Ověřit

Než aplikaci přesunete do modelu profilů, doporučujeme aplikaci důkladně otestovat. Sestavy se můžou načíst i v případě, že kód aplikace SaaS neobsahuje chyby, protože jste v pracovních prostorech neodstranili starší oprávnění.

Vyčištění po migraci

Po dokončení migrace a ověření výsledků odeberte, co už nepotřebujete.

  • Vyčištění kódu: Možná budete chtít zakázat staré cesty ke kódu, abyste měli jistotu, že spouštíte jenom nový kód, který spoléhá na profily.
  • Vyčištění pracovních prostorů a oprávnění v Power BI: Pokud jste vytvořili nové pracovní prostory, můžete staré pracovní prostory, které se už nepoužívají, odstranit. Pokud jste znovu použili stejné pracovní prostory, můžete v pracovním prostoru odstranit starší oprávnění (například hlavní uživatelská oprávnění).

Související obsah

Správa profilů instančních objektů

Máte ještě další otázky? Zkuste se zeptat Komunita Power BI