Поделиться через


Перенос многопользовательских приложений в модель профилей субъектов-служб

В этой статье описывается, как повысить масштабируемость, переносив приложения Power BI embedded analytics с несколькими клиентами в модель профилей субъектов-служб.

Профили субъектов-служб упрощают управление содержимым организации в Power BI и более эффективно используют емкости.

Примечание.

Эта статья предназначена для организаций, у которых уже есть приложение, которое поддерживает несколько клиентов из одного клиента Power BI.

Не все приложения получают преимущества от модели субъекта-службы. Например, следующие приложения не должны переноситься:

  • Небольшие приложения, поддерживающие один субъект-службу с небольшим количеством объектов.
  • Приложения, использующие один несколько субъектов-служб для каждого клиента

Необходимые компоненты

Перед началом миграции важно ознакомиться с профилями субъектов-служб.

Вам также необходимо сделать следующие шаги:

Снимок экрана: портал администрирования с параметром включения создания профилей.

Миграция на профили субъекта-службы

Миграция в профили субъекта-службы включает в себя следующие действия.

  1. Создайте профили, один профиль для каждого клиента.
  2. Упорядочение рабочих областей.
  3. Измените код приложения на использование профилей.
  4. Протестируйте приложение с помощью модели профилей.
  5. Очистка избыточных разрешений.

Создание профилей (обязательно)

Используйте REST API профилей с субъектом-службой, созданной для создания одного профиля для каждого клиента.

Рекомендуется сохранить сопоставление каждого идентификатора клиента данных с соответствующим идентификатором профиля в базе данных. Это сопоставление потребуется позже для вызова API с профилем клиента.

Упорядочение рабочих областей

Самый простой способ управления данными — это обслуживание одной рабочей области для каждого клиента. Если приложение уже использует эту модель, вам не нужно создавать новые рабочие области. Однако вам по-прежнему необходимо предоставить каждому профилю доступ администратора к соответствующей рабочей области с помощью API добавления пользователя группы.

Если у вас нет одной рабочей области для каждого клиента, используйте соответствующий профиль для вызова API создания пользователей группы, чтобы создать новую рабочую область для каждого клиента.

Упорядочение элементов в рабочих областях

Теперь у вас должен быть профиль и рабочая область для каждого клиента. Если вы создали новые рабочие области на предыдущем шаге, необходимо импортировать элементы (например, отчеты и семантические модели) в эти рабочие области. Импортируемые семантические модели зависят от текущего решения:

  • Если в приложении используется отдельная семантическая модель для каждого клиента, семантическая модель может работать так же, как это.

  • Если приложение использует одну семантику с безопасностью на уровне строк (RLS) для предоставления разных данных разным клиентам, вы можете повысить масштабируемость, создав отдельную семантику модели для каждого клиента и используя профили, как описано в этой статье.

  • После преодоления ограничений масштабируемости с помощью профилей и отдельных источников данных можно получить еще больше разделения данных с помощью RLS с профилями.

    • Если вы используете Dynamic RLS, имя профиля будет возвращено в функции UserName()DAX.
    • Если при создании маркера внедрения используются статические RLS и переопределяются роли, это можно продолжить.

Когда элементы будут готовы, импортируйте их в соответствующие рабочие области. Чтобы автоматизировать процесс, рассмотрите возможность использования API импорта.

Изменение кодов приложений для использования профилей

После того как у вас есть профили с правами администратора на соответствующие рабочие области и база данных с сопоставлением, в которой показано, какой профиль представляет клиента, вы можете внести необходимые изменения в код. Рекомендуется хранить два потока кода параллельно и постепенно предоставлять поток кода профилей клиентам.

Внесите следующие изменения кода:

  • Изменение кода авторизации

    • Если вы используете основного пользователя в приложении идентификатора Microsoft Entra ID , измените код маркера получения. Чтение внедрения с помощью субъекта-службы для получения сведений о создании токена Microsoft Entra только для приложений.
    • Если вы используете субъект-службу и создали новый для профилей, измените код, чтобы использовать правильный идентификатор субъекта-службы и секреты.
  • Изменение кода управления

    Некоторые приложения имеют код управления, который автоматизирует подключение нового клиента при регистрации. Часто код управления использует REST API Power BI для создания рабочих областей и импорта содержимого. Большая часть этого кода должна оставаться такой же, но может потребоваться адаптировать следующие сведения:

    • Каждый раз, когда вы создаете новый клиент клиента, создайте новый профиль службы, чтобы быть создателем и администратором рабочей области для этого клиента.
    • Если вы решите переорганизовать содержимое Power BI, измените код, чтобы отразить изменения.
  • Изменение кода маркера внедрения

    Замените вызывающий объект API. Убедитесь, что профиль вызывает API GenerateToken, так как в модели профилей только конкретный профиль имеет доступ к содержимому клиента.

Проверить

Рекомендуется тщательно протестировать приложение перед перемещением его в модель профилей. Отчеты могут загружаться, даже если в коде приложения SaaS возникают ошибки, так как вы не удалили старые разрешения в рабочих областях.

Очистка после миграции

Теперь, когда вы завершили миграцию и проверили результаты, удалите то, что вам больше не нужно.

  • Очистка кода: может потребоваться отключить старые пути кода, чтобы убедиться, что выполняется только новый код, основанный на профилях.
  • Очистка рабочих областей и разрешений в Power BI. Если вы создали новые рабочие области, можно удалить старые рабочие области, которые больше не используются. Если вы повторно используете те же рабочие области, вы можете удалить старые разрешения (например , разрешения главного пользователя ) в рабочей области.

Управление профилями субъекта-службы

Есть еще вопросы? Задайте их в сообществе Power BI.