Udostępnij za pośrednictwem

Opracowywanie skalowalnych aplikacji wielodostępnych przy użyciu osadzania w usłudze Power BI

  • Artykuł

W tym artykule opisano sposób tworzenia aplikacji wielodostępnej, która osadza zawartość usługi Power BI przy jednoczesnym osiągnięciu najwyższych poziomów skalowalności, wydajności i zabezpieczeń. Projektując i implementując aplikację z profilami jednostki usługi, można utworzyć rozwiązanie wielodostępne składające się z dziesiątek tysięcy dzierżaw klientów, które może dostarczać raporty do odbiorców ponad 100 000 użytkowników.

Profile jednostki usługi to funkcja, która ułatwia zarządzanie zawartością organizacji w usłudze Power BI i wydajniejsze korzystanie z pojemności. Jednak użycie profilów jednostki usługi może zwiększyć złożoność projektu aplikacji. W związku z tym należy ich używać tylko wtedy, gdy trzeba osiągnąć znaczną skalę. Zalecamy używanie profilów jednostki usługi, jeśli masz wiele obszarów roboczych i ponad 1000 użytkowników aplikacji.

Uwaga

Wartość korzystania z profilów jednostki usługi zwiększa się wraz ze wzrostem skali, a także potrzebą osiągnięcia najwyższego poziomu izolacji zabezpieczeń i dzierżawy.

Osadzanie w usłudze Power BI można osiągnąć przy użyciu dwóch różnych scenariuszy osadzania: Osadzanie dla organizacji i Osadzanie dla klienta.

Scenariusz osadzania dla organizacji ma zastosowanie, gdy odbiorcy aplikacji składają się z użytkowników wewnętrznych . Użytkownicy wewnętrzni mają konta organizacyjne i muszą uwierzytelniać się przy użyciu identyfikatora Entra firmy Microsoft. W tym scenariuszu usługa Power BI to oprogramowanie jako usługa (SaaS). Czasami jest określany jako Użytkownik jest właścicielem danych.

Scenariusz osadzania dla klienta ma zastosowanie, gdy odbiorcy aplikacji składają się z użytkowników zewnętrznych . Aplikacja jest odpowiedzialna za uwierzytelnianie użytkowników. Aby uzyskać dostęp do zawartości usługi Power BI, aplikacja korzysta z tożsamości osadzania (jednostki usługi Microsoft Entra lub głównego konta użytkownika) do uwierzytelniania w usłudze Microsoft Entra. W tym scenariuszu usługa Power BI jest platformą jako usługą (PaaS). Czasami nazywa się to aplikacją będącą właścicielem danych.

Uwaga

Ważne jest, aby zrozumieć, że funkcja profilów jednostki usługi została zaprojektowana do użycia ze scenariuszem Osadzanie dla klienta . Dzieje się tak dlatego, że ten scenariusz oferuje niezależnych dostawców oprogramowania i przedsiębiorstwa możliwość osadzania z większą liczbą użytkowników i dużą liczbą dzierżawców klientów.

Tworzenie aplikacji wielodostępnych

Jeśli znasz firmę Microsoft Entra, słowo dzierżawa może prowadzić Cię do myślenia o dzierżawie firmy Microsoft Entra. Jednak koncepcja dzierżawy różni się w kontekście tworzenia rozwiązania wielodostępności, które osadza zawartość usługi Power BI. W tym kontekście dzierżawa klienta jest tworzona w imieniu każdego klienta, dla którego aplikacja osadza zawartość usługi Power BI przy użyciu scenariusza Osadzanie dla klienta. Zazwyczaj każda dzierżawa klienta jest aprowizowany przez utworzenie jednego obszaru roboczego usługi Power BI.

Aby utworzyć skalowalne rozwiązanie wielodostępne, musisz mieć możliwość zautomatyzowania tworzenia nowych dzierżaw klientów. Aprowizowanie nowej dzierżawy klienta zwykle obejmuje pisanie kodu, który używa interfejsu API REST usługi Power BI do utworzenia nowego obszaru roboczego usługi Power BI, tworzenia modeli semantycznych przez importowanie plików programu Power BI Desktop (pbix), aktualizowanie parametrów źródła danych, ustawianie poświadczeń źródła danych i konfigurowanie zaplanowanego odświeżania modelu semantycznego. Na poniższym diagramie przedstawiono sposób dodawania elementów usługi Power BI, takich jak raporty i modele semantyczne, do obszarów roboczych w celu skonfigurowania dzierżaw klientów.

Diagram przedstawiający konfigurację dla trzech dzierżaw. Każda dzierżawa ma własne źródło danych i obszar roboczy.

Podczas tworzenia aplikacji korzystającej ze scenariusza Osadzanie dla klienta można wykonywać wywołania interfejsu API REST usługi Power BI przy użyciu tożsamości osadzania, która jest kontem użytkownika głównego lub jednostką usługi. Zalecamy używanie jednostki usługi dla aplikacji produkcyjnych. Zapewnia ona najwyższe zabezpieczenia i dlatego jest to podejście zalecane przez firmę Microsoft Entra. Ponadto obsługuje ona lepszą automatyzację i skalowanie oraz mniejsze obciążenie związane z zarządzaniem. Wymaga to jednak uprawnień administratora usługi Power BI do konfigurowania i zarządzania nimi.

Korzystając z jednostki usługi, można uniknąć typowych problemów związanych z kontami użytkowników głównych, takich jak błędy uwierzytelniania w środowiskach, w których użytkownicy muszą się zalogować przy użyciu uwierzytelniania wieloskładnikowego (MFA). Użycie jednostki usługi jest również zgodne z założeniem, że scenariusz Osadzanie dla klienta jest oparty na osadzaniu zawartości usługi Power BI przy użyciu myślenia PaaS, a nie do myślenia SaaS.

Ograniczenie 1000 obszarów roboczych

Podczas projektowania środowiska wielodostępności, które implementuje scenariusz Osadzanie dla klienta , należy wziąć pod uwagę, że tożsamość osadzania nie może mieć dostępu do ponad 1000 obszarów roboczych. Usługa Power BI nakłada to ograniczenie, aby zapewnić dobrą wydajność podczas wykonywania wywołań interfejsu API REST. Przyczyną tego ograniczenia jest sposób, w jaki usługa Power BI utrzymuje metadane związane z zabezpieczeniami dla każdej tożsamości.

Usługa Power BI używa metadanych do śledzenia obszarów roboczych i elementów obszaru roboczego, do których może uzyskiwać dostęp tożsamość. W efekcie usługa Power BI musi obsługiwać oddzielną listę kontroli dostępu (ACL) dla każdej tożsamości w podsystemie autoryzacji. Gdy tożsamość wykonuje wywołanie interfejsu API REST w celu uzyskania dostępu do obszaru roboczego, usługa Power BI musi przeprowadzić sprawdzanie zabezpieczeń względem listy ACL tożsamości, aby upewnić się, że jest autoryzowana. Czas potrzebny na ustalenie, czy docelowy obszar roboczy znajduje się wewnątrz listy ACL, zwiększa się wykładniczo w miarę wzrostu liczby obszarów roboczych.

Uwaga

Usługa Power BI nie wymusza ograniczenia obszaru roboczego 1000 za pomocą kodu. Jeśli spróbujesz, dodasz tożsamość osadzania do ponad 1000 obszarów roboczych, a wywołania interfejsu API REST będą nadal wykonywane pomyślnie. Jednak aplikacja przejdzie do stanu nieobsługiwanego , co może mieć wpływ, jeśli spróbujesz poprosić o pomoc od pomocy technicznej firmy Microsoft.

Rozważmy scenariusz, w którym skonfigurowano dwie aplikacje z wieloma dzierżawami w celu używania pojedynczej jednostki usługi. Teraz należy wziąć pod uwagę, że pierwsza aplikacja utworzyła 990 obszarów roboczych, podczas gdy druga aplikacja utworzyła 1010 obszarów roboczych. Z perspektywy pomocy technicznej pierwsza aplikacja znajduje się w obsługiwanych granicach, podczas gdy druga aplikacja nie jest.

Teraz porównaj te dwie aplikacje wyłącznie z perspektywy wydajności. Nie ma tak dużej różnicy, ponieważ listy ACL dla obu jednostek usługi pozwalają na zwiększenie metadanych dla ich list ACL do punktu, w którym obniży wydajność do pewnego stopnia.

Oto kluczowa obserwacja: liczba obszarów roboczych utworzonych przez jednostkę usługi ma bezpośredni wpływ na wydajność i skalowalność. Jednostka usługi, która jest członkiem 100 obszarów roboczych, będzie wykonywać wywołania interfejsu API REST szybciej niż jednostka usługi, która jest członkiem 1000 obszarów roboczych. Podobnie jednostka usługi, która jest członkiem tylko 10 obszarów roboczych, będzie wykonywać wywołania interfejsu API REST szybciej niż jednostka usługi, która jest członkiem 100 obszarów roboczych.

Ważne

Z punktu widzenia wydajności i skalowalności optymalna liczba obszarów roboczych, dla których jednostka usługi jest elementem członkowskim, jest dokładnie jedna.

Zarządzanie izolacją modeli semantycznych i poświadczeń źródła danych

Innym ważnym aspektem projektowania aplikacji wielodostępnej jest odizolowanie dzierżaw klientów. Ważne jest, aby użytkownicy z jednej dzierżawy klienta nie widzieli danych należących do innej dzierżawy klienta. W związku z tym musisz zrozumieć, jak zarządzać własnością modelu semantycznego i poświadczeniami źródła danych.

Własność modelu semantycznego

Każdy semantyczny model usługi Power BI ma jednego właściciela, który może być kontem użytkownika lub jednostką usługi. Własność modelu semantycznego jest wymagana do skonfigurowania zaplanowanego odświeżania i ustawienia parametrów modelu semantycznego.

Napiwek

W usługa Power BI można określić, kim jest właściciel modelu semantycznego, otwierając ustawienia modelu semantycznego.

W razie potrzeby możesz przenieść własność modelu semantycznego na inne konto użytkownika lub jednostkę usługi. Możesz to zrobić w usługa Power BI lub przy użyciu operacji interfejsu API TakeOver REST. Podczas importowania pliku programu Power BI Desktop w celu utworzenia nowego modelu semantycznego przy użyciu jednostki usługi jednostka usługi jest automatycznie ustawiana jako właściciel modelu semantycznego.

Poświadczenia źródła danych

Aby połączyć model semantyczny z jego bazowym źródłem danych, właściciel modelu semantycznego musi ustawić poświadczenia źródła danych. Poświadczenia źródła danych są szyfrowane i buforowane przez usługę Power BI. Od tego momentu usługa Power BI używa tych poświadczeń do uwierzytelniania za pomocą bazowego źródła danych podczas odświeżania danych (w przypadku tabel magazynu importu) lub wykonywania zapytań przekazujących (w przypadku tabel magazynu DirectQuery).

Zalecamy zastosowanie wspólnego wzorca projektowego podczas aprowizacji nowej dzierżawy klienta. Możesz wykonać serię wywołań interfejsu API REST przy użyciu tożsamości jednostki usługi:

  1. Tworzenie nowego obszaru roboczego.
  2. Skojarz nowy obszar roboczy z dedykowaną pojemnością.
  3. Zaimportuj plik programu Power BI Desktop, aby utworzyć model semantyczny.
  4. Ustaw poświadczenia źródła modelu semantycznego dla tego modelu semantycznego.

Po zakończeniu tych wywołań interfejsu API REST jednostka usługi będzie administratorem nowego obszaru roboczego i właścicielem semantycznego modelu i poświadczeń źródła danych.

Ważne

Istnieje typowe błędne przekonanie, że poświadczenia źródła danych modelu semantycznego są ograniczone na poziomie obszaru roboczego. To nieprawda. Poświadczenia źródła danych są ograniczone do jednostki usługi (lub konta użytkownika) i zakres ten rozszerza się na wszystkie obszary robocze usługi Power BI w dzierżawie firmy Microsoft Entra.

Jednostka usługi może tworzyć poświadczenia źródła danych współużytkowane przez modele semantyczne w różnych obszarach roboczych w różnych dzierżawach klientów, jak pokazano na poniższym diagramie.

Diagram przedstawiający konfigurację dwóch dzierżaw. Każda dzierżawa współużytkuje te same poświadczenia źródła danych.

Gdy poświadczenia źródła danych są współużytkowane przez modele semantyczne należące do różnych dzierżaw klientów, dzierżawy klientów nie są w pełni odizolowane.

Projektowanie strategii przed profilami jednostki usługi

Zrozumienie strategii projektowania przed udostępnieniem funkcji profilu jednostki usługi może pomóc Ci docenić potrzebę korzystania z tej funkcji. Wcześniej deweloperzy utworzyli aplikacje wielodostępne przy użyciu jednej z następujących trzech strategii projektowania:

  • Pojedyncza jednostka usługi
  • Buforowanie jednostki usługi
  • Jedna jednostka usługi na obszar roboczy

Istnieją mocne i słabe strony związane z każdą z tych strategii projektowania.

Strategia projektowania pojedynczej jednostki usługi wymaga jednorazowego utworzenia rejestracji aplikacji Entra firmy Microsoft. W związku z tym wiąże się to z mniejszym obciążeniem administracyjnym niż pozostałe dwie strategie projektowania, ponieważ nie ma potrzeby tworzenia większej liczby rejestracji aplikacji Firmy Microsoft Entra. Ta strategia jest również najprostsza do skonfigurowania, ponieważ nie wymaga pisania dodatkowego kodu, który przełącza kontekst wywołujący między jednostkami usługi podczas wykonywania wywołań interfejsu API REST. Jednak problem z tą strategią projektowania polega na tym, że nie jest skalowany. Obsługuje tylko środowisko wielodostępności, które może dorastać do 1000 obszarów roboczych. Ponadto wydajność ma obniżoną wydajność, ponieważ jednostka usługi ma dostęp do większej liczby obszarów roboczych. Występuje również problem z izolacją dzierżawy klienta, ponieważ pojedyncza jednostka usługi staje się właścicielem każdego modelu semantycznego i wszystkich poświadczeń danych we wszystkich dzierżawach klientów.

Strategia projektowania puli jednostek usługi jest często używana w celu uniknięcia ograniczenia 1000 obszarów roboczych. Umożliwia aplikacji skalowanie do dowolnej liczby obszarów roboczych przez dodanie poprawnej liczby jednostek usługi do puli. Na przykład pula pięciu jednostek usługi umożliwia skalowanie do 5000 obszarów roboczych; pula 80 jednostek usługi umożliwia skalowanie do 80 000 obszarów roboczych itd. Jednak chociaż ta strategia może być skalowana do dużej liczby obszarów roboczych, ma kilka wad. Najpierw wymaga pisania dodatkowego kodu i przechowywania metadanych, aby umożliwić przełączanie kontekstu między jednostkami usługi podczas wykonywania wywołań interfejsu API REST. Po drugie, wiąże się to z większym nakładem pracy administracyjnej, ponieważ należy utworzyć rejestracje aplikacji Microsoft Entra za każdym razem, gdy trzeba zwiększyć liczbę jednostek usługi w puli.

Co więcej, strategia buforowania jednostki usługi nie jest zoptymalizowana pod kątem wydajności, ponieważ pozwala jednostkom usługi stać się członkami setek obszarów roboczych. Nie jest to również idealne rozwiązanie z punktu widzenia izolacji dzierżawy klienta, ponieważ jednostki usługi mogą stać się właścicielami modelu semantycznego i poświadczeń danych udostępnionych w dzierżawach klientów.

Jedna jednostka usługi na strategię projektowania obszaru roboczego obejmuje utworzenie jednostki usługi dla każdej dzierżawy klienta. Z teoretycznej perspektywy ta strategia oferuje najlepsze rozwiązanie, ponieważ optymalizuje wydajność wywołań interfejsu API REST, zapewniając prawdziwą izolację modeli semantycznych i poświadczeń źródła danych na poziomie obszaru roboczego. Jednak to, co działa najlepiej w teorii, nie zawsze działa najlepiej w praktyce. Wynika to z faktu, że wymóg utworzenia jednostki usługi dla każdej dzierżawy klienta jest niepraktyczny dla wielu organizacji. Dzieje się tak, ponieważ niektóre organizacje mają formalne procesy zatwierdzania lub wymagają nadmiernej biurokracji w celu utworzenia rejestracji aplikacji Firmy Microsoft Entra. Te powody mogą uniemożliwić przyznanie aplikacji niestandardowej urzędu, który musi utworzyć rejestracje aplikacji Firmy Microsoft Entra na żądanie i w zautomatyzowany sposób wymagany przez rozwiązanie.

W mniej typowych scenariuszach, w których aplikacja niestandardowa otrzymała odpowiednie uprawnienia, może użyć interfejsu API programu Microsoft Graph do utworzenia rejestracji aplikacji Microsoft Entra na żądanie. Jednak aplikacja niestandardowa jest często złożona do opracowywania i wdrażania, ponieważ musi w jakiś sposób śledzić poświadczenia uwierzytelniania dla każdej rejestracji aplikacji Firmy Microsoft Entra. Musi również uzyskiwać dostęp do tych poświadczeń zawsze, gdy musi uwierzytelnić się i uzyskać tokeny dostępu dla poszczególnych jednostek usługi.

Profile jednostki usługi

Funkcja profilów jednostki usługi została zaprojektowana tak, aby ułatwić zarządzanie zawartością organizacji w usłudze Power BI i wydajniejsze korzystanie z pojemności. Pomagają one sprostać trzem konkretnym wyzwaniom, które wiążą się z najniższym nakładem pracy deweloperów i nakładem pracy. Te wyzwania obejmują:

  • Skalowanie do dużej liczby obszarów roboczych.
  • Optymalizacja wydajności wywołań interfejsu API REST.
  • Izolowanie modeli semantycznych i poświadczeń źródła danych na poziomie dzierżawy klienta.

Podczas projektowania aplikacji wielodostępnej przy użyciu profilów jednostki usługi można skorzystać z zalet trzech strategii projektowych (opisanych w poprzedniej sekcji) przy jednoczesnym unikaniu powiązanych słabości.

Profile jednostki usługi to konta lokalne utworzone w kontekście usługi Power BI. Jednostka usługi może używać operacji interfejsu Profiles API REST do tworzenia nowych profilów jednostki usługi. Jednostka usługi może tworzyć własne zestawy profilów jednostki usługi dla aplikacji niestandardowej i zarządzać nimi, jak pokazano na poniższym diagramie.

Diagram przedstawiający jednostkę usługi tworzącą trzy profile jednostki usługi w usłudze Power BI.

Zawsze istnieje relacja nadrzędny-podrzędna między jednostką usługi a utworzonymi profilami jednostki usługi. Nie można utworzyć profilu jednostki usługi jako jednostki autonomicznej. Zamiast tego należy utworzyć profil jednostki usługi przy użyciu określonej jednostki usługi, a jednostka usługi służy jako element nadrzędny profilu. Ponadto profil jednostki usługi nigdy nie jest widoczny dla kont użytkowników lub innych jednostek usługi. Profil jednostki usługi może być widoczny tylko i używany przez jednostkę usługi, która ją utworzyła.

Profile jednostki usługi nie są znane firmie Microsoft Entra

Chociaż sama jednostka usługi i jego podstawowa rejestracja aplikacji Microsoft Entra są znane firmie Microsoft Entra, identyfikator Entra firmy Microsoft nie wie nic o profilach jednostki usługi. Dzieje się tak dlatego, że profile jednostki usługi są tworzone przez usługę Power BI i istnieją tylko w podsystemie usługa Power BI, który kontroluje zabezpieczenia i autoryzację usługi Power BI.

Fakt, że profile jednostki usługi nie są znane identyfikatorowi Entra firmy Microsoft, mają zarówno zalety, jak i wady. Główną zaletą jest to, że aplikacja Osadzanie dla scenariusza klienta nie wymaga żadnych specjalnych uprawnień firmy Microsoft Entra do tworzenia profilów jednostki usługi. Oznacza to również, że aplikacja może tworzyć zestaw tożsamości lokalnych, które są oddzielone od firmy Microsoft Entra i zarządzać nimi.

Istnieją jednak również wady. Ponieważ profile jednostki usługi nie są znane firmie Microsoft Entra, nie można dodać profilu jednostki usługi do grupy Microsoft Entra w celu niejawnego udzielenia mu dostępu do obszaru roboczego. Ponadto zewnętrzne źródła danych, takie jak usługa Azure SQL Database lub Azure Synapse Analytics, nie mogą rozpoznawać profilów jednostki usługi jako tożsamości podczas nawiązywania połączenia z bazą danych. Dlatego jedna jednostka usługi na strategię projektowania obszaru roboczego (tworzenie jednostki usługi dla każdej dzierżawy klienta) może być lepszym wyborem, jeśli istnieje wymóg łączenia się z tymi źródłami danych przy użyciu oddzielnej jednostki usługi z unikatowymi poświadczeniami uwierzytelniania dla każdej dzierżawy klienta.

Profile jednostki usługi to jednostki zabezpieczeń pierwszej klasy

Chociaż profile jednostki usługi nie są znane firmie Microsoft Entra, usługa Power BI rozpoznaje je jako podmioty zabezpieczeń pierwszej klasy. Podobnie jak konto użytkownika lub jednostka usługi, można dodać profile jednostki usługi do roli obszaru roboczego (jako administrator lub członek). Można również utworzyć go jako właściciela modelu semantycznego i właściciela poświadczeń źródła danych. Z tych powodów utworzenie nowego profilu jednostki usługi dla każdej nowej dzierżawy klienta jest najlepszym rozwiązaniem.

Diagram przedstawiający wiele dzierżaw klientów, z których każdy ma własne profile jednostki usługi.

Napiwek

Podczas tworzenia aplikacji osadzania dla scenariusza klienta przy użyciu profilów jednostki usługi wystarczy utworzyć tylko jedną rejestrację aplikacji Microsoft Entra, aby zapewnić aplikacji pojedynczą jednostkę usługi. Takie podejście znacznie obniża nakład pracy administracyjnej w porównaniu z innymi strategiami projektowania wielodostępności, w przypadku gdy konieczne jest utworzenie dodatkowych rejestracji aplikacji Microsoft Entra na bieżąco po wdrożeniu aplikacji w środowisku produkcyjnym.

Wykonywanie wywołań interfejsu API REST jako profilu jednostki usługi

Aplikacja może wykonywać wywołania interfejsu API REST przy użyciu tożsamości profilu jednostki usługi. Oznacza to, że może wykonywać sekwencję wywołań interfejsu API REST w celu aprowizacji i konfigurowania nowej dzierżawy klienta.

  1. Gdy profil jednostki usługi tworzy nowy obszar roboczy, usługa Power BI automatycznie dodaje ten profil jako administrator obszaru roboczego.
  2. Gdy profil jednostki usługi importuje plik programu Power BI Desktop w celu utworzenia modelu semantycznego, usługa Power BI ustawia ten profil jako właściciela modelu semantycznego.
  3. Gdy profil jednostki usługi ustawia poświadczenia źródła danych, usługa Power BI ustawia ten profil jako właściciel poświadczeń źródła danych.

Ważne jest, aby zrozumieć, że jednostka usługi ma tożsamość w usłudze Power BI, która jest oddzielona i różni się od tożsamości swoich profilów. Zapewnia to wybór jako deweloper. Wywołania interfejsu API REST można wykonywać przy użyciu tożsamości profilu jednostki usługi. Alternatywnie można wykonywać wywołania interfejsu API REST bez profilu, który używa tożsamości jednostki usługi nadrzędnej.

Zalecamy wykonywanie wywołań interfejsu API REST jako jednostki usługi nadrzędnej podczas tworzenia, wyświetlania lub usuwania profilów jednostki usługi. Aby wykonać wszystkie inne wywołania interfejsu API REST, należy użyć profilu jednostki usługi. Te inne wywołania mogą tworzyć obszary robocze, importować pliki programu Power BI Desktop, aktualizować parametry modelu semantycznego i ustawiać poświadczenia źródła danych. Mogą również pobierać metadane elementu obszaru roboczego i generować tokeny osadzania.

Rozważmy przykład, w którym należy skonfigurować dzierżawę klienta dla klienta o nazwie Contoso. Pierwszym krokiem jest wywołanie interfejsu API REST w celu utworzenia profilu jednostki usługi z nazwą wyświetlaną ustawioną na contoso. To wywołanie jest wykonywane przy użyciu tożsamości jednostki usługi. Wszystkie pozostałe kroki konfiguracji używają profilu jednostki usługi, aby wykonać następujące zadania:

  1. Utwórz obszar roboczy.
  2. Skojarz obszar roboczy z pojemnością.
  3. Zaimportuj plik programu Power BI Desktop.
  4. Ustaw parametry modelu semantycznego.
  5. Ustaw poświadczenia źródła danych.
  6. Skonfiguruj zaplanowane odświeżanie danych.

Należy pamiętać, że dostęp do obszaru roboczego i jego zawartości należy wykonać przy użyciu tożsamości profilu jednostki usługi, który został użyty do utworzenia dzierżawy klienta. Ważne jest również, aby zrozumieć, że jednostka usługi nadrzędnej nie potrzebuje dostępu do obszaru roboczego ani jego zawartości.

Napiwek

Pamiętaj: Podczas wykonywania wywołań interfejsu API REST użyj jednostki usługi, aby utworzyć profile jednostki usługi i zarządzać nimi, a następnie użyć profilu jednostki usługi do tworzenia, konfigurowania i uzyskiwania dostępu do zawartości usługi Power BI.

Korzystanie z operacji interfejsu API REST profilów

Grupa operacji interfejsu API REST profilów obejmuje operacje, które tworzą profile jednostki usługi i zarządzają nimi:

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

Tworzenie profilu jednostki usługi

Użyj operacji Create Profile REST API (Tworzenie interfejsu API REST profilu ), aby utworzyć profil jednostki usługi. Należy ustawić displayName właściwość w treści żądania, aby podać nazwę wyświetlaną nowej dzierżawy. Wartość musi być unikatowa we wszystkich profilach należących do jednostki usługi. Wywołanie zakończy się niepowodzeniem, jeśli dla jednostki usługi istnieje już inny profil o tej nazwie wyświetlanej.

Pomyślne wywołanie zwraca id właściwość , która jest identyfikatorem GUID reprezentującym profil. Podczas tworzenia aplikacji korzystających z profilów jednostki usługi zalecamy przechowywanie nazw wyświetlanych profilów i ich wartości identyfikatorów w niestandardowej bazie danych. Dzięki temu aplikacja może pobrać identyfikatory.

Jeśli programujesz przy użyciu zestawu SDK platformy .NET usługi Power BI, możesz użyć Profiles.CreateProfile metody , która zwraca ServicePrincipalProfile obiekt reprezentujący nowy profil. Ułatwia to określenie id wartości właściwości.

Oto przykład tworzenia profilu jednostki usługi i udzielania mu dostępu do obszaru roboczego.

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

W usługa Power BI w okienku Dostęp do obszaru roboczego można określić, które tożsamości, w tym podmioty zabezpieczeń, mają dostęp.

Zrzut ekranu przedstawiający zrzut ekranu przedstawiający okienko dostęp do obszaru roboczego. Zostanie wyświetlony profil jednostki usługi z nazwą wyświetlaną firmy Contoso, która ma uprawnienia administratora.

Usuwanie profilu jednostki usługi

Użyj operacji Usuń interfejs API REST profilu, aby usunąć profil jednostki usługi. Ta operacja może być wywoływana tylko przez jednostkę usługi nadrzędnej.

Jeśli programujesz przy użyciu zestawu .NET SDK usługi Power BI, możesz użyć Profiles.DeleteProfile metody .

Pobieranie wszystkich profilów jednostki usługi

Użyj operacji uzyskiwania interfejsu API REST profilów , aby pobrać listę profilów jednostki usługi należących do nazwy głównej usługi wywołującej. Ta operacja zwraca ładunek JSON zawierający id właściwości i displayName każdego profilu jednostki usługi.

Jeśli programujesz przy użyciu zestawu .NET SDK usługi Power BI, możesz użyć metody Profiles.GetProfiles .

Wykonywanie wywołań interfejsu API REST przy użyciu profilu jednostki usługi

Istnieją dwa wymagania dotyczące wykonywania wywołań interfejsu API REST przy użyciu profilu jednostki usługi:

  • Należy przekazać token dostępu dla nadrzędnej jednostki usługi w nagłówku Autoryzacja .
  • Musisz dołączyć nagłówek o nazwie X-PowerBI-profile-id z wartością identyfikatora profilu jednostki usługi.

Jeśli używasz zestawu .NET SDK usługi Power BI, możesz jawnie ustawić wartość nagłówka X-PowerBI-profile-id , przekazując identyfikator profilu jednostki usługi.

// 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 pokazano w powyższym przykładzie, po dodaniu nagłówka X-PowerBI-profile-id do PowerBIClient obiektu można łatwo wywołać metody, takie jak Groups.GetGroups, więc będą wykonywane przy użyciu profilu jednostki usługi.

Istnieje wygodniejszy sposób ustawiania nagłówka X-PowerBI-profile-id dla PowerBIClient obiektu. Obiekt można zainicjować, przekazując identyfikator profilu do konstruktora.

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

W miarę programowania aplikacji wielodostępnej prawdopodobnie trzeba będzie przełączać się między wykonywaniem wywołań jako jednostką usługi nadrzędnej i wykonywaniem wywołań jako profilu jednostki usługi. Przydatne podejście do zarządzania przełączaniem kontekstu polega na zadeklarowaniu zmiennej na poziomie klasy, która przechowuje PowerBIClient obiekt. Następnie można utworzyć metodę pomocnika, która ustawia zmienną przy użyciu poprawnego obiektu.

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

Jeśli musisz utworzyć profil jednostki usługi lub zarządzać nim, możesz wywołać metodę SetCallingContext bez żadnych parametrów. W ten sposób można tworzyć profile i zarządzać nimi przy użyciu tożsamości jednostki usługi.

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

Jeśli musisz utworzyć i skonfigurować obszar roboczy dla nowej dzierżawy klienta, chcesz wykonać ten kod jako profil jednostki usługi. W związku z tym należy wywołać metodę SetCallingContext , przekazując identyfikator profilu. W ten sposób można utworzyć obszar roboczy przy użyciu tożsamości profilu jednostki usługi.

// 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 użyciu określonego profilu jednostki usługi do utworzenia i skonfigurowania obszaru roboczego należy nadal używać tego samego profilu do tworzenia i konfigurowania zawartości obszaru roboczego. Nie ma potrzeby wywoływania SetCallingContext metody w celu ukończenia instalacji.

Przykład dla deweloperów

Zachęcamy do pobrania przykładowej aplikacji o nazwie AppOwnsDataMultiTenant.

Ta przykładowa aplikacja została opracowana przy użyciu platformy .NET 6 i ASP.NET oraz pokazuje, jak zastosować wskazówki i zalecenia opisane w tym artykule. Możesz przejrzeć kod, aby dowiedzieć się, jak opracować aplikację wielodostępną, która implementuje scenariusz Osadzanie dla klienta przy użyciu profilów jednostki usługi.

Powiązana zawartość

Aby uzyskać więcej informacji na temat tego artykułu, zapoznaj się z następującymi zasobami: