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

Разработка масштабируемых мультитенантных приложений с помощью внедрения Power BI

  • Статья

В этой статье описывается, как разработать мультитенантное приложение, которое внедряет содержимое Power BI при достижении самых высоких уровней масштабируемости, производительности и безопасности. Создавая и реализуя приложение с профилями субъектов-служб, вы можете создавать и управлять мультитенантным решением, включающим десятки тысяч клиентов, которые могут доставлять отчеты аудитории более 100 000 пользователей.

Профили субъектов-служб — это функция, которая упрощает управление содержимым организации в Power BI и более эффективное использование емкостей. Однако использование профилей субъектов-служб может добавить сложность в дизайн приложения. Поэтому их следует использовать только в том случае, если требуется добиться значительного масштаба. Мы рекомендуем использовать профили субъектов-служб, если у вас много рабочих областей и более 1000 пользователей приложений.

Примечание.

Значение использования профилей субъекта-службы увеличивается по мере увеличения масштаба, а также необходимости достижения наивысшего уровня безопасности и изоляции клиента.

Вы можете реализовать внедрение Power BI с помощью двух различных сценариев внедрения: внедрение для вашей организации и внедрение для клиента.

Сценарий внедрения для организации применяется, когда аудитория приложения состоит из внутренних пользователей. Внутренние пользователи имеют учетные записи организации и должны проходить проверку подлинности с помощью идентификатора Microsoft Entra. В этом сценарии Power BI — программное обеспечение как услуга (SaaS). Иногда он называется данными пользователя.

Внедрение сценария клиента применяется, когда аудитория приложения состоит из внешних пользователей. Приложение отвечает за проверку подлинности пользователей. Чтобы получить доступ к содержимому Power BI, приложение использует внедренное удостоверение (субъект-службу Microsoft Entra или основную учетную запись пользователя) для проверки подлинности с помощью Microsoft Entra. В этом сценарии Power BI — платформа как услуга (PaaS). Иногда он называется данными приложения.

Примечание.

Важно понимать, что функция профилей субъектов-служб предназначена для использования с внедрением для вашего сценария клиента . Это связано с тем, что этот сценарий предлагает поставщики программного обеспечения и корпоративные организации возможность внедрения с большим масштабом до большого количества пользователей и большого количества клиентов.

Разработка мультитенантных приложений

Если вы знакомы с Microsoft Entra, клиент word может привести к тому, что вы думаете о клиенте Microsoft Entra. Однако концепция клиента отличается в контексте создания мультитенантного решения, включающего содержимое Power BI. В этом контексте клиент клиента создается от имени каждого клиента, для которого приложение внедряет содержимое Power BI с помощью внедрения для вашего сценария клиента. Обычно каждый клиент подготавливается путем создания одной рабочей области Power BI.

Чтобы создать масштабируемое мультитенантное решение, необходимо автоматизировать создание новых клиентов. Подготовка нового клиента обычно включает написание кода, использующего REST API Power BI для создания новой рабочей области Power BI, создания семантических моделей путем импорта файлов Power BI Desktop (PBIX), обновления параметров источника данных, задания учетных данных источника данных и настройки запланированного обновления семантической модели. На следующей схеме показано, как добавить элементы Power BI, такие как отчеты и семантические модели, в рабочие области для настройки клиентов клиентов.

Схема, на которую показана настройка для трех клиентов. Каждый клиент имеет собственный источник данных и рабочую область.

При разработке приложения, использующего внедрение для сценария клиента , можно сделать вызовы REST API Power BI с помощью удостоверения внедрения, который является главной учетной записью пользователя или субъектом-службой. Рекомендуется использовать субъект-службу для рабочих приложений. Он обеспечивает максимальную безопасность и по этой причине рекомендуется в Microsoft Entra. Кроме того, он лучше поддерживает автоматизацию и масштабирование, а также требует меньше затрат на управление. Однако для настройки и управления им требуются права администратора Power BI.

Используя субъект-службу, можно избежать распространенных проблем, связанных с основными учетными записями пользователей, например ошибок проверки подлинности в средах, где пользователям требуется выполнить вход с помощью многофакторной проверки подлинности (MFA). Использование субъекта-службы также соответствует идее, что внедрение для вашего сценария клиента основано на внедрении содержимого Power BI с помощью мышления PaaS в отличие от мышления SaaS.

Ограничение 1000 рабочих областей

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

Power BI использует метаданные для отслеживания рабочих областей и элементов рабочей области, к которые может получить доступ удостоверение. В действительности Power BI должен поддерживать отдельный список управления доступом (ACL) для каждого удостоверения в подсистеме авторизации. Когда удостоверение вызывает REST API для доступа к рабочей области, Power BI должен выполнить проверку безопасности в ACL удостоверения, чтобы убедиться, что она авторизована. Время, необходимое для определения того, находится ли целевая рабочая область внутри ACL, увеличивается экспоненциально по мере увеличения количества рабочих областей.

Примечание.

Power BI не применяет ограничение рабочей области 1000 через код. При попытке добавить удостоверение внедрения в более чем 1000 рабочих областей, а вызовы REST API по-прежнему будут выполняться успешно. Однако приложение перейдет в неподдерживаемое состояние, которое может иметь последствия, если вы попытаетесь запросить помощь от поддержки Майкрософт.

Рассмотрим сценарий, в котором два мультитенантных приложения настроены для использования одного субъекта-службы. Теперь рассмотрим, что первое приложение создало 990 рабочих областей, а второе приложение создало 1010 рабочих областей. С точки зрения поддержки первое приложение находится в поддерживаемых границах, в то время как второе приложение не является.

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

Вот ключевое наблюдение: количество рабочих областей, созданных субъектом-службой, непосредственно влияет на производительность и масштабируемость. Субъект-служба, который входит в 100 рабочих областей, будет выполнять вызовы REST API быстрее, чем субъект-служба, член 1000 рабочих областей. Аналогичным образом субъект-служба, который входит только в 10 рабочих областей, будет выполнять вызовы REST API быстрее, чем субъект-служба, член 100 рабочих областей.

Внимание

С точки зрения производительности и масштабируемости оптимальное количество рабочих областей, для которых субъект-служба является членом, является именно одним.

Управление изоляцией для семантических моделей и учетных данных источника данных

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

Владение семантической моделью

Каждая семантическая модель Power BI имеет одного владельца, который может быть учетной записью пользователя или субъектом-службой. Для настройки запланированного обновления и задания параметров семантической модели требуется владение семантической модели.

Совет

В служба Power BI можно определить, кто является владельцем семантической модели, открыв параметры семантической модели.

При необходимости можно передать владение семантической моделью другому пользователю или субъекту-службе. Это можно сделать в служба Power BI или с помощью операции REST APITakeOver. При импорте файла Power BI Desktop для создания новой семантической модели с помощью субъекта-службы субъект-служба автоматически устанавливается в качестве владельца семантической модели.

Учетные данные источников данных

Чтобы подключить семантику модели к его базовому источнику данных, владелец семантической модели должен задать учетные данные источника данных. Учетные данные источника данных шифруются и кэшируются Power BI. С этого момента Power BI использует эти учетные данные для проверки подлинности с помощью базового источника данных при обновлении данных (для импорта таблиц хранилища) или выполнения сквозных запросов (для таблиц хранилища DirectQuery).

Рекомендуется применить общий шаблон проектирования при подготовке нового клиента. Можно выполнить ряд вызовов REST API с помощью удостоверения субъекта-службы:

  1. Создайте новую рабочую область.
  2. Свяжите новую рабочую область с выделенной емкостью.
  3. Импортируйте файл Power BI Desktop для создания семантической модели.
  4. Задайте учетные данные источника семантической модели для этой семантической модели.

После выполнения этих вызовов REST API субъект-служба будет администратором новой рабочей области и владельцем семантической модели и учетных данных источника данных.

Внимание

Существует распространенное неправильное представление о том, что учетные данные источника данных семантической модели ограничены на уровне рабочей области. Это неправда. Учетные данные источника данных относятся к субъекту-службе (или учетной записи пользователя), и эта область распространяется на все рабочие области Power BI в клиенте Microsoft Entra.

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

Схема, показывающая настройку для двух клиентов. Каждый клиент совместно используют одни и те же учетные данные источника данных.

Если учетные данные источника данных совместно используются семантические модели, принадлежащие разным клиентам клиента, клиенты клиента не полностью изолированы.

Разработка стратегий до профилей субъекта-службы

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

  • Один субъект-служба
  • Пул субъектов-служб
  • Один субъект-служба для рабочей области

Существуют сильные и слабые стороны, связанные с каждой из этих стратегий проектирования.

Для разработки единого субъекта-службы требуется однократное создание регистрации приложения Microsoft Entra. Таким образом, он включает менее административные издержки, чем другие две стратегии проектирования, так как нет необходимости создавать больше регистраций приложений Microsoft Entra. Эта стратегия также является самой простой для настройки, так как она не требует написания дополнительного кода, который переключает контекст вызова между субъектами-службами при выполнении вызовов REST API. Однако проблема с этой стратегией проектирования заключается в том, что она не масштабируется. Она поддерживает только среду мультитенантности, которая может увеличиваться до 1000 рабочих областей. Кроме того, производительность снижается, так как субъект-служба получает доступ к большему количеству рабочих областей. Существует также проблема с изоляцией клиента клиента, так как один субъект-служба становится владельцем каждой семантической модели и всех учетных данных данных для всех клиентов.

Стратегия проектирования пула субъектов-служб обычно используется для предотвращения ограничения на 1000 рабочих областей. Это позволяет приложению масштабировать любое количество рабочих областей, добавив правильное количество субъектов-служб в пул. Например, пул из пяти субъектов-служб позволяет масштабировать до 5 000 рабочих областей; Пул 80 субъектов-служб позволяет масштабировать до 80 000 рабочих областей и т. д. Однако в то время как эта стратегия может масштабироваться до большого количества рабочих областей, у нее есть несколько недостатков. Во-первых, он требует написания дополнительного кода и хранения метаданных, чтобы разрешить переключение контекста между субъектами-службами при выполнении вызовов REST API. Во-вторых, это требует больше административных усилий, так как необходимо создавать регистрации приложений Microsoft Entra всякий раз, когда необходимо увеличить число субъектов-служб в пуле.

Более того, стратегия пула субъектов-служб не оптимизирована для производительности, так как она позволяет субъектам-службам стать членами сотен рабочих областей. Это также не идеально с точки зрения изоляции клиента клиента, так как субъекты-службы могут стать владельцами семантической модели и учетных данных, общих для клиентов.

Один субъект-служба для каждой стратегии разработки рабочей области включает создание субъекта-службы для каждого клиента. С точки зрения теории, эта стратегия предлагает лучшее решение, так как она оптимизирует производительность вызовов REST API, обеспечивая истинную изоляцию для семантических моделей и учетных данных источника данных на уровне рабочей области. Однако то, что лучше всего работает в теории, не всегда работает лучше всего на практике. Это связано с тем, что требование создать субъект-службу для каждого клиента нецелесообразно для многих организаций. Это связано с тем, что у некоторых организаций есть формальные процессы утверждения или они включают чрезмерную бюрократию для создания регистрации приложений Microsoft Entra. Эти причины могут сделать невозможным предоставить пользовательскому приложению полномочия, необходимые для создания регистраций приложений Microsoft Entra по запросу, и автоматизированным способом, которым требуется ваше решение.

В менее распространенных сценариях, когда пользовательское приложение было предоставлено надлежащие разрешения, он может использовать API Microsoft Graph для создания регистраций приложений Microsoft Entra по запросу. Однако пользовательское приложение часто сложно разрабатывать и развертывать, так как оно должно как-то отслеживать учетные данные проверки подлинности для каждой регистрации приложения Microsoft Entra. Он также должен получить доступ к этим учетным данным всякий раз, когда он должен пройти проверку подлинности и получить маркеры доступа для отдельных субъектов-служб.

Профили субъекта-службы

Функция профилей субъектов-служб была разработана для упрощения управления содержимым организации в Power BI и более эффективного использования емкостей. Они помогают решить три конкретных проблемы, которые включают наименьшее количество усилий разработчика и затрат. К этим проблемам относятся:

  • Масштабирование до большого количества рабочих областей.
  • Оптимизация производительности вызовов REST API.
  • Изоляция семантических моделей и учетных данных источника данных на уровне клиента.

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

Профили субъектов-служб — это локальные учетные записи, созданные в контексте Power BI. Субъект-служба может использовать Profiles операцию REST API для создания новых профилей субъекта-службы. Субъект-служба может создавать собственный набор профилей субъектов-служб для пользовательского приложения и управлять ими, как показано на следующей схеме.

Схема, на которую показан субъект-служба, создающий три профиля субъекта-службы в Power BI.

Между субъектом-службой и профилями субъекта-службы всегда существует связь между родительским и дочерним элементом. Невозможно создать профиль субъекта-службы в виде автономной сущности. Вместо этого вы создаете профиль субъекта-службы с помощью определенного субъекта-службы, а этот субъект-служба служит родительским объектом профиля. Кроме того, профиль субъекта-службы никогда не отображается для учетных записей пользователей или других субъектов-служб. Профиль субъекта-службы можно просматривать и использовать только субъект-службу, создавший его.

Профили субъекта-службы не известны Microsoft Entra

Хотя сам субъект-служба и его базовая регистрация приложений Microsoft Entra известны Microsoft Entra, идентификатор Microsoft Entra не знает ничего о профилях субъекта-службы. Это связано с тем, что профили субъектов-служб создаются Power BI и существуют только в подсистеме служба Power BI, которая управляет безопасностью и авторизацией Power BI.

Тот факт, что профили субъектов-служб не известны идентификатору Microsoft Entra ID имеют как преимущества, так и недостатки. Основное преимущество заключается в том, что для приложения сценария клиента внедрение не требует специальных разрешений Microsoft Entra для создания профилей субъекта-службы. Это также означает, что приложение может создавать и управлять набором локальных удостоверений, которые отделены от Microsoft Entra.

Однако есть и недостатки. Так как профили субъектов-служб не известны Microsoft Entra, вы не можете добавить профиль субъекта-службы в группу Microsoft Entra, чтобы неявно предоставить ему доступ к рабочей области. Кроме того, внешние источники данных, такие как База данных SQL Azure или Azure Synapse Analytics, не могут распознавать профили субъектов-служб в качестве удостоверения при подключении к базе данных. Таким образом, один субъект-служба для каждой стратегии разработки рабочей области (создание субъекта-службы для каждого клиента) может быть лучшим выбором, если требуется подключиться к этим источникам данных с помощью отдельного субъекта-службы с уникальными учетными данными проверки подлинности для каждого клиента.

Профили субъектов-служб — это субъекты безопасности первого класса

Хотя профили субъектов-служб не известны Microsoft Entra, Power BI распознает их как субъекты безопасности первого класса. Как и учетная запись пользователя или субъект-служба, можно добавить профили субъекта-службы в роль рабочей области (как администратор или участник). Вы также можете сделать его владельцем семантической модели и владельцем учетных данных источника данных. По этим причинам создание нового профиля субъекта-службы для каждого нового клиента рекомендуется.

Схема с несколькими клиентами клиента, каждая из которых содержит собственные профили субъекта-службы.

Совет

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

Выполнение вызовов REST API в качестве профиля субъекта-службы

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

  1. Когда профиль субъекта-службы создает новую рабочую область, Power BI автоматически добавляет этот профиль в качестве администратора рабочей области.
  2. Когда профиль субъекта-службы импортирует файл Power BI Desktop для создания семантической модели, Power BI задает этот профиль в качестве владельца семантической модели.
  3. Когда профиль субъекта-службы задает учетные данные источника данных, Power BI задает этот профиль как владелец учетных данных источника данных.

Важно понимать, что субъект-служба имеет удостоверение в Power BI, которое отличается от удостоверений своих профилей. Это обеспечивает выбор в качестве разработчика. Вызовы REST API можно выполнять с помощью удостоверения профиля субъекта-службы. Кроме того, можно выполнять вызовы REST API без профиля, который использует удостоверение родительского субъекта-службы.

Рекомендуется выполнять вызовы REST API в качестве родительского субъекта-службы при создании, просмотре или удалении профилей субъектов-служб. Для выполнения всех других вызовов REST API следует использовать профиль субъекта-службы. Эти другие вызовы могут создавать рабочие области, импортировать файлы Power BI Desktop, обновлять параметры семантической модели и задавать учетные данные источника данных. Они также могут получать метаданные элемента рабочей области и создавать маркеры внедрения.

Рассмотрим пример, в котором необходимо настроить клиент клиента для клиента с именем Contoso. Первый шаг выполняет вызов REST API для создания профиля субъекта-службы с отображаемым именем Contoso. Этот вызов выполняется с помощью удостоверения субъекта-службы. Все остальные действия по настройке используют профиль субъекта-службы для выполнения следующих задач:

  1. Создайте рабочую область.
  2. Свяжите рабочую область с емкостью.
  3. Импортируйте файл Power BI Desktop.
  4. Задайте параметры семантической модели.
  5. Задайте учетные данные источника данных.
  6. Настройте запланированное обновление данных.

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

Совет

Помните: при вызове REST API используйте субъект-службу для создания профилей субъектов-служб и управления ими используйте профиль субъекта-службы для создания, настройки и доступа к содержимому Power BI.

Использование операций REST API профилей

Группа операций REST API профилей состоит из операций, которые создают профили субъектов-служб и управляют ими:

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

Создание профиля субъекта-службы

Используйте операцию СОЗДАНИЯ REST API профиля для создания профиля субъекта-службы. Чтобы указать отображаемое имя нового клиента, необходимо задать displayName свойство в тексте запроса. Значение должно быть уникальным для всех профилей, принадлежащих субъекту-службе. Вызов завершится ошибкой, если для субъекта-службы уже существует другой профиль с отображающимся именем.

Успешный вызов возвращает id свойство, которое представляет профиль. При разработке приложений, использующих профили субъектов-служб, рекомендуется хранить отображаемые имена профилей и их значения идентификаторов в пользовательской базе данных. Таким образом, это просто для приложения, чтобы получить идентификаторы.

При программировании с помощью пакета SDK для .NET Для Power BI можно использовать Profiles.CreateProfile метод, который возвращает ServicePrincipalProfile объект, представляющий новый профиль. Это упрощает определение id значения свойства.

Ниже приведен пример создания профиля субъекта-службы и предоставления ему доступа к рабочей области.

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

В служба Power BI в области доступа к рабочей области можно определить, какие удостоверения, включая субъекты безопасности, имеют доступ.

Снимок экрана, на котором показан снимок экрана области доступа к рабочей области. В нем показан профиль субъекта-службы с отображаемым именем Contoso с разрешением администратора.

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

Используйте операцию REST API удаления профиля для удаления профиля субъекта-службы. Эта операция может вызываться только родительским субъектом-службой.

Если вы программировать с помощью пакета SDK для .NET Для Power BI, можно использовать Profiles.DeleteProfile этот метод.

Получение всех профилей субъектов-служб

Используйте операцию REST API get Profile для получения списка профилей субъектов-служб, принадлежащих вызывающей субъекту-службе. Эта операция возвращает полезные данные JSON, содержащие id и displayName свойства каждого профиля субъекта-службы.

Если вы программируете с помощью пакета SDK для .NET Для Power BI, можно использовать метод Profiles.GetProfiles .

Выполнение вызовов REST API с помощью профиля субъекта-службы

Существует два требования для выполнения вызовов REST API с помощью профиля субъекта-службы:

  • Необходимо передать маркер доступа для родительского субъекта-службы в заголовке авторизации .
  • Необходимо включить заголовок с именем X-PowerBI-profile-id со значением идентификатора профиля субъекта-службы.

Если вы используете пакет SDK для .NET Для Power BI, можно явно задать значение заголовка X-PowerBI-profile-id , передав идентификатор профиля субъекта-службы.

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

Как показано в приведенном выше примере, после добавления заголовка X-PowerBI-profile-id в PowerBIClient объект просто вызывать методы, такие как, чтобы Groups.GetGroupsони выполнялись с помощью профиля субъекта-службы.

Существует более удобный способ задать заголовок X-PowerBI-profile-id для PowerBIClient объекта. Объект можно инициализировать, передав идентификатор профиля конструктору.

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

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

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

Если необходимо создать или управлять профилем субъекта-службы, можно вызвать SetCallingContext метод без каких-либо параметров. Таким образом, можно создавать профили и управлять ими с помощью удостоверения субъекта-службы.

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

Когда необходимо создать и настроить рабочую область для нового клиента, необходимо выполнить этот код в качестве профиля субъекта-службы. Поэтому необходимо вызвать SetCallingContext метод, передав идентификатор профиля. Таким образом можно создать рабочую область с помощью удостоверения профиля субъекта-службы.

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

После использования определенного профиля субъекта-службы для создания и настройки рабочей области следует продолжать использовать этот же профиль для создания и настройки содержимого рабочей области. Для завершения установки не требуется вызывать SetCallingContext метод.

Пример разработчика

Мы рекомендуем скачать пример приложения с именем AppOwnsDataMultiTenant.

Этот пример приложения был разработан с помощью .NET 6 и ASP.NET, и демонстрирует, как применить рекомендации и рекомендации, описанные в этой статье. Вы можете просмотреть код, чтобы узнать, как разработать мультитенантное приложение, реализующее внедрение для сценария клиента с помощью профилей субъекта-службы.

Связанный контент

Дополнительные сведения об этой статье см. в следующих ресурсах: