Migrowanie aplikacji dla wielu klientów do modelu profilów jednostki usługi

W tym artykule opisano, jak można uzyskać lepszą skalowalność, migrując osadzone aplikacje analityczne usługi Power BI dla wielu klientów do modelu profilów jednostki usługi.

Profile jednostki usługi ułatwiają zarządzanie zawartością organizacyjną w usłudze Power BI i wydajniejsze korzystanie z pojemności.

Uwaga

Ten artykuł jest przeznaczony dla organizacji, które mają już aplikację, która obsługuje wielu klientów z jednej dzierżawy usługi Power BI.

Nie wszystkie aplikacje korzystają z modelu jednostki usługi. Na przykład następujące aplikacje nie powinny migrować:

  • Małe aplikacje, które utrzymują jedną jednostkę usługi z niewielką liczbą obiektów.
  • Aplikacje korzystające z jednej jednostki usługi na klienta

Wymagania wstępne

Przed rozpoczęciem migracji ważne jest zapoznanie się z profilami jednostki usługi.

Należy również wykonać następujące czynności:

Screenshot of Admin portal switch.

Migrowanie do profilów jednostki usługi

Migracja do profilów jednostki usługi obejmuje następujące kroki:

  1. Utwórz profile, jeden profil dla każdego klienta.
  2. Organizowanie obszarów roboczych.
  3. Zmień kod aplikacji, aby używał profilów.
  4. Przetestuj aplikację przy użyciu modelu profilów.
  5. Czyszczenie nadmiarowych uprawnień.

Tworzenie profilów (wymagane)

Użyj interfejsu API REST profilów z utworzoną jednostką usługi, aby utworzyć jeden profil dla każdego klienta.

Dobrym pomysłem jest zapisanie mapowania każdego identyfikatora klienta danych z odpowiednim identyfikatorem profilu w bazie danych. To mapowanie będzie potrzebne później, aby wykonać wywołania interfejsu API z profilem dzierżawy.

Organizowanie obszarów roboczych

Najprostszym sposobem zarządzania danymi jest utrzymanie jednego obszaru roboczego na klienta. Jeśli aplikacja korzysta już z tego modelu, nie musisz tworzyć nowych obszarów roboczych. Jednak nadal musisz podać każdemu profilowi Administracja dostęp do odpowiedniego obszaru roboczego przy użyciu interfejsu API dodaj użytkownika grupy.

Jeśli nie masz jednego obszaru roboczego na klienta, użyj odpowiedniego profilu, aby wywołać wywołanie interfejsu API tworzenia użytkownika grupy w celu utworzenia nowego obszaru roboczego dla każdego klienta.

Organizowanie elementów w obszarach roboczych

Teraz powinien istnieć profil i obszar roboczy dla każdego klienta. Jeśli w poprzednim kroku utworzono nowe obszary robocze, musisz zaimportować elementy (takie jak raporty i modele semantyczne) do tych obszarów roboczych. Importowane modele semantyczne zależą od bieżącego rozwiązania:

  • Jeśli aplikacja używa oddzielnego modelu semantycznego dla każdego klienta, semantyczny projekt modelu może działać zgodnie z oczekiwaniami.

  • Jeśli aplikacja używa jednego semantycznego modelu z zabezpieczeniami na poziomie wiersza w celu zapewnienia różnych danych różnym klientom, możesz uzyskać lepszą skalowalność, tworząc oddzielny model semantyczny dla każdego klienta i używając profilów zgodnie z opisem w tym artykule.

  • Po przekroczeniu ograniczeń skalowalności przy użyciu profilów i oddzielnych źródeł danych można uzyskać jeszcze więcej separacji danych przy użyciu zabezpieczeń na poziomie wiersza z profilami.

    • Jeśli korzystasz z dynamicznego zabezpieczeń na poziomie wiersza, nazwa profilu zostanie zwrócona w funkcji UserName()języka DAX .
    • Jeśli podczas generowania tokenu osadzania używasz statycznych zabezpieczeń na poziomie wiersza i przesłonisz role, możesz to kontynuować.

Gdy elementy będą gotowe, zaimportuj je do odpowiednich obszarów roboczych. Aby zautomatyzować ten proces, rozważ użycie interfejsu API importu.

Zmienianie kodów aplikacji w celu używania profilów

Po utworzeniu profilów z dostępem Administracja do odpowiednich obszarów roboczych oraz bazy danych z mapowaniem pokazującym, który profil reprezentuje klienta, możesz wprowadzić niezbędne zmiany w kodzie. Zalecamy, aby zachować dwa przepływy kodu obok siebie i stopniowo uwidaczniać przepływ kodu profilów klientom.

Wprowadź następujące zmiany kodu:

  • Zmiana kodu autoryzacji

  • Zmiana kodu zarządzania

    Niektóre aplikacje mają kod zarządzania, który automatyzuje dołączanie nowego klienta podczas rejestracji. Często kod zarządzania używa interfejsów API REST usługi Power BI do tworzenia obszarów roboczych i importowania zawartości. Większość tego kodu powinna pozostać taka sama, ale może być konieczne dostosowanie następujących szczegółów:

    • Za każdym razem, gdy tworzysz nową dzierżawę klienta, utwórz nowy profil usługi, który będzie twórcą i administratorem obszaru roboczego dla tej dzierżawy.
    • Jeśli zdecydujesz się zreorganizować zawartość usługi Power BI, zmodyfikuj kod, aby odzwierciedlić zmiany.
  • Zmiana kodu tokenu osadzania

    Zastąp obiekt wywołujący interfejs API. Upewnij się, że profil wywołuje interfejs API GenerateToken, ponieważ w modelu profilów tylko określony profil ma dostęp do zawartości klienta.

Sprawdź poprawność

Najlepszym rozwiązaniem jest dokładne przetestowanie aplikacji przed przeniesieniem jej do modelu profilów. Raporty mogą być ładowane nawet wtedy, gdy w kodzie aplikacji SaaS występują błędy, ponieważ nie usunięto starszych uprawnień w obszarach roboczych.

Czyszczenie zasobów po migracji

Po zakończeniu migracji i zweryfikowaniu wyników usuń to, czego już nie potrzebujesz.

  • Czyszczenie kodu: możesz wyłączyć stare ścieżki kodu, aby upewnić się, że używasz tylko nowego kodu, który opiera się na profilach.
  • Czyszczenie obszarów roboczych i uprawnień w usłudze Power BI: jeśli utworzono nowe obszary robocze, możesz usunąć stare obszary robocze, które nie są już używane. Jeśli używasz tych samych obszarów roboczych, możesz usunąć starsze uprawnienia (takie jak uprawnienia użytkownika głównego) w obszarze roboczym.

Masz więcej pytań? Spróbuj zadać Społeczność usługi Power BI