使用.NET代码在SSRS中强制执行粒度数据访问

Question

这是一个问题，我和我的团队一直在互联网上寻求帮助，但收效甚微。这听起来像（在我们的脑海中）一种常见的情况，对最佳方法的归零可能对许多人非常有用。

我们有一个ASP.NET应用程序，它使用.NET代码在相当精细的级别上控制数据访问。也就是说，我们有一个用户表，一个角色表，安全表，工作流表，然后是许多业务数据表。最终用户可以高度配置对业务数据的访问，因为他们可以直接在应用程序中自行管理用户帐户和安全性。我们的.NET C＃代码确定特定请求有权使用哪些数据（基于Windows登录）并提供服务。使用SQL Server登录/角色没有相关的业务安全性。

那么，如何将SSRS实现到一个系统中，该系统使用.NET代码以编程方式强制执行关系数据中定义的数据访问？

我们认为我们的解决方案看起来像下列之一：

[SSRS报告]＆gt; [数据源]＆gt;我们控制数据访问的.NET代码＆gt; [SQL Server]
......或...... [SSRS报告]＆gt;我们控制数据访问的.NET代码＆gt; [数据源]＆gt; [SQL Server]

如果这是正确的，那么我们缺少哪些技术或概念才能实现这一目标？

任何解决方案都应满足以下关键要求：

1. 业务用户（报告创建者）应该能够使用Report Builder 3.0创建SSRS报告。他们仍然可以使用数据集设计视图和查询设计器来处理业务数据和关系。
2. 业务用户（报告创建者）不必对其报告或数据查询实施数据访问。他们只需要担心报告设计。
3. 访问报告的最终用户（报告使用者）将根据其特定访问级别在其报告中获取过滤数据（由.NET代码完成）。

当然有其他人使用.NET代码来管理数据访问 - 在这种情况下SSRS不是一个选项吗？

谢谢！

Answer 1

我们的ASP.Net MVC应用程序也有类似的情况，其中RESTful Web服务将XML或JSON数据传递回前端应用程序。

对于报告，我们想要调用这些相同的控制器来获取相同的数据。幸运的是，SSRS具有惊人的可扩展性。我创建了一个custom data processing extension来调用我们的ASP.Net MVC控制器并返回数据，这些数据被反序列化为数据集以供报告使用。

我的查询看起来像这样：

Action=SomeAction;Controller=ControllerName;DtoType=List<MyDto>

虽然并非无足轻重，但并不像您想象的那么难，实现自定义数据处理扩展是解决问题的好方法。网上有很多例子可以帮助您入门。

Answer 2

SSRS运行良好，因为它非常靠近数据库。试图在数据库和它自身之间插入一个.NET层并不会很好。

数据库中有用户，角色和安全表，Windows用户有SSRS will tell you User!UserID。如果您愿意重新实现数据访问逻辑，则可以编写一个T / SQL存储过程，该过程接受UserID作为参数并过滤返回的数据。存储过程是报告的数据集。

让业务用户能够创建自己的报告会更加困难。您可以通过实现一系列存储过程来执行此操作，这些存储过程返回一般数据集，以便在构建报表时使用这些高级用户。然后，这些过程将作为基础表数据的过滤视图。当报表使用者运行生成的报表时，他们将看到根据自己的UserID过滤的数据。