Profile jednostki usługi dla aplikacji wielodostępnych w usłudze Power BI Embedded

W tym artykule wyjaśniono, jak niezależny dostawca oprogramowania (ISV) lub inny właściciel aplikacji Power BI Embedded z wieloma klientami może używać profilów jednostki usługi w celu mapowania i zarządzania danymi poszczególnych klientów w ramach rozwiązania Power BI 'osadzanie 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.

Profil jednostki usługi to profil utworzony przez jednostkę usługi. Aplikacja ISV wywołuje interfejsy API Power BI za pomocą profilu jednostki usługi, jak wyjaśniono w tym artykule.

Aplikacja ISV główny serwis tworzy inny profil 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 posłuży do renderowania raportu w przeglądarce.

Użycie profilów jednostki usługi umożliwia aplikacji niezależnego dostawcy oprogramowania (ISV) hostowanie wielu klientów w jednym dzierżawcy 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.

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
• Ustaw szczegóły połączenia modelu semantycznego, aby połączyć się z danymi klienta
• Usunięcie uprawnień z pryncypału 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

Zanim utworzysz profile jednostki usługi, musisz:

• Skonfiguruj jednostkę usługi, wykonując trzy pierwsze kroki z instrukcji Osadzanie zawartości Power BI za pomocą jednostki usługi.
• Z konta administratora dzierżawy usługi Power BI umożliw tworzenie profilów w ramach dzierżawy przy użyciu tej samej grupy zabezpieczeń, którą użyto podczas tworzenia zasadniczej 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"}

Obiekt usługi może również wywołać interfejs REST API GET Profiles, 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 do grupy może być używany do przyznawania uprawnień profilowi 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 tożsamości usługi Microsoft Entra do wywoływania interfejsów API REST Power BI.

Aplikacje niezależnego dostawcy oprogramowania wywołują interfejsy API REST usługi Power BI, podając token jednostki usługi Microsoft Entra 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 głównej 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:

• Oddzielna baza danych dla każdego klienta
• Pojedyncza wielodostępna baza danych

W obu przypadkach powinieneś mieć w usłudze Power BI modele semantyczne o architekturze jeden-tenantowej (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 jednodzierżawcze modele semantyczne 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 parametramiw 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, który wskazuje na źródło danych z przykładową zawartością. Następnie zaimportuj plik .pbix do obszaru roboczego klienta i zmień szczegóły połączenia, korzystając z Update Datasource API.

Pojedyncza wielonajemcowa 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 Twoją 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 w razie potrzeby również rozdzielić dzierżawców na wiele pojemności usługi Power BI.

Bez profilów, jednostka usługi może obsłużyć maksymalnie 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 raportów utworzonych przez wszystkich jego 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 nowego najemcy
• Aktualizowanie raportu dla niektórych lub wszystkich najemców
• Aktualizacja schematu modelu semantycznego dla niektórych lub wszystkich najemców
• Nieplanowane dostosowania dla konkretnych najemców
• Częstotliwość odświeżania modelu semantycznego

Na przykład utworzenie profilu i obszaru roboczego dla nowego użytkownika 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 zasobów w preferowanym 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 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 częściach, zamiast jednej dużej całości semantycznej. Te mniejsze modele umożliwiają wydajniejsze zarządzanie użyciem pamięci. Małe, nieużywane modele semantyczne można usuwać po nieaktywnym okresie, 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żnych dostawców oprogramowania mogą przechowywać wszystkie dane swoich klientów w jednym dużym modelu semantycznym i używać zabezpieczeń na poziomie wiersza do 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 RLS 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 jednej instancji z własnym mechanizmem skalowania i innymi ograniczeniami.

Nawet jeśli używasz profilów głównych usług 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ć RLS (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. Profil jednostki usługi nie jest obsługiwany w Power BI za pośrednictwem punktu końcowego XMLA lub Modelu Obiektów Tabelarycznych (TOM) przy użyciu starszych bibliotek klienckich.
• Profile głównych usług nie są obsługiwane przez 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 zakupionym SKU. W przypadku zalecanego rozmiaru modelu semantycznego dla każdej jednostki SKU zapoznaj się z tematem Duże modele semantyczne Premium.
• 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 użytkownikom. Mając to ograniczenie na uwadze, jeśli chcesz zmienić jednostkę usługi z jakiegokolwiek powodu, musisz ponownie utworzyć wszystkie profile i zapewnić nowym profilom dostęp 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 podmiotu usługi

Jeśli usuniesz jednostkę usługi w usłudze Active Directory, wszystkie jej 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, nadać nowym profilom dostęp do odpowiednich obszarów roboczych i zaktualizować identyfikatory profili w bazie danych aplikacji niezależnego dostawcy oprogramowania (ISV).

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 jednego głównego usługowego wymaga, aby główny usługowy miał 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żdego najemcy.

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 osadzenia, czyli procesu zaplecza, którego użytkownicy końcowi nie mogą zobaczyć ani zmienić. Żądanie tokenu osadzania za pomocą profilu specyficznego dla dzierżawcy spowoduje wygenerowanie tokenu osadzania dla tego profilu, co zapewni odseparowanie klientów przy korzystaniu z usługi.

Jeden raport, wiele modeli semantycznych

Ogólnie rzecz biorąc, masz jeden raport i jeden model semantyczny na najemcę. 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 najemców. 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 trwania sesji powiąż raport z semantycznym modelem 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żdym dzierżawcy na edycję, łatwo 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żesz użyć przypisanej przez użytkownika lub zarządzanej tożsamości przypisanej przez system do tworzenia profili. Tożsamości zarządzane zmniejszają potrzebę używania haseł i certyfikatów.

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, gdy podmiot usługi zostaje usunięty.
• 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 profili głównej usługi do zarządzania środowiskiem wielu dzierżawców za pomocą osadzania Power BI i App-Owns-Data, pobierz repozytorium App owns data multitenant z Power BI Dev Camp (strona zewnętrzna).

Powiązana zawartość

• Korzystanie z zestawu SDK Power BI z pryncypałami usługi
• Migrowanie aplikacji wielodostępnych do modelu profilów jednostki usługi
• Opracowywanie skalowalnych aplikacji wielodostępnych przy użyciu osadzania w usłudze Power BI