400 998 0226将多客户应用程序迁移到服务主体配置文件模型
- 版本 ：2023.1(当前版本)
将多客户应用程序迁移到服务主体配置文件模型
本文介绍如何通过将 Power BI 嵌入式分析多客户应用迁移到服务主体配置文件模型来获得更好的可伸缩性。
利用服务主体配置文件，可以更轻松地管理 Power BI 中的组织内容，更有效地使用容量。
备注
本文面向已有应用支持单个 Power BI 租户中的多个客户的的组织。
并非所有应用都可从服务主体模型中获益。 例如，不应迁移以下应用：
维护一个包含少量对象的服务主体的小型应用。
每个客户使用一个多个服务主体的应用
先决条件
在开始迁移之前，请务必阅服务主体配置文件。
还需要执行以下步骤：
按照使用服务主体嵌入 Power BI 内容的前三个步骤设置服务主体。
通过 Power BI 租户管理员帐户，可在租户中创建配置文件。
迁移到服务主体配置文件
迁移到服务主体配置文件时，涉及到以下步骤：
创建配置文件，每个客户一个配置文件。
整理工作区。
更改应用程序代码以使用配置文件。
使用配置文件模型测试应用程序。
清理冗余权限。
创建配置文件（必需）
将配置文件 REST API 与创建的服务主体配合使用，为每个客户创建一个配置文件。
最好在数据库中保存每个数据客户 ID 及其相应配置文件 ID 的对照表。 稍后需要此对照表来使用租户配置文件进行 API 调用。
整理工作区
管理数据的最简单方法是为每个客户维护一个工作区。 如果应用已使用此模型，则无需创建新的工作区。 但是，仍必须使用添加组用户 API 向每个配置文件提供对相应工作区的“管理员”访问权限。
如果没有为每个客户维护一个工作区，请使用相应的配置文件调用创建组用户 API 来为每个客户创建新工作区。
在工作区中组织项
现在，每个客户都有一个配置文件和一个工作区。 如果在上一步中创建了新工作区，需要将报表和数据集等项导入这些工作区。 导入的数据集取决于当前的解决方案：
如果应用为每个客户使用单独的数据集，则数据集设计可以按原样工作。
如果应用使用一个具有行级别安全性 (RLS) 的数据集来为不同的客户提供不同的数据，则可以通过为每个客户创建单独的数据集并使用本文中所述的配置文件来获得更好的可伸缩性。
使用配置文件和单独的数据源克服可伸缩性限制后，可以通过将 RLS 与配置文件配合使用来获得更多的数据分离。
如果依赖于 Dynamic RLS，在 DAX 函数
UserName()中将返回配置文件的名称。如果在生成嵌入令牌时使用静态 RLS 和替代角色，可以继续使用。
项准备就绪后，将它们导入相关工作区。 若要自动执行此过程，请考虑使用导入 API。
更改应用程序代码以使用配置文件
拥有配置文件（对相关工作区具有管理员访问权限）以及具有对照表（显示哪个配置文件代表哪个客户）的数据库后，就可以进行必要的代码更改。 建议并排保留两个代码流，并逐渐向客户公开配置文件代码流。
执行以下代码更改：
授权代码更改
如果在 Azure AD 应用中使用主用户，请更改获取令牌代码。 阅读使用服务主体嵌入，了解如何创建仅限应用的 Azure AD 令牌。
如果你在使用某个服务主体并为配置文件新建了一个，请调整代码以使用正确的服务主体 ID 和机密。
管理代码更改
某些应用具有管理代码，可在注册时自动载入新客户。 通常，管理代码使用 Power BI REST API 创建工作区并导入内容。 这段代码大部分应该保持不变，但你可能需要调整以下细节：
每次创建新的客户租户时，都创建一个新的服务配置文件，作为该租户工作区的创建者和管理员。
如果决定重新组织 Power BI 内容，请编辑代码以反映更改。
嵌入令牌代码更改
替换 API 调用方。 请确保配置文件调用 GenerateToken API，因为在配置文件模型中，只有特定配置文件才有权访问客户的内容。
验证
最佳做法是先彻底测试应用，然后再将其移动到配置文件模型。 即使 SaaS 应用程序代码中存在 bug，报表也可以加载，因为你没有删除工作区上较旧的权限。
迁移后的清理
完成迁移并验证结果后，可以删除不再需要的内容。
清理代码：最好禁用旧代码路径，以确保仅运行依赖于配置文件的新代码。
清理 Power BI 中的工作区和权限：如果创建了新工作区，则可以删除不再使用的旧工作区。 如果重复使用同一工作区，最好删除工作区上的旧权限（例如主用户权限）。