提供SQL报表为SharePoint增强团队协作

体系结构

　　假设您所在的公司有一个关键的数据库应用程序，它不断地记录新的传入信息。该数据库可能存储定单信息、销售联系人信息，或者任何其他类型的数据。现在假设，您公司内的一组员工根据有关该数据的报表（也许是月结帐单的趋势分析）进行关键的业务决策。这些报表根据定时任务创建：每日、每周或每月。听起来很熟悉吧？您的公司可能已经拥有了类似系统。差不多任何类型的公司都有可能这样。

　　Microsoft SQL Server Reporting Services 允许用户订阅报表并将报表自动传递给用户，从而简化了这种情况。尽管这是一个有用的功能，但它只解决了更大目标的一个方面。用户在收到报表后，很可能希望不仅限于通览数据。也许他们需要为员工创建并分配任务，或者他们可能希望允许小组内的成员对数据进行建设性的讨论，或者他们可能只需要将数据合并到一个 Microsoft PowerPoint？ 演示文稿中。

　　问题是，系统通过电子邮件或将报表粘贴到公司内部的文件共享（这是订阅的两种现成的传递方法），从而将报表的副本传递给每个员工。这两种情况都不支持有关组内报表的协作。一个更有趣的解决方案是将报表传递给 Microsoft SharePoint？ 文档库，其中的讨论和协作功能都能很容易地与报表一起使用。本文详细介绍如何创建一个自定义的 SQL Server Reporting Services 传递扩展，它会将报表存储在一个 Windows？ SharePoint Services (WSS) 文档库中。

　　体系结构

　　在我所描述的情况中，报表的时间很重要。不管用户何时查看报表，报表必须对所有用户都是一样的。因此，我不能依赖于这样的模型：每个用户在他们碰巧访问 SharePoint 站点时按需运行报表。（使用 SQL Server 2000 Reporting Services Service Pack 2 中新增的报表查看器 Web 部件可以很轻松地实现按需解决方案，但是 SharePoint 的协作功能并不适用。）相反，自定义传递扩展必须按计划的时间运行报表，并且以完全自动的方式传递它们。由于 SharePoint 能够存储文档，因此，我的传递扩展会将报表呈现为一个 PDF 文件，并将其存储在指定的文档库中。

　　那么，文件生成后如何存储到文档库中呢？解决方案包括一个自定义的 SharePoint Web 服务，它提供一个接口来接收报表文件，然后通过 WSS 对象模型将文件存储在适当的库中。使用自定义的 Web 服务可以增加灵活性，这样您除了存储文件还可以包括其他任务。

　　为了方便在请求中包含二进制文件，Web 服务将使用带有 WS-Attachment 功能的 Web Service Enhancements (WSE) 进行直接 Internet 消息封装（Direct Internet Message Encapsulation，DIME）。我之所以选择该方法，而不选择 XML 消息中二进制数据的 base64 编码，是因为在 Unicode 字符格式中，base64 编码方法增加了请求的大小。通过 DIME 发送附件会将文件移到 SOAP 信封外。图 1 以较高级别显示该体系结构。

　　该体系结构的优点在于，最终结果只是文档库中的一个文件。这样，用户就可以使用 SharePoint 必须提供的所有常规功能，包括协作和 SharePoint 警报。如果有人需要确认某个报表是有效的并在上面签字，然后其他用户才能够查看该报表，她可以打开内容审批。如果报表的内容必须是可搜索的，则只需安装一个 PDF IFilter。

　　构建 Web 服务

　　自定义的 SharePoint Web 服务只有一个方法，就是 UploadDocument。该方法只接受带有一个文件附件的 SOAP Web 服务请求。为了接收来自客户端的一组参数，Web 服务公开了一个 DocInfo 类，该类是专门为提供灵活性以及版本复原而设计的。

　　至少，该 Web 服务必须接收两个字符串：文件名和库名。但是，解决方案必须保持灵活性，以便将来能够支持其他参数。事实上，该 Web 服务很可能为您的 SharePoint 实现增加功能，而不仅仅是存储报表。有关构建一个类以使其序列化开放的详细信息，请参见 Doug Purdy（Microsoft 的一位项目经理）在 MSDN？ TV 节目中有关该主题的讨论"Loosely Coupled Web Services"。

　　DocInfo 类中的元素和属性数组允许我将来添加字段，而不破坏向后兼容性。同时，版本标识符使 Web 服务方法能够发现在发出请求的客户端的级别，以便它可以作出相应的反应。

　　一旦 UploadDocument Web 服务方法已经确认该请求有一个附件，它就会使用 BinaryReader 将附件读入字节数组中。在示例代码（下载代码中提供 C# 和 Visual Basic 两种版本）中，您将了解 RequestSoapContext 的使用方法。该类提供对 Web 服务的特定于 WSE 的扩展的访问。通过其 Attachments 集合，您可以访问传递扩展正发送的实际 PDF 报表文件。收到附带的报表后，UploadDocument 方法继续使用 SharePoint 对象模型进行处理，以确定客户端针对的是哪个"web"： Dim site As SPWeb = SPControl.GetContextWeb(Me.Context)

　　在该上下文中，"web"是一个通用的 SharePoint 对象模型术语。它可以指 Windows SharePoint Services (WSS) 站点或 SharePoint Portal Server (SPS) 区域。正确的 Web 是通过 SharePoint 上下文对象确定的，它基于客户用来发出请求的 URL。SharePoint 站点的 Web 服务以下述方式部署：可以通过任何 web 的 vti_bin 文件夹引用它们。要获得该功能，您必须确保部署 Web 服务的方式与部署现成服务的方式相同。我在本文的部署部分中详细介绍该主题。

　　一旦 UploadDocument 方法确定在报表应该存储在哪个 web 中，GetFolder 方法将用于检索正确的文档库。然后，库使用给定的文件名将字节数组添加到其文件集合中： Dim folder As SPFolder = site.GetFolder(info.Folder)

　　Dim file As SPFile = folder.Files.Add(info.FileName， fileData， True)

　　该过程将报表保存到 SharePoint 文档库中。本调用中指定的 True 参数指明当前文件将覆盖任何具有相同名称的现有文件。如果用户启用了对 SharePoint 库的版本控制，则新文件实际上将更新现有的文件。如本文后面所述，传递扩展还可以选择将时间戳附加到文件名中。如果用户不希望启用库的版本控制，但还想保持全部的报表实例，这会很方便。

构建传递扩展

　　构建传递扩展

　　我在前面提到的现成的传递方法（通过电子邮件传递以及将文件传递到文件共享），每种方法都包含一个传递扩展。要使报表到达 SharePoint 库，我必须构建一个自定义传递扩展。这涉及三个类的编写：一个类存储订阅设置，一个类呈现用户界面，一个类实际传递报表。当用户设置一个订阅将报表传递到 SharePoint 时，他们需要提供四部分信息：WSS 站点或 SPS 区域的 URL、文档库名、用于报表的文件名，以及是否应向文件名添加时间戳。上述每个值都存储在一个 SubscriptionData 类中。

　　解决方案还包括一个 SPSLibraryDeliveryUIProvider 类，它生成用于从用户捕获该信息的用户界面。该类呈现了特定于 SharePoint 库传递扩展的窗体字段。图 4 显示自定义传递扩展的订阅项窗体。SPSLibraryDeliveryUIProvider 仅负责与这些设置匹配的三个文本框和一个下拉列表。

　　传递扩展的大部分工作涉及编写实际传递报表的类。我创建的类名为 SPSLibraryDeliveryProvider。它实现 IExtension 和 IDeliveryExtension 接口。当准备传递报表，并且用户已经选择了自定义解决方案作为传递方法时，Reporting Services 引擎自动实例化该类。

　　在该类中，操作在 Deliver 方法中开始。该方法收到一个通知参数，该参数用于检索特定于用户的传递设置，以及与主机服务就进度或故障进行通讯。接着，Deliver 方法调用 SaveReport，这是传递扩展调用自定义 SharePoint Web 服务的位置。SaveReport 通过将报表呈现给 PDF 文件开始。

　　SaveReport 方法的下一部分配置 Web 引用添加到项目中时 Visual Studio？ 创建的代理类。在代码中，代理类是 DocumentUtilService.DocumentUtilWse。要初始化代理，我必须将其 Url 属性设置为用户提供的 URL，但是后面需要加上 /_vti_bin/DocumentUtil.asmx。这将确保为 Web 服务方法中的代码正确地建立 SharePoint 上下文。由于 SharePoint 实际上修改了传入某个站点的 _vti_bin 目录中的请求，并将这些请求路由到虚拟服务器根目录下的 _vti_bin，因此代理必须配置一个目的终结点引用。通过设置目的终结点引用，最终的请求将传递由 WSE 中的 WS-Addressing 逻辑实施的验证。终结点引用的URL 是用 CreateVSUrl 函数构建的，它根据用户提供站点的 URL 确定虚拟服务器的 URL。

　　最后，设置代理的安全凭据。Web 服务将通过分配给 ReportServer 服务的帐户的安全上下文进行调用。然而，这仅对于示例是可行的。Microsoft 不推荐以高权限运行服务，因为这样会将网络暴露给高权限的攻击。相反，您应该将特定的凭据集中在传递扩展设置中，使用这些凭据进行请求。

　　SaveReport 方法的最后一部分实际上使用数据填充了请求。创建一个 DocInfo 类，并使用应该存储该类的报表的文件名及库名填充该类。此处调用的 GenerateFileName 函数采用用户指定的文件名，并添加 .pdf 文件扩展名和选定的时间戳类型（可选）。使用 RequestSoapContext.Attachments 集合将报表的二进制表示附加到请求。最后，传递扩展将其信息发送给自定义的 SharePoint Web 服务。

　　部署

　　关键部署项在随示例代码打包的说明中进行了详细的描述，但在此处说明是为了确保您知道应该牢记它们。

　　SQL Server Reporting Services 安装的 ReportServer Windows 服务应该配置有一个 Active Directory？ 域帐户。通过为其分配一个域帐户，管理员能够为特定的 SharePoint 库分配传递扩展权限。

　　自定义的 SharePoint Web 服务必须按照 MSDN 文章"Writing Custom Web Services for SharePoint Products and Technologies" 中描述的方式进行部署。这包括从 .wsdl 和 .disco 文件创建 .aspx 文件，并将其放在 C：Program FilesCommon FilesMicrosoft SharedWeb server extensions60ISAPI 文件夹中。

　　传递扩展程序集必须部署在 SQL Server Reporting Services 的 ReportManager 和 ReportServer 目录中。传递扩展还必须添加到 RSWebApplication 和 RSReportServer 配置文件中。最后，Rssrvpolicy 和 Rsmgrpolicy 文件中还有需要解决的代码访问安全性 (CAS) 配置。有关此内容的详细信息，请参阅 MSDN 文章"Code Access Security in SQL Server 2000 Reporting Services"。

　　SQL Server 2000 和SQL Server 2005

　　我原先使用 SQL Server 2000 编写本文中描述的解决方案。好消息是，对于 SQL Server 2005 而言，我所依赖的接口保持不变，除了对传递扩展项目进行升级/重编译外，一切运行良好。

　　对于 SQL Server 2005，Reporting Services 目录位于 C：Program FilesMicrosoft SQL ServerMSSQL.3Reporting Services 中（如果您一起安装了 SQL Server， Analysis Services 和 Reporting Services）。在将升级的 SPSLibraryDelivery.dll 放入 bin 文件夹中时，按照相同的说明修改配置文件和策略文件。

　　针对我的测试，我还安装了 Windows SharePoint Services Service Pack 1，扩展了一个新的 IIS Web 站点，并且创建了一个顶级的小组站点。自定义 Web 服务的部署说明保持不变。

　　小结

　　可以使用多种不同的方法来生成报表，从而为用户提供重要信息。大部分组织所面临的挑战不是生成这样的报表，而是以及时有效的方式地传递它们。通过本文所述的自定义传递扩展，可以捕获报表并将它们放在 SharePoint 文档库中，从而使用户能够以更健壮的方式（支持协作和其他有用的功能）查看和分析报表。