业务应用连接服务

  • 项目

通过 Office 和 SharePoint BCS 管理员工奖励

Ying Xiong

管理员工奖励在任何公司中都是一项关键业务功能。对于像 Microsoft 这样的大型企业来说，情况更是如此。在 Microsoft，我们向符合条件的员工提供很多种奖励，例如，基于绩效的加薪、晋升、奖金、股票和其他奖励。按照公司指导方针和预算（针对每个地区、业务部门或组织、员工薪资计划和工资水平而制定）来管理这些奖励是一个复杂的过程。

向员工提供奖励涉及许多业务规则。尤其是，这些规则要确保所有层次上表现最为出色的员工获得最高奖励，同时确保所有层次上的组织都实现其目标并符合预算和指导方针。每一年，经理和人力资源部门的人员都对数字进行分析，并确定所有层次上每项奖励的指导原则和限额。这是一个耗费时间的复杂过程（称为“校正”）。

目前由我们的经理和人力资源部门的人员所使用的奖励管理工具是一个 Windows 窗体应用程序。该工具发挥着所设计的功能，但无法满足我们的全部需要 — 可通过很多方式对其加以改进以简化校正过程。

作为对校正工具改进建议的响应，Microsoft IT (MSIT) 部门、人力资源业务部门以及 Microsoft Office 和 SharePoint 产品团队展开合作，基于 Microsoft Office 2010 和 SharePoint 2010 中的 Microsoft 业务连接服务 (BCS) 功能创建了一种新的解决方案。BCS 提供了对业务线 (LOB) 系统、Web 服务和数据库以及 SharePoint 和 Office 应用程序中的外部数据的读/写访问。

这种新解决方案将 Microsoft Excel 2010 用作奖励管理 UI，并利用 BCS 技术来缓存和同步用户本地计算机与后端系统（奖励 Web 服务和 SQL Server 数据库）之间的员工数据和业务规则。

本文将与您分享 Microsoft 团队在开发和部署该奖励管理 BCS 解决方案中所总结的经验。

原有设计

现有的奖励管理工具最初的设计是通过一个集成工具集，针对员工的综合评估、校正、评级和奖励工作，提供集成的绩效管理体验。图 1 显示了现有工具的体系结构设计。该工具是一个典型的三层应用程序，其中，UI 层是一个 Windows 窗体应用程序，用于从后端 Web 服务读取数据以及向其写入数据。这些服务可查询和更新 SQL Server 数据库中的员工记录、业务规则和其他参考数据。

图 1 当前奖励管理工具的体系结构

该解决方案的设计方式可将用户计算机与承载 Web 服务组件的 Web 服务器之间的网络流量降到最低。当客户端应用程序启动时，它会检索和缓存组织中该用户拥有访问权限的所有必要参考数据、业务规则数据和员工记录。大多数奖励管理业务逻辑和规则都在客户端组件中实现。因此，当用户分配或更改员工奖励时，将触发相应的业务规则以验证所做的更改，而不会在后端调用 Web 服务。

Web 服务组件是使用 Microsoft .NET Framework 2.0 Web 服务框架（ASP.NET Web 服务）构建的。如前所述，它会将员工记录和业务规则数据返回给客户端应用程序，并将从客户端传递的数据更改保存到数据库中。该 Web 服务中包含业务验证逻辑，用于确保将数据保存到数据库之前的数据完整性。所有 Web 服务调用都设计为同步方法。

用户会在 Web 服务调用失败时获得错误消息，并且用户可以基于错误的性质来采取行动。另外，该 Web 服务设计为将员工和其他数据记录序列化为一个字节数组，并将该字节数组返回给客户端，这样做是为了最大限度地降低在 Web 服务服务器与客户端应用程序之间传输的数据量。

最后，奖励数据存储于在 Microsoft SQL Server 2005 中实现的关系数据库中。该数据库存储管理员工奖励所需的全部数据，以及过去业绩评估期间的历史数据。

如前所述，这种应用程序体系结构大体上可按计划发挥作用，相对以前的奖励与校正系统有了显著的改进。但是，在使用中，我们发现可在很多方面对该工具加以改进，以使校正更加容易，耗费时间更少。为了您能够了解针对新服务做出的设计决定背后的原因，我们来快速了解一下在旧服务中发现的某些问题。

在旧的校正工具中遇到的第一个（或许也是最重要的）问题就是对奖励建模比较困难。在校正过程中，经理们需要对两个变量加以平衡。每个员工必须基于绩效评级获得相应奖励。但是，整个组织又需要符合预定义的奖励预算。正确实现这种平衡是一个耗费时间的过程。经理需要输入员工奖励数字，了解它们对团队奖励预算的影响，并对奖励进行调整以平衡奖励规则和预算。可能要进行多轮工作才能将奖励方案最终确定下来。

现有工具不利于奖励与预算间的平衡过程。在它所提供的功能中，无法让经理针对每种奖励输入不同数字并对结果进行分析，因而无法了解其对预算和指导方针的影响。为此，经理常常不得不将员工数据导出到 Excel 电子表格中，并对奖励和预算数字进行手动建模。

当校正完成且每个员工的奖励最终确定之后，经理必须手动将数据输入到工具中，并提交奖励方案以供审批。这种双重数据输入也是一个耗费时间的过程。

基于 Windows 窗体的工具要求用户联机并位于企业网络上，因为该工具需要访问后端 Web 服务以进行数据读写。这为业务繁忙或经常出差的员工增加了额外的麻烦。

最终，虽然现有奖励管理工具提供了一组内置报表，但我们对附加报表以及灵活的即席生成报表功能仍有许多需求，以提高校正过程的透明度和效率。

BCS 基本信息

通过 BCS，您可以使用 Office 应用程序（Excel、Outlook、InfoPath、Word 等）和 SharePoint 处理后端系统中的数据。如前所述，Office 2010 和 SharePoint 2010 都提供 BCS 组件，因此，该组件在客户端计算机和服务器计算机上均可用。有关 BCS 工具和运行时组件的更多信息，请参见 msdn.microsoft.com/library/ee556826。

在设计支持 BCS 的解决方案时，首先是定义一个实体模型，该实体模型可以连接到外部系统，并将来自这些外部数据结构的数据映射到 BCS 数据结构中。该实体模型称为“外部内容类型”(ECT)。通过 SharePoint Designer 或 Visual Studio，可以根据需要为解决方案创建任意多的 ECT。

ECT 元数据（包括用于定义实体模型的代码）将发布和存储在一个 SharePoint 元数据存储中。通过 SharePoint 工作区或 BCS 提供的独立打包工具，可以将发布的 ECT 模型下载并安装在用户客户端计算机上。

在运行时，客户端或服务器上的 BCS 运行时组件调用该 ECT 模型来与外部系统通信。在客户端上，来自外部系统的数据缓存在用户计算机上的 SQL Server Compact Edition (SQL CE) 数据库之中。缓存的数据随后可通过 BCS API 在 Office 应用程序中进行显示和操作。由用户对缓存数据所做的更改将在用户计算机上的同一 SQL CE 数据库中进行排队。随后，BCS 运行时组件负责通过 ECT 模型将这些更改更新到外部系统。

新的奖励工具

针对新的奖励管理工具，我们使用 BCS 框架创建了一个将 Excel 作为奖励管理 UI 的解决方案，用于解决前面所述的业务问题。在这个 Excel/BCS 解决方案中，我们针对员工信息、业务规则和其他参考数据定义了总共 15 个 ECT。BCS 运行时使用这些 ECT 连接到现有奖励管理 Web 服务（作为外部系统），并检索和缓存员工和业务规则数据。

员工数据将通过一个使用 BCS 本地缓存 API 的 Excel 加载项呈现为一个 Excel 工作表。经理可以完全在 Excel 内分配、校正和管理其员工奖励，并且仍能够基于缓存在 BCS 本地存储中的规则数据来强制执行所有业务规则，即使经理在脱机时也可以做这些工作。通过 Excel 和 BCS 解决方案，经理可在一个屏幕上看到所选员工的列表（在 Excel 工作表中）和各种统计数据（在 Excel 任务面板中）。底部的统计数据将随奖励值的改变而动态更新，并且将根据用户选择的字段而显示不同的统计数据。用户体验因此得到了很大的改善。

使用本机 Excel 功能（如数据透视表和数据透视图），经理和人力资源部门的人员可以创建并显示由 BCS 缓存的数据的各种报表，从而提高工作效率。通过 Excel 模板，用户可以更加轻松地创建报表，且报表无需进行 IT 开发。

除了业务效益之外，我们在开发这个新的奖励管理解决方案时还发现一个有趣的技术方面，即我们可以利用 BCS 解决方案中现有的奖励 Web 服务组件，即使这些 Web 服务并非针对 BCS 设计也未进行相关优化也是如此。我们还能够利用 Excel 加载项解决方案中的现有业务规则数据对象和验证代码。因此，我们能够在相对较短的时间内提供和演示新的解决方案。

解决方案体系结构

新的解决方案体系结构如图 2 所示。您可以看到，对原始体系结构的更改仅限于客户端体系结构组件。在图中，绿色框是在安装 Office 2010 时已安装在用户计算机上的 BCS 组件。蓝色框是为新解决方案开发的组件，浅蓝色框是现有奖励管理工具的组件。

图 2 新奖励解决方案的体系结构

在用户计算机上安装为新奖励解决方案开发的 ECT 时，BCS 同步进程 (BCSSync.exe) 会立即调用实体模型，以便从外部奖励 Web 服务为该模型中定义的每个 ECT 检索数据。所同步的实际数据取决于用户的数据访问权限（数据访问权限通过用户安全 Web 服务获得）。这一步骤要求用户联机，以便访问 Web 服务。

检索到的数据（如组织的员工记录）存储在由 BCS 同步进程创建的 SQL CE 数据库中，该数据库作为用户的本地数据缓存。SQL CE 中的数据使用用户证书进行加密，数据在用户级别是安全的。

BCS 同步进程定期运行，以针对在服务器端进行的任何更改将用户的本地缓存与奖励服务器同步。通过 BCS 框架，可以为每个 ECT 定义不同的同步频率。这意味着我们可以针对不常更改的实体（如业务规则）定义较长的同步频率（数小时或数天），而针对在审查期间可能频繁发生改变的员工奖励数据定义较短的同步频率（数分钟或数小时）。

对于在用户计算机上缓存的员工数据、业务规则数据和其他参考数据，用户只需启动 Excel 即可启动奖励管理工具。奖励 Excel 加载项使用 BCS API 从 SQL CE 数据库中检索数据，并将数据绑定到一个 Excel 工作表中。从此时起，用户就可以在 Excel 中查看员工记录及其奖励数据。这个 Excel 文件与您通常创建或使用的其他 Excel 文件并无差别，用户可以使用本机 Excel 功能来操作和分析数据。

当用户在工作表中做出更改以分配或更新员工奖励（如绩效加薪百分比、升职情况或股份奖励数额）时，则将触发相应业务规则以验证和处理这些更改。我们可以通过将某个 Excel 单元格的值更改事件挂接到现有业务规则代码来实现这一点。

此外，某些员工数据（如员工编号、职务和电子邮件地址）不能由用户来更改。我们可通过本机 Excel 锁定功能来满足这一要求。

当用户已准备好（联机或脱机）将更改提交到后端服务器时，所做的更改将提交到存储在 SQL CE 数据库中的本地队列中。BCS 同步进程从队列中一次提取一个更改，然后将更改发送到后端奖励 Web 服务。如果用户脱机或后端 Web 服务不可用，则 BCS 进程将重试该更改，直到用户联机或 Web 服务可用。

如果用户没有准备好将更改提交到后端服务器，希望将更改保存为草稿，则这个操作将作为普通 Excel 文件保存操作来处理。

定义 ECT

如前所述，任何支持 BCS 的项目的第一个重要步骤都是为解决方案创建 ECT。设计 ECT 是指对要在 Office 或 SharePoint 解决方案中使用的数据实体进行建模。ECT 的数目和每个 ECT 的数据结构取决于应用程序数据的性质、数据在应用程序中的使用方式以及由外部系统提供的接口。

由于 ECT 实体的数据来自外部系统（本例中为奖励 Web 服务），因此，对实体进行建模的最简单方法是将其设计为与外部系统的返回类型相同。此过程不涉及从一个结构到另一个结构的数据映射。不过，这种做法并非总是可行，尤其是在外部 Web 服务返回复杂且具有较深层次结构的数据类型时。奖励管理系统就是这种情况。

现有的奖励 Web 服务会返回一个序列化字节数组（用于员工数据和业务规则数据），该字节数组需要在客户端反序列化为自定义 System.Data.DataTable 类型。默认情况下，这些自定义数据类型在 BCS 中不受支持。

在针对新奖励系统的 ECT 实现中，我们为员工和业务规则实体定义了一种相对较平的数据结构（具有简单数据类型）。它还会将自定义数据表中的数据转换或映射到该平面 ECT 结构中（反序列化之后）。然后，当用户通过 ECT 更新数据时，我们将数据转换回自定义数据表类型，并将更改发送到后端 Web 服务。

每个 ECT 必须定义至少两种方法。Finder 方法将由 BCS 运行时调用以下载所有数据。对于员工 ECT，该方法返回用户拥有访问权限的所有员工记录。当在客户端计算机上安装 ECT 时，安装过程将基于用于 BCS 运行时的 Finder 方法创建一个订阅以定期同步 ECT。

SpecificFinder 方法基于实体标识符（员工编号）返回数据（员工）的特定实例。SpecificFinder 由 BCS 运行时使用，用于将员工实例与后端服务器同步。对于用户在客户端更新的数据实体（如员工记录），ECT 提供一种更新方法，BCS 运行时可以调用该方法以将更新发送到服务器。同样，如果用户需要创建某个实体的新记录，则可以使用在 ECT 中定义一种创建方法。用户不会更改的参考数据实体不需要其 ECT 提供更新或创建方法。

在您自己的 ECT 实现中，可以在调用外部 Web 服务之前添加验证或处理数据所需的任何业务逻辑。这是一个绝佳的 BCS 设计选项，可让您将业务逻辑放在 ECT 中，并在客户端和服务器上都运行该业务逻辑。

您可通过两种方法来设计和创建 ECT。如果外部系统返回相对较平的强类型化数据类型，则您可以使用 SharePoint Designer 来生成 ECT。SharePoint Designer 基于外部系统接口（对于 Windows Communication Foundation (WCF) Web 服务而言，是指操作和数据约定）来生成 ECT。不过，SharePoint Designer 目前不支持复杂类型和自定义类型，例如自定义数据集和数据表。

第二种方法（也是更加强大的方法）是使用 Visual Studio 来设计和创建 ECT。Visual Studio 2010 提供一个专门用于创建 BCS 实体模型的项目模板。我们在奖励解决方案中用的就是这种方法。

ECT 部署和安装

若要让奖励管理系统正常工作，需要下载 ECT 模型并将其安装在客户端计算机上。Microsoft Office 和 SharePoint 2010 提供了两种用于部署 ECT 的方法。图 3 显示了一个部署过程，该部署过程使用了随 Office 2010 安装在用户计算机上的 SharePoint Workspace。图 4 说明了其工作原理。

图 3 通过 SharePoint Workspace 执行的 ECT 部署过程

图 4 通过 BCS 解决方案打包工具执行的 ECT 部署过程

首先，将 ECT 从 Visual Studio 发布到 SharePoint Server 元数据存储（步骤 1）。Visual Studio 若要将 ECT 元数据发布到 SharePoint 数据存储，必须在安装有 SharePoint 2010 的同一台服务器上运行。

接下来，为每个发布的 ECT 创建一个外部列表（步骤 2）。您可以从任何能够连接到 SharePoint Server 的计算机中通过 SharePoint 主页来创建外部列表。

在您为 ECT 创建外部列表之后，SharePoint 会立即运行 ECT，该 ECT 将连接到外部系统并从中检索数据，然后在 SharePoint 站点上以列表的形式显示数据内容。通过这个部署过程，您除了可以查看从客户端上的 Office 应用程序返回的数据外，还可以查看从 SharePoint 服务器上的 ECT 返回的数据。在某些情况下，这是一个十分有用的功能，但不是必需的功能。奖励管理解决方案不使用这个功能，因为我们不希望通过 SharePoint 来显示敏感的员工奖励数据。

现在，将在步骤 2 中从 SharePoint Server 创建的外部列表下载到本地计算机（步骤 3）。您可以通过从 Internet Explorer 连接到 SharePoint 主页并选择“网站操作”|“同步到 SharePoint Workspace”来开始下载过程。这将启动客户端计算机上的 SharePoint Workspace 程序，并以一次下载一个列表的方式开始下载外部列表。使用 Workspace 2010 的当前版本时，用户必须针对每个要下载的外部列表单击“安装”按钮。

通过下载外部列表，SharePoint Workspace 自动将 ECT（元数据和程序集）安装到 BCS 本地数据存储中（步骤 4）。另外，将为所安装的 ECT 创建订阅，以便 BCS 运行时定期将 ECT 数据与外部系统同步。默认数据同步频率为 6 个小时。

奖励管理解决方案使用另外一个部署过程将 ECT 安装到用户的客户端计算机上（如图 4 所示）。

在这种部署方法中，我们使用 BCS 解决方案打包工具 (code.msdn.microsoft.com/odcsps14bcspkgtool)，部署过程不涉及外部列表。因此，无需使用 SharePoint 主页和 SharePoint Workspace，不过，我们仍会利用 SharePoint Server 元数据存储。

在此部署过程中，在将 ECT 发布到 SharePoint 元数据存储中之后，我们使用 SharePoint Designer 将 ECT 导出到模型文件 (.bdcm) 中。您可以在服务器计算机上或您的客户端计算机上运行 SharePoint Designer，并且可将导出的模型文件放置在一个共享文件夹中。BCS 解决方案打包工具读取该模型文件，并生成一个可由用户运行的 Visual Studio Tools for Office (VSTO) 安装包。

从用户的角度来看，这是一个简单、方便和透明的安装过程。在运行 setup.exe 时，用户只需单击一次即可安装从 SharePoint Designer 导出的所有 ECT。安装过程也将立即启动 BCSSync.exe 来运行 ECT，并直接从外部系统将 ECT 数据下载到 BCS 本地数据缓存中。

Excel 加载项

如前所述，我们将现有的 Windows 窗体应用程序组件重新设计为一个 Excel 加载项组件，并将 Excel 用作管理员工奖励的 UI。该 Excel 加载项执行以下主要功能：

  • 将员工记录以及相关指南和统计数据呈现在 Excel 工作表和任务窗格之中。
  • 使用 BCS API 从 BCS 本地缓存检索员工数据和业务规则数据，并将所做的任何更改写回 BCS 本地更新队列。
  • 在用户对员工奖励进行更改时调用现有业务逻辑代码，以确保所做的更改符合相应指导值和最小值/最大值范围。

图 5 显示了新的基于 Excel 的奖励管理 UI。屏幕的上半部分是一个 Excel 工作表，其中显示了该用户组织的员工记录。屏幕的下半部分是一个任务窗格，其中显示了突出显示的员工（所选行）的指导值和该组织的统计数据。屏幕底部显示了所选列的指导值和统计数据。

图 5 奖励管理解决方案的 Excel 设计

这个简单易用的 Excel 界面可帮助经理和人力资源部门的人员有效管理他们的员工奖励。他们将在一个屏幕上完成其所有工作，并且仍会看到该组织的总体奖励情况。当然，他们可以使用本机 Excel 功能（如数据透视表和数据透视图），基于工作表员工数据来构建附加的统计数据和图表。

在启动 Excel 程序时，Excel 加载项将在菜单栏中添加一个自定义的“奖励”选项卡。用户单击“奖励”选项卡之后，将显示一个包含各种按钮的功能区，供用户启动和使用奖励管理解决方案。

使用 BCS API

当然，BCS API 在任何基于 BCS 的解决方案中都处于中心地位。我们来看一些演示 BCS API 用法的示例代码。

首先，我们来看一些用于从本地缓存存储中检索所有员工记录的代码（请参见图 6）。

图 6 检索员工记录

string entityNameSpace = "MSIT.HR.Rewards.BCS";
string entityName = "EmployeeDetails";

// Initialize and connect to BCS local cache
RemoteSharedFileBackedMetadataCatalog catalog = 
  new RemoteSharedFileBackedMetadataCatalog();

// Get the ECT for employee entity
IEntity entity = catalog.GetEntity(@entityNameSpace, entityName);

// Get the finder method defined for employee ECT
string methodName = entity.GetMethodInstance(
  MethodInstanceType.Finder)[0].Value.Name;
IMethodInstance mi = entity.GetMethodInstance(
  methodName, MethodInstanceType.Finder);

// Get external system instance
ILobSystemInstance LobSysteminstance = 
  entity.GetLobSystem().GetLobSystemInstances()[0].Value;

// Retrieves all instances of employee ECT
IEntityInstanceEnumerator instanceEnumerator = 
  entity.FindFiltered(entity.GetDefaultFinderFilters(),
  mi, LobSysteminstance, OperationMode.CachedWithoutRefresh);

// Loop each employee and add it to Excel worksheet list object
while (instanceEnumerator.MoveNext()) {
  ...
// Loop each instance of employee record and
      // add it to Excel worksheet list object
}

IEntity 是您为解决方案所定义的 ECT 使用的主要 BCS 接口。 IEntityInstance 表示要从中获取数据的实体的特定数据实例。 每个 ECT 在实体命名空间内都有一个唯一的实体名称。 每个实体实例都由一个您在定义 ECT 时指定的唯一 ID 来标识。 在本例中，该标识为员工编号。

您可以通过一个 BCS 实体实例更新方法来更新员工记录（或者，更具体地说是员工 ECT 实例）。 这会在 BCS 本地队列中创建一个更新操作。 因此，如果对 10 个员工记录进行更改，则有 10 个操作在本地缓存中排队。 BCS 同步将一次处理一个操作，如下所示：

// Query the employee instance you want to change
Identity identity = new Identity(employeeNumber);
IEntityInstance myEmployee = 
  entity.FindSpecific(identity, LobSysteminstance);

// Update the employee bonus amount
myEmployee["BonusAmount"] = 1000;

// Submit the changes to BCS local cache
myEmployee.Update();

图 7 中的代码显示了如何在 BCS 缓存中查询因外部系统不可用、错误和数据冲突导致的所有挂起或失败的操作。

图 7 查找挂起或失败的操作

// Initialize and connect to offline cache store
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISynchronizationManager syncManager = 
  offlineRuntime.GetSynchronizationManager();
IMetadataCatalog catalog = 
  offlineRuntime.GetMetadataCatalog();

// Get all current operations from local operation queue
IOperationCollection allOps = syncManager.GetOperations();

foreach (IOperation op in allOps) {
  // ECT associated with the operation
  IEntity entity = op.Entity;

  // Query for operation status
  string operationstatus = op.OperationStatus.ToString();

  // Query for operation retry count
  int retryCount = op.RetryCount;

  // Get last exception message if operation errored out
  string errMsg = op.LastException.Message;

  // Retry the operation if status is pending or error
  op.Retry();

  // Decide if error is due to data conflict
  if (errMsg.Contains("ConflicDetectedException"))
    // Then the error is due to data conflict
}

ISynchronizationManager 是 BCS 实体同步过程的主接口。 每个操作 (IOperation) 都是对实体数据的更改，由 BCS 运行时进行处理。 处理之后，每个数据更新操作都拥有“挂起”（）或“发生错误”状态。 如果成功处理了某一操作，就会将该操作从队列中删除，您将无法通过同步管理器来查询该操作。

“挂起”状态表示该操作因外部系统不可用而挂起。 BCS 将自动重试，直到操作成功或遇到错误。

“发生错误”状态表示该操作因验证错误、数据完整性错误或数据冲突错误而无法由外部系统进行处理。

有时，用户希望从外部系统明确刷新其本地缓存，而不是等待 BCS 运行时定期同步。 以下是强制刷新所有 ECT 的数据的方法：

// Initialize and connect to offline cache
RemoteOfflineRuntime offlineRuntime = new RemoteOfflineRuntime();
ISubscriptionManager subManager = 
  offlineRuntime.GetSubscriptionManager();

// Get all subscriptions
ISubscriptionCollection mysubs = subManager.GetSubscriptions();
IEnumerator<ISubscription> ie = mysubs.GetEnumerator();

while (ie.MoveNext()) {
  ISubscription mySub = ie.Current;
  mySub.RequestRefresh(true);
}

如前所述，在用户计算机上第一次部署和安装 ECT 时，BCS 运行时会在其本地数据存储中创建对外部系统的数据的订阅。 该订阅将由 BCS 运行时使用以将 ECT 数据与外部系统同步。

在示例代码中，ISubscriptionManager 是用于获取在 BCS 数据存储中创建的所有订阅 (ISubscription) 的接口。 通过订阅对象可以执行许多操作，包括更改 ECT 的同步频率、添加附加查询参数、获取最新的刷新状态、请求立即刷新（如在示例中所示）和获取为 ECT 同步的实例数目。

经验教训

在设计、开发和部署新的奖励管理解决方案的过程中，我们通过 Office 加载项开发和 SharePoint 2010 BCS 实现获得了很多实用的实际经验。 下面是我们在此过程中总结的一些见解：

首先，请尽可能多花些时间来设计解决方案的 ECT。 ECT 设计是 BCS 解决方案成功的关键。 ECT 直接影响到 BCS 运行时的行为，ECT 若设计不好可能引起 BCS 运行时崩溃或引发内存不足异常。

我们好不容易才吸取了这个教训。 我们最初设计了一个很大的 ECT，它以单一实例的形式返回了所有业务规则。 这个实例包含一个 40MB 的数组，导致 BCS 运行时在该数组反序列化为对象时达到 600MB 内存使用峰值。

为了缓解内存使用问题，我们随后基于规则类别，将这个较大的 ECT 重新设计为几个单独的 ECT。 每类 ECT 都返回与实际规则同等数量的实体实例。 通过这些更加集中的新 ECT，BCS 同步进程可更加高效地工作。

另一个最佳做法是尽可能使用强类型化和相对较平的结构来定义 ECT。 如果使用 SharePoint Designer 来生成 ECT，可节省大量开发时间。 在 Visual Studio 中通过大量实体属性来创建 ECT 会为您带来更大的灵活性，但这可能是一个耗费时间且枯燥乏味的过程。

请全面考虑可以向用户本地计算机下载和缓存多少数据方面的要求。 这决定着为 ECT 实现查找器方法的方式。 当然，从外部系统调用返回的数据会设置可下载数据记录数的限制。 如果您的 ECT 设计需要比该限制更多的数据，则为了满足您的要求，需要更改外部系统。

在我们的奖励解决方案中，一位经理仅可为其所在组织下载和缓存员工记录。 因此，两个不同用户很可能将两组不同的员工数据下载到其本地缓存上。 现有的奖励 Web 服务会对用户进行身份验证，并仅返回允许该用户访问的员工数据。 换言之，数据筛选在外部系统中进行，ECT 实现无需基于用户权限对数据进行筛选。 如果您的解决方案不是这种情况，就需要考虑花费更多的设计和开发时间为本地缓存筛选 ECT 数据。

在您的 ECT 实现中，请仔细处理外部系统异常。 有时，用于 Finder 和 SpecificFinder 方法的 ECT 实现需要调用外部系统方法来检索数据。 您需要在代码中捕获和处理从外部系统引发的异常。 不过，您需要在处理异常之后将异常发回 BCS 运行时。 否则，BCS 运行时会认为对外部系统的调用已经成功，返回零行数据并删除本地缓存中已有的数据。 您肯定不希望因外部系统异常而将本地数据缓存删除。

还有一些有关在 ECT 实现中使用第三方库的附加注意事项。 在我们的一个 ECT 中，我们必须引用一个由其他小组开发的程序集，以便执行附加业务逻辑和数据转换。 在部署该 ECT 期间，我们发现所引用的程序集未在 ECT 安装期间部署到客户端计算机上。 因此，BCS 无法运行 ECT 和下载数据。

在我撰写本文时，我们正在与 BCS 产品团队合作设计一种解决方案。 解决方法是在安装 VSTO 期间将该程序集添加到全局程序集缓存中。

对 ECT 进行测试和调试十分重要。 ECT 由 BCS 运行时在后台运行，当 ECT 在客户端计算机上运行时，您无法从 Visual Studio 调试 ECT。 我们建议您在服务器上通过在 SharePoint 中创建外部列表来测试和调试 ECT。 当您在“SharePoint 列表”页面上查看和更改外部列表的内容时，就会运行与该外部列表关联的 ECT 代码，并且可以从运行在同一台 SharePoint 服务器上的 Visual Studio 实例来调试 ECT。

最后，了解 BCS API 实体操作模式是至关重要的。 在使用 BCS API 操作 ECT 实体实例的客户端应用程序中，可以使用 4 种操作模式来管理 ECT 数据。 以下是对其工作方式的简单概述：

  • **OperationMode.CacheWithoutRefresh：**将此操作模式用于某个实体实例时，BCS 从缓存返回该实体实例。 如果数据不在缓存中，则 BCS 从外部系统刷新缓存，并返回缓存副本。 如果无法访问外部系统，则 BCS 会引发异常。
  • **OperationMode.CacheWithImmedicateRefresh：**在此操作模式中，BCS 首先从外部系统刷新缓存中的实体实例，然后返回缓存副本。 如果无法访问外部系统，则 BCS 仍返回该缓存副本。 如果实体实例未进行缓存且无法访问外部系统，则 BCS 会引发异常。
  • **OperationMode.Offline：**在脱机操作模式中，即使缓存中没有任何数据，也从不访问外部系统。 BCS 从缓存返回实体实例。 如果缓存中无实体实例，则 BCS 会引发异常。
  • **OperationMode.Online：**对于联机操作模式，BCS 从不使用本地缓存数据，并且总是访问外部系统以获取该实体实例的副本。 如果无法访问外部系统，则 BCS 会引发异常。

总结

带有 BCS 的 Microsoft Office 和 SharePoint 2010 为企业提供了可实现简单易用且功能强大的解决方案的基础，可用于通过熟悉的 Office UI 管理来自多个外部系统的企业数据。 这个基础可促进业务数据和过程随时随地的可用性，从而提高业务效率。

BCS 同步基础结构可解决与数据副本、更改和冲突有关的很多问题。 BCS 同步较之其他数据同步框架的优点之一是：BCS 允许您的解决方案通过 ECT 实现将业务和数据验证逻辑嵌入到同步过程中。 BCS 的另一个优点是能够将来自多种不同系统的复合数据同步（同样通过 ECT 设计实现），而不必进行许多其他同步框架所提供的点到点数据同步。

Ying Xiong 是 Microsoft IT 团队的一位首席架构师，负责搭建和设计 Microsoft 内部的企业应用程序和集成。他致力于研究用于构建分布式企业应用程序的各种 Microsoft 技术。您可通过 yingx@microsoft.com 与 Xiong 联系。

衷心感谢以下技术专家对本文的审阅：Rolando Jimenez Salgado 和 Satish Thatte