Extend SharePoint to Integrate Other Office Applications

项目
12/07/2015

深入剖析 SharePoint集成 Office 应用程序

Pav Cherny

Office 应用程序集成
扩展 SharePoint UI
使用 Office OpenDocuments 控件
与 SharePoint 进行通信
实现自定义 OpenControl 解决方案
总结

Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 能够与 2007 Microsoft Office 系统中的桌面应用程序实现无缝集成，从而简化了文档、电子表格、日历、联系信息等的协作。实际上，这种集成非常天衣无缝，以至于

可以说 2007 Office 系统是一个统一的办公解决方案平台。

这对于那些注重使用 Microsoft® Office 技术来提高信息工作者生产效率的组织来说非常理想。但是，采用不同 Office 应用程序的组织无法享受同样的现成互操作优势。虽然 2007 Office 系统提供了必要的集成功能，但接口和组件的文档记录非常少，并且无法用于所有情形。因而使得第三方供应商难以将 SharePoint® 技术集成到其应用程序当中，而他们的客户要向信息工作者提供统一的体验则更是难上加难。

在本专栏中，我将介绍 Office 应用程序如何与 SharePoint 进行集成和通信，以及可如何根据相同的原理实现非 Microsoft 应用程序与 SharePoint 之间的集成。不过，我将首先简要介绍用于实现无缝集成的服务器配置设置、客户端组件和通信协议。

了解这些细节之后，我将进一步介绍如何与不具备内置 SharePoint 支持的应用程序进行集成。一般来说，这方面的内容侧重于实现 IFilter 组件，以便扩展搜索功能并在 SharePoint 服务器上添加自定义图标，但我的介绍不仅限于此。扩展搜索并返回带有适当图标的结果并不表示实现了完整的应用程序集成；用户可能还希望直接在 SharePoint 用户界面中打开这些文档。

而这正是复杂之处。如果尚未在工作站上部署 Office，那您需要临时安装一个客户端组件。但即使已部署 Office，您仍可能发现该组件无法可靠地运行，具体取决于您的 SharePoint 站点拓扑和配置。

为解决这一问题，我创建了一个自定义解决方案，以让您在无需部署 Office 的情况下就可集成任意应用程序（如记事本、Adobe Reader 或 Autodesk AutoCAD）。该自定义解决方案还将说明基于标准 Office 组件的应用程序集成在某些情况下失败的原因。您可以在本专栏的随附材料（可通过网站的“代码下载”获取）中找到该解决方案以及分步部署和配置说明。

Office 应用程序集成

从用户角度来看，SharePoint 的菜单类似于 Windows®“开始”菜单。在文档库中创建一个新文档非常简单：单击“New”（新建），然后单击“New Document”（新建文档），Microsoft Office Word 2007 即启动。编辑现有的文档同样非常简单。将鼠标置于文档上方，打开“Edit Control Box (ECB)”（编辑控件箱）下拉菜单，然后单击“Edit in Word”（在 Word 中编辑）。很少有人会想到当通过 JavaScript 从网页启动 Word 2007 时，虽然您是在本地运行此应用程序，但文档却位于远程 SQL Server® 数据库中，并且 Web 服务器存在于数据访问路径当中（如图 1 所示）。

图 1 在 SharePoint 中处理 Word 文档（单击该图像可查看大图）

尽管比较复杂，但在安装了 2007 Office 系统的 Windows 工作站上可以得到无缝的用户体验。在 SharePoint 库中处理文档与处理本地文件或网络共享中的文件非常类似。

然而，如果没有安装 Office 2003 或 2007 Office 系统，Windows 工作站上的 UI 则有所不同。单击“New Document”（新建文档）或“Edit in Word”（在 Word 中编辑）仅出现一个对话框，提示您没有兼容 Windows SharePoint Services 的应用程序。

这也并不奇怪。要提供 Office 用户所中意的统一体验，必须多种元素协同工作才能实现。SharePoint 必须了解文档库中维护的内容类型才能在“New”（新建）和 ECB 菜单中呈现出所需的命令。为响应这些命令的鼠标单击事件，必须运行 JavaScript 代码以启动相关的应用程序，并沿文档路径传递。这部分工作与工作站配置有关，因为 JavaScript 代码是在本地运行。此外，相关的应用程序必须与 SharePoint 进行通信，以便读取并可能写入文件。如果希望将应用程序与 SharePoint 集成，则必须将这些元素组合在一起。

另一方面，SharePoint 与数据库服务器之间的通信对应用程序是透明的，并且 Web 服务器上的索引过程也对应用程序透明以便于搜索。因此，虽然我不会在本文中详细介绍这些方面的内容，但我建议您阅读 Microsoft 知识库文章“如何使用 Windows SharePoint Services 3.0 注册 Microsoft 筛选器包”（网址为 support.microsoft.com/kb/946338）以了解 Microsoft 筛选器包。现在，我们的重点是添加命令、实现必要的客户端组件和促进应用程序通信。

扩展 SharePoint UI

扩展 SharePoint 用户界面和功能的方法非常多。可更改站点的设计、自定义 ASP.NET 页面、开发 Web 部件，或更改 WSS 和 MOSS 中包含的 JavaScript 代码以便直接启动应用程序。

还可以在文本编辑器中打开 Ows.js 文件（该文件位于 SharePoint 前端服务器上的 COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Layouts\1033 文件夹中），并更改 createNewDocumentWithProgIDCore、editDocumentWithProgIDNoUI 和 DispDocItem 函数的工作方式。但还有更好的方法，不需要您以不支持的方式更改 WSS 代码库：使用内容类型和文档类型映射。

在文章“使用自定义内容类型对数据管理进行标准化”（请参阅 2008 年 2 月刊的《TechNet 杂志》，网址为 technet.microsoft.com/magazine/cc194408.aspx）中，我解释了如何创建全局和特定于站点的内容类型以便管理文档以及 SharePoint 文档库和列表中的其他内容。也可以阅读该文章随附材料中的工作表 Text Content Type.pdf，它解释了如何为 .text 文件创建一个新的内容类型并将该内容类型与文档库进行关联。这样就可从“New”（新建）菜单选择“Text Content”（文本内容）命令，正如可针对 Word 文档选择“Document”（文档）命令一样（请参阅图 2**）。

图 2 SharePoint UI 中的自定义内容类型（单击该图像可查看大图）

ECB 菜单同样可以进行扩展。您可能希望 ECB 菜单可以感知内容类型，但在当前的 WSS 版本中并非按照这种方式实现该菜单。必须在 Docicon.xml 中注册您的文档类型，该文件位于每台 SharePoint 前端服务器上的 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Xml 文件夹中。

例如，通过将以下文档类型映射添加到 Docicon.xml 的 <ByExtension> 段落中，就可使 SharePoint 显示“Edit in Notepad”（在记事本中编辑）命令（请参阅 Text Content Type.pdf 文件了解更多详细说明）：

<Mapping Key="text" Value="ictxt.gif" 
  EditText="Notepad"
  OpenControl="SharePoint.OpenDocuments"/>

Key 参数标识文件扩展名、Value 参数定义显示在用户界面中的文档图标、EditText 参数定义 SharePoint 附加到“Edit in”（在…中编辑）命令中的字符串，而 OpenControl 参数指定客户端 COM 组件的 ProgID。SharePoint JavaScript 函数将该 ProgID 传递给 ActiveXObject 调用（请参阅 Ows.js 了解详细信息）以实例化 COM 对象（此对象可以是应用程序本身，也可以是基于相关文件类型启动应用程序的帮助程序控件）。

SharePoint 产品和技术网站

请注意：名为 SharePoint.OpenDocuments 的 OpenControl 是指最新版本的 Office 随附的一个 ActiveX® 控件 (%PROGRAMFILES%\Microsoft Office\Office12\Owssupp.dll)。如果工作站中存在该文件且 SharePoint 服务器上的 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\Template\Images 文件夹中存在指定的文档图标（Value 参数），则表示您可能已完成大部分必要的集成工作。

Windows SharePoint Services 3.0 SDK 中包含一些有关 2007 Office 系统随附的客户端 API（包括 OpenDocuments 控件）的信息。请参阅 msdn2.microsoft.com/ms440037 上有关客户端 API 参考的部分。

使用 Office OpenDocuments 控件

OpenDocuments 控件满足了最重要的应用程序集成需求，但它需要 Office 2003 或 2007 Office 系统，并且功能比较有限。“New”（新建）菜单中的命令可能并不总是有效，而且有时它们还会显示可能会误导用户的通知。

如图 3 所示，OpenDocuments 控件通知用户未正确安装所需应用程序或无法打开模板文件，但实际上并不存在这两种问题。“Edit”（编辑）菜单的功能也有问题。用户经常会看到显示在图 3 前面的第二条错误消息。我对这条消息记忆深刻，因为它甚至可以误导 SharePoint 专家，稍后我将向您详细介绍该消息。

图 3 OpenDocuments 控件令人误解的错误消息（单击此图像可查看大图）

尽管如此，对于所有工作站都已安装最新版本的 Office 的环境而言，OpenDocuments 控件非常有用。除此之外，可在“New”（新建）菜单中隐藏内容类型（显示“Document Library Settings”（文档库设置），单击“Change New Button Order And Default Content Type”（更改“新建”按钮的顺序和默认内容类型），然后取消选中所有内容类型的“Visible”（可见）复选框），这样用户就不会遇到第一条错误消息。还可使站点拓扑尽量简单，以避免基于 Web 的分布式创作和版本控制 (WebDAV) 通信问题，从而消除第二条错误消息。

与 SharePoint 进行通信

到目前为止，我已成功地扩展了 SharePoint UI，并可通过 OpenDocuments 控件启动应用程序，但我的应用程序仍需要一种方法来与 SharePoint 进行通信以访问数据。通常，SharePoint 支持多种方法来实现此目的，如 Microsoft Office FrontPage® Server Extensions、WSS 远程过程调用 (RPC)、WebDAV 和 Web 服务。实际上，Office 应用程序（如 Word 2007）可使用这些通信方法中的任意一种或全部，具体取决于访问文档的方法（如通过 Web 文件夹、映射网络驱动器或 SharePoint UI）。

每种 SharePoint 客户端/服务器通信方法都依赖 HTTP 作为底层协议。例如，FrontPage 和 WSS RPC 均使用 HTTP POST 和 HTTP GET 请求定向到 SharePoint 服务器上 %COMMONPROGRAMFILES%\Microsoft Shared\Web Server Extensions\12\ISAPI 文件夹及其所有子文件夹中的 ISAPI 扩展。

ISAPI 最重要的一项扩展是 Owssvr.dll，它能处理列表和文档库。图 4 显示了在 Word 2007 中打开 SharePoint 的“Save”（保存）对话框（左侧），以及通过 URL 请求 https://sharepoint/HR/Administration/_vti_bin/owssvr.dll?dialogview=FileSave&location=Shared%20Documents&FileDialogFilterValue=*.docx 直接在浏览器中打开该对话框（右侧）的示例。两个屏幕快照之间的相似之处非常明显。

图 4 Word 2007 和 Internet Explorer 中的 SharePoint“Save”（保存）对话框（单击此图像可查看大图）

其他重要的 ISAPI 扩展包括 Author.dll，它运行 FrontPage 和 WSS RPC 以执行客户端编辑操作，如上载、重命名和删除文档）；Admin.dll 可用于管理站点并执行多个其他管理任务；Shtml.dll 可用于支持 HTML 表单提交。

通常，如果不访问源代码，则不会将 FrontPage 和 WSS RPC 支持添加到现有的应用程序中（如记事本或 Adobe Reader）。但是可通过 Windows 中包含的 Web 客户端功能来提供必要的通信工具。

SharePoint 还通过 Httpext.dll 支持 WebDAV（位于 %WINDIR%\System32\Inetsrv\ 文件夹中），但我们仅讨论在客户端的实现。运行 Windows Server® 2008 或 Windows Vista® 的计算机默认安装 Web 客户端功能。可在“控制面板”的“管理工具”中的“服务”小程序中找到对应的 WebClient 服务。在 Windows XP 和 Windows Server 2003 上，必须单独安装 Web 客户端。无论使用什么系统，均需确保已启动 WebClient 服务，并将“启动类型”设为“自动”。

图 5 显示了 Web 客户端的体系结构。WebClient 服务是在一个用户模式 DLL (Webclnt.dll) 中实现的，“服务控制管理器”将这个 DLL 加载到 Svchost.exe 宿主进程中。Webclnt.dll 提供“网络提供程序”接口来执行非 I/O 操作（如对访问 WebDAV 的用户执行身份验证；将 SharePoint 站点安装为网络驱动器；将 SharePoint 站点、列表和文档库枚举为网络资源；以及断开已安装的驱动器）。

图 5 WebDAV 客户端重定向程序体系结构（单击此图像可查看大图）

为此，Webclnt.dll 需要与提供实际重定向程序功能的内核模式文件系统驱动程序进行通信。WebDAV 客户端重定向程序驱动程序 (Mrxdav.sys) 以重定向驱动器缓冲子系统 (RDBSS) 为基础，该子系统与 I/O 管理器和其他内核组件集成以提供远程文件系统服务。Mrxdav.sys 运行 WebDAV 通信工具以支持对 SharePoint 站点和文档库进行文件系统级别的访问。

如果通过网络重定向程序访问 SharePoint 站点和文档库，则用户应用程序中将不再需要提供 FrontPage 和 WSS RPC 支持。可将网络驱动器映射到文档库（如 net use x:http://wss/doclib/Shared%20Documents），并且还可通过 UNC 路径访问 SharePoint 资源。

URL http://wss/doclib/Shared%20Documents 映射到 \\wss\doclib\Shared%20Documents。因此，可采用多种方式来在应用程序中打开文档。例如，可使用 HTTP 路径 http://wss/doclib/Shared%20Documents/New%20Text%20Document.txt 或 UNC 路径 \\wss\doclib\Shared%20Documents\New%20Text%20Document.txt 在记事本中打开文档。

遗憾地是，Web 客户端的功能存在一些限制。无法访问自定义属性或使用自定义 TCP 端口的 Web 应用程序。如果用户无权访问层次结构中的父站点，那么 Windows Vista 随附的 Web 客户端也会失败，如 WebDAV Access.pdf 中所述（请参阅随附材料）。

路径 https://sharepoint/HR/Administration/Shared%20Documents/ 包括一个不存在的根站点（即 https://sharepoint），而如果不访问根，Web 客户端将无法确定 Web 服务器的功能。Web 服务器拒绝 Web 客户端的 OPTIONS 请求且状态代码为 401，它表示访问并未通过身份验证，并且 Web 客户端将继续提示用户输入凭据，即使用户拥有站点集合 sharepoint/HR 及其中所有站点的管理访问权限（如图 6 所示）。

图 6 失败的 WebDAV 访问 （单击此图像可查看大图）

在使用 OpenDocuments 控件时，如果 Web 客户端无法打开文档，您将收到如图 3 所示的错误消息。应用程序运行正常且文档类型映射正确。原因在于无法通过 WebDAV 重定向程序访问该文档。

实施自定义 OpenControl 解决方案

通常，可通过以下两种方法来解决 Web 客户端的不足之处。可以等到 Microsoft 提供更新后的 Web 客户端版本，也可以实施能够解决当前状况的自定义 OpenControl 解决方案。实施自定义 OpenControl 并非易事，但它可以免去在工作站上安装 Office 的需要，使您能够以更有意义的方式处理“新建”（New）命令和“Edit in”（在…中编辑）命令，并且它还使您能够从 Web 客户端失败的境况中解脱出来。

如果这些问题中有您感兴趣的内容，请参阅随附材料中包含的 AppStart 源代码。它显示了如何在 Microsoft .NET Framework 程序集中公开 SharePoint JavaScript 代码可以调用的 OpenControl COM 接口。AppStart 源代码还展示了一种可行方法，如果无法使用 WebDAV 进行直接访问，该方法能通过 HTTP 检查能否访问文件并将文件下载到本地计算机。最后，AppStart 源代码通过将与内容类型相关的模板下载到本地计算机来响应“New”（新建）命令，从而使用户可以开始处理文档。Text Content Type.pdf 和 Adobe Reader Support.pdf 工作表介绍了部署此 OpenControl 解决方案的方法。

图 7 中所示的图表显示了 AppStart 的体系结构。我的自定义 OpenControl 组件（称为 Biblioso.dll）公开了两个等同的 COM 接口，SharePoint JavaScript 可以调用这两个接口来创建新文档或打开现有文档进行编辑（Biblioso.AppStart.2 和 Biblioso.AppStart.3）。

图 7 AppStart 的体系结构 （单击此图像可查看较大视图）

如果已打开文档进行编辑，Biblioso.dll 将确认文件是否存在，并且如果可直接通过 WebDAV 访问该文件，则启动相关的应用程序以及文档路径。如果无法访问该文件，Biblioso.dll 将启动进程外 COM 服务器，此服务器将加载 OpenDocsUtility.dll 以通过 HTTP 下载文件并启动应用程序以及已下载文档的路径。

进程外 COM 服务器使此解决方案可以摆脱 Internet Explorer® 进程（此进程要求必须在保护模式下将文件下载到 Temporary Internet 文件夹）。用户必须能够在不受保护模式限制的情况下下载文件，而作为应用程序代理运行的进程外 COM 服务器可以提供这一功能。

由于不支持使用 .NET 来开发进程外 COM 服务器，因此我转而使用 C/C++ 编写该可执行程序。我仅使用 C++ 实现最基本的“Save As”（另存为）对话框。为使解决方案尽可能地直观简单且减少开发工作量，我把实际的下载代码放在一个 .NET 程序集 (OpenDocsUtility.dll) 中，然后通过另一 COM 接口来进行调用。

为简化部署，我为该解决方案添加了一个“安装”项目。除此之外，安装例程注册了所有 COM 组件，并将应用程序特定的设置写入 HKEY_LOCAL_MACHINE\SOFTWARE\Biblioso\AppStart。最重要的两个参数是 AllowedApps 和 AllowedFileTypes。AppStart 解决方案仅适用于必须显式指定这些参数的应用程序和文件类型。

安装例程还为进程外 COM 服务器创建了一个提升策略，以便 Internet Explorer 进程中的 Biblioso.dll 可在不触发安全警报的情况下启动 AppBrokerEngine.exe。如果希望了解有关 Internet Explorer 保护模式和如何在应用程序开发中处理它的更多信息，强烈推荐阅读 Marc Silbey 和 Peter Brundrett 撰写的“了解并运行 Internet Explorer 保护模式”，网址为 msdn2.microsoft.com/bb250462。

在查看 AppStart 组件时，请记住开发此解决方案的目的只是为了说明能够实现哪些功能；它并不适用于生产环境。我们没有足够的时间去优化代码和全面测试该解决方案，并且除源代码注释外，并未编写功能文档。

使用该解决方案所带来的风险应由您自己承担。如果有兴趣研究源代码以创建自己的解决方案，可从 Biblioso 代码项目中的 AppStart.cs 着手。该文件实现了 OpenControl COM 接口和来自 Ows.js 的 JavaScript 调用的入口点。

总结

在处理文档以及 SharePoint 文档库和列表中的其他项目时，WSS 3.0 和 MOSS 2007 提供了大量应用程序集成功能以实现无缝的用户体验。2007 Office 系统中的桌面应用程序非常生动地展示了这一点，并且还有可能与非 Office 应用程序实现相同级别的集成和可用性。

应用程序集成体系结构的核心是 SharePoint JavaScript 函数所使用的 COM 组件，以及用于启动应用程序的文档路径。2007 Office 系统提供了多个针对特定 Office 应用程序需求优化的 COM 组件，并且还可重用 Office OpenDocuments 控件来集成非 Microsoft 应用程序。OpenDocuments 控件满足了最基本的需求。对于更高级的应用程序集成需求，可创建一个自定义控件。

要实现应用程序与 SharePoint 的完全集成，不仅需要安装 IFilter 组件和文档图标以扩展搜索和显示功能，还需在 SharePoint 服务器上创建自定义内容类型和文档类型映射以便在 SharePoint 用户界面中提供适当的“New”（新建）和“Edit in”（在…中编辑）命令。这些命令调用 JavaScript 函数，而这些函数又调用通过 OpenControl 组件公开的方法。工作站上还必须有 OpenControl 组件。

另一重要组件是 Windows Vista 上默认包含并安装的 Web 客户端。Web 客户端实现了 WebDAV 重定向程序和远程文件系统驱动程序，这样所有应用程序都可以通过类似于在网络中共享文件的方式访问 SharePoint 列表和文档库中的资源。尽管 Windows Vista 随附的 Web 客户端具有一些缺陷，但它仍是应用程序集成过程中的一个极其重要的部分。

WebDAV 支持还弥合了在非 Windows 工作站上运行的应用程序与 SharePoint 之间的沟壑。在这些操作系统中，COM 和 ActiveX 控件技术通常均不可用，因此无法使用 OpenControl 组件来自动启动应用程序，但大多数操作系统都包含 WebDAV 重定向程序，因此用户至少可以直接访问文档库，而不必将文件下载到本地工作站。

WSS 3.0 和 MOSS 2007 是 2007 Office 系统成功的基础，并且使用第三方基于 Office 的应用程序的用户可以采用同样的方法来从 SharePoint 中获益。集成功能远远超过了 Office。通过充分利用 SharePoint，可构建一个统一的办公解决方案平台，该平台提供 Office 和第三方软件所具有的相同用户体验，从而提高信息工作者的生产效率。

Pav Cherny 是一位 IT 专家兼撰稿人，专门研究 Microsoft 协作与统一通信技术。他的作品包括白皮书、产品手册和书籍，其内容主要介绍 IT 运营和系统管理。Pav 是 Biblioso Corporation 的总裁，该公司主要经营托管文档和本地化服务。

其他资源