适用于：
　Web 服务
　智能客户端
　Microsoft Office System
　Microsoft Office Outlook 2003
　Microsoft Visual Studio 2005 Tools for Microsoft Office System
　Microsoft SQL Server 2005, Express Edition

摘要：提供体系结构设计和示例代码，以演示一个将企业 CRM 和其他 LOB 应用程序数据集成到 Microsoft Outlook 用户界面的方法。

单击此处下载 CRM Integration for Outlook 示例。

本页内容

　 摘要
　 简介
　 动机和业务难点
　 使用 Web 服务公开 CRM 数据
　 使用 Microsoft Outlook 作为集成点
　 技术体系结构概述
　 体系结构组件讨论
　 优势
　 小结
　 附加资源

摘要

　在过去十年中，许多组织在客户关系管理 (CRM) 系统和其他业务流程 (LOB) 应用程序上投入了数百万美元。虽然其中的许多应用程序提供了显著的业务优势，但某些组织发现这些定制的系统并没有提供预期的投资回报。其中一个争论的原因是，专用企业系统、数据库和应用程序没有与信息工作者的工作流很好地集成在一起。

本文是系列文章的第一篇，该系列将展示一个体系结构设计指南和示例应用程序，以示范一个将企业 CRM 和其他 LOB 应用程序与 Microsoft Outlook 相集成的方法。本文中的指导来自 Microsoft 的 Project Elixir，这是一个将重要客户数据与 Outlook 相集成的 Microsoft 内部 IT 计划。该设计使用 Microsoft Visual Studio 2005 Tools for Office (VSTO)、Microsoft SQL Server 2005 Express Edition (SQL Server Express) 和 Web 服务。

有关本系列的其他文章和示例代码链接的详细信息，请参阅本文结尾处的附加资源部分。

返回页首

　简介

　在大多数与信息打交道的行业中，Microsoft Office 是日常工作中不可缺少的一部分。有超过 4 亿的人依赖于 Microsoft Office 应用程序来捕获、发布和处理重要业务信息。它是一个用于创建内容、进行决策以及彼此进行沟通的重要工具。在大型组织中，大部分重要的业务信息都存储在大型数据库中。例如，客户联系信息通常保存在专用的集中式 CRM 应用程序中。

遗憾的是，其中许多 LOB 应用程序提供的用户体验较差，其客户端界面繁琐且不直观。通常，应用程序无法与信息工作者经常使用的桌面生产应用程序（如 Microsoft Office，特别是 Outlook）很好地集成在一起。用户越发地要求应用程序界面：

• 易于学习和使用。
• 根据具体的职务功能和角色进行调整。
• 与日常工作流兼容。
• 与其他应用程序集成在一起。

信息工作者需要能够分析、操作和使用业务系统中的信息。局限于企业数据库（具有有限且繁琐的访问权限）的信息没有什么优势。问题在于为信息工作者提供一致、聚合的业务数据视图，使他们能够与同事更高效地合作，实行监督机制，以及作出更快、更具体的决定来帮助驱动业务。

本文展示一个体系结构和方法，您可以在自己的组织中使用它来解决这个难题。它分析如何使用 Web 服务提供连接不同系统所需的消息处理支持。它还说明如何使用 Visual Studio Tools for Office 这样的工具为 LOB 应用程序开发更直观、更强大的界面，并使其能够与桌面生产应用程序（如 Outlook）集成在一起。

本文包含以下主题：

• 动机和业务难点
• 使用 Web 服务公开 CRM 数据
• 使用 Outlook 作为集成点
• 技术体系结构概述
• 体系结构组件讨论
• 优势

返回页首

　动机和业务难点

　许多扮演面向客户的角色和管理角色的信息工作者，在日常工作中会将大部分时间花在使用桌面生产应用程序（如 Microsoft Office）上。这些用户可能还需要与专用的 LOB 应用程序定期交互；例如，查询客户信息或生成销售报价。结合使用 LOB 应用程序与桌面生产应用程序会带来以下业务难题：

• 数据聚合。用户可能需要搜索多个应用程序和多个独立的数据竖井 (data silo)，以查找执行操作或进行业务决策所需的信息。在具有多个部门和功能组的大型组织中，数据通常分散在许多系统中。难点是提供单一、聚合的数据视图。在 CRM 方案中，该问题尤具挑战性，因为客户数据会不断扩散到多个应用程序和数据库中。客户的联系信息可能同时存储在企业 CRM 应用程序、帐单系统和 Microsoft Outlook 中。在这种情况下，很容易想像，由于对某一个系统（而不是其他系统）进行更新，该信息很快变得不同步了。
  
• 应用程序到应用程序集成。花费大部分时间使用 Microsoft Office 应用程序的信息工作者通常会发现，自定义的 LOB 应用程序不够直观，并且难以使用。例如，大多数企业 CRM 系统拥有自己独特的 UI 和行为。因此，通常需要对这些企业应用程序的用户进行大量培训。昂贵的最终用户支持是一项附加成本。在应用程序之间移动数据也可能具有挑战性。用户必须经常管理多个用户登录，手动重新输入数据，或者将一个应用程序的值复制并粘贴到另一个应用程序。该过程不但耗费时间而且容易出错。
  
• 业务决策制定。文档或电子邮件可能会引用特定的业务实体，如客户和帐户 — 通常存储在企业 CRM 系统中的相同信息。如果这些重要的业务文档、数据和电子邮件驻留在单个计算机中，则同事之间无法使用该信息，这会导致业务处理和决策制定效率低下。由于复杂的 UI 以及缺少无缝应用程序集成，该问题通常会导致难以保持数据是最新的。

Microsoft 案例研究：Project Alchemy 和 Project Elixir

Microsoft 的现场销售组织在公司的内部 CRM 系统上面临着这些业务难题。Microsoft 的销售人员要求应用程序界面提供客户的完整视图，并与他们的日常工作流很好地集成在一起。日常工作流主要包括通过 Outlook 与客户进行交流。此外，这类移动性很强的销售人员需要能够访问客户数据，不论他们是否连接到企业网络上。

作为解决这个难题的第一步，Microsoft 启动了 Project Alchemy。该项目合并了 Web 服务层的设计和部署，以便将多个单独的 LOB 系统中的数据收集到一起，并通过一致的界面公开。Alchemy Web 服务界面能够展示一个完整的、集成的客户数据视图，即使客户数据本身存储在多个后端数据存储和应用程序中。有关详细信息，请参阅 "Alchemy" Turns Customer Data into Gold。

尽管 Project Alchemy 有助于将多个系统界面合并为单个 Web 服务，但访问 Alchemy 数据的许多应用程序仍然是基于浏览器的，并且与用户的桌面应用程序有点脱节。即使现在使用面向服务的方法公开数据，前面列出的与应用程序切换和同步有关的难题仍然存在。销售人员仍然需要在应用程序之间重复切换，或者将数据从 Outlook 复制并粘贴到基于浏览器的应用程序，然后再次返回。

此外，Web 浏览器界面方法无法满足脱机支持需求，因为销售人员在连接到企业网络时只能访问客户数据。

为了解决这些悬而未决的问题，Microsoft 启动了一个补充计划，代号为 Project Elixir。该项目的目标是，使用智能客户端技术并使用 Microsoft Office 作为开发平台，来创建下一代 CRM 客户端体验（称为 Customer Explorer）。

Project Elixir 利用 Alchemy Web 服务的开发成果，并使 Microsoft 能够在熟悉的 Outlook 界面中，从多个 Microsoft 系统创建全方位的客户数据视图。通过将 CRM 功能集成到 Outlook，该项目还有助于降低与自定义应用程序培训相关的成本，解决了雇员不愿意将数据输入 CRM 系统的问题，并且提高了 CRM 系统中数据的整体质量。有关详细信息，请参阅 https://members.microsoft.com/customerevidence/search/EvidenceDetails.aspx?EvidenceID=13848&LanguageID=1。

该设计指南引领您了解从项目中获得的一些经验和教训，并指明在面对此类技术难点时需要考虑的范畴。

返回页首

　使用 Web 服务公开 CRM 数据

　客户数据是业务最重要的信息来源之一，但在许多大型组织中，该信息驻留在多个企业系统中。本文已经重点说明了多个自定义应用程序如何影响用户的工作效率。其他缺点是由这些专用、独立的应用程序对组织的 IT 体系结构的影响所造成的。自定义程序可能会将应用程序编程接口 (API) 调用编码到 UI 中，或者要求其他软件库（动态链接库或 DLL 文件）访问企业应用程序中的信息。这种紧密耦合会降低应用程序的可靠性，难以维护，并导致脆弱的体系结构。例如，如果某个软件供应商发布了软件库的更新版本，则更改后的版本可能会无意地影响自定义应用程序。

理想情况下，客户端应用程序需要与单个合并界面集成在一起，以便与多个企业应用程序进行通讯。企业应用程序资源的一致界面可以简化系统的体系结构。该方法使得构建业务实体（如客户）的完整视图更加简单。

此外，企业应用程序访问层设计可使用消息队列解决方案和其他异步处理技术来帮助提供可伸缩性和性能。单一登录解决方案（如 Microsoft Identity Integration Server 2003）还可以帮助简化多个企业应用程序中用户身份和凭据的管理。

图 1 显示一个企业应用程序访问层，它提供对各种各样的后台企业系统的访问。

　图 1. 企业应用程序访问层提供了一致的应用程序界面

如果不加以注意，会出现一个常见错误：创建一个紧密耦合的企业访问层。例如，如果企业应用程序访问层依赖特定的操作系统，则集成的应用程序必须在这个特定平台上调用程序。而且，实现企业应用程序访问层的编程模型的特性可对客户端应用程序施加限制。

图 1 所示的设计意味着，客户端应用程序需要通过分布式对象框架对企业应用程序进行一组同步方法调用。引入 Web 服务外观层有助于克服这些限制。

Web 服务简化了企业环境中协作应用程序和集成应用程序的创建。提供 Web 服务外观来公开企业应用程序数据使您能够通过标准技术（如可扩展标记语言 (XML)、简单对象访问协议 (SOAP) 和 Web 服务定义语言 (WSDL)）创建单一的一致界面。

该方法将客户端应用程序从企业应用程序的实现细节中分离出来，这使得在 Web 服务外观的任一面上的开发，甚至整体重新构建都能够独立进行。一些主要的企业应用程序供应商已经将 Web 服务功能合并到其产品中，这无疑推动了 Web 服务在业界的广泛采用。

使用这些产品的组织可以从完整的 Web 服务支持获益，并且可以将这些产品合并到他们的 IT 环境中。Microsoft 和其他软件界领头人发起的业界范围的活动（如 Web 服务互操作性 (WS-I) 组织）一直在推动着使 Web 服务安全、可靠且事务化的技术标准化。

虽然 Web 服务外观层有助于提供对企业后台应用程序和数据库的一致访问，但组织中的信息工作者对 UI 的选择也会大大影响所有集成解决方案的信息获取和最终成功。大部分信息工作者在 Microsoft Outlook 中花费了大量时间。因此，如果 Outlook 中的数据与 LOB 应用程序中的数据自然重叠，那么在 Outlook 界面中直接提供一个自定义 UI 是个不错的建议。

返回页首

　使用 Microsoft Outlook 作为集成点

　一段时间以来，用户界面分为两大类 — 胖客户端和瘦客户端（基于 Web 浏览器的客户端）。虽然胖客户端通常可以提供高品质、响应的用户体验，并且具有较好的开发人员和平台支持，但它们会带来部署和维护难题。然而，瘦客户端具有交互性和可用性问题，并且在解决组织所面对的后端集成问题上也不够理想。瘦客户端没有充分利用本地计算资源，并且通常没有脱机功能。而且，瘦客户端通常无法与信息工作者整天使用的桌面应用程序很好地集成在一起。智能客户端将这两种方法的优点结合在一起，从而提供了一个有吸引力的选择。

智能客户端

认识到瘦客户端和胖客户端方法的内在缺陷后，出现了一类新的客户端应用程序，它尝试结合了这两种方法的优点。智能客户端结合了胖客户端的优势和瘦客户端的可管理性。智能客户端解决方案的一些特性和隐含优势包括：

• 利用本地资源。智能客户端利用本地硬件和软件资源。
• 脱机功能。无论是否与网络连接，智能客户端都能够工作。
• 智能安装与更新。部署智能客户端相对简单。它们可以通过单击 URL 来按需部署，并且可以自动更新。
• 连接。智能客户端应用程序可以与能够访问数据或企业应用程序的 Web 服务交互。

由于这些优点，在许多情况下，智能客户端应用程序可以提供效率更高、更强大的用户体验。Microsoft Office 是一个出色的智能客户端解决方案示例，它提供了一个强大的开发平台，其他自定义的智能客户端解决方案可以在该平台上构建。

创建使用 Microsoft Office 构建的智能客户端解决方案

Microsoft Office 应用程序利用本地处理器的功能，同时允许用户访问驻留在远程系统上的信息和服务。此外，通过使用托管代码和 Office 应用程序对象模型，还可以扩展和自定义 Office 应用程序。

Visual Studio Tools for Office (VSTO) 是一个专业的开发工具，用于构建将 LOB 后端应用程序与 Microsoft Office 相集成的智能客户端解决方案。VSTO 使开发人员能够扩展 Microsoft Word、Microsoft Excel、Microsoft InfoPath 和 Microsoft Outlook，以构建能够与组织中各种用户的日常工作流良好集成的强大交互式智能客户端解决方案。自定义 Office 应用程序以便用户能够在 Office 应用程序中读取和更新后台系统可带来重大优势，从而解决前面讨论的以下业务难题。

• 无缝集成。用户在熟悉的应用程序上下文中可以访问一个或多个后端系统的数据。
• LOB 应用程序以外的文档和信息。通常，只有在 Outlook 电子邮件和其他 Office 文档中可用的数据，不再锁定于单个用户的桌面计算机中。通过对 Office UI 简单且一致的自定义，用户可以在 Office 应用程序中读取和更新一个或多个后端系统的数据。

返回页首

　技术体系结构概述

　将 Web 服务外观层（提供对后台系统和数据的独立于平台的访问）与集成到熟悉界面（如 Outlook 或其他 Office 应用程序）中的智能客户端 UI 相结合的体系结构，是许多组织采用的方法。根据当前的业务需求和客户端选项，本部分将概述这个新兴的体系结构。

问题陈述

客户信息和业务信息分散在企业的各种应用程序中。这会影响用户的工作效率，并分裂与客户及其他业务相关的数据的视图。用户必须在多个应用程序之间频繁地切换，如图 2 所示。

图 2. 多个企业系统造成的应用程序切换

约束条件

需要尽可能地利用现有 IT 投资。信息工作者和其他前台人员，将大部分时间花在使用 Outlook 与客户和同事进行沟通并管理他们的时间上。

理想解决方案

自定义 Outlook 以使用户能够在 Outlook 应用程序上下文中查看和更新相关的后台数据。通过业界标准公开后台系统和数据，如图 3 所示。

图 3. 使用标准技术提供单一的一致界面的 Web 服务外观

Web 服务可以提供单一、标准、一致的界面，Outlook 和其他应用程序可以使用它与后端系统集成。扩展前面的访问层可以得到如图 4 所示的整个解决方案体系结构。

图 4. Microsoft Outlook 与企业 CRM 系统集成

要求

考虑到前面的问题、约束条件和理想解决方案，构成设计的主要要求可以分为以下几点：

• 使用外接程序自定义 Outlook。对 Microsoft Outlook 的任何修改将包括使用自定义菜单项、文件夹视图和 Microsoft Windows 窗体来自定义应用程序，以便用户能够与企业系统的数据进行交互。这些自定义应该与标准的 Outlook UI 无缝且一致地集成在一起。某些自定义可能会更改 Outlook 对象的原始行为，因此在任何可能的情况下，您应该尽量确保保持传统的 Outlook 用法。
  
• 使用本地脱机存储。为了提供脱机存储，需要创建脱机数据存储，以便 Outlook 能够在本地客户端计算机上缓存从后端系统中检索的数据。用户进行的更新会立即反映到本地数据存储，并且在网络连接存在的情况下，可以与后台系统和数据库同步。
  
• 远程数据同步。要使本地存储和后台应用程序之间的数据保持同步，需要一个远程同步引擎。这将使用 Web 服务连接到后端系统。远程同步引擎检测与 Web 服务的连接，如果连接可用，就会将本地脱机数据缓存中的数据与远程系统进行同步。用户在脱机状态下进行的更新将被推到后台系统，并且本地缓存会定期刷新。脱机数据存储和远程同步引擎共同为用户规避了网络连接问题。这将赋予他们更强的灵活性，并使他们能够随意地连接和断开网络。

需要注意的是，Web 服务不一定要与企业应用程序直接交互。许多组织已经拥有了中间件或类似的解决方案。在这些情况下，Web 服务外观层可以使用现有的解决方案从各种企业应用程序中检索业务信息。

除了这些要求外，在构建符合该整体体系结构的解决方案时，您还需要考虑许多额外的设计注意事项。这些设计注意事项包括：

• 为 Outlook 外接程序设计适当的本地数据存储。在许多情况下，Outlook 智能客户端实现甚至需要能够在没有企业后台系统互连的情况下操作。要满足这个要求，需要本地数据缓存。为了帮助确保 Outlook 的性能不会受到太大影响，与企业数据存储的同步应该支持异步操作，特别是在具有大量数据和高负载的情况下。
  
• 要在 Outlook 中显示的数据类型和数量。要加载到 Outlook 中的数据类型和数量是决定选择哪种客户端数据存储的关键因素。对于某些数据，您也许能够使用原始 Outlook 存储，但对于其他数据，您可能需要具有相应的本地数据同步机制的外部本地存储。对于较大的数据量以及数据类型与原始 Outlook 项不太紧密耦合的情况，您可能需要 Outlook 以外的本地数据存储。

例如，与客户、帐户、联系人、会议和任务相关的数据就是能够自然集成到 Outlook 中的优秀数据示例。但是，某些形式的业务数据最好在原始应用程序中查看。评估哪些类别的数据最适于集成的一个方法是，尝试将数据实体映射到 Outlook 项。例如，CRM 系统中存储的业务帐户代表的联系信息与 Outlook 联系人具有一对一的关系，因此它是理想的备选信息。同样，与客户帐户有关的业务约会可以与 Outlook 日历很好地集成在一起。

• 为大量用户而设计。从可用性和性能角度来说，最终用户的数量对整个解决方案的设计具有直接影响。设计一个 Web 服务外观层以处理几乎在早晨的同一时刻启动 Outlook 的大量用户会带来其他问题。同步引擎和 Web 服务中的异步处理能力对于支持峰值并发活动很重要。
  
• 延迟将数据加载到 Outlook 中。由于 Outlook 必须在加载外接程序之前加载 VSTO 运行库，因此最终用户在启动 Outlook 时可能会感觉到延迟。这可以与外接程序的初始化处理过程结合在一起，该处理过程可能会创建自定义菜单项和文件夹视图，随后再从本地数据存储中加载数据。要改善启动延迟情况，可能需要延迟对本地数据存储的数据访问，直到用户单击特定的数据对象。
  
• 实现大多数情况下可用的最少用例。在 Outlook 智能客户端中捕获后台应用程序的所有功能和业务逻辑可能是不可行的。理想情况下，设计应该支持最常见的最终用户用例。对于不太常见的用例，用户可能需要使用专用的 CRM 或 LOB 客户端应用程序或者 Web 前端。

既然已经讨论了设计的要求和考虑事项，下面需要讨论底层体系结构的更多详细信息。这将帮助制定设计的重要方面，并提供指向示例代码以及该设计系列的其他三篇文章的链接。

返回页首

　体系结构组件讨论
　本部分将详细讨论主要的体系结构组件。主要的体系结构组件和机制包括：

• 远程数据同步。
• 本地数据存储和本地同步。
• 使用外接程序自定义 Outlook。

远程数据同步

需要一个远程同步解决方案，以便定期同步本地数据存储和远程数据存储之间的数据。该解决方案还必须能够处理冲突解决。在许多情况下，使用 Web 服务提供消息处理基础结构和到后端系统的连接是恰当的选择，很大程度上因为许多最大的企业软件供应商目前在他们的应用程序中原本就支持 Web 服务。但是，如果使用本地 SQL Server Express 数据库，其他解决方案（如 SQL Server 复制）可能也适用。

使用 Web 服务构建企业应用程序需要关注服务描述文档 (WSDL)、服务边界以及应用程序用来与 Web 服务通讯及协作的其他人工制品的设计。Web 服务层应该符合频繁提到的面向服务原则，例如，使边界跨越显式行为，使 Web 服务自主，共享架构和协定，以及使服务兼容性基于策略。例如，要自主操作，Web 服务应该执行输入消息验证。服务使用者（如 Outlook 外接程序）可以合并额外的验证，以改进客户体验并减少到 Web 服务的往返次数。

远程数据同步引擎设计的其他主要考虑事项包括：

• 使用单独的辅助线程。要帮助提高性能和用户体验，同步引擎应该宿主在单独的辅助线程上，以避免过度影响 Outlook 的性能和可用性。
• 提供进度反馈并取消同步。同步引擎应该为用户提供进度反馈，并允许用户取消同步。
• 在同步期间处理本地冲突。无论实现哪种同步方案，如果您允许用户在同步期间继续使用 Outlook，就可能会在远程同步的数据与本地数据存储之间发生本地冲突。您需要针对这种可能性进行设计。一个可供选择、更简单的设计方法是，防止用户在同步期间与 CRM 数据进行交互。
• 调用同步。另一个考虑事项是如何以及何时调用同步。请注意，内置到 Outlook 中并通过单击 Send/Receive 调用的同步功能不会将外接程序加载的数据与后台系统进行同步。它会将 Outlook 数据文件 (OST) 的内容与 Exchange Server 上对应的邮箱进行同步。

您可以使用以下任何一种方法同步后台数据：

• 手动。您可以为用户提供触发远程数据同步的自定义菜单项或热键。
  
• 按预先定义的时间间隔自动执行。您可以配置同步引擎，使其按预先定义的时间间隔或周期性时间间隔执行数据同步。远程同步处理应该能够检测到网络连接中的更改，并进行相应的调整，以便将用户从手动同步中解救出来。

由于企业后端体系结构的复杂性和多样性，示例解决方案不提供在本地数据存储和 Web 服务后端之间实现远程同步的任何示例代码。

本地数据存储和本地同步

要实现对后端企业数据的脱机访问，Outlook 外接程序需要在本地存储和访问数据。启动时，外接程序会从本地数据存储加载数据。对于本文中描述的本地脱机存储，可以使用以下存储技术：

• Outlook 脱机存储 (OST)。脱机文件夹文件（也称为 OST 文件）是一项 Outlook 功能，允许 Outlook 在未连接到网络的情况下处理 Microsoft Exchange Server 文件夹中的内容。连接到网络时，它会同步文件夹。从后台系统检索的数据可以存储在 OST 文件的 Outlook 对象中。例如，CRM 联系信息（如姓名、头衔和电话号码）可以直接存储在 OST 文件的 Outlook 联系人对象中。此外，通过使用自定义属性扩展 Outlook 数据文件，可以将自定义数据字段存储在 OST 文件中。将数据存储在 OST 文件中的一个主要缺点是，这会影响 OST 在 Outlook 和 Exchange 之间的同步性能。如果您考虑将大量数据存储在 OST 文件中，这可能是个问题。而且，用户的邮箱大小可能需要增加，以便 OST 文件中容纳额外数据。另一方面，使用 OST 文件至少存储一些后台数据的一个优势在于，由于数据可以与 Exchange Server 同步，因此用户可以通过 Outlook Web Access (OWA) 或 Pocket PC 上的桌面到设备同步来访问该数据。在这些情况下，用户仅限于数据的只读视图，因为 Outlook 外接程序在 Exchange Server 或 Pocket PC 上不可用。
  
• Outlook 个人存储文件 (PST)。另一种类型的脱机文件夹文件（也称为 PST 文件）是一项允许 Outlook 在本地磁盘的单独文件中存储数据的功能。尽管使用 PST 文件不会遇到同步问题和 OST 文件的配额大小限制，但只能从 Outlook 对象模型访问 PST 存储，因此可能无法提供专用数据库解决方案的灵活性。
  
• 本地数据库。本地的轻量级数据库（如 SQL Server 2005 Express Edition (SQL Server Express)）可以提供将数据存储在本地计算机上的最佳解决方案。作为免费下载资源，SQL Server Express 取代了 Microsoft 桌面引擎 (MSDE)，并与 Microsoft Visual Studio 2005 集成在一起。此外，SQL Server Express 可以参与 SQL Server 数据库复制，这为具有 SQL Server 后端的组织提供可能的同步选项。

本系列白皮书中描述的示例解决方案使用 SQL Server Express 作为 CRM 外接程序的本地数据存储。示例设计包含一个在 Outlook 和本地 SQL Server Express 之间同步数据的本地同步引擎。Outlook 外接程序代码对数据进行的更改保存在本地数据库中，并且在适当的情况下保存在 Outlook 数据存储中。

为了自定义 Outlook 用户界面，外接程序显示新的文件夹以展示各种业务实体，包括与特定帐户相关的 CRM 活动和 CRM 机会。如图 5 所示。

图 5. 从本地数据存储构建的 Outlook UI 自定义

请注意，如果您选择使用 SQL Server Express 作为本地脱机数据存储，则应该设计表结构，以便它能够准确构建企业应用程序中表示的业务数据实体。例如，企业应用程序中的帐户数据实体应该在本地脱机存储中具有对应的 Account 表。这使得企业系统和这些实体的 Outlook 表示中的数据实体之间更容易进行集成。

有关如何使用 Outlook 实现本地数据存储同步的详细信息，请参阅 Synchronizing a Local Data Store with Microsoft Outlook。

使用外接程序自定义 Outlook

通常，Outlook 和 Office 应用程序通过分层对象模型公开它们的功能。Outlook 对象模型提供丰富的功能来操作 Outlook 数据存储中存储的数据，并使您能够控制 Outlook UI 的许多方面。您可以使用对象模型自定义 Outlook，并通过自定义代码调用它的功能。

Outlook 代码基是非托管的，并且是使用 COM 技术生成的。因此，针对 Microsoft .NET Framework 编写的代码需要互操作程序集来访问 Outlook 对象模型。为 Office 提供的主 interop 程序集 (PIA) 有助于使 COM interop 对托管代码客户端更加无缝。

您可以通过以下三种方法扩展 Outlook：

• 使用 Microsoft Visual Basic for Applications (VBA) 扩展 Outlook。Outlook 2000 及更高版本支持 VBA，从而使您能够编写代码来控制 Outlook 并响应其事件。希望在 Outlook 中编写代码以修改默认应用程序行为的开发人员可以创建一个 Outlook VBA 项目，或者将 Visual Basic Scripting Edition (VBScript) 添加到 Outlook 窗体。
  
• 使用 COM 外接程序扩展 Outlook。Outlook COM 外接程序（或仅仅是外接程序）是一个实现预定义接口 (IDTExtensibility2) 的 DLL，并且是专门注册的，以便 Outlook 能够识别并加载它。COM 外接程序可使用 Visual Studio .NET 进行构建。
  
• 使用 Visual Studio Tools for Office (VSTO) 扩展 Outlook。构建 Outlook 解决方案的第三种选择是使用 VSTO。构建 VSTO Outlook 外接程序解决方案时，开发人员继续使用现有的 Outlook 扩展模型，并且 VSTO 提供一个增强的外接程序加载器，以解决 Outlook 开发人员在过去创建外接程序时所面临的许多问题。

Outlook 中的外接程序技术是扩展和自定义 Outlook 的强有力的手段。外接程序可以访问 Microsoft .NET Framework 和 Outlook 对象模型。通过操作特定 Outlook 对象（如文件夹、Explorer 窗口、Inspector 窗口等），外接程序可以自定义并扩展 Outlook。

Visual Studio Tools for Office 之前的外接程序开发

在 VSTO 发布之前，您可以使用 Visual Studio.NET 2003 中的共享外接程序项目模板为 Outlook 创建外接程序。开发人员通常使用托管代码来开发外接程序，以便从 .NET Framework 和 Visual Studio .NET 的丰富功能中获益。但是，由于安全、隔离和支持问题，此类托管外接程序的开发并不是很简单。

有关相关问题的详细信息，请参阅 Introducing Outlook Add-in Support in Visual Studio 2005 Tools for Office 和 Architecture of the Outlook Add-in Support in Visual Studio 2005 Tools for Office。

Visual Studio Tools for Office 中的外接程序开发

VSTO 包括设计时和运行时支持，以便使用托管代码为 Outlook 构建应用程序级别的外接程序。在使用 VSTO 构建 Outlook 外接程序解决方案时，Visual Studio 将该解决方案编译为程序集 (.dll) 文件，并创建一个包含部署信息的单独的应用程序清单文件。

VSTO 中引入的与 Outlook 相关的主要开发增强功能包括：

• 设计时支持。设计时支持包括一个帮助您构建 Outlook 外接程序的 Visual Studio 项目模板（有 C# 和 Visual Basic .NET 两个版本）。
  
• 调试和故障排除。您可以使用用于其他 Visual Studio 项目的 Visual Studio 工具来调试 Outlook 项目。当您开始调试项目时，Visual Studio 启动 Outlook，随后 Outlook 加载外接程序。
  
• 运行时支持。运行时支持包含一个专用的外接程序加载器组件，它可以为每个外接程序创建一个单独的 .NET 应用程序域，并执行严格的安全策略。运行库在断开连接时卸载外接程序。使用不同的应用程序域可在 Outlook 中宿主的外接程序之间提供更好的隔离，并允许使用代码访问安全性，以便为外接程序代码提供沙箱执行环境。

图 6 显示 Outlook 加载自定义托管外接程序的方式。

图 6. Outlook 使用 Visual Studio Tools for Office 加载构建的托管外接程序

　探究 CRM Outlook 示例外接程序

为了帮助说明前面概括的业务需求，并演示如何使用 Visual Studio Tools for Office 自定义 Outlook 界面，我们创建了一个示例外接程序。有关如何获得该示例的详细信息，请参阅本文结尾处的附加资源部分。

示例外接程序显示如何扩展 Microsoft Outlook 中的用户界面，以便为虚拟的企业 CRM 系统提供前端。示例解决方案使用了一组托管实用程序类，以促进托管外接程序代码和基于 COM 的 Outlook 对象模型之间的交互。托管实用程序类通过隔离 COM interop 调用的复杂性，来简化外接程序的整体设计。这种体系结构如图 7 所示。

图 7. 示例 CRM 外接程序概览

　该示例外接程序实现了许多 Outlook 自定义技术，使得展示和操作 CRM 数据成为可能。这些技术包括：

• 创建菜单栏和菜单项。
• 创建工具栏和按钮。
• 创建自定义文件夹主页。
• 以编程方式创建、删除和修改标准的 Outlook 对象，如电子邮件、联系人、任务和张贴项。
• 创建自定义 Windows 窗体以便在 Outlook 中显示数据。
• 管理 Outlook 事件。
• 使用 Outlook 视图控件。

示例外接程序演示了如何将自定义菜单栏和菜单项添加到标准 Outlook 菜单栏，如图 8 所示。外接程序在初始化时创建自定义菜单项。如果 Outlook 中的文件夹上下文发生更改，则外接程序还可以根据当前选择的文件夹和项来启用和禁用自定义工具栏。

图 8. Outlook 中的自定义菜单项

外接程序在 Outlook 中集成了四种类型的 CRM 数据，包括 CRM 帐户、CRM 活动、CRM 联系人和 CRM 机会。数据在 Outlook Folder List 窗口的文件夹层次结构中作为各种 Outlook 对象公开。每个 CRM 帐户与 Outlook Folder List 窗口中的一个自定义文件夹相关联，并具有一个汇总该帐户详细信息的自定义文件夹视图。每个帐户文件夹包括一组与该帐户相关的 CRM 活动、CRM 联系人和 CRM 机会。

文件夹层次结构的根部是 CRM Today 文件夹，如图 9 所示。该文件夹提供了 CRM 信息的全面摘要，如业务帐户列表、所有未完成的任务或即将发生的活动。请注意，本示例中公开的数据对象只是一种能够集成到 Outlook 中的数据示例，您并不局限于只使用它们。

图 9. Outlook 中的自定义文件夹视图

当您打开 CRM 活动和 CRM 机会项时，它们将显示在自定义 Windows 窗体中。要在 Outlook 中宿主自定义窗体，您需要在用户单击某一项时截获 Outlook 引发的特定事件。图 10 显示一个宿主在 Outlook 中的自定义活动 Windows 窗体示例。

　图 10. Outlook 中显示的自定义 Windows 窗体

通常，通过自定义的菜单项，以及单击自定义文件夹视图和 Windows 窗体中相应的命令栏、按钮和控件，用户可以与 Outlook 外接程序进行交互。

有关该示例外接程序代码中包含的 Outlook 自定义及其实现方式的更多详细讨论，请参阅 Outlook Customization for Integrating with Enterprise Applications。

返回页首

　优势
　本文讨论的体系结构模式解决了许多业务难题，并且可以提供以下主要优势：

• 快速的投资回报。组织可以利用其在企业后端系统上的投资以及在 Microsoft Office 系统中的投资。用户可以获得增强的功能，并且可以从他们熟悉的应用程序上下文中访问后端数据。
  
• 提高数据质量。现在，只需单击几次，就可以用 Outlook 电子邮件和任务中驻留的重要数据来更新后端系统。这可以提高流入企业后端系统的数据的质量。
  
• 提高用户的工作效率。用户可以在单个应用程序中管理大量企业数据并与之通讯和协作，并且不再需要在不同的应用程序间进行切换，或者花费时间将数据从 Outlook 复制和粘贴到 CRM/LOB 客户端。由于自定义菜单项、文件夹视图和 Windows 窗体与其余的 Office UI 保持一致，因此最终用户相对易于理解，并且使用自定义 Office 应用程序相当直观。

Microsoft 的 Project Alchemy 和 Project Elixir 解决方案在本例中的内部部署提供了许多优势。通过在 Outlook UI 中直接提供来自 CRM 系统的客户数据的聚合视图，Microsoft 企业销售人员增强了 CRM 数据的捕获能力，并提高了客户交互的可见性。反过来，这又可以使销售人员在客户身上花费更多时间。

返回页首

　小结
　本文讨论了如何使用 Web 服务提供互连的体系基础结构，该结构能够集成企业应用程序和数据库中包含的分散的数据岛。通过将该方法与 Visual Studio Tools for Office 这样的开发工具结合使用，组织可以将它们集成到桌面生成应用程序（如 Outlook）中，从而为企业系统开发更直观的界面。

　附加资源
　Microsoft 开发了一个示例 Outlook 外接程序解决方案，它演示了如何扩展和自定义 Outlook UI 以创建 CRM 系统的前端。有关“Microsoft Outlook 的 CRM 集成外接程序示例”的详细信息，请参阅 http://download.microsoft.com/download/9/9/C/99CD8598-2A46-48A8-9A5B-7A30D46C0856/CRM Integration Sample for Outlook Source Setup.msi。

有关如何自定义 Outlook 以便与企业应用程序的数据相集成的更详细讨论，请参阅 Outlook Customization for Integrating with Enterprise Applications 白皮书。

有关如何将 Outlook 与本地数据存储相集成以及如何在 Outlook 和本地存储之间进行同步的更详细讨论，请参阅 Synchronizing a Local Data Store with Microsoft Outlook 白皮书。

有关 Microsoft 内部 IT 项目（代号为 Project Elixir）为 Microsoft 的内部 CRM 系统创建 Outlook 前端的详细信息，请参阅 https://members.microsoft.com/customerevidence/search/EvidenceDetails.aspx?EvidenceID=13848&LanguageID=1。