Profile jednostki usługi dla aplikacji wielodostępnych w usłudze Power BI Embedded
W tym artykule wyjaśniono, jak niezależnego dostawcy oprogramowania lub innego właściciela aplikacji usługi Power BI Embedded z wieloma klientami może używać profilów jednostki usługi do mapowania danych poszczególnych klientów i zarządzania nimi w ramach rozwiązania osadzania usługi Power BI dla klientów. Profile jednostki usługi umożliwiają niezależnemu dostawcy oprogramowania tworzenie skalowalnych aplikacji, które umożliwiają lepszą izolację danych klientów i ustanowienie ściślejszych granic zabezpieczeń między klientami. W tym artykule omówiono zalety i ograniczenia tego rozwiązania.
Uwaga
Słowo dzierżawa w usłudze Power BI może czasami odwoływać się do dzierżawy firmy Microsoft Entra. W tym artykule używamy jednak terminu multitenancy do opisania rozwiązania, w którym pojedyncze wystąpienie aplikacji oprogramowania obsługuje wielu klientów lub organizacje (dzierżawy) wymagające fizycznego i logicznego rozdzielenia danych. Na przykład konstruktor aplikacji usługi Power BI może przydzielić oddzielny obszar roboczy dla każdego z jego klientów (lub dzierżaw), jak pokazano poniżej. Ci klienci nie muszą być dzierżawami firmy Microsoft Entra, dlatego nie należy mylić terminu wielodostępna aplikacja używana tutaj z wielodostępną aplikacją firmy Microsoft.
Profil jednostki usługi to profil utworzony przez jednostkę usługi. Aplikacja niezależnego dostawcy oprogramowania wywołuje interfejs API usługi Power BI przy użyciu profilu jednostki usługi, jak wyjaśniono w tym artykule.
Jednostka usługi aplikacji niezależnego dostawcy oprogramowania tworzy inny profil usługi Power BI dla każdego klienta lub dzierżawy. Gdy klient odwiedza aplikację niezależnego dostawcy oprogramowania, aplikacja używa odpowiedniego profilu do wygenerowania tokenu osadzania, który będzie używany do renderowania raportu w przeglądarce.
Użycie profilów jednostki usługi umożliwia aplikacji niezależnego dostawcy oprogramowania hostowanie wielu klientów w jednej dzierżawie usługi Power BI. Każdy profil reprezentuje jednego klienta w usłudze Power BI. Innymi słowy każdy profil tworzy zawartość usługi Power BI i zarządza nią dla danych określonego klienta.
Uwaga
Ten artykuł jest przeznaczony dla organizacji, które chcą skonfigurować wielodostępną aplikację przy użyciu profilów jednostki usługi. Jeśli Twoja organizacja ma już aplikację, która obsługuje wielodostępność i chcesz przeprowadzić migrację do modelu profilu jednostki usługi, zobacz Migrowanie do modelu profilów jednostki usługi.
Konfigurowanie zawartości usługi Power BI obejmuje następujące kroki:
- Tworzenie profilu
- Ustawianie uprawnień profilu
- Tworzenie obszaru roboczego dla każdego klienta
- Importowanie raportów i modeli semantycznych do obszaru roboczego
- Ustawianie szczegółów połączenia modelu semantycznego w celu nawiązania połączenia z danymi klienta
- Usuwanie uprawnień z jednostki usługi (opcjonalnie, ale pomaga w skalowalności)
- Osadzanie raportu w aplikacji
Wszystkie powyższe kroki można w pełni zautomatyzować przy użyciu interfejsów API REST usługi Power BI.
Wymagania wstępne
Przed utworzeniem profilów jednostki usługi należy wykonać następujące czynności:
- Skonfiguruj jednostkę usługi, wykonując trzy pierwsze kroki osadzania zawartości usługi Power BI przy użyciu jednostki usługi.
- Na koncie administratora dzierżawy usługi Power BI włącz tworzenie profilów w dzierżawie przy użyciu tej samej grupy zabezpieczeń, która została użyta podczas tworzenia jednostki usługi.
Tworzenie profilu
Profile można tworzyć, aktualizować i usuwać przy użyciu interfejsu API REST profilów.
Aby na przykład utworzyć 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"}
Jednostka usługi może również wywołać interfejs API REST profilów GET, aby uzyskać listę swoich profilów. Na przykład:
GET https://api.powerbi.com/v1.0/myorg/profiles HTTP/1.1
Authorization: Bearer eyJ0eXA…UUPA
Uprawnienia profilu
Każdy interfejs API, który przyznaje użytkownikowi uprawnienia do elementów usługi Power BI, może również udzielić uprawnień profilu do elementów usługi Power BI. Na przykład interfejs API dodawania użytkownika grupy może służyć do udzielania uprawnień profilu do obszaru roboczego.
Podczas korzystania z profilów ważne są następujące kwestie:
- Profil należy do jednostki usługi, która ją utworzyła, i może być używany tylko przez jednostkę usługi.
- Nie można zmienić właściciela profilu po utworzeniu.
- Profil nie jest tożsamością autonomiczną. Potrzebuje tokenu jednostki usługi Microsoft Entra do wywoływania interfejsów API REST usługi Power BI.
Aplikacje niezależnego dostawcy oprogramowania nazywają interfejsy API REST usługi Power BI, podając token entra jednostki usługi w nagłówku Autoryzacja oraz identyfikator profilu w nagłówku X-PowerBI-Profile-Id . Na przykład:
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
Tworzenie obszaru roboczego
Obszary robocze usługi Power BI są używane do hostowania elementów usługi Power BI, takich jak raporty i modele semantyczne.
Każdy profil musi:
Tworzenie co najmniej jednego obszaru roboczego usługi 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" }Udziel uprawnień dostępu do obszaru roboczego. Profil jednostki usługi musi mieć dostęp administratora do obszaru roboczego.
Przypisywanie obszaru roboczego do pojemności
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" }
Przeczytaj więcej na temat obszarów roboczych usługi Power BI.
Importowanie raportów i modeli semantycznych
Użyj programu Power BI Desktop , aby przygotować raporty połączone z danymi klienta lub przykładowymi danymi. Następnie możesz użyć interfejsu API importu, aby zaimportować zawartość do utworzonego obszaru roboczego.
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=
Użyj parametrów zestawu danych, aby utworzyć semantyczny model, który może łączyć się ze źródłami danych różnych klientów. Następnie użyj interfejsu API aktualizacji parametrów , aby zdefiniować dane klientów, z którymi łączy się model semantyczny.
Ustawianie połączenia modelu semantycznego
Dostawcy oprogramowania internetowego zwykle przechowują dane swoich klientów na jeden z dwóch sposobów:
W obu przypadkach w usłudze Power BI należy utworzyć modele semantyczne z jedną dzierżawą (jeden model semantyczny na klienta).
Oddzielna baza danych dla każdego klienta
Jeśli aplikacja niezależnego dostawcy oprogramowania ma oddzielną bazę danych dla każdego klienta, utwórz modele semantyczne z jedną dzierżawą w usłudze Power BI. Podaj każdy model semantyczny ze szczegółami połączenia wskazującymi pasującą bazę danych. Użyj jednej z następujących metod, aby uniknąć tworzenia wielu identycznych raportów z różnymi szczegółami połączenia:
Parametry modelu semantycznego: utwórz model semantyczny z parametrami w szczegółach połączenia (np. nazwa serwera SQL, nazwa bazy danych SQL). Następnie zaimportuj raport do obszaru roboczego klienta i zmień parametry tak, aby odpowiadały szczegółom bazy danych klienta.
Aktualizowanie interfejsu API źródła danych: utwórz plik pbix wskazujący źródło danych z przykładową zawartością. Następnie zaimportuj plik pbix do obszaru roboczego klienta i zmień szczegóły połączenia przy użyciu interfejsu API aktualizacji źródła danych.
Pojedyncza wielodostępna baza danych
Jeśli aplikacja niezależnego dostawcy oprogramowania używa jednej bazy danych dla wszystkich swoich klientów, rozdziel klientów na różne modele semantyczne w usłudze Power BI w następujący sposób:
Utwórz raport przy użyciu parametrów , które pobierają tylko dane odpowiedniego klienta. Następnie zaimportuj raport do obszaru roboczego klienta i zmień parametry , aby pobrać tylko dane odpowiedniego klienta.
Embed a report (Osadzanie raportu)
Po zakończeniu instalacji można osadzać raporty klientów i inne elementy w aplikacji przy użyciu tokenu osadzania.
Gdy klient odwiedza aplikację, użyj odpowiedniego profilu, aby wywołać interfejs API GenerateToken. Użyj wygenerowanego tokenu osadzania, aby osadzić raport lub inne elementy w przeglądarce klienta.
Aby wygenerować token osadzania:
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 projektowania
Przed skonfigurowaniem wielodostępnego rozwiązania opartego na profilu należy pamiętać o następujących problemach:
- Skalowalność
- Automatyzacja i złożoność operacyjna
- Wymagania dotyczące wielu regionów geograficznych
- Efektywność kosztowa
- Zabezpieczenia na poziomie wiersza
Skalowalność
Oddzielając dane na oddzielne modele semantyczne dla każdego klienta, można zminimalizować potrzebę dużych modeli semantycznych. Gdy pojemność zostanie przeciążona, można wykluczyć nieużywane modele semantyczne, aby zwolnić pamięć dla aktywnych modeli semantycznych. Ta optymalizacja jest niemożliwa dla pojedynczego dużego modelu semantycznego. Korzystając z wielu modeli semantycznych, można również w razie potrzeby rozdzielić dzierżawy na wiele pojemności usługi Power BI.
Bez profilów jednostka usługi jest ograniczona do 1000 obszarów roboczych. Aby wyeliminować ten limit, jednostka usługi może utworzyć wiele profilów, w których każdy profil może uzyskiwać dostęp do 1000 obszarów roboczych. W przypadku wielu profilów aplikacja niezależnego dostawcy oprogramowania może odizolować zawartość każdego klienta przy użyciu odrębnych kontenerów logicznych.
Gdy profil jednostki usługi ma dostęp do obszaru roboczego, można usunąć dostęp jednostki usługi nadrzędnej do obszaru roboczego, aby uniknąć problemów ze skalowalnością.
Nawet w przypadku tych zalet należy wziąć pod uwagę potencjalną skalę aplikacji. Na przykład liczba elementów obszaru roboczego, do których może uzyskać dostęp profil, jest ograniczona. Obecnie profil ma takie same limity jak zwykły użytkownik. Jeśli aplikacja niezależnego dostawcy oprogramowania umożliwia użytkownikom końcowym zapisywanie spersonalizowanej kopii osadzonych raportów, profil klienta będzie miał dostęp do wszystkich utworzonych raportów wszystkich użytkowników. Ten model może ostatecznie przekroczyć limit.
Automatyzacja i złożoność operacyjna
W przypadku separacji opartej na profilu usługi Power BI może być konieczne zarządzanie setkami lub tysiącami elementów. Dlatego ważne jest, aby zdefiniować procesy, które często występują w zarządzaniu cyklem życia aplikacji, i upewnić się, że masz odpowiedni zestaw narzędzi do wykonywania tych operacji na dużą skalę. Niektóre z tych operacji obejmują:
- Dodawanie nowej dzierżawy
- Aktualizowanie raportu dla niektórych lub wszystkich dzierżaw
- Aktualizowanie schematu modelu semantycznego dla niektórych lub wszystkich dzierżaw
- Nieplanowane dostosowania dla określonych dzierżaw
- Częstotliwość odświeżania modelu semantycznego
Na przykład utworzenie profilu i obszaru roboczego dla nowej dzierżawy jest typowym zadaniem, które można w pełni zautomatyzować za pomocą interfejsu API REST usługi Power BI.
Wymagania dotyczące wielu regionów geograficznych
Obsługa funkcji Multi-Geo dla usługi Power BI Embedded oznacza, że dostawcy oprogramowania i organizacje tworzące aplikacje korzystające z usługi Power BI Embedded do osadzania analizy w aplikacjach mogą teraz wdrażać swoje dane w różnych regionach na całym świecie. Aby obsługiwać różnych klientów w różnych regionach, przypisz obszar roboczy klienta do pojemności w żądanym regionie. To zadanie jest prostą operacją, która nie wiąże się z dodatkowymi kosztami. Jeśli jednak masz klientów, którzy potrzebują danych z wielu regionów, profil dzierżawy powinien zduplikować wszystkie elementy do wielu obszarów roboczych przypisanych do różnych pojemności regionalnych. Duplikowanie może zwiększyć złożoność zarówno kosztów, jak i zarządzania.
Ze względów zgodności nadal możesz utworzyć wiele dzierżaw usługi Power BI w różnych regionach. Przeczytaj więcej na temat funkcji multi-geo.
Efektywność kosztowa
Deweloperzy aplikacji korzystający z usługi Power BI Embedded muszą zakupić pojemność usługi Power BI Embedded. Model separacji oparty na profilu działa dobrze z pojemnościami, ponieważ:
Najmniejszy obiekt, który można przypisać niezależnie do pojemności, to obszar roboczy (na przykład nie można przypisać raportu). Oddzielając klientów według profilów, uzyskujesz różne obszary robocze — jeden na klienta. Dzięki temu uzyskasz pełną elastyczność zarządzania poszczególnymi klientami zgodnie z ich potrzebami w zakresie wydajności i zoptymalizuj wykorzystanie pojemności przez skalowanie w górę lub w dół. Na przykład można zarządzać dużymi i istotnymi klientami z dużą ilością i zmiennością w oddzielnej pojemności, aby zapewnić spójny poziom usług, jednocześnie grupując mniejszych klientów w innej pojemności w celu optymalizacji kosztów.
Oddzielenie obszarów roboczych oznacza również oddzielenie modeli semantycznych między dzierżawami, dzięki czemu modele danych znajdują się w mniejszych fragmentach, a nie w jednym dużym modelu semantycznym. Te mniejsze modele umożliwiają wydajniejsze zarządzanie użyciem pamięci. Małe, nieużywane modele semantyczne można eksmitować po okresie braku aktywności, aby zachować dobrą wydajność.
Podczas zakupu pojemności należy wziąć pod uwagę limit liczby odświeżeń równoległych, ponieważ procesy odświeżania mogą potrzebować dodatkowej pojemności, jeśli masz wiele modeli semantycznych.
Zabezpieczenia na poziomie wiersza
W tym artykule wyjaśniono, jak używać profilów do tworzenia oddzielnego modelu semantycznego dla każdego klienta. Alternatywnie aplikacje niezależnego dostawcy oprogramowania mogą przechowywać wszystkie dane swoich klientów w jednym dużym modelu semantycznym i używać zabezpieczeń na poziomie wiersza w celu ochrony danych każdego klienta. Takie podejście może być wygodne dla niezależnych dostawców oprogramowania, które mają stosunkowo niewielu klientów i małe i średnie modele semantyczne, ponieważ:
- Istnieje tylko jeden raport i jeden semantyczny model do utrzymania
- Proces dołączania dla nowych klientów można uprościć
Przed użyciem zabezpieczeń na poziomie wiersza upewnij się jednak, że rozumiesz jego ograniczenia. Wszystkie dane dla wszystkich klientów znajdują się w jednym dużym modelu semantycznym usługi Power BI. Ten semantyczny model działa w pojedynczej pojemności z własnym skalowaniem i innymi ograniczeniami.
Nawet jeśli używasz profilów jednostek usługi do oddzielania danych klientów, nadal możesz używać zabezpieczeń na poziomie wiersza w ramach modelu semantycznego pojedynczego klienta, aby zapewnić różnym grupom dostęp do różnych części danych. Na przykład można użyć zabezpieczeń na poziomie wiersza, aby uniemożliwić członkom jednego działu uzyskiwanie dostępu do danych innego działu w tej samej organizacji.
Rozważania i ograniczenia
- Profile jednostki usługi są obsługiwane tylko za pośrednictwem interfejsu API REST usługi Power BI, zestawu .NET SDK usługi Power BI oraz punktu końcowego XMLA i modelu obiektów tabelarycznych (TOM) w przypadku korzystania z bibliotek klienckich usług Analysis Services w wersji 16.0.139.27 lub nowszej. Profile jednostki usługi nie są obsługiwane w usłudze Power BI za pośrednictwem punktu końcowego XMLA ani tabelarycznego modelu obiektów (TOM) ze starszymi bibliotekami klienckimi.
- Profile jednostki usługi nie są obsługiwane w usługach Azure Analysis Services (AAS) w trybie połączenia na żywo.
- Maksymalna liczba profilów, które może mieć jedna jednostka usługi, wynosi 100 000.
Ograniczenia pojemności usługi Power BI
- Każda pojemność może używać tylko przydzielonej pamięci i rdzeni wirtualnych, zgodnie z zakupiona jednostka SKU. W przypadku zalecanego rozmiaru modelu semantycznego dla każdej jednostki SKU zapoznaj się z tematem Premium — duże modele semantyczne.
- Aby użyć modelu semantycznego większego niż 10 GB, użyj pojemności Premium i włącz ustawienie Duże modele semantyczne.
- W przypadku liczby odświeżeń, które mogą być uruchamiane współbieżnie w ramach pojemności, należy odwołać się do zarządzania zasobami i optymalizacji.
Zarzadzanie jednostkami usługi
Zmienianie jednostki usługi
W usłudze Power BI profil należy do jednostki usługi, która ją utworzyła. Oznacza to, że profil nie może być udostępniany innym podmiotom zabezpieczeń. Jeśli chcesz zmienić jednostkę usługi z jakiegokolwiek powodu, musisz ponownie utworzyć wszystkie profile i udostępnić nowe profile dostępu do odpowiednich obszarów roboczych. Często aplikacja niezależnego dostawcy oprogramowania musi zapisywać mapowanie między identyfikatorem profilu a identyfikatorem klienta, aby w razie potrzeby wybrać odpowiedni profil. Jeśli zmienisz jednostkę usługi i ponownie utworzysz profile, identyfikatory również zmienią się i może być konieczne zaktualizowanie mapowania w bazie danych aplikacji niezależnego dostawcy oprogramowania.
Usuwanie jednostki usługi
Ostrzeżenie
Podczas usuwania jednostki usługi należy zachować ostrożność. Nie chcesz przypadkowo utracić danych ze wszystkich skojarzonych profilów.
Jeśli usuniesz jednostkę usługi w usłudze Active Directory, wszystkie jego profile w usłudze Power BI zostaną usunięte. Jednak usługa Power BI nie usunie zawartości natychmiast, więc administrator dzierżawy nadal będzie mógł uzyskiwać dostęp do obszarów roboczych. Należy zachować ostrożność podczas usuwania jednostki usługi używanej w systemie produkcyjnym, szczególnie podczas tworzenia profilów przy użyciu tej jednostki usługi w usłudze Power BI. Jeśli usuniesz jednostkę usługi, która utworzyła profile, pamiętaj, że musisz ponownie utworzyć wszystkie profile, udostępnić nowe profile dostępu do odpowiednich obszarów roboczych i zaktualizować identyfikatory profilów w bazie danych aplikacji niezależnego dostawcy oprogramowania.
Separacja danych
Gdy dane są oddzielone profilami jednostki usługi, proste mapowanie między profilem a klientem uniemożliwia jednemu klientowi wyświetlanie zawartości innego klienta. Użycie jednej jednostki usługi wymaga, aby jednostka usługi ma dostęp do wszystkich różnych obszarów roboczych we wszystkich profilach.
Aby dodać dodatkową separację, przypisz oddzielną jednostkę usługi do każdej dzierżawy, zamiast mieć jeden dostęp do wielu obszarów roboczych przy użyciu różnych profilów. Przypisywanie oddzielnych jednostek usługi ma kilka zalet, w tym:
- Błąd człowieka lub wyciek poświadczeń nie spowoduje ujawnienia danych wielu dzierżawców.
- Rotacja certyfikatów może odbywać się oddzielnie dla każdej dzierżawy.
Jednak korzystanie z wielu jednostek usługi wiąże się z wysokim kosztem zarządzania. Wybierz tę ścieżkę tylko wtedy, gdy potrzebujesz dodatkowego rozdzielenia. Należy pamiętać, że konfiguracja danych do pokazania użytkownika końcowego jest zdefiniowana podczas generowania tokenu osadzania, czyli procesu tylko zaplecza, którego użytkownicy końcowi nie widzą ani nie zmieniają. Żądanie tokenu osadzania przy użyciu profilu specyficznego dla dzierżawy spowoduje wygenerowanie tokenu osadzania dla tego konkretnego profilu, co zapewni rozdzielenie klientów w użyciu.
Jeden raport, wiele modeli semantycznych
Ogólnie rzecz biorąc, masz jeden raport i jeden semantyczny model na dzierżawę. Jeśli masz setki raportów, będziesz mieć setki modeli semantycznych. Czasami może istnieć jeden format raportu z różnymi modelami semantycznymi (na przykład różnymi parametrami lub szczegółami połączenia). Za każdym razem, gdy masz nową wersję raportu, musisz zaktualizować wszystkie raporty dla wszystkich dzierżaw. Chociaż można to zautomatyzować, łatwiej jest zarządzać, jeśli masz tylko jedną kopię raportu. Utwórz obszar roboczy zawierający raport do osadzenia. Podczas wykonywania sesji powiąż raport z modelem semantycznym specyficznym dla dzierżawy. Przeczytaj powiązania dynamiczne, aby uzyskać więcej szczegółów.
Dostosowywanie i tworzenie zawartości
Podczas tworzenia zawartości należy dokładnie rozważyć, kto ma uprawnienia do jej edytowania. Jeśli zezwolisz wielu użytkownikom w każdej dzierżawie na edycję, łatwo jest przekroczyć ograniczenia modelu semantycznego. Jeśli zdecydujesz się na zapewnienie użytkownikom możliwości edytowania, uważnie monitoruj generowanie zawartości i skaluj w górę zgodnie z potrzebami. Z tego samego powodu nie zalecamy używania tej funkcji do personalizacji zawartości, gdzie każdy użytkownik może wprowadzać małe zmiany w raporcie i zapisywać je samodzielnie. Jeśli aplikacja niezależnego dostawcy oprogramowania zezwala na personalizację zawartości, rozważ wprowadzenie zasad przechowywania obszaru roboczego dla zawartości specyficznej dla użytkownika. Zasady przechowywania ułatwiają usuwanie zawartości, gdy użytkownicy przechodzą na nowe stanowisko, opuszczają firmę lub przestają korzystać z platformy.
Tożsamość zarządzana przez system
Zamiast jednostki usługi można utworzyć profile przy użyciu przypisanej przez użytkownika lub przypisanejprzez system tożsamości zarządzanej. Tożsamości zarządzane zmniejszają zapotrzebowanie na wpisy tajne i certyfikaty.
Podczas korzystania z tożsamości zarządzanej przez system należy zachować ostrożność, ponieważ:
- Jeśli tożsamość zarządzana przypisana przez system zostanie przypadkowo wyłączona, utracisz dostęp do profilów. Taka sytuacja jest podobna do przypadku usunięcia jednostki usługi.
- Tożsamość zarządzana przypisana przez system jest połączona z zasobem na platformie Azure (aplikacja internetowa). Jeśli usuniesz zasób, tożsamość zostanie usunięta.
- Użycie wielu zasobów (różnych aplikacji internetowych w różnych regionach) spowoduje oddzielne zarządzanie wieloma tożsamościami (każda tożsamość będzie miała własne profile).
Ze względu na powyższe zagadnienia zalecamy użycie tożsamości zarządzanej przypisanej przez użytkownika.
Przykład
Aby uzyskać przykład użycia profilów jednostki usługi do zarządzania środowiskiem wielodostępnym za pomocą osadzania usługi Power BI i App-Owns-Data, pobierz repozytorium App owns data multitenant z usługi Power BI Dev Camp (witryna innej firmy).