Автоматизация рабочих областей Premium и семантических задач модели с помощью субъектов-служб
Субъекты-службы — это регистрация приложения идентификатора Microsoft Entra, созданная в клиенте для выполнения автоматических операций с ресурсом и уровнем обслуживания. Это уникальный тип удостоверения пользователя с именем приложения, идентификатором приложения, идентификатором клиента и секретом клиента или сертификатом для пароля.
Power BI Premium использует те же функции субъекта-службы, что и Power BI Embedded. Дополнительные сведения см. в статье "Внедрение содержимого Power BI с помощью субъектов-служб".
В Power BI Premium можно использовать субъекты-службы с конечной точкой XMLA (XML Analysis) для автоматизации задач управления семантической моделью, таких как рабочие области подготовки, развертывание моделей и обновление семантической модели с помощью:
- PowerShell.
- Служба автоматизации Azure.
- Azure Logic Apps.
- Пользовательские клиентские приложения.
Только новые рабочие области поддерживают подключения конечных точек XMLA с помощью субъектов-служб. Классические рабочие области не поддерживаются. Субъект-служба имеет только те разрешения, необходимые для выполнения задач в рабочих областях, где она назначена. Разрешения назначаются через доступ к рабочей области, как и обычные учетные записи участника-пользователя (имя участника-пользователя).
Для выполнения операций записи рабочая нагрузка семантических моделей емкости должна включать конечную точку XMLA для операций чтения и записи. Семантические модели, опубликованные из Power BI Desktop, должны иметь расширенный формат метаданных.
Создание субъекта-службы
Субъекты-службы создаются в качестве регистрации приложения в портал Azure или с помощью PowerShell. При создании субъекта-службы обязательно скопируйте и сохраните отдельно имя приложения, идентификатор приложения (клиента), идентификатор каталога (клиента) и секрет клиента. Инструкции по созданию субъекта-службы см. в статье:
Создание группы безопасности Microsoft Entra
По умолчанию субъекты-службы имеют доступ к любым параметрам клиента, для которых они включены. В зависимости от параметров администратора доступ может включать определенные группы безопасности или всю организацию.
Чтобы ограничить доступ субъекта-службы к определенным параметрам клиента, можно разрешить доступ к определенным группам безопасности. Кроме того, можно создать выделенную группу безопасности для субъектов-служб и исключить ее из требуемых параметров клиента. Сведения о создании группы безопасности и добавлении субъекта-службы см. в статье "Создание базовой группы" и добавление участников с помощью идентификатора Microsoft Entra.
Включение субъектов-служб
Прежде чем начать использовать субъект-службу в Power BI, администратор должен включить доступ субъекта-службы на портале администрирования Power BI.
- Перейдите на портал администрирования Power BI и выберите параметры клиента.
- Прокрутите страницу до параметров разработчика и разверните узел "Разрешить субъектам-службам использовать API Power BI".
- Щелкните Включено.
- Чтобы применить разрешения к группе безопасности, выберите определенные группы безопасности (рекомендуется).
- Введите имя группы.
- Выберите Применить.
Доступ к рабочей области
Чтобы субъект-служба имели необходимые разрешения для выполнения операций рабочей области Premium и семантической модели, необходимо добавить субъект-службу в качестве члена рабочей области или администратора. Использование доступа к рабочей области в служба Power BI описано здесь, но вы также можете использовать REST API добавления пользователя группы.
В служба Power BI рабочей области выберите "Дополнительное>доступ к рабочей области".
Выполните поиск по имени приложения и добавьте субъект-службу в качестве администратора или участника в рабочую область.
Строки подключения для конечной точки XMLA
После создания субъекта-службы включите субъект-службу для клиента и добавьте субъект-службу в доступ к рабочей области, используйте его в качестве удостоверения пользователя в строка подключения с конечной точкой XMLA. Разница заключается в том, что вместо user id password параметров указывается идентификатор приложения, идентификатор клиента и секрет приложения.
Data Source=powerbi://api.powerbi.com/v1.0/myorg/<workspace name>; Initial Catalog=<dataset name>;User ID=app:<appId>@<tenantId>;Password=<app_secret>;
PowerShell
Откройте сеанс PowerShell, чтобы запустить следующий пример кода.
Использование модуля SQLServer
В следующем примере AppIdи TenantIdAppSecret используется для проверки подлинности операции обновления семантической модели:
Param (
[Parameter(Mandatory=$true)] [String] $AppId,
[Parameter(Mandatory=$true)] [String] $TenantId,
[Parameter(Mandatory=$true)] [String] $AppSecret
)
$PWord = ConvertTo-SecureString -String $AppSecret -AsPlainText -Force
$Credential = New-Object -TypeName "System.Management.Automation.PSCredential" -ArgumentList $AppId, $PWord
Invoke-ProcessTable -Server "powerbi://api.powerbi.com/v1.0/myorg/myworkspace" -TableName "mytable" -DatabaseName "mydataset" -RefreshType "Full" -ServicePrincipal -ApplicationId $AppId -TenantId $TenantId -Credential $Credential
Объекты управления анализом (AMO) и ADOMD.NET
При подключении к клиентским приложениям и веб-приложениям можно использовать клиентские библиотеки AMO и ADOMD версии 15.1.42.26 (июнь 2020 г.) и более поздних установок из NuGet для поддержки субъектов-служб в строка подключения с помощью следующего синтаксиса: app:AppID и пароля илиcert:thumbprint.
В следующем примере appID для password выполнения операции обновления базы данных модели используются значения:
string appId = "xxx";
string authKey = "yyy";
string connString = $"Provider=MSOLAP;Data source=powerbi://api.powerbi.com/v1.0/<tenant>/<workspacename>;Initial catalog=<datasetname>;User ID=app:{appId};Password={authKey};";
Server server = new Server();
server.Connect(connString);
Database db = server.Databases.FindByName("adventureworks");
Table tbl = db.Model.Tables.Find("DimDate");
tbl.RequestRefresh(RefreshType.Full);
db.Model.SaveChanges();