Power BI 是一款非常容易上手的数据分析工具。对报表设计人员来讲，可以快速的形成样式丰富的分析统计报表，而不需要掌握太多的数据处理知识。除了在云端的Power BI Service外，本地On-premise环境下， 也可以搭建自己的PowerBI Report Server(PRS)。
传统的做法是报表设计人员可以将报表上传到PRS的指定路径上，然后对报表进行授权，并分享给其他人（可能主要是领导）查阅。但在这个过程中，对于不通PRS技术的报表设计人员来讲， 不是特别友好，而且在内容管理、权限分配上也有诸多弊端，常见的问题包括：
- 报表在本地设计时不能连PROD环境的数据源，但在上传分享后应该使用正式的PROD数据源
- 报表权限管理应该对报表设计师透明；应该有整体的权限管理规划
- 报表的生命周期应该在管理之内
- 报表的查看、更新应该在严格的授权控制内
- 报表的行级数据安全控制（RLS）对设计人员理解能力有更高要求
所以我建议的思路是通过PRS的API ， 将报表的设计、发布、查看托管到应用中。
相关的API 可以参考地址： PBIRS | 2.0 | microsoft-rs | SwaggerHub
具体的报表制定过程如下：
1. 设计阶段
在该阶段， 设计人员跟业务人员沟通报表的数据范围，并从生产环境获得范围内数据的副本（混淆后的副本），然后根据需求完成报表的设计。在设计过程中，可以上传到PRS的[My Reports]路径下；可以上传多次，直到最终定稿。由于PRS不能在线编辑， 上传的意义主要在于防丢失，留记录。
由于报表文件是在【My Reports】目录下，所以默认其他普通用户（管理员除外）无法访问，仅本人可以查看。
2. 预览阶段
通过API， 切换到正式数据源。首先PRS是可以连到PROD环境下的数据源，但设计人员本地是无法连接的。所以只有上传到PRS后，才可以连接到正式数据源查看效果。
然后，可以将【My Reports】设计稿分享给指定的业务人员，请他们验收。该过程需要调用报表的Policy设定的API。
3. 发布阶段
验收通过后，则可进入发布阶段。发布的过程实际上是将报表从【My Reports】中移动到【Publish】下的【xx Project】子目录下，并继承该目录的Policy设定。通常该目录已经配好了报表查阅的权限(即 Policy）, 拥有权限的人则可以看到报表。设计师可能不在其中，所以不一定可以继续看到报表。
4. 下线阶段
经过一段时间使用，报表可能需要下线。而下线操作则是调用API将报表移动回设计师的【My Reports】中，并继承目录的Policy设定。这样设计师可以继续更新（上传新）报表，而业务用户不再能看到报表，直到重新发布。
在整个过程中，有一个很关键的阶段， 即本地PBI Desktop连接使用的副本数据源。如果是SQL Server作为数据源的话，可以自动化的完成副本源的部署。这里用到的一个关键工具是SQLPACKAGE.exe
* 导出生产数据源表和数据：
sqlpackage /a:export /ssn:{MyProdDbServer} /sdn:"{MyDatabase}" /su:{dbuser} /sp:{dbuserpassword} /tf:exported.bacpac /p:tabledata=dbo.Table1 /p:TableData=dbo.Table2
导出的是BACPAC文件， 里面既包含了数据库的完整结构Schema，也包括了表的数据。但是如果希望只导出部分表的数据， 则可以像上面一样指定多个参数：
/p:tabledata=xxx
* 导入到测试数据库服务器上：
sqlpackage /a:import /tsn:{MyTestDbServer} /tdn:{MyDatabase} /sf:exported.bacpac
-- 如果是集成身份验证，则可以省略用户名密码信息
导入的时候，必须确保目标库是不存在的，或者是个空库。否则不能成功。
整个过程可以使用Azure Devops 的CI Pipeline完成， 感兴趣的读者可以自行试试。 使用Pipeline的好处是，一方面自动化了， 另一方面，数据库连接的信息比较敏感，不应该交给人工来使用。这些敏感信息可以作为变量在管道中使用，从而降低了暴露的风险。
上述方法是连带着数据一起导入到了测试环境。由于某些场景中，这些数据也是比较敏感的，所以还可以在Pipeline中加一个任务， 对数据进行脱敏处理。
如果生产数据量巨大， 可能不适合使用BACPAC这种方式，也可以考虑使用SQLPACKAGE的 Extract/Publish 组合。 这个命令组合仅转移数据库的结构Schema，并不包含数据，即DACPAC文件。 所以还需要在管道中加上数据初始化的任务，也能达到类似的效果。
总结:
本文提出了在On-Premise环境中的Power BI Report Server 做报表平台的协作思路。对于一些常规报表需求， 在开发人员零参与的情况下，报表设计人员和业务人员，可以独立完成PowerBI报表的制作和发布。
