Sharepoint
在企业中收集数据的智能方法
Keith Deshaies
概览:
- 收集和处理数据
- 将表示逻辑从信息管理逻辑中分离出来
- 利用 Microsoft Office 2007 技术构建数据收集解决方案
下载这篇文章的代码: DataGathering2008_02.exe (567KB)
企业利用各种方法来收集大量信息。数据的收集方式包括电子邮件、调查、Web 窗体及其他数据收集机制。通常情况下，数据会
发挥积极的作用。不过，管理大量数据收集工具和所有分散的信息却极其困难。可靠地集成和安全地共享数据一直是 IT 组织面临的挑战。随着各种标准和面向服务的体系结构的不断发展，IT 专业人员可以更加轻松地提高数据的可访问性和安全性。但是，尽管具有构建有效企业体系结构所需的各种工具和技术，其通用程度却远不能满足大量专有接口，因此产生了各自独立的解决方案。
以 Microsoft® Office system 中可用的技术为例。您可以基于 Windows® SharePoint® Services 3.0 快速创建一个部门调查，但是它是否为标准解决方案则取决于您的组织。如果您的公司将 ASP.NET 和 SharePoint 用作基于 Web 的协作和数据集成的平台，则此调查确实提供了标准的解决方案。但是，如果您的环境像我所在的公司那样采用了包括 SharePoint 在内的多个平台，情况就不同了。
当然，SharePoint 提供了多种用来与 IBM、HP、Siebel 等公司的各种系统集成的方法。对于希望创建专门的解决方案且仍使结果数据流入各种后端系统的高级用户而言，这是一个好消息。不过，如果您是一名解决方案架构师，还可以选择更好的方法 — InfoPath® 2007。
InfoPath 2007 是 2007 Office system 的一部分，您可以通过它将解决方案的表示逻辑从服务器上托管的信息管理逻辑中分离出来。利用基于 XML 的 InfoPath 技术，可构建适用于企业的数据收集解决方案。并且，在大多数情况下，InfoPath 窗体设计人员无需去详细了解 XML、Web 服务、解决方案体系结构、ASP.NET 或 SharePoint 对象模型。
在本文中，我将介绍如何使用 InfoPath 2007、Office SharePoint Server 2007 和窗体服务来构建灵活的数据收集解决方案。此外，还会展示如何利用 XML 在多层企业体系结构中将表示逻辑从业务逻辑中分离出来。
请注意，此处提及的“数据收集”指收集来自人类的信息的过程。当然，还有其他收集数据的方法（如爬网数据源），但是这些自动方法不在本文讨论范围之内。
采集和处理数据
数据采集要求可能非常复杂，但是它们具有一些共同点。通过在集中式模块中处理这些相似点，而在分散组件中处理独特要求，可有效地降低冗余工作、维护开销以及总体拥有成本。
例如，上市公司的符合性规定将产生业务要求，后者随之转换成适用于整个公司的信息管理策略。这些策略会影响跨部门的数据收集解决方案并且经常在各部门产生重复工作，例如，HR 部门（处理员工信息）和客户服务部门（处理客户信息）对个人身份信息的收集规则。甚至，类似但不相关的各部门之间的业务流程也可以采用统一的信息管理解决方案。
图 1 显示了典型业务流程的示例。当某个员工希望与同事交换任务时，他必须首先获得该同事的同意，然后是任务计划经理或协调员的批准，最后是主管的批准。例如，它可能涉及员工交换工作班次。尽管这些交换发生在不同的部门且可能采用不同的形式，但各种部门解决方案之间却可以共享相关工作流和信息管理逻辑。
图 1** 可在部门之间共享的数据收集过程示例 **(单击该图像获得较大视图)
当然，巩固冗余组件任务艰巨。推动整个公司的组织结构变化并非易事，但利用 Office system 技术可构建坚实的基础来促进这些变化。通过 InfoPath 2007，单个部门可创建与集中式标准信息管理系统相集成的窗体应用程序。同时，SharePoint 2007 使 IT 部门可将对站点集合、站点和文档库的管理控制委派给各个部门和团队。因此，各团队可在 IT 参与程度最低的情况下构建和部署自己的解决方案，而 IT 部门仍可控制所有共享服务和组件（如工作流、信息管理策略和备份过程）。
集中数据收集工作
企业通常向各团队提供部门应用程序服务器，以满足各自的信息管理需求。IT 部门仅负责保持硬件和操作系统正常运行，而各部门则需要管理其解决方案的所有方面。这些部门之间几乎很少协调，因此信息共享非常困难。
集中数据收集工作的技术难题主要涉及共享环境中自定义组件的安全性、性能、维护和支持。例如，如果在部门应用程序服务器上托管单个解决方案，则故障组件的影响会被隔离。但是，在共享环境中，故障组件则可能会更大规模地影响业务流程。这样，IT 部门就必须建立严格的策略来管理集中式系统上自定义组件的部署和维护。
如果在中心服务器场上托管部门的 SharePoint 解决方案，您需要在中心应用程序服务器上部署和维护这些部门解决方案的所有自定义组件。一种解决方案是依赖自定义字段类型，通过从后端 Web 服务填充的下拉列表来扩充解决方案的 UI。另一解决方案可依赖于 Web 部件来实现相同目的，它可以使用自定义工作流，所有工作流均使用托管代码编写且部署为 Microsoft .NET Framework 程序集。
即使将相对较少数量的 SharePoint 解决方案移动到中心应用程序服务器场，也可能产生棘手的配置和支持问题。如果必须在全局程序集缓存 (GAC) 中部署程序集，则安全性将成为问题，因为这些程序集将以完全信任方式运行。编程拙劣的组件可能使系统面临 SQL 注入、跨站点脚本或拒绝服务攻击。您需要确保组件可满足典型工作负载、峰值要求和长期运行操作，并保证它们不会阻止其他流程、可同步处理事件且组件执行可靠的输入验证。这样，用户就无法将 SQL 语句或脚本插入用于更新数据库或远程 Web 系统的列中。
简而言之，目的是要在标准产品功能的基础上加强安全且可扩展的服务器配置。通过依赖可重用且经过全面测试的解决方案，可避免创建大量自定义组件的麻烦。因此，可以保持前端分散而后端集中。关键是以松散耦合方式集成组件，以促进现有解决方案的重复使用。
拆分业务逻辑
那么，如何构建可在服务器上配置的灵活数据收集解决方案？最佳策略是将解决方案体系结构拆分成单个层，如图 2 所示：数据存储、业务逻辑和表示或 UI。现在，UI 通常基于浏览器，而业务逻辑则驻留在 Web 应用程序服务器上。它们分别需要访问数据库和非关系型数据存储库。
图 2** 构建于三层体系结构上的典型企业解决方案 **(单击该图像获得较大视图)
通常，业务逻辑包括事务逻辑来确保事务以原子级方式应用到各数据库管理系统。业务逻辑还可通过 HTTP、消息队列、RPC 等集成多个中间层服务。然而，整体解决方案体系结构本质上仍为三层模型。
图 2 中没有说明企业环境中业务逻辑的复杂性。此图中的应用程序服务器看起来似乎仅注重呈现基于浏览器的窗体和处理提交的数据，但该表示并未考虑工作流、符合性或信息管理需求。要解决这些需求，需将业务逻辑拆分成两个：表示逻辑和信息管理逻辑。这样，即可根据需要混合和匹配中间层组件，而不用针对每个解决方案从头重新构建组件。
图 3 显示了该体系结构，其核心是内容或数据，周围则是信息管理逻辑（它将在内容的整个生命周期中对其进行管理）。将表示逻辑与信息管理逻辑接合，即可通过用户界面访问数据。
图 3** 将表示逻辑从信息管理逻辑中分离出来 **
XML 的收集和处理
在面向服务的应用程序 (SOA) 环境中，XML 是用于定义以及在各组件间共享数据和数据结构的主要标准。因此，XML 是在表示和信息管理组件之间实现接合的理想选择。
必须通过以下两种方式实现通信：需将 XML 转换成适于浏览器读取的文档和由窗体生成的 XML 文档。到目前为止，构建基于 XML 的窗体应用程序仍需要大量的编程技能。当结果 XML 数据必须遵守行业架构以促进组织内部的信息交换时尤其如此。
通过 InfoPath 2007，可以更加轻松地开发基于 XML 的窗体。掌握 XML 的具体细节当然非常有帮助，但窗体设计人员和高级用户已无需通过 XML 向导来构建基于 XML 的窗体应用程序。窗体设计人员只需将 XML 文档或 XML 架构导入 InfoPath，然后将各个属性和元素节点从数据源映射到窗体中的字段即可。窗体设计人员也可从 Web 服务、SQL Server® 数据库或者空白模板开始从头构建一个窗体，而 InfoPath 会在后台自动创建底层架构和数据绑定。
使用 InfoPath 和 XML 架构标准化窗体有多个好处。如果已有明确定义的 XML 架构，窗体设计人员以及工作流和信息管理组件的开发人员可根据相同的数据结构创建解决方案。如果窗体设计人员从头开始设计，则开发人员必须等到窗体完成后才能了解它对于底层数据结构的影响。定义完成数据结构后，只要现有的工作流和信息管理组件依赖于相同的数据结构，未来的解决方案（如新窗体模板）就可重复使用它们。并且，未来的工作流和信息管理组件可通过现有窗体和数据协同工作。如果基于已建立的行业架构来构建数据收集解决方案，结果会变得更加灵活。实际上，这些解决方案将与使用相同架构的其他公司所构建的解决方案相互兼容。
我创建了一个简单的 DirectReports 架构来将员工和经理关联起来。经理可使用结果窗体对其直接下属进行评估。可在本文所引用下载项的 Direct Reports 文件夹中找到架构、窗体以及说明如何重新创建窗体的 readme.htm，网址为 technetmagazine.com/code08.aspx。窗体只是基础，但却说明了基本概念。
下面这一点非常重要：我并未在 InfoPath 中创建任何验证逻辑，但是 InfoPath 仍会要求以特定的格式（domain\account 和 recipient@domain.tld）输入用户 ID 和电子邮件地址。否则，结果 XML 文档将无效。这是因为 XML 架构定义了这些格式。您可保存具有无效数据的窗体，但却无法提交它（如图 4 所示）。（我已向窗体添加了一个虚拟提交规则，因此您可以对此进行测试而不用实际向任何位置提交数据。）InfoPath 2007 验证会自动确保窗体已完全填写且无此类错误。
图 4a** 验证出错阻止用户提交窗体 **(单击该图像获得较大视图)
图 4b** 生成的错误消息 **(单击该图像获得较大视图)
XML 架构将用作表示逻辑和信息管理逻辑之间的绑定约定。InfoPath 将锁定架构，这样窗体设计人员将无法刻意更改数据结构。这一点非常重要，因为更改已建立的 XML 架构可能会破坏现有的企业解决方案（如计划与新窗体模板结合使用的工作流模块）。
InfoPath 提供了大量功能，用来将高级的表示逻辑构建到窗体应用程序中。可使用 XML 文件、Web 服务、SharePoint 库和列表、数据库等中的数据来引入有意义的默认值。可通过规则（包括验证逻辑）根据用户选择更改字段值、添加托管代码以满足最高级的自定义需求，以及使用窗体服务使得可通过 Web 访问窗体模板。在任何情况下，窗体中的数据最后均会作为符合架构定义的 XML 文档到达信息管理逻辑。
使用 XML 或元数据
您可能想知道是应将信息管理逻辑直接应用到提交的 XML 文档还是使用分析器来将所需信息提取为元数据。SharePoint 可同时支持这两种方法。开发人员习惯于直接使用 XML 文档，但元数据更加灵活。
为了说明这一点，我创建了一个简单的 Web 服务，用于分析从图 4 所示的 Direct Reports 窗体传入的 XML 文档（可在随附下载项的 XMLParsingWebService 文件夹中找到源代码、安装文件以及具有分步说明的 readme.htm）。Web 服务可轻松地从 XML 文档中读取经理的用户 ID，将用户 ID 拆分成域和用户名两部分，根据这两部分创建消息，然后引发一个普通异常以返回处理后的信息，并在 InfoPath 窗体中以伪错误消息的形式显示。这是提交数据后在 InfoPath 中弹出对话框的一种简便方法。Web 服务非常有效，但是如果更改了底层数据源（例如，如果在 DirectReports.xsd 中将 OrgPerson 元素重命名为 Manager，并如 readme.htm 文件所述使用新架构更新了 InfoPath 窗体），Web 服务将失败。这一点也不奇怪。现在，XML 文档已发生变化，访问 User ID 元素的旧 XPath 表达式已无效。OrgPerson 和 Manager 架构几乎相同、InfoPath 窗体相同并且所需的处理结果也相同，尽管差异极小，但仍需部署和维护相同的 Web 服务。
如果希望将自定义代码在应用程序服务器上所占的空间降至最小，它并非一个好方法。与之相反，通过将 XML 节点映射到元数据字段并基于元数据执行处理，可针对类似数据结构使用相同的工作流和信息管理逻辑（即使 XML 架构并不相同）。只需确保子元素映射到正确的元数据字段并且数据格式符合处理要求，然后即可重复使用现有代码。
将 XML 节点映射到元数据字段与在 InfoPath 窗体中将 XML 节点绑定到 UI 控件（如图 5 所示）类似。在 SharePoint 中，元数据字段与在站点级别或列表级别定义且在内容类型定义中引用的列对应。内容类型定义了内容项目的特性（如元数据字段、工作流和窗体）。为使内容类型的元数据字段与相关 XML 文档中的对应节点保持同步，SharePoint 依赖于内置 XML 分析器执行属性升级和降级。在属性升级过程中，XML 分析器将 XML 文档中的节点值提取到文档库的对应列中。属性降级则指相反的过程，即从文档库中取出列值并写回文档。最重要的一点是 XML 分析器可使元数据字段和映射 XML 节点之间保持同步。
图 5** InfoPath 和 SharePoint 间的 XML 架构映射 **(单击该图像获得较大视图)
使用 SharePoint 对象模型时，Web 部件、工作流和信息管理逻辑可使用元数据字段以及底层 XML 文档。更改映射元数据字段的值会改变 XML 文档中的节点值，反之亦然。但是，直接使用 XML 文档可将业务逻辑和 XML 架构紧密结合起来。另一方面，映射元数据字段会提高代码的可重复使用性。显然，需确定哪种方法适合您的环境，但在大多数情况下，依赖元数据字段的 SharePoint 解决方案提供了更大的灵活性和更多的代码重用机会。
为说明 SharePoint 如何将 XML 节点与元数据字段关联起来，我在附属材料中包括了一个 SharePoint 功能以提供自定义文档库（请参阅随附下载项的 OrgPersonLib 文件夹中的 OrgPersonContentType.xml 文件）。OrgPerson 内容类型引用了以下四个字段：UserID、FullName、EMail 和 Direct_x0020_Reports。FullName 和 EMail 为内置字段。UserID 和 Direct_x0020_Reports 为 OrgPersonSiteColumns.xml 中定义的自定义字段。
字段定义非常通俗易懂。可在字段定义中直接将字段绑定到 XML 节点，也可在内容类型中覆盖此信息。我决定使用后一技术，因为它允许我在与 XML 文档不相关的内容类型以及依赖于不同 XML 结构的内容类型中使用自定义字段。OrgPerson 内容类型将元数据字段绑定到 XML 节点（其安排与我之前介绍的 OrgPerson 架构匹配）。此外，还有一个 AdditionalContentTypes.xml 文件，它定义了将相同元数据字段绑定到不同 XML 节点的更多内容类型。查看 Node 属性中的 XPath 表达式即可了解二者之间的差异。
OrgPersonLib 类型的文档库可存储不同类型的 XML 文档，而节点值通过相同的库列提供。此外，也可利用这个简单的映射技术来重用工作流和信息管理逻辑，因为四个内容类型（OrgPerson、Manager、Supervisor 和 User）引用一组共同的元数据字段。
图 6 显示了来自 Direct_x0020_Reports 的 OrgPerson 内容类型的 FieldRef 元素，它根据 XPath 表达式将字段映射到直接下属的 User ID 节点 (/OrgPerson/direct-report/user-id)。由于 XML 文档可包括多个直接下属条目，因此必须指定 Aggregation 属性。这便定义了 XML 分析器将如何处理返回的值集合。如果忽略此属性，XML 分析器将仅提取第一个节点值。支持的聚合值为 sum、count、average、min、max、merge、plain text、first 和 last。
图 6** 映射到 XPath 表达式的元数据字段 **(单击该图像获得较大视图)
所有示例内容类型均将标准 upload.aspx 页面用作 DocumentTemplate，因此单击 SharePoint UI 中的“新建”按钮时可将 XML 文件上载到文档库中。只要上载具有 .xml 文件扩展名的文件，SharePoint 就会自动调用内置 XML 分析器（一个例外情况是 WordProcessingML 文件，SharePoint 会为它调用 WordProcessingML 分析器）。XML 分析器会检查上载的 .xml 文件以确定相关的内容类型。这样，即可从字段定义中指定的位置中提取节点值并执行属性升级。（您可在上载 OrgPersonLib\XMLFiles 文件夹中包括的 OrgPerson.xml 文件时检验此过程。）此 XML 文档的结构与 OrgPerson 内容类型定义中指定的 XPath 表达式匹配。相应地，SharePoint 从 .xml 文件中提取数据、将数据写入对应的库列中并在 EditForm.aspx 页面中显示数据，因此可以确认并更新未标记为只读的文档属性。图 7 显示了包含从 OrgPerson.xml 中提取的数据的 EditForm.aspx 窗体。
图 7** 包含提取数据的 EditForm.aspx 窗体 **(单击该图像获得较大视图)
如果更改 EditForm.aspx 中的 User ID、Full Name 或 E-Mail 值，SharePoint 会执行属性降级以更改底层 XML 文档中的节点值。不过，请注意，SharePoint 并不会强制施加 XML 架构限制，除非您亲自针对窗体执行所需逻辑。
此外，SharePoint 不会运行窗体应用程序的表示逻辑。例如，如果更改了 User ID，SharePoint 不会验证新值是否符合 NetBIOS 约定，也不会自动更新 Full Name 和 E-Mail 字段以匹配新选择。因此，如果更改单个字段可能产生不一致，应将内容类型定义中的对应列标记为只读，从而强制用户使用窗体应用程序（如 InfoPath）来更新数据。并且 XML 分析器会将 XML 文档中的所有更改提升到 SharePoint 中的对应元数据字段。
在 OrgPersonLib 示例中，可上载 OrgPersonLib\XMLFiles 文件夹中的任意 .xml 文件。.xml 文件使用完全不同的数据结构，但 SharePoint 会识别内容类型并将正确的节点值升级到站点列中。这是因为我在 XML 文件中使用了一个处理指令，来将 XML 文档与其对应的内容类型相关联。然而，OrgPerson.xml 文件并不包含此信息，但这不是问题。如果 SharePoint 无法通过处理指令或文档模板将 XML 文档与内容类型相关联，SharePoint 会使用默认的内容类型。对于 OrgPersonLib 的情况，它将恰好是 OrgPerson 内容类型，因此 XML 文档可被正确解析。
图 8 显示了如何明确地将 XML 文档与内容类型相关联。MicrosoftWindowsSharePointServices 处理指令将 ContentTypeID 定义为 0x010100668E393E4F0EFF4294DBD202D5D8321D。它恰好是 User 内容类型的 ID（如 AdditionalContentTypes.xml 中所定义）。
图 8** User.xml 示例文件的处理指令和 XML 数据 **(单击该图像获得较大视图)
XML 分析器处理 MicrosoftWindowsSharePointServices 处理指令并将 ContentTypeID 值写入 ContentType 元数据字段。所有 SharePoint 内容类型都将共享此元数据字段，因为它是在 System 内容类型中的根级别定义的。如果打开 SharePoint 服务器上的 fieldswss.xml 文件（位于 %CommonProgramFiles%\Microsoft Shared\Web Server Extensions\12\Template\Features\Fields 文件夹中）并搜索 MicrosoftWindowsSharePointServices，即可了解 SharePoint 如何将处理指令与 ContentType 字段相关联。PITarget 属性指向 MicrosoftWindowsSharePointServices（它是处理指令），PIAttribute 指向 ContentTypeID（它包含 User 内容类型的 ID）。
InfoPath 中的内容类型关联
许多窗体设计人员都对 XML 分析和内容类型关联的技术细节感到非常头疼，但 InfoPath 2007 考虑到了所有的细枝末节。OrgPersonLib 示例随附的 readme.htm 文件包含了在 SharePoint 中发布 Direct Reports 窗体模板，以及创建仍然再次绑定到相同元数据字段（UserID、FullName、EMail 和 Direct_x0020_Reports）的内容类型的指令。您可以轻松地将新内容类型添加到 SharePoint UI 中的 OrgPersonLib 文档库。但是，新内容类型也指向作为文档模板的 InfoPath 窗体模板，以在更新现有 XML 文档时调用窗体应用程序。图 9 展示了 InfoPath 发布向导如何简化 XML 节点值与 SharePoint 站点列之间的属性映射。并且，如果再次将节点值与现有站点列相关联，可重复使用现有的 SharePoint 组件。
图 9** InfoPath 2007 中的属性映射 **(单击该图像获得较大视图)
结束语
其他在线资源
通过利用 Office 中提供的技术，企业架构师可构建各种数据收集解决方案，它们具备改善代码重用和信息交换的功能。通过 InfoPath 2007，各部门可创建从各种来源提取信息的解决方案，然后将数据提交到各种系统（如 SharePoint）。SharePoint 还为开发人员提供了一整套 Web 服务和接口以构建工作流和信息管理组件。通过将这些组件托管在集中式 SharePoint 服务器上，各部门就拥有了构建其各自应用程序所需的基础结构。
同时，各部门可更快速地创建数据收集解决方案，可跨部门解决符合性规定和其他全球业务需求，并且随着应用程序服务器上自定义组件使用的减少，IT 环境的可维护性和可靠性将得以增强。
Keith Deshaies 是一位自由技术撰稿人和一家大型电信公司的 IT 分析师。他是 Microsoft Office 和 SharePoint 技术方面的专家，同时也是“技术交流协会”的一名会员。
© 2008 Microsoft Corporation 与 CMP Media, LLC.保留所有权利；不得对全文或部分内容进行复制.