BizTalk-服务入门指南-全-

BizTalk 服务入门指南（全）

原文：zh.annas-archive.org/md5/672de9f20ff11eabbe5128e4ae104589

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

所有这一切都始于大约一年前，BizTalk Services 将在几个月后进行预览。我们都兴奋地期待在云中间件时代开辟新的领域。我们必须告诉你们，作为产品组的一员（或成为 MVP），一个好处是你们可以提前很久就获得这些功能。在研究这些功能时，我们心想，“如果我们的客户能有一个指南来构建有效的解决方案，那岂不是很好？”这本书关于 BizTalk Services 的设想并不是为了添加每一个细节而破坏乐趣，而是要涵盖足够的内容，以便理解架构、关键组件，并帮助你探索。

这本书是为初学者编写的，并不假设或期望读者了解 BizTalk Server。这也是该主题的第一本书，我们将详细涵盖所有重要功能，包括 EAI、B2B 和混合部署——所有这些都有代码示例和操作指南。如果你是 EAI 用户，可以从第一章，欢迎使用 BizTalk Services开始，然后继续阅读第二章，消息和转换，第三章，桥梁，以及第四章，企业应用集成。另一方面，一个 B2B 开发人员或架构师可以遵循第一章，欢迎使用 BizTalk Services，第二章，消息和转换，以及第五章，企业对企业集成。如果你对支撑服务的 API 感兴趣，需要解决你的解决方案的问题，或者想知道如何迁移到 BizTalk Services，那么第六章，API，第七章，跟踪和故障排除，以及第八章，迁移到 BizTalk Services将为你提供指导。

本书涵盖的内容

第一章，欢迎使用 BizTalk Services，介绍了 BizTalk Services，其架构以及如何创建服务实例和部署解决方案。

第二章, 消息和转换，解释了消息处理以及如何将消息转换为不同的格式。它还解释了如何使用映射操作来聚合数据、执行参考数据查找以及在转换中使用自定义代码。

第三章, 桥梁，详细介绍了桥梁，并解释了如何丰富消息并将消息路由到不同的端点。

第四章，企业应用集成，解释了源和目标，以及如何从云中将 BizTalk 服务连接到本地企业应用和系统。

第五章，企业对企业集成，讨论了使用行业标准协议（如 EDIFACT、X12 和 AS2）进行 B2B 集成。它还讨论了如何在 BizTalk 服务中创建合作伙伴和协议以连接交易伙伴，以及如何利用消息批处理和归档。

第六章，API，讨论了 BizTalk 服务下的丰富 API。它还解释了它能够做什么，以及如何在不同的环境中使用它，包括 REST、PowerShell 和自定义代码。

第七章，跟踪和故障排除，讨论了在 BizTalk 服务中消息是如何被跟踪的，以及当问题发生时如何使用 BizTalk 服务提供的工具来查找和解决问题。

第八章，迁移到 BizTalk 服务，解释了如何从 BizTalk 服务器迁移到 BizTalk 服务，两个产品的区别以及未来的计划。

您需要这本书的内容

要跟随书中提供的代码示例和解决方案，您需要以下先决条件：

• 互联网接入

• 以下操作系统之一：Windows 7 Service Pack 1、Windows 8、Windows 8.1、Windows Server 2008 R2 SP1、Windows Server 2012 或 Windows Server 2012 R2

• 互联网浏览器 9 或 10

• Visual Studio 2012

• Windows Azure BizTalk 服务 SDK

  请访问msdn.microsoft.com/en-us/library/windowsazure/hh689760.aspx

• 需要的 Windows Azure 订阅和 Windows Azure BizTalk 服务实例

  要创建 BizTalk 服务实例，请访问www.windowsazure.com/en-us/pricing/free-trial/

这本书面向的对象

这本书是为希望了解 BizTalk 服务、它能做什么以及如何用它来集成服务、本地应用和企业的软件开发人员、IT 专业人士、架构师和技术经理而编写的。

习惯用法

在这本书中，您将找到许多不同风格的文本，以区分不同类型的信息。以下是一些这些风格的示例及其含义的解释。

文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 用户名如下所示："让我们解决ShippingAddress节点。"

代码块设置如下：

public string CreateAddress (string Number, string Street, string City, string State, string Country)
{
  return Number + " " +
    Street + "," +
    City + "," +
    State + "," +
    Country;
}

任何命令行输入或输出都如下所示：

select-azuresubscription –SubscriptionName "Test"

新术语和重要词汇以粗体显示。您在屏幕上、菜单或对话框中看到的单词，例如，在文本中显示为：“点击添加以创建地图并将其添加到解决方案。”

注意

警告或重要注意事项以这种框的形式出现。

小贴士

小技巧和技巧以这种形式出现。

读者反馈

我们始终欢迎读者的反馈。请告诉我们您对这本书的看法——您喜欢什么或可能不喜欢什么。读者的反馈对我们开发您真正能从中受益的标题非常重要。

要发送一般反馈，只需发送电子邮件到<feedback@packtpub.com>，并在邮件主题中提及书名。

如果您在某个主题上具有专业知识，并且您对撰写或为书籍做出贡献感兴趣，请参阅我们的作者指南www.packtpub.com/authors。

客户支持

现在您已经是 Packt 书籍的骄傲拥有者，我们有一些事情可以帮助您从您的购买中获得最大收益。

下载示例代码

您可以从www.packtpub.com上下载您购买的所有 Packt 书籍的示例代码文件。如果您在其他地方购买了这本书，您可以访问www.packtpub.com/support并注册，以便将文件直接通过电子邮件发送给您。

错误清单

尽管我们已经尽一切努力确保我们内容的准确性，但错误仍然会发生。如果您在我们的书中发现错误——可能是文本或代码中的错误——如果您能向我们报告这一点，我们将不胜感激。通过这样做，您可以节省其他读者的挫败感，并帮助我们改进本书的后续版本。如果您发现任何错误清单，请通过访问www.packtpub.com/submit-errata来报告它们，选择您的书籍，点击错误清单提交表链接，并输入您的错误详情。一旦您的错误清单得到验证，您的提交将被接受，错误清单将被上传到我们的网站，或添加到该标题的错误清单部分。任何现有的错误清单都可以通过从www.packtpub.com/support中选择您的标题来查看。

盗版

互联网上对版权材料的盗版是一个跨所有媒体的持续问题。在 Packt，我们非常重视我们版权和许可证的保护。如果您在互联网上发现我们作品的任何非法副本，无论形式如何，请立即向我们提供位置地址或网站名称，以便我们可以追究补救措施。

请通过<copyright@packtpub.com>与我们联系，并提供疑似盗版材料的链接。

我们感谢您在保护我们的作者以及为我们提供有价值内容的能力方面提供的帮助。

问题

如果你在本书的任何方面遇到问题，可以通过 <questions@packtpub.com> 联系我们，我们将尽力解决。

第一章。你好，BizTalk 服务

随着公司构建和扩展其 IT 信息资产，需要集成应用程序以交换数据。虽然使用自定义代码进行点对点应用程序集成是可能的，但它无法解决大规模应用程序集成的问题，包括数据重复和管理的复杂性。BizTalk 是本地系统和服务在 Azure 上基于消息的集成的事实选择，适用于应用程序和业务。

在这本书中，我们将向您介绍 BizTalk 服务，这是微软在 Windows Azure 上托管的新集成中间件。本书假设您已经理解了集成需求以及使用专业集成软件而不是构建定制的点对点集成解决方案的许多好处。我们将探讨为什么云托管集成服务如此吸引人，以及这些服务在哪些场景下最有意义。虽然对 BizTalk Server 的先验知识不是必需的，但它将帮助您快速理解本书中的某些主题。我们假设您是一位熟悉集成异构系统和应用程序挑战的专业开发者、架构师或解决方案设计师。本书还假设您熟悉微软的开发者工具集，特别是.NET、Visual Studio 和 SQL。

在本章中，我们将开始回答一些关于 BizTalk 服务是什么以及它如何帮助您构建集成解决方案的基本问题。具体来说，以下主题将被讨论：

• Azure 上 BizTalk 服务的商业和技术驱动因素

• BizTalk 服务的概念和架构

• 使用 BizTalk 服务实现简单的采购订单场景

背景

首先，一些背景信息是必要的。在 2008 年的专业开发者大会（PDC）上，微软揭幕了 Windows Azure——一个专为云设计的操作系统。在随后的几年里，Windows Azure 已成为微软的事实上的云平台，涵盖了服务、媒体、网站、移动应用程序等等。虽然 BizTalk Server 已经是一个超过十年（和八个版本）的成熟产品，但云的采用正在推动不同服务和业务线应用程序的连接系统。为了满足对基于云的集成不断增长的需求，微软 BizTalk 团队于 2011 年 12 月 17 日发布了 BizTalk 服务的第一个版本，名为 Service Bus EAI 和 EDI Labs 社区技术预览（CTP）。目标是让客户能够在共享环境中注册并设置简单的 XML/EDI 流，而无需担心安装和维护。这些功能足够丰富，可以支持简单的点对点集成场景；在次年 4 月 9 日，CTP 进行了更新，通过提供额外的功能来吸收客户的反馈。

CTP 环境托管在公共共享服务上，因此对运行用户自定义代码有限制。集成很少是直接的，开发者编写自定义代码并将其作为集成解决方案的一部分部署的能力是一个关键要求。客户还需要关于性能和服务级别协议（SLAs）的保证。通过切换到按租户部署，将用户组件作为云服务的一部分托管成为现实。因此，名为 BizTalk Services 的云产品于 2013 年 6 月 3 日诞生。像许多 Azure 服务一样，BizTalk Services 预计将定期更新。截至本文撰写时的最新更新是在 2014 年 2 月 20 日。这项技术正在开启新的集成可能性；随着微软持续的投资，它将在不久的将来与本地部署的同类产品 BizTalk Server 的能力相当。

业务驱动因素

在 Azure 上构建解决方案今天有许多实际的好处。其中一些包括根据可预测或动态变化的应用程序负载和吞吐量需求调整平台规模的能力，无需担心硬件采购时间和设置，按使用付费，将费用作为运营支出（OpEx）而不是资本支出（CapEx），以及某些集成场景的覆盖范围增加。

对于 Azure 上的集成，有四个因素推动其采用：

• 专注于业务运营，而非 IT：通过利用规模经济下运行的平台，降低了成本，使客户能够以更高的服务质量以更低的价格获得它们。当务之急是简化 IT 部署和管理，专注于业务服务而不是配置软件或硬件。

• 外部服务管理的简单性：企业通常在地理和组织边界之外提供服务。许多这些服务需要更改公司防火墙以允许或拒绝应用程序。这个过程对于许多组织来说是一个 IT 噩梦。通过 Azure 集成服务，如 B2B，这些服务本质上需要外部通信，所有这些都可以转移到云端，并且必要的访问和控制策略可以集中管理所有内部服务。这也使得对应用程序进行自助服务配置更改成为可能，从而显著提高对业务变化的响应速度。

• 绿色云应用：移动设备（如智能手机和平板电脑）以及销售点（POS）系统的普及，催生了本质上基于云的服务。想想一个 POS 系统将每日交易日志传输到其后端业务系统，或者一个 RFID 服务将零售店购物车中每个商品的详细信息传输到库存应用程序。随着新服务的推出，组织希望能够使用 Azure 在更短的时间内开发和部署这些服务。

• 对于云服务，另一个需要考虑的因素是利用现有的本地投资。企业已经在各种本地系统上进行了投资，包括传统的 ERP 系统、遗留的主机以及运行业务的定制系统。

技术驱动因素

BizTalk 服务的首要技术目标是减少交换信息时源和目标系统之间的阻抗不匹配。这种阻抗可能存在于不同的级别：

• 传输协议阻抗：源可能通过一种传输方式（例如 FTP）发送消息，而目标可能仅接受通过另一种传输方式（例如 POP3）发送的消息。也可能出现消息从一个业务线（LOB）发送到另一个业务线的情况，例如，一端通过销售力适配器发送消息，而另一端通过 SAP 适配器接收消息。BizTalk 服务提供适配器的概念来解决这个问题。

• 应用协议阻抗：源可能发送 EDIFACT 消息，而目标可能仅接受 XML 格式的消息。BizTalk 服务为 X12、EDIFACT 和平面文件等协议提供原生支持，以解决这种阻抗问题。

• 格式阻抗：源可能发送一种 XML 格式的消息，而目标可能仅接受另一种 XML 格式的消息。BizTalk 服务提供转换功能来解决这个问题。

• 时间阻抗：源可以在一天中的任何时间发送消息，但目标仅接受在下午 4 点到 7 点之间的消息。源发送消息的速度是目标处理速度的两倍。

• 大小阻抗：源可以发送任何大小的消息，但目标最多只能接受 1 MB 大小的消息。

BizTalk 服务提供连接到服务总线、批处理和去批处理的功能，以解决最后两个阻抗问题。

核心场景

上述驱动因素导致了 BizTalk 服务三个核心场景：

• 企业应用集成：这些主要是涉及平面文件或基于 XML 的数据，且在两个或更多应用程序之间的消息传递场景，其中至少有一个应用程序运行在云端。一个很好的例子是一个连接到多家航空公司订票系统的旅行门户。

• 业务对业务集成：这是两个组织之间具有结构化平面文件/XML 的消息场景。一个例子是 IT 公司从 HP、Dell 或联想等供应商采购硬件。

• 与混合应用程序的连接：这是 Azure 和本地应用程序之间的消息场景。这里的例子是将 Salesforce 应用程序连接到运行在您内部 IT 环境中的 SAP 应用程序。

我们将在本书的单独章节中详细探讨这些场景。

概念

下图展示了从 FTP 源到 LOB 目标的基本集成流程。BizTalk Services（由中间的框表示）是一系列处理步骤。

BizTalk Services 的作用

BizTalk Services 引入了几个关键概念，以简化在 Azure 上构建集成解决方案：

• 桥梁：桥梁是 BizTalk Services 中的处理单元，可以解决阻抗不匹配问题。它包含三个单元：一个或多个源位置（例如，FTP）用于读取消息，一个管道用于处理消息，以及一个或多个目标（例如，队列）用于写入处理后的消息。管道被划分为具有各自功能的独立处理单元，称为阶段（例如，管道中的一个阶段可以验证消息是否符合模式）。一系列阶段代表桥梁模式或桥梁模板。默认情况下，BizTalk Services v1 附带三个模板：XML、EDI 和 AS2。

• 适配器：适配器是传输介质，可以发送消息（到目的地）或接收消息（从源），并将它们通过桥梁传递到管道中；例如，业务线适配器如 SAP 和 Oracle EBS 或传输适配器如 FTP 和 SFTP。

• 转换：转换将消息从一种格式转换为另一种格式，有助于结构转换。转换包含可以执行常用转换的操作，如字符串操作、循环结构、列表操作以及算术和逻辑表达式。

• 应用协议：协议定义了消息格式和处理语义，例如发送和关联消息确认的要求。

• 路由：路由定义了基于指定标准将消息发送到的目标端点。路由标准基于 SQL-92 表达式语法进行评估。

• 批处理：基于选择标准的消息聚合称为批处理。批次的释放（发送）由大小、数量或时间，或这些参数的组合来控制。

• 提升属性：提升属性是名称-值对，其中名称是用户定义的，而值是从消息头、消息体或桥梁中的上下文中派生的。提升属性通常用于批处理和路由，以指定它们的条件。

• 工件：工件是指任何有助于在桥接器中处理消息的东西。XML 模式、映射、自定义程序集和证书是 XML 和 EDI 桥接器中使用的工件。在 BizTalk 服务中，每个工件都存储在工件存储中，并且可以通过一个唯一的 URL 访问。

生命周期和架构

与大多数其他 Azure 服务部署不同，BizTalk 服务为存储和计算实例分配了专用资源，这些资源在租户之间是隔离的。这意味着两个部署之间没有任何共同之处。优点是您可以编写任何自定义代码，并确信您不会影响其他部署的性能或可用性。这种专用部署还提供了在存储级别上的数据隔离，从而增加了数据的隐私性和服务的 SLA。

广义上讲，在您拥有一个活跃可用的部署之前，需要经历三个步骤。第一步是使用标准 Azure 工具配置服务，包括使用 Azure 门户创建服务；第二步是使用 Visual Studio 和 BizTalk 服务门户部署在 BizTalk 服务概念 部分中概述的必要工件和配置；第三步是发送或接收消息。

BizTalk 服务的架构包含三个关键组件：

• 配置服务：这是一组微软服务，用于管理 BizTalk 服务部署的生命周期以及监控其健康状况。它还包括基于 BizTalk 服务使用情况向最终用户计费的功能组件。服务的管理界面通过 Red Dog 前端（RDFE）公共 API 公开。Azure 管理门户或用户从 PowerShell 脚本通过 RDFE API 进行访问。使用此服务，您可以扩展或缩减您的部署，以及跨数据中心备份和恢复部署。

  注意

  Red Dog 是 Azure 的原始代号，其中的 "FE" 代表公开可访问的前端，用户可以直接通过 Azure 门户或服务管理 API 与其交互。

• 按租户 BizTalk 服务：这是在用户的 Azure 订阅中创建的按租户部署。BizTalk 服务部署通过部署名称进行标识，并通过访问控制服务（ACS）加密的 URL 可访问。所有如桥接器和模式等工件都添加到部署中，其 URL 是部署 URL 的子路径。例如，桥接器添加到 <deployment URL>/default/<bridgeName> 下。这里的 default 是工件分组到的命名空间名称。

• 按租户依赖项：这些依赖项是用于跟踪、故障排除和安全的 Azure 服务。例如，BizTalk Services 提供了一个跟踪存储库，这是一个 Azure SQL 数据库，其中存储了消息的处理状态以及相关的属性，当消息通过桥接器时。跟踪存储库中的信息显示在 BizTalk Services 门户跟踪视图中。存档和监控存储在 Azure 存储 blob 和表中。存档消息存储在基于存档日期的 blob 容器中。存储还包含 Azure 表 WADLogsTable，其中可以获取桥接器的跟踪信息。最后，访问控制服务管理对部署中所有端点的访问。在创建部署期间，配置服务使用管理服务凭据以编程方式访问 ACS，为 BizTalk Services 部署创建一个信任方，为发送、监听和管理声明添加规则组，并创建具有直接与 ACS 通信所需密码的服务标识。这些组件之间的交互在以下图中说明：

  BizTalk Services 共享和按租户服务的框图

角色和工具

BizTalk Services 为不同的角色提供不同的用户体验，以促进优化的基于任务的解决方案。主要角色包括：

角色	描述	主要工具
开发者	创建集成解决方案和组件，如转换和模式的人员	Visual Studio
IT 专业人员	管理环境的人员，包括部署、设置和配置等任务	Azure 门户和仪表板
合作伙伴管理员	设置和管理贸易伙伴的人员	贸易伙伴/BizTalk 门户

开发者

开发者通常会专注于使用 Visual Studio 创建解决方案。BizTalk Services VS 2012 项目模板提供，以实现快速创建 EAI 和 EDI 解决方案。这些模板提供了一个图形工作界面，用于创建和配置桥接，以促进企业与贸易伙伴之间的通信。此外，还提供了高级工具，包括图形映射界面和模式编辑器。

IT 专业人员

Windows Azure 平台管理门户提供访问权限以创建 BizTalk Services 部署和管理任务，以及提供有关所有部署和账户整体健康状况的快速查看状态信息。除了服务部署外，Windows Azure 平台管理门户还提供了一个用于配置 Azure SQL 数据库、移动服务、Service Bus 实体等的接口。

合作伙伴管理员

合作伙伴管理员角色使用 BizTalk 服务门户执行多项管理功能，例如创建和管理贸易伙伴、配置包括所需转换、路由和确认、跟踪消息以及异常处理。

BizTalk 服务门户允许创建贸易伙伴及其之间的协议。这使您可以设置和管理用于交换数据（例如，X12 和 AS2）的协议以及要使用的消息格式，包括转换和路由功能。通过这种方式，非 IT 人员可以快速轻松地将贸易伙伴上线并配置，而无需使用如 Visual Studio 等开发工具，所有操作都通过基于 Web 的门户完成。

此外，管理门户还提供了设置和查看消息流跟踪数据的能力，包括上下文细节（发送者、消息类型等）以及消息体本身。作为服务的一部分，还提供了存档和导出消息数据的功能。

此外，还实现了 RESTful API，以提供与门户的完全兼容性，使活动可以脚本化，部署可以自动化。此外，使用此 API 还可以实现与客户系统（如 SharePoint）的集成，用于跟踪数据、可视化或本地存储。

部署注意事项

您需要考虑为您的生产使用所需的 BizTalk 服务版本，以及用于测试和/或预演的环境。这取决于以下决策点：

• 目标系统上的预期消息负载

• 现在所需的功能与 6 个月后的需求

• 与合规性、安全和灾难恢复相关的 IT 要求

不同版本的功能列表可以在 Windows Azure 文档页面 www.windowsazure.com/en-us/documentation/articles/biztalk-editions-feature-chart 中找到。

注意

关于 BizTalk 服务版本和注册的说明

BizTalk 服务目前有四个版本：开发者版、基本版、标准版和高级版，每个版本都有不同的功能和价格。您可以从 Azure 门户注册 BizTalk 服务。开发者 SKU 包含尝试和评估所需的所有功能，无需担心生产就绪性。我们在本书的所有示例中都使用开发者版。

配置 BizTalk 服务

BizTalk 服务的部署可以使用 Windows Azure 管理门户或使用 PowerShell 创建。在本例中，我们将使用前者。

证书和 ACS

使用 SSL 进行通信需要证书，并且访问控制服务用于保护 BizTalk 服务部署的端点。首先，您需要知道是否需要为 BizTalk 服务部署自定义域名。对于测试或开发者部署，答案通常是“不”。BizTalk 服务部署将自动生成一个有效期接近 5 年的自签名证书。用于部署的 ACS 也将自动创建。发送消息到网关和协议需要证书和访问控制服务详情，这些可以在部署后的仪表板页面上检索。

存储需求

您需要创建一个 Azure SQL 数据库用于跟踪数据。建议使用具有适当大小的商业版；对于测试目的，可以从 1 GB 的 Web 版开始。您还需要传递存储账户凭据以存档消息数据。建议只为 BizTalk 服务创建一个新的 Azure SQL 数据库和存储账户。

BizTalk 服务创建向导

现在我们已经解决了安全和存储的细节，让我们从 Azure 管理门户创建一个 BizTalk 服务部署：

1. 从管理门户导航到新建 | 应用服务 | BizTalk 服务 | 自定义创建。

2. 为部署输入一个唯一的名称，同时保留以下值—版本：开发者，区域：东美国，跟踪数据库：创建新的 SQL 数据库实例。

3. 在下一页，保留默认数据库名称，选择 SQL 服务器，并输入服务器登录名和密码。

   备注

   到本书编写时，每个 Azure 订阅可以有六个 SQL 服务器实例。

4. 在下一页，选择用于存档和监控信息的存储账户。

5. 部署解决方案。

Windows Azure 管理门户中的 BizTalk 服务创建向导

部署过程大约需要 30 分钟来完成。完成后，您将看到部署状态为“Active”。导航到部署仪表板页面；点击连接信息并记下 ACS 凭据以及下载部署 SSL 证书。SSL 证书需要安装到将使用 Visual Studio SDK 的客户端机器上。

BizTalk 门户注册

我们还剩下一项步骤，那就是配置 BizTalk 服务管理门户以查看协议、网关及其跟踪数据。为此，执行以下步骤：

1. 从仪表板屏幕点击管理。

2. 这将启动<mydeployment>.portal.biztalk.windows.net，其中托管了 BizTalk 门户。

3. 一些字段，如用户的 Live ID 和部署名称，将自动填充。

4. 输入上一步中记录的ACS 发行者名称和ACS 发行者密钥，然后点击注册。

BizTalk Services 门户注册

创建您的第一个 BizTalk Services 解决方案

让我们付诸实践，并使用之前创建的部署来处理一个现实世界的多渠道销售场景。

场景描述

一位交易员，Northwind，管理着一个电子商务网站，用于在线客户购买。他们还从活动公司和公司接收大量订单。Northwind 需要开发一个解决方案来验证订单并将请求路由到正确的库存位置以交付商品。传入请求是一个包含订单详细信息的 XML 文件。活动公司和公司的请求通过 FTP 进行，而电子商务网站的请求通过 HTTP 进行。如果客户位置在美国境内，则订单后处理请求将转发到美国地址的中继服务。对于所有其他位置，订单需要发送到中央站点，并使用位置作为提升属性发送到 IntlAddress 的 Service Bus 队列。

前提条件

在我们开始之前，我们需要通过以下步骤设置客户端机器以连接到之前创建的部署：

1. 将从部署下载的证书安装到您的客户端机器上的受信任根存储中。这验证了您客户端和 Azure 上的集成解决方案之间的任何 SSL 流量。

2. 下载并安装 BizTalk Services SDK (go.microsoft.com/fwLink/?LinkID=313230)，以便在 Visual Studio 2012 中启用开发者项目体验。

3. 从 MSDN 代码库中下载 BizTalk Services EAI 工具的消息发送器和消息接收器示例，该代码库位于 code.msdn.microsoft.com/windowsazure。

实现解决方案

我们将实现细节分解为定义传入格式和创建桥梁，包括处理传入消息的传输以及创建目标端点、中继和 Service Bus 队列。

创建 BizTalk Services 项目

您可以在 Visual Studio 2012 中创建一个新的 BizTalk Services 项目。

Visual Studio 中的 BizTalk Services 项目

创建订单架构

在您的项目中，右键单击项目名称，点击 添加 | 新建项，然后添加一个新的 平面文件架构。

将平面文件架构添加到 BizTalk Services 项目中

将以下节点添加到架构中，以便结构如下所示：

平面文件架构结构

对于 XSD 文件中的每个记录，确保正确添加了分隔符：

<b:recordInfo structure="delimited" child_delimiter_type="char" child_delimiter="," child_order="postfix" preserve_delimiter_for_empty_data="true" suppress_trailing_delimiters="false" sequence_number="4" />

您可以通过运行实例文件来验证架构。通过在解决方案资源管理器中右键单击创建的架构文件，可以使用验证实例命令。在两个单独的文件中添加以下平面文件和 XML 实例，使用验证实例命令，并验证架构是否验证这些实例。对于每次命令运行，请确保架构属性窗口具有正确的验证实例输入类型（在这种情况下为 XML）：

OrderId|PaymentType|OrderDate|Code,Qty,Price,|Name,Email,Phone,|Recipient,Number,Street,City,State,Country,Pincode,|

<ns0:Order >
  <OrderId>MyOrder</OrderId>
  <PaymentType>CreditCard</PaymentType>
  <OrderDate>09-08-2013 22:50:00</OrderDate>
  <Product>
    <Code>100</Code>
    <Qty>1</Qty>
    <Price>500</Price>
  </Product>
  <Customer>
    <Name>Karthik</Name>
    <Email>user@hotmail.com</Email>
    <Phone>1-111-1111</Phone>
  </Customer>
  <ShippingAddress>
    <Recipient>Jon</Recipient>
    <Number>Building 1</Number>
    <Street>One Redmond Way</Street>
    <City>Redmond</City>
    <State>Washington</State>
    <Country>US</Country>
    <Pincode>98052</Pincode>
  </ShippingAddress>
</ns0:Order>

小贴士

下载示例代码

您可以从www.packtpub.com您购买的所有 Packt 书籍的账户下载示例代码文件。如果您在其他地方购买了此书，您可以访问www.packtpub.com/support并注册以直接将文件通过电子邮件发送给您。

创建 BizTalk 服务解决方案

打开桥接器配置界面（通常是MessageFlowItinerary.bcs文件）。Visual Studio Toolbox 应显示以下实体：

BizTalk 服务项目 Visual Studio Toolbox

使用 VS 工具箱拖放FTP 源、Xml 单向桥接、单向中继端点和队列，并使用连接器将它们连接起来，如图所示：

BizTalk 服务项目中的桥接消息流

在消息流中配置以下内容：

1. 选择 FTP 服务器，并正确配置地址、用户名和密码。

2. 双击桥接器以打开Xml 单向桥接配置：

   • 在消息类型块中，添加之前创建的OrderFF.xsd实例。

     桥接器配置

   • 在第一个富化阶段，添加一个 XPath 类型属性，从/*[local-name()='Order' and namespace-uri()='http://BizTalkServicesOrderSample.OrderFF']/*[local-name()='ShippingAddress' and namespace-uri()='']/*[local-name()='Country' and namespace-uri()='']读取并作为字符串写入位置。XPath 值可以通过在 VS 中打开架构，点击相关记录，并从记录属性窗口复制 XPath 值来获取。

   

   在桥接器的富化阶段提升属性配置

3. 在父MessageFlowitinerary.bcs视图中，点击从OrderProcessingBridge到USAddressRelay的路由链接，并将过滤器条件设置为location='US'；对于其他链接，设置位置为US。

   消息流的路由属性

4. 编辑MessageFlowitinerary.bcs下的队列.config文件，并更新<tokenProvider>和<endpoint>细节以包含服务总线信息。

5. 编辑位于 MessageFlowitinerary.bcs 下的 Relay 服务 .config 文件，并更新 <endpoint> 详细信息以包含 Service Bus 中继信息。

6. 构建和部署解决方案。

7. 如果部署成功，将您的浏览器指向 https://<yourdeployment>/default/OrderProcessingBridge；您应该看到一个 401 HTTP 错误代码，表明此操作需要管理声明。

验证解决方案

我们需要测试发送两种类型的消息：一种来自企业，另一种来自网站：

• 在 VS 中加载 MessageReceiver 示例并构建解决方案。从输出 bin 文件夹中，在命令提示符窗口中运行以下命令：

  MessageReceiver.exe ServiceBusNS owner issuerkey USAddressRelay OneWayRelay
  

  在这里，ServiceBusNS 是中继运行所在的命名空间，MyRelayTestSvc1 是在桥接配置中配置的端点信息。

• 在新的命令窗口中加载另一个 MessageReceiver。

  MessageReceiver.exe ServiceBusNS owner issuerkey IntlAddressQueue Queue
  

  在这里，ServiceBusNS 是已预先创建队列的命名空间，IntlAddressQueue 是与桥接器配置的端点信息。

• 在 VS 中加载 MessageSender 示例并构建解决方案。《yourdeployment》是 BizTalk 服务之前配置的 URL。

  MessageSender.exe BizTalkSvcACS owner issuerkey https://<yourdeployment>/default/OrderProcessingBridge instance.xml application/xml
  

  在这里，BizTalkSvcACS 是 BizTalk 服务部署 ACS 的命名空间，owner 和 issuerkey 是该命名空间的 ACS 凭证，而 instance.xml 是 XML 格式的 OrderFF.xsd 实例。

• 输出将在中继的 MessageReceiver 中观察到。

• 使用 location=EU 编辑 instance.xml 并再次运行 MessageSender 命令。这次输出将在队列的 MessageReceiver 中观察到。

• 在 FTP 中放置一个平面文件，指定 location=US 并在中继服务窗口中观察输出。

• 在 FTP 中放置一个平面文件，指定 location=EU 并在消息接收队列中观察输出。

Northwind 现在可以从 HTTP 或 FTP 端点处理平面文件和 XML 订单。您可以从 BizTalk 服务门户的桥接视图或使用 PowerShell 删除桥接器。

摘要

在本章中，我们介绍了 BizTalk 服务的基础知识以及可用于构建集成解决方案的概念、架构、角色和工具。我们还通过 BizTalk 服务和 Service Bus 中继以及队列的简单订单处理场景练习了所有学到的概念。该示例可以进一步扩展，包括转换、路由到其他桥接器如 EDI、自定义代码等。在下一章中，我们将更详细地探讨一些 BizTalk 服务功能。

第二章。消息和转换

在第一章 Hello BizTalk Services 中，我们讨论了BizTalk Services的基础知识和桥梁提供的数据接收和发送的中央概念，通过其内置的管道通过端点适配器（源和目的地）。在本章中，我们将讨论消息方面，重点关注消息的一个特定方面：转换，或映射。集成最常见的一个方面是将一种消息格式转换为另一种格式；我们在第一章 Hello BizTalk Services 中提到的结构阻抗。这是任何集成人员工具箱中的基本工具，BizTalk Services 提供了一个全新的、现代化的映射引擎，以及图形工具来构建复杂和强大的转换。在本章中，我们将详细探讨 BizTalk Service 的映射和转换功能及其提供的灵活性。总结来说，本章将涵盖以下内容：

• 为什么转换和映射很重要

• BizTalk Services 中的映射功能

• 创建您的第一个映射

• 理解映射操作

问题

BizTalk Services 的职责是让您将此连接到彼。实际上，这个“此”和“彼”可能并不总是清晰、明确，或者标准化为某种国际认可的协议。因此，映射功能至关重要——一种将此转换为彼的方法。在许多情况下，映射需求可能很复杂；例如，需要基本改变消息的形状或结构，或者需要用对接收者有意义的内容替换源消息中的数据值。我们可以将这些问题分为两类：一类需要解决消息的结构，即转换；另一类需要解决其内容，即转码或翻译。两种类型的映射，转换和翻译，在 BizTalk Services 中都是可能的，正如我们将在本章中看到的。

映射器

到目前为止，我们故意保持模糊，并且有很好的理由。通常，映射需求并不明确，并且随着对涉及的消息格式的细微差别及其变体的了解越来越多，它们会发生变化。熟悉处理基于 XML 的消息的人可能会惊讶地发现，仅仅使用 XML Schema Definition (www.w3.org/XML/Schema)来描述它们的有效性，结果可能比最初看起来要复杂。不幸的是，这有时与单个架构可以创建或生成的不同生产或 XML 消息实例有关，这往往是无意中发生的。XSD 有时不够精确，因此集成通常很混乱，需要良好的工具来使事情适应，而标准和规范的纯洁性并没有足够深入，以避免在实现中的歧义。这是我们将在本书中多次回顾的主题：为了成功，任何集成技术都必须灵活，以适应手头的特定问题，适应它，不要改变，适应，转换，并集成。映射是工具箱中的一个工具，并且对于满足这些要求非常重要。因此，它值得有一个专门的章节。

映射设计器

看一下下面的屏幕截图。这显示了可以从 Visual Studio 2012 访问的新图形映射设计器。对于那些熟悉BizTalk Server的人来说，不要被误导。虽然它可能看起来和感觉与 BizTalk Server 映射器相似，但这个工具有显著的不同；主导的设计美学是尽可能简化常见的映射任务，因此映射器经历了重大的改造。

图形映射设计器

架构

然而，我们可能有些过于急切了。为了将一种消息格式或结构映射到另一种，例如翻译其内容，我们首先需要理解这些消息本身。这其中的基础是架构。

BizTalk Services 区分两种类型的消息：XML 和非 XML。所有 XML 消息格式都使用 XSD 表达，所有非 XML 消息格式都使用 XSD 表达。因此，XSD 很重要！本书的目的不是提供 XSD 的入门指南；如果您需要我们提到的技术的背景信息，我们会参考其他参考资料。相反，我们将提供足够的信息，以展示 BizTalk Services 如何使用这些技术，以便那些不太熟悉的人也能理解正在发生的事情。

现在，你可能想知道你所能想到的任何消息格式如何能在 XSD 中定义。让我们看看一个例子。

一个例子

让我们扩展一下我们在第一章中看到的示例，Hello BizTalk Services。如果你还记得，这个示例通过 SFTP 接收了一个文件并将其路由到 Service Bus 端点。现在我们将向解决方案中添加一个映射。这个映射将把传入的消息转换成接收者期望的另一种格式。然而，正如之前所提到的，如果我们要把一种消息格式转换为另一种格式，我们需要首先定义目标消息的架构，以便我们能够将其映射到它。

要这样做，请右键单击项目，导航到添加 | 新建项，从项目列表中选择架构，并给出名称OrderUS.xsd。点击添加以创建架构并将其添加到解决方案中。

架构设计器现在将打开。正如你在第一章中看到的，Hello BizTalk Services，添加节点到架构以构建它，如下截图所示：

修改订单架构

现在，右键单击项目并导航到添加 | 新建项。从项目列表中选择映射，并给出名称FFtoUS.trfm。点击添加以创建映射并将其添加到解决方案中。

映射设计器现在将打开；第一个任务是设置架构。由于映射的职责是将一种格式转换为另一种格式，因此至少需要两个架构：输入和输出。

点击开源架构链接，展开树形结构，选择OrderFF.xsd，然后点击确定。现在点击打开目标架构链接，选择OrderUS.xsd架构，然后点击确定。

设计器现在将看起来如下截图所示：

使用设计器选择架构

现在我们需要将一种格式映射到另一种格式。我们通过连接节点来实现，通常是从左到右工作。

通过点击并按住鼠标左键，将左侧的OrderId节点拖动到右侧的OrderNumber节点上，并在指针位于目标字段上时释放按钮，将左侧的OrderId节点连接到右侧的OrderNumber节点。

现在请注意，目标架构和源中的客户信息不同；只有元素名称不同，但结构相同。映射器提供了一个快速映射字段的快捷方式，以避免逐个连接它们。为此，请按住鼠标左键在左侧源架构中的父 Customer 节点上，并将其拖动到目标 CustomerDetails 节点上。下一张截图所示的下拉菜单将弹出。在这里，我们提供了以下截图所示的一些选项。选择 按结构链接 并注意，尽管它们的名称不同，但所有节点都自动连接在一起。这是因为此选项按出现的顺序连接字段，而不管节点名称如何，当两个架构的结构相同时非常有用。您可以使用相同的方法来映射字段名称匹配的情况（按名称链接）或选择 简单链接，这将简单地连接顶级节点。当映射大量字段时，这种技术非常有用。

链接选项

映射操作

我们可以继续这样做，连接任意数量的节点，单独或成组连接。然而，我们往往需要做的不仅仅是将一个节点的值映射到另一个节点。为此，我们可以转向映射操作。对于那些熟悉 BizTalk 服务器的人来说，您将熟悉 functoids；在 BizTalk 服务中，概念类似。然而，尽管有相似之处，它们在实现上存在许多差异。产品组的主要目标之一是简化常见任务，例如循环，这些任务以前往往很难或耗时。这就是我们现在将关注的重点。

BizTalk 服务提供了总共 37 个映射操作，这些操作在工具箱中按功能分组。这里没有足够的空间涵盖每个映射操作，所以我们只关注一些最有用的。要获取完整参考，请查看 MSDN 文档，网址为 msdn.microsoft.com/en-us/library/windowsazure/hh689870.aspx。其理念是所有映射操作都以相同的方式进行配置和连接；因此，一旦你学会了可用的操作，使用它们的组合来完成映射任务就变得简单直接。映射操作类别如下表所示：

类别	用途
字符串操作	将节点值作为字符串进行操作，例如连接、修剪和子字符串操作
循环操作	在源中循环重复节点的操作
表达式	执行计算或决策的算术和逻辑表达式
列表操作	对可以由节点内容以条件方式创建的项目列表进行处理
累计操作	用于累计值，如总和、计数和平均值
日期和时间操作	操作日期和时间值
其他操作	用于检索上下文属性、格式化数字以及在映射中包含 C#的各种操作

一种非常常见的转换类型是展平。这是指需要将多个重复的项目（通常是一个列表）合并（或展平）成一个单一值，通常需要应用一些计算（例如，求和）。BizTalk Services 提供了一些映射操作，以简单直接的方式实现这一点。

看看下面的 XML，你可以看到<Product>元素是重复的，也就是说，可以指定多个产品。假设我们想要计算所有产品价格（Price）乘以订购数量（Qty）的总和，以计算出订单的总价值：

<ns0:Order >
  <OrderId>OrderId_0</OrderId>
  <PaymentType>PaymentType_0</PaymentType>
  <OrderDate>OrderDate_0</OrderDate>
  <Products>
    <Product>
      <Code>Code_0</Code>
      <Qty>Qty_0</Qty>
      <Price>Price_0</Price>
    </Product>
    <Product>
      <Code>Code_0</Code>
      <Qty>Qty_0</Qty>
      <Price>Price_0</Price>
    </Product>
    <Product>
      <Code>Code_0</Code>
      <Qty>Qty_0</Qty>
      <Price>Price_0</Price>
    </Product>
  </Products>
  <Customer>
    <Name>Name_0</Name>
    <Email>Email_0</Email>
    <Phone>Phone_0</Phone>
  </Customer>
  <ShippingAddress>
    <Recipient>Recipient_0</Recipient>
    <Number>Number_0</Number>
    <Street>Street_0</Street>
    <City>City_0</City>
    <State>State_0</State>
    <Country>Country_0</Country>
    <Postcode>Postcode_0</Postcode>
  </ShippingAddress>
</ns0:Order>

最终结果，即订单的总价值，需要映射到目标架构中的单个字段。我们可以使用映射操作轻松实现这一点。成功使用映射操作的关键是将需求分解，并选择最合适的映射操作来实现目标。正如我的解释已经暗示的那样，这个问题有几个部分。首先是意识到我们需要对每个Qty * Price字段计算保持累计总和——每个Product元素一个。让我们先处理这个问题。

BizTalk Services 提供了一套基于列表的映射操作，允许创建一个临时列表来存储项目并操作列表中的项目。

首先将一个创建列表映射操作拖动到设计表面上。对于 BizTalk Server 开发者来说，第一个明显的改变可能是 BizTalk Services 中的映射操作提供了嵌套功能。这是简化复杂任务的关键，因为这种嵌套行为提供了一种自然的方式来分组和组织所需的映射任务。

创建列表操作将用于存储我们计算的临时结果。我们将把每个产品的总价值推送到列表中，然后稍后计算这些列表项值的总和。双击创建列表来配置它。在对话框中，输入一个成员名称，例如total，并从下拉菜单中选择数字作为成员类型，如图所示。这是一个将用于存储我们计算值的变量。点击确定关闭对话框。

配置创建列表操作

下一步是遍历所有的Product元素。为此，拖动一个For Each映射操作并将其放入创建列表操作内部。注意我们还可以在这个操作中放置额外的操作。这就是我们将放置每行项目总值的计算的地方。

现在将左侧架构中的Product节点连接到ForEach操作。这告诉操作在Products中循环每个Product节点。

将一个算术表达式操作拖动到设计器中，并将其放入ForEach操作中。现在将Qty和Price字段连接到这个操作上。这些将成为我们的输入参数；我们想要使用数据的输入消息中的节点。依次拖动每个节点，将连接拖到画布上的算术表达式操作上。现在双击新的算术表达式来配置它。在这里，我们可以指定基于连接到操作的字段进行的计算，在这种情况下是Qty和Price。输入以下截图所示的公式：

算术表达式操作的配置

我们现在需要存储这个结果；为此，我们将它添加到外部的列表操作中。拖动一个向列表添加项操作并将其放置在算术表达式操作的右侧，在ForEach操作内。然后，通过从一侧拖动一条线到另一侧来将算术表达式操作连接到向列表添加项操作。双击向列表添加项操作来配置它。对话框应该已经预先填充，因此我们只需点击确定来保存设置。映射现在应该看起来像以下截图所示：

部分完成的映射

好的，任务的第一部分已经完成；我们正在计算每个产品的总价值。我们现在需要将这些总和相加以获得订单的总计。这非常简单。拖动一个选择条目映射操作并将其放置在创建列表操作的右侧。将创建列表操作连接到选择条目。双击选择条目以打开它，勾选total旁边的已选择复选框，并按以下截图所示点击确定。在这里，我们指定要从我们创建的列表中提取哪些变量。在这种情况下，我们只有一个，所以选择很简单。

选择条目操作的配置

最后，拖动一个累计求和操作并将其放置在选择条目操作的右侧。将选择条目操作连接到累计求和操作。现在将累计求和操作连接到目标架构中的TotalValue字段。双击您刚刚添加的累计求和操作，并在表达式文本框中输入item.total，如以下截图所示。在这里，我们指定从选择条目操作传递的列表条目中的总变量：

累计求和操作的配置

完成的映射应该看起来像以下截图：

带有循环和计算节点的映射

我们几乎完成了地图的创建。让我们来处理ShippingAddress节点。注意，左侧的字段比右侧多。因此，我们将通过连接其中一些字段来合并它们。有几种方法可以做到这一点；例如，我们可以使用String Concatenate映射操作，它可以接受任意数量的输入并生成一个连接的单字符串输出。

然而，让我们看看一些更有趣的东西。当没有满足你需求的操作时，你可以转向CSharp Scripting操作。正如其名称所暗示的，这个操作允许你在其配置中包含 C#，这给了你.NET 框架的全部力量，以便能够实现你需要的任何映射功能。

将CSharp Scripting操作拖动到映射设计表面上，并将其放置在Create List操作下方。将Number、Street、City、State和Country节点连接到它。你可能已经意识到了，这是操作在特定数据项上工作的方式，对于脚本操作也是如此。通过将这些项连接到它，它们就可供我们编写的脚本使用。双击CSharp Scripting操作以打开其配置。

在对话框中，注意有一个Script Text多行文本框。在这里，我们可以定义一个 C#函数，该函数将节点作为输入参数并返回一个值。在这个简单的例子中，你可以从下一张截图看到，我只是将输入参数与一些格式化信息连接起来，并将结果返回到地图中。输入以下代码以实现相同的功能：

public string CreateAddress (string Number, string Street, string City, string State, string Country)
{
   return Number + " " +
          Street + "," +
          City + "," +
          State + "," +
          Country;
}

注意，脚本操作的输入节点名称必须与代码中的参数名称匹配。如果名称不同，地图将无法编译。一旦我们通过点击OK保存，我们就可以将操作连接到目标架构的Address节点。

使用 C#进行映射

现在只剩下几个字段需要映射。只需将Recipient连接到FullName，将PostCode连接到Zip。我们将要查看的最后一个操作以完成此地图是日期时间重新格式化操作。将其拖放到创建列表操作上方的布局表面。将两个模式中的OrderDate节点连接到该操作，然后双击日期时间重新格式化操作以进行配置。当处理发送者和接收者之间不同的日期格式要求时，此操作非常有用。这个操作的好处是它不仅支持一组固定的日期和时间格式，而且您还可以输入自己的格式。对于输入格式字段，在格式字段中输入d/M/yyyy。请注意，这并不是下拉菜单中提供的选项之一，因此您需要将其输入到文本框中，如下面的截图所示。此外，请确保字母M是大写的，如下所示。然后，对于输出格式字段，选择M/d/yyyy。这将把输入日期解释为日/月/年格式，例如，2/9/2013，并将输出转换为月/日/年格式，例如，9/2/2013。

日期格式化

地图现在已完成。它应该看起来与以下截图相似：

完成的地图

测试

呼！这看起来可能相当复杂，但一旦分解开来，实际上非常简单。下一步是测试地图，看看它是否产生了正确的结果。测试直接集成在 Visual Studio 中，因此无需编译和部署解决方案到 Windows Azure 以查看其是否工作。这很重要，因为创建任何非平凡地图都是一个非常迭代的过程。通过逐步构建地图的功能并检查测试结果，这个过程变得更容易。这样，任何错误都更加明显且易于纠正。

要测试一个映射，我们需要一些输入。这最简单的方法是在 Visual Studio 本身中生成。在解决方案资源管理器窗口中右键单击OrderFF.xsd模式，并选择生成实例。打开创建的文件，并编辑值以匹配以下代码中显示的内容（别忘了，您可以从网站上下载此示例的源代码）：

<ns0:Order >
  <OrderId>123</OrderId>
  <PaymentType>ACCOUNT</PaymentType>
  <OrderDate>2/9/2013</OrderDate>
  <Products>
    <Product>
      <Code>AB12</Code>
      <Qty>4</Qty>
      <Price>1.50</Price>
    </Product>
    <Product>
      <Code>AC01</Code>
      <Qty>2</Qty>
      <Price>3.99</Price>
    </Product>
    <Product>
      <Code>DE4</Code>
      <Qty>10</Qty>
      <Price>12.25</Price>
    </Product>
  </Products>
  <Customer>
    <Name>John Doe</Name>
    <Email>john.doe@contoso.com</Email>
    <Phone>425-123456</Phone>
  </Customer>
  <ShippingAddress>
    <Recipient>Jane Smith</Recipient>
    <Number>1</Number>
    <Street>East Street</Street>
    <City>New York</City>
    <State>New York</State>
    <Country>USA</Country>
    <Postcode>NY12345</Postcode>
  </ShippingAddress>
</ns0:Order>

生成实例操作默认创建一个 XML 格式的消息——这是地图本身所需要的。然而，这个模式是一个平面文件模式，如果我们想生成一个传递给桥接器的消息，我们需要以这种格式生成消息。在模式属性中，有一个名为生成实例输出类型的属性，可以将其设置为原生而不是XML。当选择原生时，模式将根据其类型创建一个测试消息，无论是平面文件还是 XML。以下截图显示了将此设置为原生与OrderFF.xsd模式相比的结果：

生成实例：本地

一旦我们有了测试消息，我们就可以将其分配给映射来尝试。在 解决方案资源管理器 窗口中单击 FFtoUS.trfm 映射；在 属性 窗口中，将文件的路径输入到 测试映射输入文件 属性中。现在右键单击映射并选择 测试映射。如果有幸，您应该在输出窗口中看到以下片段类似的内容。这意味着映射执行成功！

Test Map succeeded.
Output is written to the file 'C:\Users\Jon\AppData\Local\Temp\tmp3817.xml'.

通过 文件 菜单打开文件，导航到 打开 | 文件 并浏览到前一个输出中的文件位置（在本例中：C:\Users\Jon\AppData\Local\Temp\tmp3817.xml）。如果您一切都做得正确，它应该看起来与以下 XML 代码相同：

<?xml version="1.0" encoding="utf-8"?>
<ns1:USOrder  >
  <OrderNumber>123</OrderNumber>
  <OrderDate>9/2/2013</OrderDate>
  <OrderValue>136.48</OrderValue>
  <CustomerDetails FullName="John Doe" EmailAddress="john.doe@contoso.com" Telephone="425-123456">
  </CustomerDetails>
  <ShippingDetails FullName="Jane Smith" Address="1 East Street,New York,New York,USA" Zip="NY12345" />
</ns1:USOrder>

注意这个 XML 文档与您用作输入的文档有多么不同，您可能开始欣赏 BizTalk Services 映射器的强大功能。

配置桥接器

然而，一个映射本身并没有什么用。我们需要能够在集成解决方案中使用它。希望这不会让人感到惊讶，我们这样做是通过配置桥接器。下一个截图显示了桥接器配置的一部分。此配置表示可以配置的处理管道。正如在 第一章 中提到的，该管道有多个阶段，Hello BizTalk Services。在管道的中间有一个 转换 阶段；正是在这里，我们可以指定要执行的映射。

配置带有映射的桥接器

在 解决方案资源管理器 窗口中双击 MessageFlowItinerary.bcs 文件以打开它。在设计器中，通过双击它来打开 OrderProcessing 桥接器配置。单击 转换 阶段并查看 属性 窗口。在这里，我们可以通过单击 映射 属性旁边的省略号（…）来选择映射，打开配置的映射。这将显示解决方案中包含的所有映射。

我们可以通过勾选它旁边的 选中 复选框来选择我们之前创建的映射，如图所示。单击 确定 将返回到桥接器配置，此时应该显示在 转换 阶段中选中的映射，即 FFtoUS。

选择映射对话框

整合所有内容

解决方案现在已准备就绪。像以前一样构建和部署，一旦部署，将浏览器指向 https://<yourdeployment>/default/OrderProcessingBridge，您应该看到一个 401 HTTP 错误代码，表示此操作需要管理声明。

现在，您将使用 BizTalk Services SDK 提供的两个工具。这些是 MessageSender 和 MessagerReceiver，您可以从以下链接下载它们。这些工具允许您向您创建的桥接器发送消息并从桥接器接收消息：

• code.msdn.microsoft.com/windowsazure/Windows-Azure-BizTalk-EAI-e01a5b64

• code.msdn.microsoft.com/windowsazure/Windows-Azure-BizTalk-EAI-af9bc99f

解压这两个解决方案，并在 Visual Studio 2012 中打开 MessageReceiver 示例并构建它。通过在命令提示符中键入以下内容并按Enter键来运行它。

<path>MessageReceiver.exe ServiceBusNS owner <issuerkey> USAddressRelay OneWayRelay

在前面的命令中，<path>是从 Visual Studio 构建输出到 exe 的路径，ServiceBusNS是中继运行时的命名空间，USAddressRelay是在桥接配置中配置的端点信息。请注意，您还需要将<issuerkey>值替换为您自己的订阅详情。

现在在 Visual Studio 2012 中打开 MessageSender 示例（从上一个链接下载）并构建它。按照以下代码运行以向桥接发送消息：

<path>MessageSender.exe BizTalkSvcACS owner issuerkey https://<yourdeployment>/default/OrderProcessingBridge instance.xml application/xml

在前面的代码中，BizTalkSvcACS是 BizTalk 服务部署的 ACS 命名空间。和之前一样，owner和issuerkey是该命名空间的 ACS 凭证，而instance.xml是 XML 格式的OrderFF.xsd实例。

确保在中继的 MessageReceiver 示例中观察到输出。检查输出消息并注意映射是如何将其转换的。

更多关于映射

到目前为止，我们已经覆盖了很多内容，但在 BizTalk 服务中关于映射的内容还有很多，除了我们在这里没有使用的其他 27 个操作之外。还有两组其他操作值得讨论。

这些中的第一个是获取上下文属性映射操作。这为 BizTalk 服务器提供了一个经常被询问的功能——从消息上下文中检索属性并将其包含在映射中。这种方式是通过配置它，指定要检索的属性名称，然后将其连接到目标节点来实现的；不需要输入节点。我们还没有详细讲解上下文属性，但到目前为止，请记住它们是一组包含当前消息流上下文信息的键值对；例如，接收到的消息的传输细节（例如，文件名），甚至是消息本身的属性，这些属性已经被提取。如果您想知道如何像我们之前那样在 Visual Studio 中测试它，团队也想到了这一点。在映射上提供了一个属性，上下文属性测试数据，允许您指定要执行的测试名称/值属性。对话框如图所示。在 BizTalk 服务映射中使用上下文属性的能力是一个非常受欢迎的添加。当测试映射时，也可以显示此对话框来更改使用的值。

选择映射对话框

第二个改进的领域是在表达式操作上。例如，提供了一个If-Then-Else 表达式操作。这极大地简化了测试条件的常见需求；如果它评估为真，则采取一条路径，否则采取另一条路径。在 BizTalk Server 中，这很复杂，需要很多 functoids。这突出了产品团队在这里为简化常见任务所付出的努力，正如我在本章开头提到的。对于其他逻辑操作，如逻辑 表达式也是如此。在这里，可以提供一个评估为真或假的表达式。同样，对于那些熟悉 BizTalk Server 的人来说，这个操作用简单配置和使用的单个操作替换了大量的 functoids。

另一个开始变得明显的问题是复杂性，这可以通过早期截图中的地图来参考。地图绘制者提供了页面的概念，以便在不同的页面上拆分操作和链接。你可以在设计器底部标签旁边的区域右键单击来添加新页面，如下面的截图所示：

使用页面

将地图拆分成不同的页面是在可读性和复杂性之间的一种权衡。理想情况下，你会在单页面上看到尽可能多的清晰可读的细节，以避免总是需要在不同的页面之间跳转。对于可能包含数千个链接和操作的复杂地图，这是不可能的；添加页面可以大大降低复杂性并提高清晰度，特别是对于那些需要维护解决方案的人来说。

最后一点是，正如你可能已经注意到的，新的 BizTalk Services 地图绘制器不是基于可扩展样式表语言和 XSLT（如 BizTalk Server 的那个）。然而，仍然可以在地图中包含 XSLT（仅限 1.0），这在你有现有的需要重用的 XSLT 转换时很有用。通过在设计器网格上单击并打开XSLT属性在属性窗口中访问 XSLT 属性。关于重用的话题，BizTalk Services 还提供了一个有用的工具，即 BizTalk Server 地图转换器。这会将 BizTalk Server 的.btm地图文件转换为 BizTalk Services 映射格式，当你有现有的需要重用的地图时可以节省时间，并避免从头开始的需要。由于两个之间的功能差异，它不能进行 100%的转换，但仍然是一个节省时间的巨大工具。

处理失败

开发者必须考虑的一个非常重要的问题是如何处理发生的失败。在集成解决方案中，失败尤其重要，因为它可能很难隔离和诊断。在映射中，可以配置在特定操作失败时应采取什么行动，通常是由于提供给它的数据有问题。当点击设计器顶部的设置按钮时，会显示如下截图所示的对话框。

在这里，每个操作（或在某些情况下是一组操作）都可以设置为在错误发生时失败映射，或者继续并输出一个空值。这非常有用；我们将在稍后的章节中更详细地探讨错误处理。

设置运行时属性

摘要

在本章中，我们探讨了 BizTalk 服务的映射功能。您已经看到了如何创建映射，使用许多提供的强大操作，以及如何测试它们。虽然我们没有能够涵盖每个操作，但许多都是自我解释的，易于理解；毕竟，映射器的整个目的就是使格式和内容转换的工作更加容易。我们敦促您自己进行实验，看看您能想出什么。

在下一章中，我们将探讨 BizTalk 服务提供的不同类型的桥接，从 EDI 开始。

第三章。桥梁

在第二章中，我们介绍了集成和转换的基本方面，即消息和转换。但转换只是 BizTalk 服务中桥梁提供的能力之一。在本章中，我们将更深入地探讨桥梁和以下功能：

• 管道阶段

• 验证、丰富和格式化消息

• 查找数据

• 消息路由和过滤器

• BizTalk 服务资源管理器

桥梁实际上是一个Windows Workflow Foundation（WF4）的幕后操作。虽然您不能创建自己的桥梁定义，但提供了三个模板供您使用：

类型	描述
XML 单向	调用者发送基于 XML 的消息到桥梁，并期望没有响应
XML 请求-响应	调用者发送基于 XML 的消息并等待响应消息
透传	调用者以任何格式（XML 或非 XML）的单向模式发送消息

这些模板提供了一些标准处理步骤，您可以使用它们在处理消息时对其产生影响或采取行动。这些步骤形成了一个处理管道，每个步骤依次跟随前一个步骤。每个步骤也会根据前一个步骤的消息状态及其上下文进行操作。您还有机会在本章稍后看到，添加自己的自定义管道处理。

值得记住的是，桥梁本质上是无状态的——在桥梁处理过程中没有持久化存储的内容。如果桥梁在处理过程中失败，消息可能会丢失，因此必须小心避免这种情况。我们将在本书的第七章跟踪和故障排除中更详细地讨论这个问题。

管道处理

在桥梁的管道中，有以下步骤：

阶段	方向	目的
消息类型	接收	将架构与传入的消息匹配
解码	接收	根据架构将传入的消息转换为 XML
验证	接收	根据架构确定消息是否有效
丰富	接收	从消息或上下文内容创建属性
转换	接收/发送	将消息映射到另一个消息架构格式
丰富	发送	从消息或上下文内容创建属性
编码	发送	将消息准备好进行传输

当然，对于双向和透传桥梁，事情会有所不同，正如您所期望的那样。对于双向桥梁，没有解码和解码阶段，透传桥梁只有一个阶段，即丰富。

消息处理

由于 BizTalk 服务在云中托管并公开默认 HTTP 端点给您发布的桥梁，这意味着您可以通过将消息简单发布到端点来提交消息，并且在使用请求/响应桥梁的情况下，接收响应。

当然，BizTalk 服务还提供了许多其他消息来源和目的地，例如 FTP、服务总线队列和主题，以及在第四章企业应用集成中详细说明的业务系统，如 SAP。完整的列表如下表所示：

传输	来源	目的地	描述
FTP	是	是	支持文件传输协议
SFTP	是	是	安全文件传输协议
服务总线队列	是	是	接收和发送队列中的消息
服务总线主题	是	是	接收和发送主题中的消息
HTTP(S)	是	是	默认情况下，在您创建服务的命名空间上，网关以 HTTPS 端点形式暴露。BizTalk 服务还支持 HTTP 作为目的地，允许调用 Web 服务。
Azure Blob 存储	否	是	向 Azure Blob 存储发送消息

| 中继 | 否 | 是 | 服务总线中继与 BizTalk 适配器服务一起使用，以连接以下业务系统： |

• SQL Server

• Oracle DB

• Oracle eBusiness Suite

• mySAP

• Siebel

这在第四章企业应用集成中详细说明。 |

消息传递

使用 XML 网桥，有两个阶段用于识别接收到的消息并确定如何处理那些意外的消息。为了知道什么是不预期的，网桥的消息类型部分允许指定消息模式。可以在消息类型选择器对话框中配置任意数量的模式，如图所示：

消息类型

XML 网桥的第一个阶段是解码。这仅适用于平面文件，即未作为 XML 接收且指定了平面文件模式的消息（有关平面文件模式的更多信息，请参阅第四章企业应用集成）。虽然使用 XML 网桥处理平面文件听起来很奇怪，但网桥的目的是将消息标准化为 XML 格式，因为这允许处理有用功能（如转换和增强）的统一性。这样，任何格式的数据，例如 JSON，都可以接收和处理。在解码阶段没有要配置的内容；相反，它从提供的消息类型中获取配置，并将匹配的平面文件模式应用于创建文件的 XML 表示形式。匹配基于在消息类型选择器对话框中选择的模式，如图所示。只能选择一个消息类型。

在解码阶段之后，消息将根据提供的架构进行验证。这里唯一可配置的属性是布尔设置将警告报告为错误。默认为false，这意味着未识别或无效的消息仍然会通过桥接的其余部分进行处理。将此属性设置为true将在桥接中引发错误，并且消息将不会处理。调用者（如果调用者使用 HTTP）将收到HTTP 500状态代码响应。这种通用的“服务器错误”响应通常与详细说明问题的响应一起返回，并提供一个可用于诊断原因的跟踪 ID。故障诊断和故障排除在第七章跟踪和故障排除中详细说明。如果配置的源是 FTP，则文件将留在 FTP 服务器上，桥接将在等待一段时间（这超过了重试次数）后重试最多三次。此行为目前在 WABS 中不可配置。

丰富

在桥接的以下两个点上发生丰富：在转换之前和之后。丰富阶段提供了将消息属性写入的机会，这些属性可以在任一转换（在第一个丰富阶段）或路由（转换后）中使用。消息属性仅仅是与消息本身一起移动的名称/值对，可以在丰富阶段创建。

在写入消息属性时，有多个数据源可用，以下表列出了这些数据源：

源类型	目的
Soap	访问消息的 SOAP 属性，例如 Action
Http	访问调用者发送的 HTTP 头
查找	在 Windows Azure SQL 数据库中查找值
Xpath	在消息中使用 XPath 表达式查找值
Ftp	如果源是 FTP，则访问 FTP 属性，例如文件名
Sftp	如果源是 SFTP，则访问 SFTP 属性
系统	提供访问系统属性，例如接收消息的日期/时间
中介	如果源或目的地基于队列/主题，则访问服务总线属性

使用消息属性允许桥接处理以两种主要方式受到影响和控制：

• 通过转换：从调用者接收的消息可以转换为最终接收者所需的不同格式。可以访问消息属性。

• 通过路由：我们将在稍后详细讨论这一点。消息属性可以用来将消息定向到特定的目的地。

让我们看看几个例子。在下面的图中，我们有一个配置了两个目标服务总线队列的网关，欧洲和美洲。假设我们想要创建一个属性，它包含来自消息的包含国家名称的字段值。路由网关模式如图所示：

路由网关模式

进入的消息看起来如下所示：

<ns0:Order >
  <OrderId>123</OrderId>
  <PaymentType>ACCOUNT</PaymentType>
  <OrderDate>2/9/2013</OrderDate>
  <Products>
    <Product>
      <Code>AB12</Code>
      <Qty>4</Qty>
      <Price>1.50</Price>
    </Product>
    <Product>
      <Code>AC01</Code>
      <Qty>2</Qty>
      <Price>3.99</Price>
    </Product>
    <Product>
      <Code>DE4</Code>
      <Qty>10</Qty>
      <Price>12.25</Price>
    </Product>
  </Products>
  <Customer>
    <Name>John Doe</Name>
    <Email>john.doe@contoso.com</Email>
    <Phone>425-123456</Phone>
  </Customer>
  <ShippingAddress>
    <Recipient>Jane Smith</Recipient>
    <Number>1</Number>
    <Street>East Street</Street>
    <City>New York</City>
    <State>New York</State>
    <Country>UK</Country>
    <Postcode>NY12345</Postcode>
  </ShippingAddress>
</ns0:Order>

我们可以针对此消息创建一个 XPath 属性，如下所示：

1. 在设计器中单击第一个富化阶段。

2. 在属性窗口中，双击属性定义集合省略号。

3. 在属性定义对话框中，单击添加。

4. 选择一种 XPath 类型。

5. 在标识符字段中输入以下表达式：

   /*[local-name()='Order' and namespace-uri()='http://BizTalkServicesOrderSample.Order']/*[local-name()='ShippingAddress' and namespace-uri()='']/*[local-name()='Country' and namespace-uri()='']
   

   提示

   要轻松获取 XML 架构中项的 XPath，请在架构编辑器中打开.xsd文件，选择您想要的项，然后查看属性窗口。实例 XPath属性将包含在运行时提取所需的 XPath 表达式。

6. 指定Order实例的消息类型。

7. 在属性名称字段中输入MappedCountry。

8. 将数据类型字段选择为string。

9. 单击确定。

属性定义对话框现在应该看起来像以下截图。在运行时，当网关接收到消息时，富化阶段将使用指定的 XPath 从消息中提取字段，并将国家值存储在消息属性中。

属性定义

查找

消息属性的另一种用法是与转换一起使用。在这里，一个常见的需求是转码，其中一个值需要替换为或映射到另一个值。代码表可以用于此目的，我们可以使用 BizTalk 服务的查找功能来完成此操作，然后将值输入到转换中替换消息中的值。

需要一些准备工作来设置这些内容。如果您还记得，当您配置新的 Windows Azure BizTalk 服务实例时，您可以选择创建一个新的 SQL Azure 数据库来存储服务所需的各种表。我们也可以在这个数据库中创建一个表来存储查找的转码数据。要创建一个表并向其中添加数据，请在数据库上运行以下脚本：

CREATE TABLE [dbo].CountryMap,
  [ISOCountry] [int] NULL
  CONSTRAINT [PK_CountryName] PRIMARY KEY CLUSTERED
  (
    [CountryName] ASC
  ) WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)
GO
INSERT INTO [dbo].[CountryMap] (CountryName, ISOCountry)VALUES('USA',844),('UK',826),('CANADA',124)

最简单的方法是访问Azure 管理门户并点击SQL 数据库选项卡。为您的 BizTalk 服务实例创建的数据库将使用您提供的服务名称命名，并附加_db扩展名。点击此数据库，然后点击管理。浏览器中将打开一个新窗口（或选项卡），如图所示。在此窗口中，您可以选择新建查询，粘贴前面的 SQL 代码，然后点击运行以创建表并填充一些数据。

Windows Azure SQL 查询编辑器

如属性定义对话框所示，我们可以在桥接器中通过以下步骤配置丰富阶段，就像之前一样：

1. 在第一个丰富阶段打开属性定义对话框。

2. 对于类型字段，选择查找。

3. 点击标识符字段的下拉列表，然后点击配置新…。

4. 将会显示对话框；按照以下截图所示完成它：

   提供者配置

   注意

   要获取连接字符串值，请重新登录到 Azure 管理门户，点击SQL 数据库选项卡，就像之前一样，然后点击在配置服务时创建的 WABS 数据库。点击仪表板然后点击显示连接字符串。将 ADO.NET 文本框中的值复制到该字段。

5. 点击确定以关闭对话框。

6. 对于查找属性，选择MappedCountry——这是之前由 XPath 创建的上下文属性，用作查找的输入。

7. 在属性名称字段中输入MappedCountry。

8. 在数据类型下拉菜单中选择字符串。

9. 检查以下截图所示值：

   编辑属性对话框

10. 点击确定以创建属性。

11. 最后，点击确定以关闭属性定义对话框。

现在，当接收到消息时，消息中的国家名称将在数据库中查找，并将 ISO 国家代码返回并存储在MappedCountry属性中。为了完成，我们需要添加一个转换来更新消息本身，以下是步骤：

1. 右键单击项目并选择添加 | 新建项…。

2. 在模板对话框中选择映射，并提供映射名称CountryNameToCountryCode.trfm。

3. 点击确定以创建映射。

4. 在开放映射中，点击开源模式链接。选择PO.XSD模式（来自第二章, 消息和转换）。

5. 对于开放目标模式链接也执行相同的操作。

6. 在 functoids 工具箱中，将获取上下文属性functoid 拖放到设计器中（位于杂项操作部分）。

7. 双击映射上的 functoid 以配置它。

8. 在属性名称字段中，输入MappedCountry。

9. 点击确定以关闭对话框。

10. 按住Shift键，并点击并按住左侧模式中的Order节点。在仍然按住左鼠标按钮和Shift键的同时，将鼠标拖动到右侧模式中的Order节点以连接它们。在显示的弹出窗口中，选择按名称链接。回想一下第二章，消息和转换，这个操作将映射源到目标的所有字段。

11. 最后，您需要删除左侧和右侧的Country节点之间的链接，因为您现在正在 functoid 中查找此值。

12. 地图现在应该看起来像以下截图。

    注意

    桥接器配置用户界面（UI）中存在一些限制，可能会使更改配置变得困难。值得记住的是，桥接器只是一个 XML 配置文件，以及与桥接器上每个源和目标关联的配置文件。

    例如，没有通过 UI 更改在 enrich 阶段添加的现有查找的数据库详细信息的途径。但是，要完成此操作，您只需打开LookupProviderConfigurations.xml文件并编辑连接详细信息。还应注意，连接的用户名和密码详细信息实际上存储在此文件中，因此应谨慎处理。

    

    国家代码地图

13. 需要的最后一个步骤是将地图与桥接器关联起来。双击桥接器文件以打开它（解决方案资源管理器中的MessageFlowItinerary.bcs文件）。

14. 双击SimpleBridge组件。

15. 滚动到转换阶段，并点击XML 转换框。

16. 在属性窗口中，点击地图属性旁边的省略号（…）。

17. 您刚刚创建的地图应该显示在对话框中；只需检查已选择列以启用它。

18. 点击确定。

路由

现在，让我们看看另一个常见的消息传递场景——路由。在这里，根据某些标准，消息需要发送到多个潜在端点之一。这些标准可能基于消息的属性（例如它来自哪里）或消息中的属性（例如country这样的数据项）。这种基于内容的路由可以通过 BizTalk Services 轻松实现，正如我们将看到的。

应注意，消息不能发送到多个端点。这是 BizTalk Server 能够做到的，但当前 BizTalk Services 不能。相反，BizTalk Services 允许您根据您配置的路由规则在目的地之间进行选择。

再次查看增强部分的路由桥梁模式图中的设计。注意有两个可能的终点。现在我们将配置消息流行程，以便如果Country属性是USA，则将消息路由到美洲目的地；否则，我们将路由到欧洲。为此，我们需要执行以下步骤：

1. 单击连接到美洲目的地的桥梁的箭头。

2. 在属性窗口中，单击筛选条件属性。

3. 输入 MappedCountry = '844' 或 MappedCountry = '124'。

4. 现在单击连接到欧洲目的地的箭头。

5. 在属性窗口中，单击筛选条件属性。

6. 输入 MappedCountry = '826'。

您可以通过单击桥梁并点击路由顺序表属性旁边的省略号（…）来更改路由的评估顺序。将显示一个对话框，如图所示：

更改路由顺序

通过使用上下箭头，可以更改评估顺序，以确保您想要的第一匹配条件是消息将被路由到的位置。

尝试一下

由于桥梁将消息发送到两个服务总线队列之一，您需要首先在 Azure 管理门户中创建这些队列。创建两个队列，一个名为europe，另一个名为americas。然后需要在桥梁上的每个队列目的地设置这些队列的连接信息。每个队列的运行时地址属性采用以下形式：

sb://<your namespace>.servicebus.windows.net/Europe

认证属性也需要进行配置。令牌提供者类型应设置为共享密钥，并将发行者密钥设置为您的服务总线命名空间中的 ACS 密钥。

现在您已准备好部署解决方案。按照常规方式操作，一旦部署，您将有一个 HTTPS 终端已部署，您可以将消息发送到该终端。

要将消息发送到已部署的桥梁，您可以使用 BizTalk 服务资源管理器，它提供了一些用于管理和测试解决方案的有用功能。它是 Visual Studio 的一个扩展，可以按照以下方式设置：

1. 启动 Visual Studio 2012，然后在工具菜单中选择扩展和更新…。

2. 在左上角单击在线链接，然后在搜索框中输入biztalk service explorer，如图所示：

   安装 BizTalk 服务资源管理器

3. 单击下载按钮，这将下载一个 MSI 文件。双击它以安装并重新启动 Visual Studio。

4. 在视图菜单中，选择服务器资源管理器。

5. 服务器资源管理器窗口将会有一个新节点，Windows Azure BizTalk 服务；右键单击它，并选择添加 BizTalk 服务…，如图所示：

   添加 BizTalk 服务实例

6. 在出现的对话框中，输入你的服务实例的详细信息，如图所示，用适当的值替换详细信息，然后点击确定：

   配置探索器

7. 现在你已经设置了探索器，展开桥接器节点，右键单击你刚刚部署的桥接器，然后点击发送测试消息…。

8. 在出现的对话框中，粘贴本章开头的测试消息，如图所示，然后点击发送按钮：

   测试桥接器

当你这样做时，请记住，根据你在输入消息中设置的Country值，你可以通过使用UK、USA或CANADA的值，将消息直接发送到Europe或Americas队列，如图所示在增强部分的路由桥接器模式图中。

要查看队列的内容，你可以使用可以从code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a下载的 Service Bus Explorer 应用程序。以下截图显示了包含我们刚刚发布到桥接器的消息的Europe目标队列。注意消息中的Country节点包含来自 SQL 查找表的值826，替换了原始消息中的UK值。

查看队列中的消息

尝试更改测试消息的国家为不在查找表中的国家，看看会发生什么。如果你输入一个不存在的国家，查找将失败。你实际上会收到一个 500 HTTP 响应代码，并带有 SOAP 错误消息查找未返回结果。现在尝试将查找表中的UK值更改为，比如说，123。现在会发生的情况是路由将失败，因为没有匹配到任何目的地。你将收到相同的 HTTP 500 代码，但这次带有 SOAP 错误消息没有匹配的过滤器。自己尝试实验，享受乐趣！

代理消息

如果您回顾了 增强 部分的表格，您可能会对代理属性类型感到好奇。通过桥梁流动的消息基于服务总线的 BrokeredMessage 类型（有关更多详细信息，请参阅 msdn.microsoft.com/en-us/library/microsoft.servicebus.messaging.brokeredmessage.aspx）。此类提供了一系列在 BizTalk 服务中公开的属性，如 CorrelationId、MessageId 和 SessionId。真正有趣的是，当您使用服务总线队列或主题目标时，在桥梁中创建的属性（任何属性，而不仅仅是代理属性）或当服务总线是源时在接收消息上设置的属性不仅可以在桥梁内部访问，还可以在外部访问。这对于将状态从 BizTalk 服务传递到消费队列消息的下游应用程序非常有用，因为该应用程序将能够看到您在桥梁中设置的属性。

注意，尽管这仅适用于服务总线源和目标，但如果要将一个桥梁链接到另一个桥梁，例如，您将无法传递这些属性，因为链接实际上是通过 HTTP 进行调用，从而丢失了上下文。相反，如果您希望在桥梁之间或从桥梁到另一个应用程序之间传递属性，您必须将属性写入消息头（在 HTTP 的情况下）以保留它们。然而，如果您通过服务总线进行链接，则第一个发送桥梁中设置的属性将在第二个接收桥梁中可访问。

摘要

在本章中，我们更深入地探讨了 Windows Azure BizTalk 服务的基本构建块——桥梁。我们看到了如何配置桥梁以执行一系列集成活动，以及如何执行基于内容和上下文的路由。虽然我们已经了解了桥梁的大部分功能，但在下一章中，我们将重新审视桥梁，并探讨如何使用消息检查器在桥梁的阶段上执行自定义逻辑。然后，我们将探讨如何跟踪和记录创建的消息属性（跟踪）以及如何批量发送消息。

第四章：企业应用集成

能够使应用程序相互连接以交换数据的中间件系统或服务被称为企业应用集成或 EAI。在 BizTalk Services 中，EAI 面向开发者角色，Visual Studio 是开发和部署服务的主要工具。应用程序之间的集成可以通过消息桥接实现。随着我们探讨这些概念，我们将更详细地探讨第一章中的电子商务示例。

特别是在本章中，我们将重点关注以下主题：

• 理解 Azure 中的 EAI 功能

• 理解桥接、源和目标

• 使用消息检查器理解自定义代码

• 理解混合连接

企业应用集成场景

考虑以下场景：

• Contoso 是一家电影票务公司，在多个城市的销售点终端销售票务。他们希望将终端的每日销售数据汇总到他们的 SAP 业务线系统中。在没有任何形式的中间件的情况下，POS 数据需要手动收集，并且数据需要合并并转换为与目标系统匹配的格式。使用 EAI，整个流程可以自动化，并在几分钟内通过 BizTalk Services 设置完成。

• Fabrikam 是一家软件供应商，使用 Salesforce 来管理他们的客户管道和销售订单。所有来自 Salesforce 的已批准订单都需要在他们的 ERP 系统中集中管理，如位于本地的 Oracle 系统。使用混合连接，所有连接到本地 Oracle 的连接都可以通过 BizTalk Adapter Services 进行管理。

• Northwind 是一家在线零售商，负责管理电子商务网站以供客户购买。他们还从活动公司和公司那里接收大量订单。Northwind 需要开发一个解决方案来验证订单，并将请求路由到正确的库存位置以交付商品。通过在 BizTalk Services 中使用 EAI，他们开发了一个通用解决方案来处理来自消费者的 XML 格式的采购订单以及来自活动公司的 EDI 格式的采购订单。

这些场景中的每一个都可以在 BizTalk Services 上建模为 EAI 解决方案。传入的请求（票务销售、销售订单和发票）可以是 XML 或平面文件消息，需要转换为目标业务线格式并路由到本地系统。如果目标是在本地，则使用混合连接设置中继端点。

BizTalk Services 中的 EAI

让我们更详细地查看每个概念并了解其功能。

源

源接收来自外部应用程序的消息。BizTalk Services v1 支持五个常见的开箱即用的源：SFTP、FTP、HTTP、Service Bus Queue和Service Bus Subscription。默认情况下，桥梁暴露由访问控制服务保护的 HTTPS 端点。桥梁的各种源在以下屏幕截图中显示：

桥梁的源

桥梁和 VETER 模式

桥梁由源、管道和目的地组成。管道连接两个消息系统，由一系列阶段组成，以处理从源到目的地的消息流。阶段执行解码、验证、富集、转换和路由消息。每个阶段都可以通过 Visual Studio 属性面板启用或禁用以进行部署。阶段集是固定的，并且 BizTalk Services v1 开箱即用启用VETER模式。这在上面的屏幕截图中显示：

带有 VETER 模式的桥梁

以下为 VETER 模式的阶段：

阶段	描述
验证 (V)	将传入的消息与模式进行验证
富集 (E)	使用从消息头、正文或查找中提升的属性来丰富消息（参见第三章，桥梁)
转换 (T)	将消息从一种格式映射到另一种格式（参见第二章，消息和转换)
富集 (E)	在转换后丰富新的消息
路由 (R)	路由到目标目的地之一
解码	对于平面文件处理，解码消息

目的地

目的地是管道处理后的消息提交的地方。在桥梁中，到目的地的路由基于 SQL-92 表达式语法。只有当路由规则评估为真时，消息才会发送到目的地。路由阶段也在第二章，消息和转换中解释。各种目的地在以下屏幕截图中显示：

带有桥梁的目的地

桥梁的属性

这里有一些桥梁的有趣属性：

• 状态：桥梁中的管道是无状态的，即在处理过程中不会持久化消息。如果在消息正在传输时系统崩溃或重启，则必须重新提交消息以进行处理。这也意味着消息处理是同步的。

• 错误处理：如果在消息处理过程中发生错误，则会向消息的发送者抛出异常以采取行动。由于 EAI 桥梁中没有单独的挂起端点，因此必须在客户端处理错误。

• 单向/双向：桥接器支持单向和双向通信。在单向通信的情况下，只有 HTTP 代码被传回消息的发送者。然而，在双向通信的情况下，可以发送响应消息。BizTalk 服务的双向桥接器在请求侧支持 VETER 模式，在响应侧支持 ETER 模式。响应侧的消息被认为是有效的，因为这是来自目标业务线系统或服务的。请注意，透传桥接器是单向桥接的一种特殊情况，它只有 VETER 模式的 E-R。

• 消息格式：消息可以以纯 XML、SOAP 和平文件格式发送。平文件消息只能与单向桥接一起使用。未来可能会添加其他格式，例如 JSON，但那些不同的格式在处理之前需要自定义代码将数据标准化为 XML。我们将在本章后面讨论自定义代码。

• 链式：可以通过将一个桥接器作为另一个桥接器的目标来链式多个桥接器。这可以用来通过单个桥接器集中处理消息。例如，多个桥接器可能从不同的来源抽取消息，所有这些消息都连接到单个桥接器，该桥接器将消息路由到本地端点。此外，选择性禁用阶段可以启用新的消息模式。例如，通过链式两个 VETER 桥接器可以实现 ETEVR。

混合连接

在 ERP 和本地服务上进行了 IT 投资的组织可能不会将所有 IT 资产迁移到云中。需要从云中通过混合连接连接到那些服务和资源。

BizTalk 适配器服务

BizTalk 适配器服务（BAS）是一种服务，它使运行在本地环境中的应用程序能够从云中接收数据。本地应用程序，如 ERP 和 BizTalk 服务器，可以通过使用服务总线中继实现混合连接，在企业网络之外公开。Azure 上的服务总线中继服务充当中介，客户端和本地服务可以通过它相互连接。在这种情况下，客户端是 BizTalk 服务的桥接器，而本地运行的服务是 BizTalk 适配器服务，它与 ERP 进行通信。一旦 BizTalk 适配器服务和桥接器通过服务总线中继服务进行身份验证，所有来自桥接器的消息都将转发到 BizTalk 适配器服务。

BAS 架构

以下图中展示了 BAS 架构的整体结构：

BizTalk 适配器服务架构

BizTalk Adapter 服务在客户端机器上运行，并在 IIS 中托管以处理管理操作，如端点的启动/停止以及从云到本地系统的运行时操作。有一个管理服务以及一个或多个可以通过管理服务管理的运行时服务。中继配置的元数据存储在安装期间指定的 BizTalk 服务部署的存储账户中。BizTalk Adapter 服务依赖于 BizTalk Adapter 包来连接到业务线（LOB）系统，如 Oracle DB、Oracle EBS、SAP、Siebel 和 SQL Server。

管理操作通过 Visual Studio 服务器资源管理器或通过 PowerShell 命令行进行暴露，它们都与 BAService 通信，该服务在本地机器上安装 BizTalk Adapter 服务时，在 IIS 上托管 ManagementService.svc 服务。

运行时操作按照服务总线中继进行管理，通过在 IIS 中创建新的应用程序托管 RuntimeService.svc。每个 LOB 可以创建一个新的中继或使用为另一个 LOB 配置的现有中继。当每个中继有多个 LOB 时，运行时地址中超过中继 URL 的子路径有助于将调用引导到正确的适配器。

当创建 LOB 中继时，根据用户配置，在 IIS 中使用新的或现有的应用程序作为服务宿主。生成的 WSDL 包含要中继的消息以及操作动作。INSERT、UPDATE、DELETE 和 SELECT 等操作作为以下格式的 SOAPAction 报头的一部分传递：TableOp/{Operation}/schema/Tablename。确切的 SOAP 动作字符串可以从 Visual Studio 中继配置的属性窗口中确定。

通过中继传递的每条消息都需要对 LOB 进行身份验证。身份验证凭证通过以下四种方式之一传递：

• 用户名和密码预先配置并存储在 BAS 存储中

• Active Directory 域凭证

• 包含 LOB 凭证的 SOAP 报头

• WS-Security 凭证

BAS 安装和配置

BAS 安装是 BizTalk 服务 SDK 设置的一部分。在设置过程中，需要输入 BizTalk 服务部署的 URL。此 URL 被添加到 C:\Program Files\Microsoft BizTalk Adapter Service\BAService 下的 web.config 中。在 Visual Studio 服务器资源管理器中，需要输入本地管理服务 URL 以及部署的 ACS 凭证。现在可以使用向导驱动的界面为以下每个 LOB 设置混合连接，如下所示：

Visual Studio 服务器资源管理器中的 BizTalk Adapter 服务配置

例如，设置与运行在本地主机上的 SQL Server Express 和 DemoDB 数据库的中继连接涉及以下步骤：

1. 在 服务器资源管理器 BAS 视图中，右键单击 LOB 类型 | SQL 并选择 添加 SQL 目标。

2. 在弹出向导中，阅读说明并点击 下一步。

3. 输入服务器名称、实例和目录的值（例如 localhost、SQLExpress 和 DemoDB 分别）。使用 Windows 身份验证或配置的用户名和密码，并点击 下一步。

4. 通过中继导航到 表（或 视图），选择表，并将操作选择为 插入。点击 属性 以查看生成的 WSDL。点击 下一步。

5. 当消息通过中继传递时，配置 运行时安全类型。这些是我们之前提到的四个选项。输入凭据并点击 下一步。

6. 在 指定 LOB 中继 URL 中，选择 创建新的 LOB 中继 并输入服务总线凭据。为 LOB 中继路径 和 LOB 中继子路径 输入任何名称。点击 下一步。

7. 点击 创建 以完成中继和 BAS 端点的创建。

一旦中继成功设置，每个连接将出现在相应的 LOB 类型下。

使用桥接器消费 BAS

创建新的 BizTalk 服务项目或打开现有的项目。使用桥接器使用 BAS 配置有三个部分：

1. 从服务器资源管理器中，我们现在可以右键单击之前配置的中继连接，并选择 将架构添加到项目。将发送和接收目标 LOB 的相关架构添加到项目中。这些可以在桥接器内部用于映射和验证目的。

2. 将服务器资源管理器中的连接从服务器资源管理器拖放到桥接器设计表面上。这将创建必要的图标，以便从桥接器添加目标连接。

3. 点击中继连接，在 Visual Studio 属性窗口中导航到 操作 字段。展开视图，并记下每个索引 [0]、[1] 右侧的值。这些值都是 SOAP 动作值。要添加此值，转到 VS 属性中的路由操作，并启动 路由操作 窗口。点击 添加，在 编辑路由操作 弹出窗口中，输入之前复制的 SOAP 动作值。选择 类型 为 Soap 和 标识符 为 Action。点击 确定 以接受更改。

EAI 中的自定义代码

现在我们已经了解了混合连接，让我们看看桥接器的另一个功能，即支持自定义代码。BizTalk 服务不会提供所有功能。自定义允许开发者插入新的功能，以增强现有的消息流。例如，我们可以选择将传入的发票 XML 转换为用户可读的 PDF 格式，以及出于法律原因存档。

在桥梁中可以在阶段级别、路由配置或转换中进行定制。转换及其定制已在第二章，消息和转换中介绍。在本节中，我们将查看桥梁定制。

消息检查器

消息检查器是桥梁中每个阶段进入或退出的自定义代码钩子。自定义代码必须实现IMessageInspector接口：

public interface IMessageInspector
{
Task Execute(IMessage message, IMessageInspectorContext context);
}

消息检查器使用.NET4 任务并行库中的 Task 编程模型实现。可以使用IMessageInspectorContext接口中的ITracer接口在自定义代码中发出跟踪。

public interface ITracer
{
void TraceEvent(TraceEventType eventType, string format, params object[] args);
}

注意

在开发自定义代码时，以下是一些关键点要记住：

• 预期用户代码具有弹性，但在某些情况下可能会抛出异常。在这种情况下，这被视为阶段级失败，并生成相应的跟踪记录。

• VS 项目中的用户代码必须引用Microsoft.BizTalk.Services.dll，该文件位于C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\ide\Extensions。

• 用户代码组件必须在 BizTalk 服务项目中添加为引用，并将Copy Local设置为 true。

• 当用户代码组件在 BizTalk 服务中部署时，必须重新启动服务，因为 DLL 需要在.NET AppDomain 中重新加载。重启选项在 VS 部署和 PS cmdlet 中可用。

• 桥梁的工件，如架构或映射，在用户代码中不可访问。

• 可以在自定义代码中定义和提升属性。在代码中，它们必须是具有 C#属性PipelinePropertyAttribute并设置Name属性的字符串属性。此属性在 VS 属性配置中的消息检查器配置窗口中设置，如配置桥梁部分中带有桥梁的自定义代码配置图所示。

跟踪

跟踪有助于在跟踪存储中存储消息的有趣属性。跟踪存储是在 BizTalk 服务配置期间配置的 Azure SQL 数据库。所有消息属性都存储在PipelineTrackRecords和SourceTrackRecords表中。跟踪故障排除的详细信息请参阅第七章，跟踪和故障排除。

要在 EAI 桥梁上启用跟踪，请在 VS 中选择桥梁，并在属性窗口中选择跟踪属性。跟踪的属性可以在 BizTalk 服务门户的跟踪视图中看到。

配置桥梁跟踪属性

场景演练

让我们回顾一下带有以下更改的 EAI 场景。

Northwind 是一家在线零售商，管理着客户购买的电子商务网站。而不是处理订单，假设他们现在从供应商那里收到销售商品的发票。为了可读性和法规原因，他们需要将此存储在本地系统中的 PDF 格式。

注意

假设 BizTalk Services SDK 已安装，并且 Visual Studio 显示以下项目：

• BizTalk Service 项目：创建/部署桥接器、架构和映射

• BizTalk Service 艺术品项目：创建/部署架构和映射

先决条件

Northwind 创建一个新的 BizTalk Services 部署。参见第一章，欢迎使用 BizTalk Services，了解创建 BizTalk Services 部署和注册 BizTalk 门户。我们将使用来自 pdftemplate.codeplex.com 的 PDFTemplate 工具来生成 PDF 格式的发票消息。此实用程序可在 GPLv2 许可下使用。

解决方案

该解决方案将接收发票 XML 并在 blob 存储中生成 PDF。要开始，让我们首先创建架构，添加生成 PDF 的代码，最后将该逻辑插入到桥接器配置中。

创建架构

为传入的消息创建一个示例架构。本流程中使用的示例与此章节一起提供。执行以下步骤：

1. 使用 Visual Studio 架构编辑器，为发票创建一个简单的架构，称为 InvoiceSchema.xsd。

2. 从 Visual Studio 命令提示符运行以下命令以为此 xsd 生成 InvoiceSchema.cs：

   xsd InvoiceSchema.xsd /classes
   

3. 我们将在下一步中加载此 InvoiceSchema.cs 文件。

创建自定义代码

现在让我们添加用于生成我们刚刚创建的发票的 PDF 的自定义代码：

1. 创建一个 C# 类库项目，并将对 Microsoft.BizTalk.Services.dll 和 PDF 依赖项的引用添加到项目中。

2. 实现 IMessageInspector 接口的一个类。在示例中，我们将消息体提取到 Order 消息对象中，如下所示：

   string bodystr = GetMessageBody(message);
   Order order = DeserializeMessageToOrder(bodystr);
   

3. PDFGenerator 以 layout.xml 中所需的格式描述 PDF 结构，该格式由 codeplex 工具要求。XML 本身作为嵌入资源传递在自定义代码 DLL 中，必须在使用前提取，如下面的代码片段所示：

   Stream stream = System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceStream("layout.xml");
   byte[] bytes = new byte[(int)stream.Length];
   stream.Read(bytes, 0, bytes.Length);
   File.WriteAllBytes(System.IO.Path.GetTempPath(), bytes);
   

4. 使用来自 Order 对象的数据填写 PDF 文件的标题、正文、循环和页脚数据。使用以下代码片段中显示的信息使用 PDFGenerator：

   PDFTemplateItextSharp pdfgen = new PDFTemplateItextSharp(xmlToPdfTemplateFilePath);
   pdfgen.Draw(GetHeaderData(order), GetLoopData(order), GetBodyData(), GetFooterData());
   

5. 将 PDF 数据写回以下代码片段中显示的新消息：

   message.Data = new System.IO.MemoryStream(pdfdata);
   message.ContentType = new System.Net.Mime.ContentType("text/plain");
   

6. 对项目的输出程序集进行签名。请注意，所有 DLL 依赖项都需要签名。

配置桥接器

执行以下步骤以配置桥接器：

1. 在同一解决方案中添加 BizTalk Services 项目，并将对已签名自定义代码的引用添加到项目中。

2. 添加一个桥梁，在这种情况下，一个透传桥梁，并将其命名为 Invoice2PDF。同时将消息的路由添加到 Windows Azure 块存储目的地。以下图所示为PDFArchiveBlobs：

   BizTalk 服务项目中的 Invoice2PDF 桥梁示例

3. 在桥梁属性中填写所需字段。对于桥梁，添加 BizTalk 服务运行时地址和路由表值。对于块，添加共享访问签名 URL。点击桥梁，并从属性窗口中，在桥梁窗口上打开跟踪属性以启用跟踪。

4. 获取此自定义代码的全限定程序集名称。如果指定不正确，部署期间将出现错误。您可以使用 MSDN 代码库中的GetAssemblyQualifiedTypeName示例，code.msdn.microsoft.com/windowsazure/Windows-Azure-BizTalk-EAI-56915d1c/view/SourceCode，或者运行 sn -T 在 DLL 上以确定公钥并确定全限定名称。它应该看起来像这样：

   PDFGenerator.PDFGeneratorUtil, PDFGenerator, Version=1.0.0.0, Culture=neutral, PublicKeyToken=xxxxxxxxxx
   

5. 双击透传桥梁并点击 enrich 阶段。从属性窗口中，点击退出消息检查器并在指定自定义代码检查器弹出窗口中添加全限定名称，如图所示：

   使用桥梁进行自定义代码配置

部署桥梁

现在我们可以按照以下步骤将桥梁部署到 BizTalk 服务部署中：

1. 启动 VS 并从构建菜单中选择部署命令，并输入 BizTalk 服务部署详细信息。

2. 如果项目部署多次，需要勾选部署后刷新服务复选框，以便更新自定义代码 DLL 被拾取。

VS 输出块将与以下所示类似：

VS 桥梁部署输出

发送消息

使用 MSDN 代码库示例中的 Message Sender 工具向桥梁发送消息，或者你也可以下载 BizTalk 服务探索插件用于 VS 服务器资源管理器。这允许你探索部署并发送测试消息。

一旦消息成功发送，转到具有 SAS URL 的容器并本地保存块。将文件重命名为.PDF扩展名，你应该能够查看存档的 PDF 文件。

查看跟踪数据

点击 BizTalk 服务门户导航栏中的跟踪视图以查看桥梁上消息流的状态。也可以从 VS 中的 BizTalk 服务探索器按桥梁基础查看此信息。

摘要

在本章中，我们首先介绍了 Azure 上 EAI 的基本概念，特别是桥梁、源、目标、混合连接和自定义代码。我们通过一个简单的场景在 BizTalk 服务中生成 PDF 发票并在 Blob 存储中归档进行了演示。在使用桥梁中的自定义代码时可能会遇到错误。我们将在第七章 跟踪和故障排除中介绍故障排除的各个方面。

在下一章中，我们将探讨 BizTalk 服务支持的另一个关键场景——利用 B2B 功能实现跨企业集成。

第五章：商业对商业集成

在买卖关系的两个公司之间的交易是商业对商业（B2B），而不是公司与消费者之间的 B2C 关系。在集成的背景下，B2B 是关于两个组织就一系列定义良好的交易达成一致，以交换商业信息。B2B 过程从商业谈判或协议开始，这进一步转化为消息流层面的技术细节。

在本章中，我们将重点关注以下主题：

• 在 Azure 的背景下理解 B2B 集成

• 理解与合作伙伴、协议、批处理和跟踪相关的服务能力

• 使用 Azure 上的 BizTalk 服务进行真实世界 B2B 场景的演练

B2B 基本概念

考虑一个零售商 Contoso，他希望从供应商 Northwind 那里采购库存。从技术角度来看，Contoso 和 Northwind 之间的消息流可以用以下流程来解释：

• Contoso 和 Northwind 同意建立商业关系（通常通过电话/电子邮件/会议）。双方的法律团队起草合作伙伴之间的谅解备忘录（MoU）。

• 合作伙伴交换有关如何接收/发送付款的信息，包括支票和银行详情。

• 双方合作伙伴进入一个设置阶段，其中每个 IT 部门都配置 B2B 系统以启用电子数据交换（EDI）的交换。

• 双方交换样本测试消息以验证配置，并在充分测试后，他们同意进入生产阶段。

• 在生产中，执行以下步骤：

  • Contoso 从他们的 Dynamics AX ERP 系统中发起采购订单并将其发送给 Northwind

  • Northwind 收到订单并确认已收到订单

  • Northwind 处理订单并在他们的 SAP ERP 系统中查找库存，以确定他们是否可以满足请求

  • 如果订单可以服务，Northwind 将货物发送给第三方物流公司（3PL），该公司负责货物的运输

  • Northwind 向 Contoso 回复运输详情

  • Contoso 可以选择确认收货通知

  • Northwind 向 Contoso 发送发票，以收取销售商品的成本

• 根据双方商定的财务条款，Contoso 向 Northwind 支付款项。

上述流程可以如下直观表示：

前一图中的每个箭头代表 Contoso 和 Northwind 之间交换的一组消息。每种消息类型由一个文档名称或事务集（例如，PO/X12 850）标识，并基于所使用的协议具有定义的格式。除了消息的结构外，协议还规定了来回交换的消息集。在前面的例子中，我们可以将第一个交易写为“Contoso 向 Northwind 提出 EDI X12 采购订单（850）”。在这里，X12 是 EDI 格式，850 是采购订单消息类型。

常见交互模型

B2B 集成交易伙伴有两种常见方式。如下列出。

直接企业集成

在此模型中，两个交易伙伴组织都有内部 IT，可以直接进行 EDI 消息交易。有系统用于通过点对点协议发送和接收 EDI 交易，无需任何中介或中间人。

服务提供商集成

在此模型中，一个交易伙伴是一个无法承担内部 IT 服务的小到中型企业玩家。为了促进 EDI 交互，存在一个中间人，或称 EDI 服务提供商，作为两个合作伙伴之间的联络人。服务提供商向一端的交易伙伴介绍 EDI，并与另一端的交易伙伴进行非 EDI（如 XLS/XML）交易。服务提供商根据交易规模/数量或协议的复杂性收取费用。

增值网络（VANs）是提供端到端 B2B 服务的专业网络，在服务提供商集成中发挥作用。VANs 管理服务器的托管和软件以处理 EDI 流量，通常根据消息量收费。它们可以为特定垂直领域提供专业解决方案或提供通用消息处理服务。

行业标准和协议

不同的组织为不同的行业垂直领域定义协议。每个协议都规定了交易伙伴之间交换的消息集、传输的确认和错误行为。

以下是一些 BizTalk 今天支持的最常见的协议及其支持的标准组织：

标准机构	网站	协议	行业
ANSI ASC X12	www.x12.org/	X12	在美国：制造业，零售业，政府和交通
		HIPAA	医疗保健，保险
UN/CEFACT	www.unece.org/cefact/edifactwww.gefeg.com/jswg/	UN/ EDIFACT	在欧洲：制造业，零售业，政府和交通
SWIFT	www.swift.com	SWIFT	财务，贸易和银行交易
RosettaNet	www.rosettanet.org/	RosettaNet	供应链
OAGi	www.oagi.org	CIDX	多个垂直领域的水平框架
PIDX	www.pidx.org/	PIDX	石油和天然气
HL7	www.hl7.org/	HL7	医疗保健

X12 在美国被广泛使用，而 EDIFACT 在欧洲和亚洲国家更受欢迎。这两种协议今天都支持在 BizTalk 服务中。其余的协议可在 BizTalk 服务器中找到。

BizTalk 服务 B2B 中的概念

BizTalk 服务中的 B2B 主要是处理交易伙伴之间的 EDI 和非 EDI 消息。它旨在使用 Azure 使 B2B 集成简单、强大和灵活。由于协议、格式和传输的性质，B2B 往往在配置上很复杂；使用 Azure，合作伙伴之间协议的服务配置变得简单。扩展服务并与 SharePoint 和移动服务等其他技术连接变得容易，以构建丰富而强大的解决方案。

B2B/EDI 中的顶级概念包括以下内容：

• EDI 消息结构

• 合作伙伴和协议

• EDI 中的属性提升

• 批处理

• 跟踪和归档

• 扩展性和对象模型 API

EDI 消息结构

EDI 消息（无论是 X12 还是 EDIFACT）具有嵌套结构，将交易分块以便接收者易于理解。每个结构都有一个头部和尾部来标识嵌套结构的开始和结束。以下概述了嵌套结构：

• 交换：这是最外层的封装，包含头部和尾部。它标识了消息的发送者和接收者，以及消息发送的日期/时间。在 X12 的情况下，ISA 和 IEA 分别是头部和尾部；在 EDIFACT 中，UNB 和 UNZ 形成头部和尾部。

• 组：交换中的组段是一组根据其功能组合的交易。组以头部开始（X12 中的 GS 和 EDIFACT 中的 UNG），以尾部结束（X12 中的 GE 和 EDIFACT 中的 UNE）。与 X12 不同，EDIFACT 中的组是可选的；但是当存在组时，它们必须包含相同类型的所有交易（例如，所有采购订单）。

• 交易集：组中的交易集是给定类型的消息（例如，采购订单消息），其中包含详细交易的段，如项目数量或价格。交易集以头部开始（X12 中的 ST 和 EDIFACT 中的 UNH），以尾部结束（X12 中的 SE 和 EDIFACT 中的 UNT）。

下表说明了 X12 和 EDIFACT 的头部和尾部：

X12 头部和尾部	EDIFACT 头部和尾部
ISA 交换控制头部	UNA 可选建议
GS 功能组头部	UNB 交换控制头部
ST 交易集头部	UNG 功能组头部
SE 交易集尾部	UNH 消息头部
GE 功能组尾部	UNT 消息尾部
IEA 交换控制尾	UNE 功能组尾
	UNZ 交换控制尾

合作伙伴和协议

在协议中使用的关键概念如下：

• 合作伙伴：合作伙伴是与之建立贸易关系的组织。每个合作伙伴有一个或多个称为业务配置文件的业务单元。每个业务配置文件都有一个标识符（例如，DUNS ID 或电话号码），它是唯一的，并添加到合作伙伴之间交换的每条消息中。

• 协议：协议表示合作伙伴之间消息交换的技术设置。协议是在合作伙伴的两个业务配置文件之间建立的。协议由发送设置（Contoso 的发送，Northwind 的接收）和接收设置（Contoso 的接收和 Northwind 的发送）组成，这些设置在贸易伙伴关系中。协议基于消息要求引用一个协议，如 AS2、X12、EDIFACT 等。协议还确定了跟踪和批处理周围的模式和需求。协议的部署导致两个网桥部署，因此，Azure 中的端点可以接收 EDI 消息并发送 XML，反之亦然。BizTalk 门户中的协议定义具有以下内容：

  • 传输：这是网桥的发送端或接收端传输。

  • 协议：这是网桥中使用的 EDI 协议。

  • 转换：这些是在消息在网桥中处理时使用的映射。

  • 路由：这是网桥将消息路由到消息接收者的目标目的地。

  • 入站 URI：这是接收要发送到目标合作伙伴的消息的发送端网桥的地址。

  • 挂起端点：这是在处理 EDI 消息时出现错误时将处理消息的端点。此端点可用于构建修复-重新提交场景。

• 伙伴关系：至少有一个协议在合作伙伴之间构成伙伴关系。伙伴关系的概念仅通过贸易伙伴管理 API 公开。

• 协议模板：协议模板是一个可重用单元，其中可以捕获常用设置作为模板，并在定义协议时应用，以实现快速配置。协议模板与配置文件相关联。每个模板定义都确定了在定义中指定的托管合作伙伴，以确定在创建协议时应用设置的方向。

• AS2 协议：AS2 协议是指两个遵守 RFC 4130 标准的合作伙伴之间同意的 AS2 传输设置。简而言之，AS2 允许以压缩、签名或加密的形式通过 HTTP 或 HTTPS 传输消息和确认。使用证书支持签名和加密。AS2 不特定于有效负载，可用于 B2B 平面文件和 EAI XML 消息。

  注意

  如果一方（例如合作伙伴 A）的端点需要 HTTPS 进行 AS2 流量，那么合作伙伴 A 的部署证书需要添加到合作伙伴 B 的“受信任人员”证书存储中。或者，如果合作伙伴 A 的 AS2 消息发送到合作伙伴 B 的 HTTPS 端点，那么合作伙伴 B 的公共证书需要添加到合作伙伴 A 的部署证书存储中。这两个证书都需要使用从 BizTalk 服务工具加载的PSCmdlet上传到 BizTalk 服务部署证书存储中。以下是使用 PowerShell 添加证书的示例代码：

  PS C:\>Import-Module 'C:\Program Files\Windows Azure BizTalk Services Tools\Microsoft.BizTalk.Services.PowerShell.dll'
  PS C:\>Add-AzureBizTalkArtifactCertificate –AcsNamespace myAcs –IssuerName owner –IssuerKey 193194218484a= -FilePath D:\sample.cer –ArtifactPath /sample.cer –certificateStore TrustedPeople
  

  如果使用makecert.exe生成自签名证书，请确保将–pe和–key交换参数传递给命令，以便证书可导出并可用于加密目的。

• X12 和 EDIFACT 协议：BizTalk 服务支持 X12 和 EDIFACT。协议的选择在创建协议时通过组合框选择可用。对于每个应用程序协议，协议设置包括一系列模式选择、确认配置、控制号配置、批处理、字符集和分隔符配置以及消息验证配置。

属性提升

我们之前讨论的 EDI 信封中的某些属性是自动提升的，并且可用于路由和跟踪场景。它们也可以用于程序化地确定协议端点。

以下表格列出了 EDI 和 AS2 中的提升属性：

属性	位置	描述
消息类型	X12 接收	标识消息类型的数值，例如，850 采购订单，810 发票
协议名称	X12 接收	协议名称
ISA 5-8ISA 9, 10, 12, 15	X12 接收	X12 ISA 信封
GS01-08	X12 接收	X12 GS 信封
ST01	X12 接收	X12 事务集消息类型
ST03	X12 接收	X12 事务集版本
AS2-到，AS2 版本，Mime 版本，AS2-从	AS2 发送/接收	AS2 头属性
内容 ID，内容类型，内容传输编码
处置通知到，处置通知选项
内容描述，内容处置，收据投递选项
系统请求 ID	X12 发送，X12 接收，AS2 接收	在桥接中跟踪消息流的 ID
消息接收时间	X12 发送，X12 接收，AS2 接收	来消息的日期和时间
源类型	X12 发送，X12 接收，AS2 接收	根据配置的 FTP，HTTP 或 AS2
源名称	X12 发送，X12 接收，AS2 接收	配置的源名称；这是 EDI 协议中自动生成的名称
协议 ID	X12 发送，X12 接收，AS2 接收	在 BizTalk 门户的协议列表视图中显示的协议 ID
UNA 段	EDIFACT 接收	使用字符作为分隔符和指示符的 UNA 段
UNB_Segment	EDIFACT 接收	交换头段
UNB2_1	EDIFACT 接收	发送者标识
UNB2_2	EDIFACT 接收	发送者代码限定符
UNB2_3	EDIFACT 接收	发送者反向路由地址
UNB3_1	EDIFACT 接收	接收者标识
UNB3_2	EDIFACT 接收	接收者代码限定符
UNB11	EDIFACT 接收	测试指示器
UNG_Segment	EDIFACT 接收	功能组头段
UNG1	EDIFACT 接收	功能组标识符
UNG2_1	EDIFACT 接收	群组应用发送者标识符
UNG3_1	EDIFACT 接收	群组应用接收者标识符
UNH2_1	EDIFACT 接收	消息类型标识符
UNH2_2	EDIFACT 接收	消息类型版本号
UNH2_3	EDIFACT 接收	消息类型发布号

备注

AS2 发送是将消息发送给合作伙伴；因此，属性不能直接使用。在 X12 发送的情况下，我们可以将消息路由到 blob 存储或服务总线队列，并基于提升的属性采取行动。

批处理

批处理是一种基于选择标准累积消息的概念，一旦满足称为发布标准的所需事件，就会发布。客户使用批处理消息以成本、兼容性和便利性为由聚合消息。在 VAN 的早期，消息按大小计费，客户通过发送消息批次进行优化。例如，航空公司对所有集装箱收取相同的费用，无论它们包含 2000 公斤还是 5000 公斤。货运代理人将来自多个装运的请求批处理到单个集装箱中以节省成本是有意义的。一些贸易伙伴的主机系统无法接受超过 250 KB 的消息。在将它们发送到目标系统之前，重要的是将这些消息拆分成小于或等于 250 KB 的大小。

作为 BizTalk 服务 B2B 的一部分，客户可以在协议的发送端配置中配置和管理批次（解批处理已作为系统的一部分，因为交换格式是隐式已知的）。一个协议可以包含零个或多个批次定义。每个批次都有一个状态——它可以被启用、禁用或出错。当相应的协议部署或显式使用启动命令时，批次被启用。当批次停止时，批次中的消息将被刷新。每个批次定义都包含选择和发布标准。

选择标准

选择标准用于选择要批处理的消息。在 BizTalk 服务中，客户可以提升属性并在表达式中使用它们来选择要添加到一个或多个批次的消息。如果传入批次的属性与多个定义匹配，则消息将复制到这些批次中。

发布标准

发布标准决定了批次何时应该发布。以下可以使用作为发布标准之一：

发布标准	描述
大小	消息的最大大小（不包括交换和组），以 UTF-8 编码的字节为单位
计数	批处理消息中事务集的数量
计划	配置释放消息的周期性发生和重复值
超时	批次需要释放时的消息间空闲超时
交换大小和计划	交换大小或基于计划
交换大小和超时	交换大小或配置的超时
消息计数和计划	计数或基于计划
消息计数和超时	计数或配置的超时
交换大小和消息计数	交换大小或计数

当满足释放标准或从 BizTalk 门户停止批次时，将释放批次的消息。如果满足释放标准但批次中没有消息，则不会向发送端点发送空消息。如果批次释放消息时发送端点不可用，则消息将传递到挂起端点。在最坏的情况下，如果挂起端点在重试后仍然不可用，则未批处理的事务集将保留在系统中，并在下次可用时释放到挂起端点。此外，请注意，要删除协议，协议中定义的批次不得有任何消息。

跟踪和归档

跟踪有助于在消息中存储有趣的属性并在存储中归档消息。跟踪和归档都是作为协议配置的一部分启用的设置。在 B2B 的情况下，系统和用户推广的属性被跟踪并写入 Azure SQL 跟踪数据库。除了消息外，系统还跟踪与消息可以关联的确认属性。这将使用户知道 X12 是否收到了技术或功能确认，以及 AS2 消息是否收到了其 MDN NACK 或 ACK 消息。跟踪识别了当前在批次中持有的消息列表以及活动的批次列表。它还识别了在发送端发送的批次的历史记录。

如以下图所示，X12 和 AS2 支持以下情况下的归档：

• 在发送消息之前

• 在接收到消息后立即

归档在协议中的常规设置部分进行配置。可以通过点击相关的消息条目并选择详细信息从 BizTalk 门户的跟踪视图选项访问消息。从消息信息弹出视图，您可以选择要下载的实体并点击下载选项。

不可抵赖性

在 AS2 中，不可抵赖性收据（NRR）通过跟踪和归档两种方式支持。在争议解决场景中需要 NRR，例如，供应商可能不会处理采购订单或声称未收到订单或付款。NRR 确保存储 AS2 消息，并对传入的消息完整性检查（MIC）值或哈希码与存储的 AS2 消息的 MIC 进行验证。这验证了另一合作伙伴确实已接收并处理了该消息。如果启用了 NRR 选项，并且跟踪或归档失败，则消息处理也会失败（与未启用 NRR 的情况不同，即使存在跟踪错误，消息处理也可以继续）。要启用 NRR，请在 AS2 协议的 常规设置 页面上检查 启用 NRR 选项，如图所示：

可扩展性

通过使用 贸易伙伴管理对象模型（TPM OM）的公共 API，在 B2B 中实现可扩展性。我们将作为 BizTalk 服务中 API 的整体可扩展性的一部分介绍 TPM OM。

场景演练

让我们回顾本章开始时的场景；我们将添加一个服务提供商来阐述这些概念。正如我们所知，服务提供商是 EDI 的专家，将作为中间人帮助供应商连接到大型零售商。在这个例子中，大型零售商 Contoso 希望从供应商 Northwind 采购库存。由于 Northwind 不了解 EDI，他们向服务提供商 Fabrikam 寻求帮助，以帮助他们与零售商 Contoso 连接。

生态系统参与者

在我们的示例中，有三个参与者。Contoso 是一家大型零售商，Northwind 是连接到 Contoso 的供应商，最后，Fabrikam 是为 Northwind 提供 EDI 服务的 EDI 服务提供商。

配置 BizTalk 服务

Fabrikam 创建一个新的 BizTalk 服务部署。请参阅第一章，Hello BizTalk 服务，了解创建 BizTalk 服务部署和注册 BizTalk 服务门户。

Fabrikam 将 Northwind 的管理员电子邮件 ID 添加为 BizTalk 服务门户设置页面上的注册用户。这允许 Northwind 用户登录到与 Fabrikam 相同的视图。

配置合作伙伴 – Fabrikam、Northwind 和 Contoso

我们需要在 BizTalk 服务中配置贸易伙伴和协议。以下步骤需要 Fabrikam 执行以添加合作伙伴：

1. 登录后，点击 合作伙伴 页面，然后点击 添加 按钮。

2. 将 合作伙伴名称 输入为 Northwind。

3. 如果需要，请输入 名字、姓氏、电子邮件 ID 和 电话 详细信息。

4. 点击 保存。

5. 对 Contoso 和 Fabrikam 作为合作伙伴名称重复以上步骤。

6. 点击每个合作伙伴，导航到默认配置文件，并上传 AS2 签名和加密的证书。

新合作伙伴的创建如图所示：

配置 Fabrikam 和 Contoso 之间的 AS2 协议

一旦创建了合作伙伴，我们需要添加协议。以下步骤需要执行以添加 Fabrikam 和 Contoso 之间的 AS2 协议：

1. 点击左侧导航栏中的AGREEMENTS。

2. 点击AS2选项卡。

3. 点击添加。

4. 在新协议（AS2）页面中，将协议名称填写为Fabrikam-Contoso 协议并添加一个描述。

5. 将Fabrikam选为托管合作伙伴，将Contoso选为访客合作伙伴。在这里，托管合作伙伴是拥有 BizTalk 服务的桥的合作伙伴。在这种情况下，Fabrikam拥有 BizTalk 服务的部署，因此是托管合作伙伴。

6. 将Fabrikam的AS2 身份输入为fabrikam，将Contoso的输入为contoso。

7. 启用跟踪和存档；后者适用于高级 SKU。

8. 点击继续。

9. 页面现在重命名为Fabrikam-Contoso 协议，你处于接收设置页面。

10. 以下是配置接收设置的步骤：

    • 在入站 URL下，将URL 后缀设置为endpoint1并记下完整的 URL。这是Fabrikam从Contoso接收消息的地方。

    • 在协议下，打开消息并选择消息应签名或消息应加密（如有适用）。请注意，这两个选项都需要你在 Contoso 和 Fabrikam 的配置文件页面中添加证书。此外，如果需要，设置确认并选择发送 MDN。

11. 点击发送设置：

    • 入站 URL是Fabrikam发送消息以到达Contoso的位置。URL 中的<协议 ID>将在协议部署后填写。入站指的是从Fabrikam系统发送消息到Contoso通过 AS2 的端点。

    • 在协议下，类似于发送设置，如果需要，配置签名和加密选项。此外，设置确认并选择请求 MDN（你可以不勾选其他两个复选框）。

    • 在传输下，输入Contoso端点的 URL。你可以创建一个 BizTalk 服务器或 BizTalk 服务设置，以模拟合作伙伴的另一端，或者简单地保留默认 URL www.microsoft.com。请注意，需要http前缀。

12. 点击部署。你应该在门户中看到以下消息：

配置 Northwind 和 Contoso 之间的 X12 协议

与 AS2 协议类似，我们现在需要配置 Northwind 和 Contoso 之间的 X12 协议。以下步骤需要执行：

1. 点击左侧导航栏中的AGREEMENTS。

2. 这次点击EDI；（0）表示没有 X12 或 EDIFACT 协议。

3. 点击添加。

4. 在新协议选项中，选择协议为X12，并将协议名称填写为Northwind-Contoso agreement，同时添加描述。您还可以创建 EDIFACT 协议。接下来的步骤将配置特定的 X12 设置。

5. 选择托管合作伙伴为Northwind和来宾合作伙伴为Contoso。在这里，托管合作伙伴是直接/间接拥有 BizTalk 服务中桥的合作伙伴。

6. 选择限定符为ZZ - 互相定义（X12），并为 Northwind 输入值为northwind，为 Contoso 输入值为contoso。

7. 在双方启用跟踪和存档；后者适用于高级 SKU。

8. 点击继续。

9. 页面现在已重命名为Fabrikam-Contoso agreement，您现在处于接收设置。

10. 以下是为配置接收设置的步骤：

    • 在传输下，选择传输类型为AS2和AS2 协议为Fabrikam-Contoso agreement。这意味着所有来自 X12 协议的消息都将通过之前配置的 AS2 通道接收。将来，Fabrikam可以创建多个此类 X12 协议，并重用相同的 AS2 协议来连接零售商Contoso。这是可能的，因为只有供应商之间的 X12 配置发生变化，而Fabrikam对Contoso的连接基本上是恒定的。

    • 在协议下，选择预期 TA1和预期 997。假设您已从 BizTalk 服务下载页面下载了 B2B 架构，请点击上传并依次添加X12_00401_810.xsd和X12_00401_850.xsd。它们将在上传后列出，如下面的截图所示：

    

11. 目前保留转换设置不变。

12. 在路由下，点击添加以添加成功路由规则：

    • 输入规则名称为default。

    • 点击高级设置并在表达式窗口中输入1=1。这意味着我们将将所有成功消息路由到该端点。

    • 选择传输类型为Azure Service Bus。

    • 选择路由目标类型为BasicHttpRelay。添加BasicHttpRelay URL、发行者名称和发行者密钥。这是 BasicHttpRelay 服务将监听从该协议路由的成功消息的 URL。

    • 点击保存。

13. 添加消息挂起设置。挂起设置指的是如果消息未能成功到达 Northwind，将引用的目标 URL。我们可以使用队列、主题或中继配置 Azure Service Bus。队列和主题需要使用共享访问签名或发行者名称和密钥预先创建：

    • 选择传输类型为Azure Service Bus。

    • 选择路由目标类型为BasicHttpRelay。添加BasicHttpRelay URL、发行者名称和发行者密钥。这是 BasicHttpRelay 服务将监听来自此协议的失败消息的 URL。

    • 点击保存。

14. 点击发送设置：

    • 在入站 URL下，注意端点值——在协议部署后，URL 中的<协议-ID>将被更新。我们稍后会回到这个视图。

    • 目前请保持发送端的转换设置不变。

    • 在批量下，您可以配置发送消息批而不是单个消息。

    • 点击添加批量，输入3 条消息的批量作为名称，并添加描述。点击下一步。

    • 在批量标准中，选择使用高级定义，并在文本框中输入1=1。这表示所有消息都将批量处理。点击下一步。

    • 在批量发布标准中，选择基于消息计数，并将计数的值输入为3。

    • 点击下一步，最后，保存。

    • 您无需点击开始批量处理；一旦部署了协议，批量处理将自动启动。

15. 在协议下，选择预期 TA1和预期 997。此外，在模式部分下点击+符号，并从模式下拉菜单中选择现有的X12_00401_810.xsd选项。如果之前在接收设置部分已上传，它应该已经列出来了。

16. 在传输下，填写传输设置和消息挂起设置。在传输下，选择传输类型为AS2，并将AS2 协议选为Fabrikam-Contoso 协议。这意味着所有来自 X12 协议的消息都将发送到之前配置的 AS2 通道。

17. 添加消息挂起设置。挂起设置指的是如果消息未能到达 Contoso，将引用的目标 URL。我们可以使用队列、主题或中继配置 Azure 服务总线。队列和主题需要使用共享访问签名或发行者名称和密钥预先创建。在这种情况下，我们配置了一个使用 BasicHttpRelay 绑定的服务：

    • 选择传输类型为Azure 服务总线。

    • 选择路由目标类型为BasicHttpRelay。

    • 添加BasicHttpRelay URL、发行者名称和发行者密钥。这是 BasicHttpRelay 服务将监听无法发送到Contoso的消息的 URL。

18. 点击部署：

    • 应显示一条成功消息，“Northwind 和 Contoso 之间的协议已成功部署”。如果没有显示，请检查错误并再次点击部署。

    • 导航到协议的发送设置页面，并记下入站 URL值。这将用于向协议发送消息。

发送消息

Web 发送器是 MSDN 代码库中 BizTalk 服务示例中可用的一种工具。它可以用来向 AS2 接收端点发送消息。由于在这个示例中 AS2 与 X12 端点相关联，因此所有发送到 AS2 接收的消息都应该路由到 X12 接收的成功端点（在这种情况下是 Azure 服务总线中继端点）。消息接收器是 MSDN 代码库中用于在中继端点接收消息的工具；它需要在 X12 协议路由地址中配置的地址上进行监听。

使用 MSDN 代码库中的Web Sender测试示例 850 的 AS2 消息。您可以使用 BizTalk 服务项目中的 Visual Studio 生成实例命令生成采购订单 EDI 850 的实例。

注意

您可以通过以下链接下载消息接收器 C#示例：

code.msdn.microsoft.com/Windows-Azure-BizTalk-EAI-e01a5b64

您可以通过以下链接下载 Web Sender C#示例：

code.msdn.microsoft.com/Windows-Azure-BizTalk-a0d12dca

查看跟踪数据

点击导航栏中的跟踪视图以查看协议上消息流的状态。

摘要

在本章中，我们首先介绍了围绕 B2B 的基本概念及其在 Azure 环境中的相关性。我们介绍了 Azure 上 B2B 的关键概念，特别是合作伙伴、协议、模板、批处理、跟踪和归档。我们还介绍了 BizTalk 服务中 AS2 和 X12 的简单协议配置。交易伙伴也可以使用 API 进行管理——这将在后面的可扩展性章节中详细说明。

第六章。API

到目前为止，我们只看了与 Windows Azure BizTalk 服务（WABS）交互的图形工具。这些包括用于创建和部署解决方案的 Visual Studio 以及用于管理和监控已部署解决方案的 BizTalk 服务门户（以及 Azure 管理门户）。然而，所有这些工具的底层是一个基于 REST 的 API，它允许轻松地与脚本工具以及您自己的流程集成，以促进自动化操作，如部署、测试和管理。

在本章中，我们将探讨 WABS API 以及如何使用以下方式与之交互：

• RESTful 网络服务

• PowerShell

• 自定义代码

虽然 API 可以使用三种方法（门户、REST 服务和 PowerShell），但每种方法都满足不同的需求，尽管存在重叠，但在功能上也有所不同。门户在本书的另一部分已有所探讨，并为系统管理员提供了一个易于访问的控制台。PowerShell 是 IT 专业人员熟悉的一种工具，用于脚本系统交互，如部署。直接使用 REST API 对于构建自己的工具和能力，或在 WABS 之上或从其他应用程序与 WABS 交互非常有用。到本章结束时，您将很好地理解 WABS API 以及您如何在自己的组织中利用它。

REST

首先，让我们快速了解一下提供的 API 的基础。在 Visual Studio 和管理门户中可用的所有功能也在 API 中可用。事实上，API 实际上提供了比这些工具更多的功能，正如我们将看到的。这并不令人惊讶，因为这种情况经常发生——API 通常先于工具出现。因此，了解 API 可以做什么是一个好主意。支撑这个 API 的是一组可通过 HTTP 访问的 Web 服务。WABS 使用 RESTful 服务来实现这一点。REST 不是一个标准或协议，而是一种架构风格，它通过简单的基于 HTTP 的集成来实现。它不需要 SOAP 或 Microsoft 的 WCF 等框架的开销。实际上，您通常可以使用您的网络浏览器来发出请求或查询信息。REST 基于一组标准 HTTP 动词，这些动词指定了请求的类型。WABS 在其 API 中使用以下 HTTP 动词：

动词	目的
PUT	创建新工件或更新现有工件
GET	获取工件（s）
DELETE	从 WABS 中删除工件
POST	更新工件或服务状态

WABS REST API 动词

如您所见，通过这种方式支持了完整的 CRUD（创建、读取、更新和删除）操作，这提供了很大的灵活性，因为它促进了跨平台访问和与第三方工具的轻松集成。

调用 API

让我们先看看一个简单的对 BizTalk 服务 API 的 REST 调用。在这个例子中，我们将查询为给定 Azure 订阅部署的 BizTalk 服务实例。我们将看到您如何使用一个非常有用的工具 Fiddler 来执行此请求。您可以从 fiddler2.com/ 免费下载 Fiddler。

为了在 Azure 上执行这些 API 调用，需要每个参与方之间进行相互的证书交换过程，以便相互验证。当您的机器向 Windows Azure 管理端点发出请求时，Azure 会返回配置的证书，作为回报，您的客户端机器将向 Azure 发送其证书以进行验证。一旦完成，Azure 将执行请求并返回确认。为了使这成为可能，我们首先需要创建一个客户端证书，然后将其上传到 Azure。

这里有两个选项。您可以使用自己创建的证书，这被称为自签名证书。这样的证书对于测试很有用，但不适合生产使用。在这种情况下，您将从签名机构购买证书并使用它。这样做的原因是证书关乎信任，不仅仅是两个参与方（您的机器/组织与 Azure）之间的信任，还包括与签名机构的信任。当一方收到证书时，它可以与签名机构检查其有效性。这也允许，例如，签名机构在证书被泄露时撤销证书。

然而，对于我们的目的来说，一个自签名证书就足够了。要创建证书，打开命令提示符并输入以下命令：

makecert -sky exchange -r -n "CN=wabstest" -pe -a sha1 -len 2048 -ss 
My "%HOMEPATH%\documents\wabstest.cer"

此命令将创建一个自签名证书并将其安装到您的机器的证书存储中，位于您的登录账户下。完成此操作后，我们需要将其与我们的 Azure 订阅关联，我们在其中已配置了 BizTalk 服务：

1. 打开 Windows Azure 管理门户 manage.windowsazure.com。

2. 在左侧边栏中，点击 设置（它是列表中的最后一个）。

3. 在 设置 下，点击 管理证书 选项卡，然后点击 上传。

4. 浏览到您在命令窗口中之前创建的证书文件——它默认位于 c:\users\<youraccount>\documents。

5. 点击勾选按钮以将您的证书与管理系统关联。

   上传管理证书

现在我们已经完成了这个步骤，我们可以使用 Fiddler 的请求作曲家功能进行调用，以查询 WABS 服务的部署。为了在 Fiddler 中设置证书，我们首先需要在发出请求之前执行几个步骤：

1. 打开 Fiddler。

2. 在 规则 菜单中，选择 自定义规则…。

3. 在 Notepad 中打开的 CustomRules.js 文件中，找到 OnBeforeRequest 函数。

4. 在此函数顶部添加以下内容，将<username>替换为你的用户名：

   if (oSession.HostnameIs("management.core.windows.net")) {
      oSession["https-Client-Certificate"] = "C:\\Users\\<username>\\Documents\\wabstest.cer";
   }
   

5. 保存文件并关闭记事本。

这将做的是，每当访问 Azure 管理 URL 时，都会将客户端证书发送到服务。对于下一步，你需要你的 Azure 订阅 ID。要获取此信息，请返回到 Azure 管理门户，在设置 | 订阅下，你将在订阅列中看到你的订阅列表，并在订阅 ID列中看到所需的订阅 ID，如下面的截图所示：

获取订阅 ID

现在，我们可以按照以下方式发出请求：

1. 点击作曲家标签。

2. 确保 URL 旁边的动词设置为GET。

3. 在框中输入以下 URL，将<SubscriptionID>替换为你的订阅 ID：

   https://management.core.windows.net/<SubscriptionID>/cloudservices

4. 在请求头区域添加此处提供的头信息：

   x-ms-version:2010-10-28

   这个 HTTP 头指定了我们想要的服务版本，并且是必须的。目前，只有一个版本，但随着时间的推移，服务可能会发生变化，这将允许你调用它的特定版本。

   你的 Fiddler 请求应如下截图所示：

   

   获取云服务列表

5. 点击执行按钮。

如果一切按计划进行，你现在应该在 Fiddler 窗口中看到调用结果，如下面的截图所示。你所看到的是一个列表，以 XML 格式列出为传递给订阅的 BizTalk 服务实例。如果你以编程方式调用此 API，你可以读取 XML 并提取每个实例的特定属性，也许停止或重新启动它们。出于明显的原因，我已经模糊处理了订阅 ID 和其他细节。

获取云服务列表

通过这次调用的结果，我们现在可以使用以下 URL 检索单个 WABS 实例的详细信息。在这里，传递给 Get Cloud Service 调用的云服务名称是前一个调用返回的：

https://management.core.windows.net/<SubscriptionID>/cloudservices/<CloudServiceName>

请求和响应如下截图所示：

获取单个 BizTalk 服务实例

备份和还原

现在我们已经查看了一个 WABS API 能做什么的简单示例，让我们看看一些更有趣的功能。企业开发的一个基本方面是能够在环境之间移动工件。通常，一个组织或团队将有一个开发、测试、用户验收和生产环境（以及每个环境的多个实例）。通过创建多个服务实例并根据需要配置它们，BizTalk Services 可以实现这种 DTAP（开发、测试、用户和产品）设置。然后，每个实例都可以按需使用来管理整体集成环境。

备份 BizTalk 服务实例不仅对在环境之间移动内容很有用，还可以用于保留特定环境的备份或快照，以用于灾难恢复或恢复到特定时间点。如果服务类型至少相同或更高，还可以将实例恢复到服务的不同版本。例如，基本订阅可以恢复到另一个基本订阅，也可以恢复到标准或高级订阅。然而，降级是不可能的，也不能备份服务的开发者实例。

此功能现在（截至 2014 年 2 月的服务更新）通过 Windows Azure 管理门户提供开箱即用的工具，如以下截图中的配置选项卡所示。虽然门户 UI 现在允许您备份服务实例，甚至可以从备份创建新的 BizTalk 服务实例，但使用 API 进行程序化操作非常有用。API 提供了将一组工件从一个实例（例如测试）移动到另一个实例（例如用户验收）的能力。在本节中，我们将通过编写一些.NET 代码来实现此功能。正如您将看到的，这非常简单直接。

使用管理门户备份 BizTalk 服务实例

在尝试此功能之前，我应该指出，此功能提供的服务实例的副本与原服务实例相似。很可能（甚至很可能）您的某些设置或配置是特定于环境的。例如，如果您的网桥向服务总线队列发送消息，那么您不太可能使用与生产环境相同的队列进行测试。因此，虽然能够备份一个环境并将其恢复到另一个环境确实非常有用，但您还需要考虑使用 REST API 在恢复的服务实例上应用配置更改。

打开 Visual Studio 并创建一个新的控制台应用程序。将其命名为BackupService。在静态Main方法中，添加以下代码以替换空的Main方法：

static void Main()
  {
    Task t = new Task(Run);
    t.Start();
    Console.ReadLine();
  }

现在添加如以下代码片段所示的Run方法。此代码格式化所需的 URL 以进行备份 API 调用。为此，需要三块信息。

首先，您需要您的 Windows Azure 订阅 ID；这个 ID 与之前讨论的相同，您可以通过在“调用 API”部分的“上传管理证书”截图中的 Windows Azure 门户中获取它。您还需要服务名称。这是之前显示的名称字段中的值，您可以通过在 Fiddler 中执行我们看到的那个 API 调用来获取您的服务名称。您还需要的数据的最后部分是 BizTalk 服务实例的资源名称。这是您在创建 WABS 实例时给出的名称。您可以通过 Azure 门户、点击 BizTalk 服务链接或再次使用 Fiddler（如前一个截图所示）来获取它。您需要的名称位于 Resources/Resource/Name 元素下。将代码中的三个占位符替换为您所示的服务值，如下所示：

static void Run()
{
  string subscriptionId = "<SubscriptionID>";
  string operationName = "cloudservices";
  string serviceName = "<servicename>";
  string resourceName = "<resourcename>";
  Uri requestUri = new Uri("https://management.core.windows.net/"
                                    + subscriptionId
                                    + "/cloudservices/"+ serviceName
                                    + "/resources/biztalkservices/~/biztalk/"
                                    + resourceName
                                    + "/?comp=backup");
MakeRequest(requestUri);
}

现在，添加以下两个程序集引用，它们包含用于向服务端点发出请求所需的类型：

System.Net.Http
System.net.Http.Request

直接在之前添加的代码下方添加以下方法。这将设置对备份 REST API 的调用，并且为了做到这一点，它需要您的证书。如前所述，管理 API 调用使用相互证书对服务进行身份验证，因此我们需要传递我们的证书。然而，由于我们之前添加到 Fiddler 中的规则会在向管理 URL 发出的每个请求中发送客户端证书，因此我们不需要在代码中发送证书——您只需确保 Fiddler 仍在运行（如果您想在没有 Fiddler 的情况下运行，代码中提供了添加证书的方法）。这简化了事情。

static async void MakeRequest(Uri requestUri) {
   string payload =
"{\"BackupName\":\"<backupname>\",\"BackupStoreConnectionString\":\"AccountName=<storageaccountname>;AccountKey=<storageaccountkey>;DefaultEndpointsProtocol=https\"}";

   HttpContent content = new StringContent(payload);
   content.Headers.ContentType.MediaType = "application/json";
   content.Headers.Add("x-ms-version", "2010-10-28");
   using (var client = new HttpClient())
   {
      var response = await client.PostAsync(requestUri, content);
      response.EnsureSuccessStatusCode();
      Console.WriteLine("Backup started");
   }
}

您需要将前述代码中的 <storageaccountname> 和 <storageaccountkey> 值替换为您自己的存储账户详细信息。要获取您的 AccountName 和 AccountKey 值，请执行以下操作：

1. 前往 Azure 管理门户。

2. 点击左侧导航栏中的存储图标。

3. 在存储账户列表中，选择与您的 BizTalk 服务实例创建的名称相同的账户。

4. 点击页面底部的管理访问密钥按钮。

5. 将存储账户名称和主访问密钥字段复制并粘贴到前述代码中。

实际上，您可以在第 3 步中使用任何您喜欢的存储账户，甚至创建一个新的账户。该账户用于存储备份的 WABS 实例。代码中的第三个占位符是 <backupname>。这是用于备份的标签，并且将此命名为有意义的名称是良好的实践，例如使用备份的日期。您使用的标签必须以字母或数字开头，只能包含数字、破折号（-）或小写字母，并且长度在 3 到 63 个字符之间。破折号不能连续。

发送到服务的数据格式是 JSON（JavaScript 对象表示法），这只是一个包含存储账户详情和备份名称的字符串。PostAsync 调用将调用 API 并等待响应。如果成功，服务将返回 OK 响应 HTTP 状态码 200。由于服务备份可能需要长达一小时才能完成，因此此 API 是异步的。作为响应，我们得到一个跟踪标识符，允许您检查备份操作的状态。API 提供了一个轮询查询，允许您传递返回的标识符（一个 GUID）并在任何时间点检索操作的结果。这样，您可以确保备份已成功完成。

现在代码已经完成，按 F5 构建并运行它。如果成功，控制台应用程序应该会在几秒钟后打开并关闭。您可能想在代码中设置几个断点并运行它，以查看它是否正常工作。为了简洁起见，我已经省略了任何异常处理代码。如果调用 API 失败，将抛出异常。在这种情况下，运行调试器以确定问题所在。

当然，还有一个相应的还原 API 调用，允许您将先前备份的实例还原到任何其他 BizTalk 服务实例。

如我之前提到的，您需要保持 Fiddler 运行，因为 Fiddler 正在提供必要的证书。如果您想在没有 Fiddler 的情况下运行，只需在 MakeRequest 方法的开头添加以下代码，将 <your thumbprint> 占位符替换为您自己的证书指纹，该指纹在 Azure 管理门户中显示：

var certHandler = new WebRequestHandler();
string certThumbprint = "<your thumbprint>";
X509Store certStore = new X509Store(StoreName.My,     
                                    StoreLocation.CurrentUser);
certStore.Open(OpenFlags.ReadOnly);
X509Certificate2Collection certCollection = certStore.Certificates.Find(X509FindType.FindByThumbprint, certThumbprint, false);
certStore.Close();
X509Certificate2 certificate = certCollection[0];
certHandler.ClientCertificates.Add(certificate);You also need to change the using statement as shown below to pass in the certificate from:
using (var client = new HttpClient())
To:
using (var client = new HttpClient(certHandler))

上述代码从您的本地计算机的证书存储中检索您的证书。因此，您需要确保它已经存储。为此，双击您的证书，在出现的向导中执行以下操作：

1. 首先接受任何安全警告。

2. 点击 安装证书 按钮。

3. 对于 存储位置 选项，选择 本地计算机。

4. 接受出现的任何警告。

5. 选择 将所有证书放置在以下存储中。

6. 点击 浏览 按钮。

7. 选择 个人 并点击 确定。

8. 点击 下一步 然后点击 完成。

9. 您应该会看到一个确认成功安装的消息。

10. 关闭对话框。

使用 PowerShell

到目前为止，我们已经看到了两种不同的方式来利用 BizTalk 服务提供的 API，直接在 Fiddler 中进行 HTTP 请求，以及通过编写代码来程序化地调用它。现在我们将看看一种更简单的方法，使用 Windows PowerShell。Windows PowerShell 是一个面向管理员的命令行工具，它提供了一种在许多 Microsoft 产品（包括第三方产品）中执行任务的一致方式。使用 PowerShell，可以自动化常见操作并创建复杂的脚本，用于配置和管理 BizTalk 服务环境和 Azure。

BizTalk 服务提供了一套 PowerShell cmdlet，可以调用提供的完整 API 集合。Cmdlet 是在 PowerShell 中执行的功能单元，BizTalk 服务为每个可用的 API 调用提供了一个 cmdlet。

为了绝对正确，BizTalk 服务实际上提供了两组 cmdlet。第一组是在你下载并安装 BizTalk 服务 SDK 时安装的，而第二组则需要下载。第一组允许控制已配置的 BizTalk 服务实例中的工件，而第二组允许控制 BizTalk 服务整体——包括创建新的 BizTalk 服务实例。由于第二组与我们已经查看过的 API 相关，我们将从这里开始。这第二组作为源代码提供，可以从以下链接下载：

code.msdn.microsoft.com/windowsazure/Windows-Azure-BizTalk-91e1bdf3

由于这是源代码，需要将其在 Visual Studio 中打开并编译。我们还应该注意，这是一个示例，不是来自 Microsoft 的官方支持代码。一旦源代码构建完成，通过点击开始按钮并输入 PowerShell（在 Windows 8 或 2012 上）在 Windows 8/Server 2012 上打开 PowerShell。你应该在结果列表中看到 Windows Azure PowerShell。点击它以启动它。如果你看不到 Windows Azure PowerShell，请确保你已经安装了它，并且至少安装了版本 0.6.19。

在 PowerShell 命令窗口中，输入以下命令来加载 cmdlet：

import-module <pathtosource>/Microsoft.WindowsAzure.Management.BizTalkService.dll

为了使用 cmdlet，必须首先设置订阅上下文。通过在命令窗口中输入以下代码来完成此操作：

$sub = '<subscription ID>'
$thumbprint = '<certificate thumbprint>'
$cert = Get-Item cert:\\LocalMachine\My\$thumbprint
Set-AzureSubscription -SubscriptionName "Test" -SubscriptionId $sub -Certificate $cert
select-azuresubscription –SubscriptionName "Test"

现在，你应该知道如何获取需要替换的 <subscription ID> 的值。对于 <certificate thumbprint>，如果你之前遵循了生成和上传证书的步骤，你需要将此值替换为你自己的证书的指纹。要找到这个，请转到 Azure 门户并点击左侧导航栏中的 设置。在设置页面上，点击 管理证书，然后复制并粘贴你之前上传的证书的指纹列的值。

我在之前的代码中使用 Test 的值来命名订阅。这可以是任何你喜欢的标签。它仅用于 PowerShell 会话期间命名订阅。现在，一旦完成，所有 cmdlet 都将在特定订阅的上下文中执行。

作为如何使用 cmdlet 的一个示例，让我们看看我们之前所做的其中一个 API 调用。在命令窗口中，输入以下命令，将你的 BizTalk 服务实例名称替换为 <service name>：

Get-AzureBizTalkService -resourcename <service name>

你应该在命令窗口中看到类似于以下截图的响应：

获取 BizTalk 服务 cmdlet

使用 API 不仅限于查询服务。我们还可以创建全新的 BizTalk 服务实例或删除现有的实例。如果需要，还可以暂停或恢复特定的服务实例。要创建新实例，提供了 New-AzureBizTalkService 命令。它具有以下形式：

New-AzureBizTalkService -ResourceName MyNewBizTalk -Location "West Europe" –ConfigurationFile "c: \ create_new.xml"

除了实例名称和要创建它的数据中心之外，主要参数实际上是一个文件。源代码的下载实际上包含了一些示例文件，您可以为此目的进行修改。您提供的文件包含所有您在通过 Azure 门户创建新服务时通常要指定的详细信息；例如，要使用的数据库、用于保护服务的证书、服务类型——开发者、高级等——以及 ACS 设置。在阅读完这本书后，您应该会发现使用您的设置编辑提供的示例文件非常简单。一旦完成，您就可以随心所欲地自动化创建服务！

好的，到目前为止，我们已经涵盖了 BizTalk 服务 API 的管理方面。但如前所述，还有另一组 PowerShell 命令，用于在 BizTalk 服务实例中操作工件和设置。如果您已安装 BizTalk 服务 SDK，则该命令集已经安装，默认情况下位于 C:\Program Files\Windows Azure BizTalk Services Tools。

要加载命令，请在 PowerShell 窗口中键入以下命令：

import-module "C:\Program Files\Windows Azure BizTalk Services Tools\Microsoft.BizTalk.Services.Powershell.dll"

此 PowerShell 模块提供了在 BizTalk 服务门户 UI 中不可用的功能。一个例子是能够启动和停止桥接器。当新的桥接器部署时，它默认是激活的，但有时您可能希望停止桥接器接收消息。这可以通过 Stop-AzureBizTalkBridgeSource 命令实现，如下所示：

Stop-AzureBizTalkBridgeSource –AcsNamespace <namespace> –IssuerName owner –IssuerKey <key> –BridgePath MyBridge

这将停止桥接器 MyBridge 上所有可用的源，但也可以通过提供 SourceName 参数来停止特定的源。这在您需要执行需要暂时停止某些或所有源维护操作时非常有用。要重新启动桥接器/源，使用具有相同参数的相应的 Start-AzureBizTalkBridgeSource 命令。

剩余的命令涉及向 BizTalk 服务添加和删除诸如桥接器、架构、证书和程序集等工件。Visual Studio 在部署期间使用这些 API 调用，其主要用途之外是自动化和管理部署。有关命令的完整列表，请访问 msdn.microsoft.com/en-us/library/windowsazure/dn232360.aspx。

摘要

在本章中，我们探讨了 BizTalk 服务的底层 API。我们了解了如何从简单的网页浏览器中利用 API，以及如何使用 PowerShell 命令和编写自己的代码来调用它。我们研究了不同类型的 API、功能以及封装所有这些功能的命令，希望您已经看到了如何利用 BizTalk 服务 API 的功能来创建、管理、维护，更重要的是，自动化您的 BizTalk 服务实例。在下一章中，我们将探讨如何解决您的集成解决方案的问题，以及如何使用 WABS 的跟踪功能。

第七章：跟踪和故障排除

在最后几章中，我们探讨了构建 BizTalk 服务解决方案所使用的工件。到现在，你可能想知道如何跟踪消息流，或者更好的是，如果事情没有按预期进行，如何进行故障排除。在本章中，我们将探讨用于在 BizTalk 服务中故障排除的工具和常见模式。

具体来说，我们将重点关注以下主题的故障排除：

• 源和目标

• 架构和转换

• 带有自定义代码的 EAI 桥

• B2B 协议

• 混合连接

消息和错误

首先，让我们快速总结一下基础知识。桥是消息通道，不会持久化消息。这意味着在 EAI 桥的情况下，任何消息处理失败都将返回给调用者的 HTTP 错误，而在 B2B 桥的情况下，消息将被推送到挂起端点。在 B2B 的情况下，挂起端点很重要，因为配置或消息结构中的错误不能发送回业务伙伴，而是供 IT 操作员消费。这意味着在 EAI 和 B2B 场景中，所有失败后的消息重试和重新提交都必须在桥外完成。

以下三种场景中可能发生错误：

• 部署时错误：此场景包括与 BizTalk 服务部署配置相关的所有错误。在大多数情况下，错误是自解释的，并在 Windows Azure 管理门户中显示或通过 RDFE API 发送回。需要注意的是，BizTalk 服务部署名称是唯一的。自定义域仅用于将 DNS 名称包装在 BizTalk 服务部署 URL 周围。该域的证书需要上传到访问部署的机器上的受信任根证书颁发机构证书存储中。在部署活动期间，用于跟踪和归档的存储和 Azure SQL 数据库不能重用或删除。

• 设计时错误：此场景包括在 BizTalk 服务门户中添加/更新/删除桥、部署 VS 项目或添加/更新/删除协议时出现的所有错误。这些错误在 EAI 场景中出现在输出窗口或错误列表窗口中，而在 B2B 场景中分别出现在 BizTalk 服务门户的状态栏中。

• 运行时错误：此场景包括两个应用程序或合作伙伴之间实际消息流中的所有错误。此场景可以进一步细分为四个子类别：

  • 当消息发送到 BizTalk 服务外部端点时出现的错误。

  • 当预期从 BizTalk 服务外部端点接收消息时出现的错误。

  • 当消息格式不正确且不符合桥中配置的架构时出现的错误。

  • 在 BizTalk 服务中，当桥接器、变压器、源或混合目的地等组件无法按预期工作时会出错。这通常将产品中的错误分类为缺陷。

我们将重点关注运行时错误和前三个子类别。如果启用了跟踪，跟踪记录将记录在 Windows Azure SQL 数据库中。跟踪使我们能够存储与消息相关的有趣属性——从标题、正文或通过从其他数据源查找。在 EDI 场景中，存档以原始形式持久化消息数据。对于 EAI 场景，可以通过在第四章中概述的方式添加自定义代码来实现存档，该章讨论了企业应用集成。写入跟踪和存档存储的数据是在尽力而为的基础上进行的，也就是说，如果在写入这些存储的操作中出现错误，跟踪和存档将被跳过，并且消息处理将在桥接器中继续。此情况的例外是，当 AS2 消息的存档通过在 AS2 协议的常规设置页面中启用启用 NRR选项时。在这些情况下，如果跟踪/存档无法成功完成，则消息处理将失败。

故障排除数据

在本节中，我们将探讨可用于故障排除问题的不同类型的数据。

跟踪

流经桥接器的每条消息都与一个称为请求 ID的已提升属性相关联，该属性是每条传入消息上的 GUID 值。如果消息被拆分为子消息，则每个子消息都会获得自己的跟踪 ID，该 ID 也是一个 GUID。如果请求 ID 与跟踪 ID 相同，则消息将不进行去批处理。桥接器端点 URI 和时间戳应指向消息的桥接器和时间。跟踪可以从 VS 中的桥接器属性以及 BizTalk 服务门户中的协议常规设置页面启用。

BizTalk 服务门户以用户友好的方式公开跟踪数据。有三个选项卡反映了部署中处理的消息。以下是它们的解释：

• 消息：此选项卡包含所有来自源、桥接器和协议的错误或信息类型条目。每个跟踪条目详细说明了消息的传入 URL、其请求 ID 和跟踪 ID、处理是否出错或成功、跟踪记录被发射的阶段以及发生的时间和日期。使用此视图跟踪通过桥接器和协议传递的所有 EAI 和 B2B 消息。

• 协议：此标签页列出 B2B 交互的跟踪记录。视图也被分为 EDI 和 AS2 协议级别。EDI 针对 X12 和 EDIFACT 记录的消息状态进行调用，包括发送者、接收者、消息类型（如 PO）、确认（如技术确认和功能确认）、请求 ID、交换信封的 ID 以关联批处理跟踪记录，以及记录写入的日期和时间。AS2 记录包含类似信息，但确认反映了消息处置通知（MDN）状态。使用此视图跟踪所有 B2B 协议阶段特定的跟踪条目。

• 批处理：最后，批处理标签页跟踪正在进行和完成的批次列表以及单个消息信息。视图跟踪批次名称、为该批次配置的协议以及批处理事务的发送者和接收者。条目还显示了事务接收时的大小、计数和时间，客户可以使用这些信息关联到批次的预期发布标准。使用此视图跟踪批次中的所有消息。

每个标签页都有一个搜索选项，可以帮助通过日期范围、消息类型、状态、发送者或接收者来过滤结果。

注意

不需要搜索任何选项，搜索选项会显示所有按最新日期排序的跟踪记录。这也可以在测试期间刷新页面。

跟踪视图如下截图所示：

BizTalk 服务门户中的跟踪视图

在某些情况下，您可能需要直接从 Azure SQL 数据库表中访问数据。一个常见的用例可能是基于跟踪事件构建一个通知系统。在跟踪中使用的 Azure SQL 数据库跟踪表如下（请注意，Microsoft 不提供或记录这些表以执行直接 T-SQL 查询）：

表	数据
[dbo].[PipelineTrackRecords]	桥接跟踪记录
[dbo].[SourceTrackRecords]	源跟踪记录
[dbo].[EndpointAddressMap]	存储桥接器或源的 URL，并使用外键引用 EndpointAddressID 将地址映射到管道和源跟踪记录
[dbo].[TrackRecordMessageProperties]	消息提升属性的名称和值对
[dbo].AS2, [dbo].Batch, [dbo].Functional, [dbo].Interchange, [dbo].TransactionSet*记录	AS2、MDN、批处理、交互、组、事务集记录以及功能或技术确认的 EDI 跟踪记录

跟踪和日志文件

除了跟踪之外，当消息通过网桥流动时，跟踪语句也会记录在 Azure 表中。当知道消息失败的时间段时，跟踪对于查找异常非常有用。跟踪信息可以补充来自 BizTalk 服务门户的跟踪信息。这些跟踪与事件跟踪日志（ETL）跟踪类似，但 BizTalk 服务跟踪是基于文本的，并存储在 Azure 表中。

对于每个部署，跟踪都会记录在创建 BizTalk 服务部署时指定的存储账户中名为WADLogsTable的 Azure 表中。您可以使用来自azurestorageexplorer.codeplex.com的工具，如Azure 存储资源管理器，或使用商业工具，如 CloudBerry，连接到该 Azure 存储账户并查看表中的数据。

WADLogsTable 中的以下三个字段很有趣：

• 时间戳：跟踪记录的日期和时间。

• 消息：包含组件或活动信息的消息、异常或错误信息。

• 级别：从致命（1）、错误（2）、警告（3）和信息（4）变化的跟踪级别。级别 2 的错误伴随着异常堆栈跟踪。

当使用网桥配置自定义代码进行故障排除时，跟踪信息非常有用。由于几分钟内可能有数百条条目，您可以使用以下命令之一在Azure 存储资源管理器工具中过滤表中的数据：

• 时间戳大于 datetime'2013-12-07T16:00:00'

• 级别 = 2

注意，在过滤数据时，空格以及大小写都很重要。

在 BizTalk 适配器服务的情况下，可以通过在服务的.config文件中添加日志拦截器来写入日志文件。要故障排除混合连接运行时，请编辑C:\Program Files\Microsoft BizTalk Adapter Service\BAServiceRuntime中的web.config。必须添加的精确条目在故障排除混合连接部分中概述。

性能计数器

您可以使用性能计数器来评估系统的健康状态。与 BizTalk 服务部署相关的性能计数器存储在部署的存储账户中，并可以从 Azure 管理门户的监控选项卡中查看，如下面的截图所示：

Azure 管理门户的监控视图中的性能计数器

每个部署都提供了以下性能计数器：

性能计数器名称	单位	描述
CPU 使用率	%	所有实例服务运行时消息的平均 CPU 使用率
源失败	count	源中失败的消息数量
处理中的失败	count	在管道处理过程中失败的消息数量
处理中的消息	count	当前处理中的消息数量
处理的消息	数量	部署成功处理的消息数量
接收到的消息	数量	管道接收到的消息数量
发送的消息	数量	从每个管道发送或路由的消息数量
处理延迟	毫秒	从验证阶段到路由单向桥的平均消息处理时间
往返延迟	毫秒	双向桥中处理消息往返的平均时间

这些计数器可用于对部署进行配置更改。例如，如果接收到的消息趋势较高，并且这与处理失败的增加和相应的处理延迟增加相关联，那么系统可能没有随着传入速率进行扩展。IT 管理员可以计划扩展部署并查找性能计数器的变化。

故障排除源和目标

源可以是以下之一：HTTP、FTP(s)、SFTP 或服务总线队列和主题。如果源端点是 HTTP，客户端发送消息时通常会在客户端看到 HTTP 错误代码，如下表所示：

错误场景	HTTP 错误代码	描述
消息发送到不存在的端点或错误的 URL	400, 500	错误请求、内部服务器错误或命名空间无法解析
消息头格式错误的端点	401	认证失败或未经授权的请求
消息体格式错误的端点	500	内部服务器错误；请参阅跟踪或跟踪条目以获取更多信息
目标端点故障	500	内部服务器错误
凭据错误的目标	500	内部服务器错误
桥接目标配置为 HTTP 中继但接收器正在监听 HTTPS	500	内部服务器错误

在 FTP 作为源的情况下，如果在处理过程中或目标处出现错误，消息将不会从源中删除。轮询间隔会增加，系统将自动重试消息的提交。

以下屏幕截图显示了在PORTAL TRACKING视图中看到的Poll Error源名称的NewPollInterval字段的增加。请注意，轮询间隔增加为当前轮询值的 1.5 倍。下一组轮询间隔将约为 227、341、512 和 768 秒。

跟踪条目指示对 FTP 源的指数轮询

使用 FTP 时可能出现的某些错误场景如下表所示：

错误场景	HTTP 错误代码	描述
错误的 FTP URL 或错误的用户名或密码	503	无法连接到 FTP 服务器和/或未登录
在现有服务活动时重新部署 FTP	400	一个或多个资源处于启动状态；您可以使用PSCmdlet停止源

您可以根据错误消息修复问题，并使用 PSCmdlet 的 Stop-AzureBizTalkBridgeSource 和 Start-AzureBizTalkBridgeSource 停止和启动源。以下截图显示了 Get-AzureBizTalkBridgeSource 的执行，以检查源端点的状态：

使用 PSCmdlet 获取源状态

故障排除模式和转换

当消息对模式进行验证失败时，模式中会暴露出问题。如果验证失败，例如由于额外的标签，则会在 XML 验证阶段添加跟踪记录，从而报告错误。

如果跟踪条目指示模式验证错误，测试模式的最简单方法是生成一个测试消息。对于 EAI/B2B 模式，Visual Studio 提供了一个方便的实用工具来生成模式的实例。将模式添加到项目后，右键单击模式并选择文件的生成实例。从模式的属性窗口中，您可以生成本机（对于平面文件）或 XML 格式的实例，如图下截图所示：

从 Visual Studio 生成模式的实例

与模式类似，转换可能会由于映射不正确或某个 functoid 对特定输入出现故障而产生错误输出。转换还支持在 Visual Studio 中使用样本数据进行测试。可以通过右键单击映射并选择测试映射来测试映射，如图下截图所示。测试期间出现的任何错误都会在 VS 错误列表窗口中指示为转换运行时异常。如果没有错误，转换的输出将在输出选项卡中指示。如果在映射部署后运行时出现错误，可以在跟踪视图中看到带有 xmlTransform 的错误跟踪记录。

从 Visual Studio 测试映射功能

故障排除桥接

之前，我们看到了如何故障排除桥接的两个阶段，即模式验证阶段和转换阶段。在使用桥接内部的自定义代码时，如果消息处理遇到错误，事情可能会变得困难。建议您使用 IMessageInspectorContext.Tracer 将 System.Diagnostics.TraceEventType 错误作为自定义代码的一部分进行记录。这些语句会在之前提到的 WADLogsTable 中显示出来。

故障排除协议

协议可以是传输层协议，例如 AS2，或者协议层协议，例如 X12 或 EDIFACT。在具有 X12 和 EDIFACT 协议的 B2B 场景中，返回给发送消息的客户端的传输状态可能是 HTTP 200 OK，但消息最终落在挂起端点。这可能是因为存在协议层错误。此类错误将由确认消息指示。

以下表格显示了某些示例场景：

配置	场景	结果
AS2 独立接收与同步 MDN	配置错误，例如证书错误	带有错误 MDN 的 HTTP 400
AS2 独立接收与异步 MDN	配置错误，例如证书错误	异步和 MDN 的错误，HTTP 200 OK
AS2 独立发送	配置错误，例如证书错误	HTTP 500，AS2 消息发送活动错误
X12 或 EDIFACT 独立接收	入站消息中的标识不匹配	对于客户端，HTTP 200 可能表示成功，但如果消息已配置为发送错误、NACK 并最终发送到挂起目标，请查看跟踪视图
X12 或 EDIFACT 独立发送	模式未找到	对于客户端，HTTP 200 可能表示成功，但如果消息已配置为发送错误、NACK 并最终发送到挂起目标，请查看跟踪视图

故障排除混合连接

最后，我们通过探讨故障排除混合连接来结束我们的讨论。主要涉及查看在第四章中引入的 BizTalk 适配器服务，企业应用集成。

要故障排除混合连接的运行时，请使用管理员权限将以下片段添加到C:\Program Files\Microsoft BizTalk Adapter Service\BAServiceRuntime中的web.config：

<system.diagnostics>
  <sources>
    <source name= "Microsoft.ApplicationServer.Integration.BAService.Runtime" switchValue="All">
<!-- Use Critical, Error, Warning, Verbose, All, Information to adjust the log level -->
      <listeners>
        <add name="BAServiceRuntimeTrace" />
      </listeners>
    </source>
  </sources>
  <trace autoflush="true" />
    <sharedListeners>
      <add name="BAServiceRuntimeTrace" type= "System.Diagnostics.XmlWriterTraceListener" initializeData= "C:\logs\RuntimeTraceFile.xml" />
    </sharedListeners>
</system.diagnostics>
...
<system.serviceModel>
...
  <diagnostics>
    <messageLogging
      logEntireMessage="true"
      logMalformedMessages="true"
      logMessagesAtServiceLevel="true"
      logMessagesAtTransportLevel="true"
      maxMessagesToLog="3000"
      maxSizeOfMessageToLog="2000"/>
  </diagnostics>
</system.serviceModel>
</configuration>

监听器配置将跟踪输出到配置中指定的用户文件夹中的 XML 文件。消息后，我们可以查看跟踪日志文件以检查业务访问或服务配置问题。

摘要

在本章中，我们探讨了收集数据以故障排除 BizTalk 服务的各种方法。这有助于维护服务的健康。我们还探讨了 BizTalk 服务中关键组件的错误场景以及解决这些问题的方法。

故障排除既是一门艺术也是一门科学，通常涉及一种系统的方法来识别和解决问题。在下一章和最后一章中，我们将探讨迁移以及可能添加到集成平台的功能。

第八章。迁移到 BizTalk Services

在本章的最后，我们将讨论如何迁移到 BizTalk Services。整本书中，我们探讨了 BizTalk Services 的新特性和它们能做什么，但很可能会想要将现有的解决方案迁移到 BizTalk Services。当你阅读这本书时，我们还将进一步假设你想要了解更多关于将本地 BizTalk Server 解决方案迁移到 BizTalk Services 的信息。

在本章中，我们将探讨以下主题：

• 可用于帮助将 BizTalk Server 解决方案迁移到 BizTalk Services 的资源

• 如何处理产品之间的差异

• BizTalk Services 的未来计划

到本章结束时，你应该对如何处理将现有的 BizTalk Server 解决方案迁移到 BizTalk Services 以及 BizTalk Services 发展中计划如何使这一过程更加容易有一个很好的理解。

从 BizTalk Server 迁移

BizTalk Server 由多个架构组件组成，其中只有一些在 BizTalk Services 中具有等效性。这些组件在以下表中列出，该表显示了 BizTalk Server 和 BizTalk Services 的比较：

BizTalk Server	BizTalk Services
映射	转换
管道	桥梁
业务规则引擎	无等效/无需自定义编码
业务活动监控	无等效/无需自定义编码
集成	集成
适配器	桥接源和目标
架构	架构
跟踪	跟踪
交易伙伴管理	交易伙伴管理

如前表所示，BizTalk Services v1.0 和 BizTalk Server 之间存在许多功能差异。这是可以预料的，因为 BizTalk Server 是一个在 2000 年首次发布并经过多次更新的成熟产品；而 BizTalk Services 则是在 2013 年 11 月 21 日 GA（发布为通用可用）的。然而，并非所有努力都白费，因为有多种方法可以减轻从一种产品迁移到另一种产品的努力。在接下来的章节中，我们将探讨 BizTalk Server 解决方案中的不同类型的工作件以及如何迁移到 BizTalk Services。

映射

第二章，消息和转换，详细介绍了映射，并提到了我们将在此处更详细地查看的工具。首先，让我们回答一下你是否真的需要这样的工具。

BizTalk Server 提供了运行自定义 可扩展样式表语言转换（XSLT）的能力——只需提供 XSLT 模板文件的路径，就可以忽略映射内容。以这种方式编写的映射不需要转换工具，因为你可以直接将 XSLT 配置在 BizTalk Services 转换中。

BizTalk 中的映射在 BizTalk Services 中的功能等价物是转换，正如您已经看到的。然而，这些技术的实现却非常不同，无法在 BizTalk Services 中执行 BizTalk 服务器映射。

微软发布了一个转换工具，它以 BizTalk 映射（.btm 文件）作为输入，并输出 BizTalk Services 转换文件（.trfm）。让我们看看它是如何工作的。

在 第二章 中，我们探讨了 BizTalk Services 转换及其源和目标架构。在这里，我们将重新审视这些架构，并查看等效的原始 BizTalk 服务器映射。如下面的截图所示：

BizTalk 服务器映射

转换工具是 BizTalk Services SDK 的一部分，可在 www.microsoft.com/en-us/download/details.aspx?id=39087 获取。选择 Tools.zip 下载并解压到您的本地计算机上。这是一个命令行驱动的工具，因此在这里，我将打开一个命令窗口，如下面的截图所示。可执行文件只接受两个参数：BizTalk .btm 文件的路径和输出 .trfm 文件（实际上这是可选的）。

BizTalk 映射转换工具

如下面的截图所示的结果 BizTalk Services 转换与我们在 第二章 中创建的转换产生完全相同的输出。

转换后的映射

正如您刚才看到的，转换工具是重用 BizTalk Services 中现有映射的有用方式。通常情况下，已经在 BizTalk 映射上投入了大量资金，而这个工具允许它们在许多情况下以最小的努力进行转换。然而，这个工具并非没有一些限制，这需要对生成的转换进行一些修改。

如果生成的转换无法正确加载，可能需要进行的修复之一是更改文件中的 ID 值，因为它有时会发出重复项。当您尝试在 Visual Studio 中打开映射时，您可能会看到以下截图所示的错误：

映射错误消息

这应该是一个简单的案例，当您尝试打开转换并标记为重复的 ID 时，找到该 ID 并用新的唯一值替换其值。如果 ID 指的是脚本，则至少需要更改重复 ID 的两个地方。以下代码示例中，Value 标签的内容包含重复的 ID。将其更改为唯一值，例如 14，将修复本章附带的示例中的问题。

<a1:KeyValueOfstringanyType>
   <a1:Key>Id</a1:Key>
   <a1:Value i:type="xs:int">13</a1:Value>
</a1:KeyValueOfstringanyType>

通常，如果工具无法转换映射，它将尽可能转换，并用算术表达式函数对象替换无法转换的函数对象。这将是一个空对象，因此不会编译，以指示你需要审查它。如果一个函数对象转换不可行，转换中的等效函数对象将没有输入，再次表示某些内容尚未转换。当前限制的完整列表在工具所在位置的ReadMe.txt文件中提供。

工具会生成一个日志文件，指示转换映射所采取的步骤。Log.txt文件将写入命令行中运行工具的文件夹。

管道

BizTalk 服务器中的管道用于在适配器和 MessageBox 之间处理数据。现在，这一需求由 BizTalk 服务的桥梁提供。我们已在本书的其他部分详细介绍了桥梁（第三章，桥梁和第四章，企业应用集成）。你应该会发现桥梁的使用和在其中部署自定义代码的能力提供了与管道和自定义管道组件遇到的大多数功能。BizTalk 服务标准的桥梁阶段与 BizTalk 服务器非常相似，如下表所示：

BizTalk 服务器阶段	BizTalk 服务阶段
接收：解码	丰富（1）
接收：拆装	消息类型/丰富（2）
接收：验证	验证
接收：解析方	N/A
发送：预组装	丰富（1）
发送：组装	丰富（2）
发送：编码	发送回复
接收和发送：端口映射	转换阶段

如果前表中的阶段看起来有些随意，那是因为它们确实是。就像在 BizTalk 服务器中，完全有可能在单个阶段完成所有操作（当然，这取决于是哪个阶段），BizTalk 服务也是如此。虽然 BizTalk 服务没有管道组件的概念，但它提供了足够的阶段占位符供你自己的代码使用，当然，它还提供了许多你传统上会为自定义管道组件编写的功能，例如属性提升。尽管 BizTalk 服务器提供了四个接收管道阶段，实际上，管道阶段是可以配置的（你可以定义自己的），但没有人真正关心这一点，几乎所有解决方案都只使用了解码和验证阶段（如果有的话）。发送管道甚至不那么重要，但同样，BizTalk 服务提供了与阶段相似的镜像，如果你需要，你可以在这里对通过的消息执行操作。

话虽如此，应该清楚的是，如果您遇到一个包含自定义管道组件的解决方案，您有一些工作要做，即尝试将其转换为 BizTalk Services。

架构

BizTalk Services 对架构的支持在很大程度上是相同的，并且通常，您在将架构在两者之间移动时不应遇到太多问题。有一些值得注意的例外，例如将多个架构传递到 BizTalk Server 映射中，这在 BizTalk Services 中目前是不可能的，但通常架构可以以直接的方式重用。

适配器

BizTalk Services 与适配器的概念相同，尽管适配器的集合要小得多。此外，BizTalk Services 提供了两种集成方法：桥接的源和目标以及 BizTalk Adapter Service，它使用服务总线中继将消息传递到由 Internet Information Services (IIS)托管的业务线（LOB）适配器（实际上，与 BizTalk 一起提供的相同的 LOB 适配器）。因此，如果您的 BizTalk Server 解决方案需要的适配器在 BizTalk Services 集合中表示，转换过程将非常直接。然而，对于 BizTalk Server 有数百个适配器可用，而对于 BizTalk Services 则有十几个左右，因此显然存在一些差距。其中一些对于云托管平台来说可能没有意义（例如，备受喜爱的文件适配器），但对于其他一些，这可能会带来问题。

微软认识到这个问题，当然会随着时间的推移根据客户反馈引入新的源和目标。微软还计划开放架构，提供适配器 SDK，以便您（或第三方）构建自己的适配器，从而提供另一种解决方案。因此，随着时间的推移，这个问题可能会减少。

交易伙伴管理（TPM）

BizTalk Server 使用 TPM 来定义和管理 EDI 交易伙伴。使用 BizTalk 的 EDI 功能的组织可能会在 BizTalk 中设置数百甚至数千个交易伙伴，并且如果他们希望采用 BizTalk Services，他们将希望有一种将这些合作伙伴迁移到 BizTalk Services 的方法。

BizTalk Services 在合作伙伴管理方面采取了与 BizTalk 相同的方法，并且对 BizTalk Server 2010 中 TPM 模型和架构所做的更改也被 BizTalk Services 采用。这意味着这两个系统实际上非常相似，迁移可以通过几种方式完成。

对于现有的 BizTalk Server 用户，Microsoft 提供了 TPM 数据迁移工具。这个工具包含在之前讨论的映射转换工具相同的Tools.zip下载中，并且能够将 TPM 数据从 BizTalk Server 2010 或 2013 迁移过来。

下面的屏幕截图显示了 BizTalk Server 管理控制台。在这里，您可以看到两个参与方和一个我们希望迁移到 BizTalk Services 的协议。

BizTalk Server 管理控制台

要启动它，双击 TPMMigration.exe，应用程序将如以下截图所示出现：

TPM 数据迁移工具

工具以 SQL Server 的机器名作为 BizTalk Server 管理数据库的存放位置，以及 BizTalk 服务连接详情作为输入。然后，它将显示如下截图所示的可用合作伙伴以供迁移：

选择要迁移的合作伙伴

在这里，我从 BizTalk Server 管理控制台中选择了两个合作伙伴。点击 下一步 然后显示协议。我只有一个，如下截图所示，这是两个当事人之间的协议，因此选择此协议并点击 下一步 将开始将合作伙伴和协议迁移到 BizTalk 服务的过程：

选择协议

一旦在 BizTalk 服务中创建了合作伙伴和协议，摘要 页面将详细说明已完成的工作，如下截图所示：

迁移摘要

现在，在 BizTalk 服务门户中查看，我们可以看到已经创建了合作伙伴和协议，如下截图所示：

BizTalk 服务门户

工具应该能够迁移您在 BizTalk Server 中设置的各方和协议。工具的一个限制是它不会迁移您用于保护您组织与交易伙伴之间对话的证书。这些需要手动迁移。

当从 BizTalk Server 2010/2013 迁移到 BizTalk 服务时，TPM 数据迁移工具非常有用。然而，如果您需要从不同的产品或 BizTalk Server 的早期版本迁移，也存在另一种选择。如果您想通过自定义应用程序或与其他产品集成来程序化创建交易伙伴，这种方法也是一个有用的方法。此方法使用 TPM API。实际上，迁移工具也利用此 API 来完成其工作。

此前，TPM 使用的 API 没有文档记录，因此如果客户希望在 BizTalk 中程序化创建交易伙伴，则不会得到支持。现在情况不再是这样。微软现在已在 MSDN 上发布了该 API，从而允许客户以受支持的方式利用它。

BizTalk 服务 TPM API 的文档位于以下位置：

msdn.microsoft.com/en-us/library/windowsazure/dn232369.aspx

为了调用 TPM API，需要 OAuth WRAP 令牌进行身份验证。这个令牌只是一个包含以下信息的字符串：

• 用户名：owner

• 密码：来自 ACS 的发行者密钥

• BizTalk 服务端点名称：https://<yourservice>.biztalk.windows.net/

调用 API 的过程由两个步骤组成。首先，POST 一个 WRAP 请求并接收一个 WRAP 令牌，然后将其传递到后续请求中。API 与我们在第六章（Chapter 6）中查看的其他 API 一样是基于 REST 的。由于 OAuth 要求（与相互证书认证相对），在 Fiddler（或浏览器）中调用它们更困难（尽管并非不可能）。因此，让我们以获取合作伙伴列表的代码为例来查看所需的代码。

以下代码将使用 WRAP 请求调用 Azure 并获取令牌：

string nameSpace = "<your WABS  namespace>"; // WABS namespace
string defaultIssuer = "owner"; // WABS issuer - usually "owner"
string defaultKey = "<your WABS key>"; // WABS issuer key
string serviceName = "gettingstartedwabs";
string address = string.Format((IFormatProvider)CultureInfo.InvariantCulture, "https://{0}.{1}/{2}/",
nameSpace, "accesscontrol.windows.net", "WRAPv0.9");
string payload = string.Format((IFormatProvider) CultureInfo.InvariantCulture,
"wrap_name={0}&wrap_password={1}&wrap_scope={2}", defaultIssuer,
                Uri.EscapeDataString(defaultKey),
                Uri.EscapeDataString("http://" + serviceName + ".biztalk.windows.net/default/$PartnerManagement/Partners"));
            HttpContent content = new StringContent(payload);
            content.Headers.ContentType.MediaType = "application/x-www-form-urlencoded";
using (var client = new HttpClient())
{
   // get WRAP token
   var response = await client.PostAsync(address, content);
   response.EnsureSuccessStatusCode();
   string token = await response.Content.ReadAsStringAsync();
   token = Uri.UnescapeDataString(token.Split('&')[0]);
}

这相当简单。需要四条信息。要获取 BizTalk 服务实例的 ACS 详细信息，请转到 Azure 门户，在左侧边栏中单击 BizTalk Services，选择您的实例，然后单击 连接信息。您将在这里找到用于替换前面代码的命名空间、发行者和密钥。服务名称是您在创建 BizTalk 服务实例时给出的名称，将在 Azure 门户仪表板上显示为标题。

这些信息被连接并发送到 ACS。它验证并返回一个身份验证令牌——一个可以在后续调用中使用的字符串。

以下代码（应放置在 using 语句前面的最后一个大括号内）将在请求中传递令牌并接收指定 BizTalk 服务实例中的合作伙伴列表：

// get partner list
client.DefaultRequestHeaders.Add("x-ms-version", "1.0");
client.DefaultRequestHeaders.Authorization = new AuthenticationHeaderValue("WRAP", "access_token=\"" + token.Substring(18) + "\"");
response = await client.GetAsync("https://" + serviceName + ".biztalk.windows.net/default/$PartnerManagement/Partners");
// write out partner list
Console.WriteLine("Partners:");
System.Xml.XmlDocument doc = new XmlDocument();
doc.LoadXml(await response.Content.ReadAsStringAsync());
foreach (XmlElement node in doc.SelectNodes("//*[local-name()='feed']//*[local-name()='entry']//*[local-name()='content']//*[local-name()='properties']//*[local-name()='Name']"))
{
   Console.WriteLine(node.InnerText);
}
Console.ReadLine(); // wait

之前的代码在您的 BizTalk 服务实例端点执行 HTTP GET 请求，附加操作（$PartnerManagement/Partners）并传递令牌。响应是一个包含 BizTalk 服务实例中设置的所有合作伙伴的 XML 文档。要尝试此操作，请在 Visual Studio 中创建一个控制台应用程序，并将代码粘贴到 Main 方法中，用您自己的服务详细信息替换代码中标记的值。以下截图显示了之前执行的合作伙伴导入的结果：

合作伙伴列表

使用 API 可以做很多事情，例如创建合作伙伴、更新或删除它们。然而，方法始终相同，所以请随意探索并看看您能做什么！

EDIFACT 支持

BizTalk 服务最初支持 X12 和 AS/2。截至 2014 年 2 月的服务更新，现在也提供了 EDIFACT 支持，这对于欧洲客户来说将特别受欢迎。

业务规则引擎 (BRE)

现在我们来到一些更成问题的地方。自 2004 年以来，BizTalk 服务器已经提供了业务规则引擎和编辑器，因此它被用于许多 BizTalk 服务器解决方案中。目前 BizTalk 服务中没有等效的组件。

微软计划在某个时候将规则引擎作为 BizTalk 服务的一部分提供，但目前还没有具体的时间表。目的是提供与 BizTalk Server 相同的功能和改进的工具，这两项发展将在推出时使从服务器迁移到服务变得更加容易。

同时，一个选择是将 BizTalk BRE 规则转换为代码。有一些解决方案可以将 BizTalk 规则转换为 Windows Workflow 规则，而 Windows Workflow 规则是以代码定义的。Windows Workflow 也是 .NET 框架的一部分，因此使用它没有许可费用。因此，可以在 BizTalk 服务解决方案中的某个地方运行代码，例如在网桥或转换中。当然，这有点简化了问题，因为 BRE 规则可以访问数据库和其他资源，所以可能需要做更多的工作。然而，这是一个根据规则所执行的操作的选择。

编排

将 BizTalk Server 解决方案迁移到 BizTalk 服务中最大的挑战可能是编排。目前，还没有银弹般的、自动的或零成本的方法来转换或迁移编排到 BizTalk 服务。尽管如此，也有一些选择。

微软计划将工作流引入 BizTalk 服务，这无疑将有助于填补这一空白。这意味着编排可以被重新编码为工作流，并保持相似的架构。

首先，记住网桥实际上是一个工作流。这意味着网桥已经提供了一些编排可能曾经用过的功能，例如消息丰富和路由（占很大比例），因此可能已经可以迁移基于编排的解决方案。

然而，在过渡期间，可能需要找到另一种解决方案。一种解决方案是使用 Azure 中的工作角色云服务托管的工作流，例如。BizTalk 服务可以通过传递消息或数据来调用云服务，服务将运行工作流并返回结果。但这多少改变了架构，因为通常编排是控制者——它可能等待一个设定的时间间隔或来自其他系统的特定响应，并且通常编排用作业务流程的驱动程序。值得注意的是，网桥可以串联，因此这种流程定义风格可以用 BizTalk 服务来模仿，其中消息被处理，根据路由（到更多网桥）做出决策，等等。然而，这样的解决方案可能会变得复杂，最好避免。

也许遗憾的是，在 BizTalk Server 中过度使用编排一直很普遍。编排被视为早期 BizTalk 中的“啊哈”时刻，当时像业务流程管理（BPM）这样的缩写词很流行。这是不幸的，因为编排经常在不必要的时候被使用，而一个没有它的简单解决方案本可以创建。虽然随着时间的推移教育有所帮助，但仍然存在大量以复杂编排为中心的 BizTalk Server 应用程序。如果我们面临这种场景，今天迁移到 BizTalk 服务将具有挑战性。

何时不迁移

在关闭之前，值得指出的是，BizTalk 服务并不是用来取代 BizTalk Server 的。虽然这两个产品在提供的功能上确实有许多相似之处（并且还有更多即将到来），但使用每个产品的理由是不同的。以下是一些你应该继续在本地使用 BizTalk Server 的原因：

• 所有的连接点（应用程序、服务等）都在本地

• 在 BizTalk Server 专用解决方案上的大量投资——因为这可能需要完全重写，因此，超过了某些好处

• 使用不在 BizTalk 服务中或不适合云模型的功能，例如，文件和 MQ 系列适配器

• 云不是正确的解决方案，因为例如，安全性和/或监管限制、数据分类或当地法律可能阻止通过公共互联网发送此类数据或阻止在本地以外存储数据

未来

微软承诺将继续投资 BizTalk Server 并为 BizTalk 服务制定一个强大的路线图。以下是对两个产品即将到来的关键宣布发展：

• BizTalk Server 将每隔一年发布一个主要版本

• 从今年的 BizTalk Server 2013 R2 开始，每两年将发布一次 BizTalk Server 的平台更新版本

• 计划为 BizTalk 服务添加以下功能，目标是每季度发布一次：

  • 工作流集成

  • 规则引擎集成

  • 业务活动监控

  • 适配器可扩展性/SDK

  • 桥接中的自定义代码改进

  • 与 Windows Azure Active Directory (WAAD) 集成

  • 支持业务流程建模符号（BPMN）

  • Windows Azure 存储第三方组件

  • 定期备份

摘要

在本章中，我们探讨了从 BizTalk Server 迁移到 BizTalk Services 的策略和方法，以及 BizTalk Services 将添加的一些功能，这些功能将使迁移过程更加容易。我们试图涵盖 BizTalk Server 架构的所有主要构建块及其在 BizTalk Services 中的等效项（或替代方案）。正如你所看到的，尽管功能上有显著的重叠，但 BizTalk Services 的功能集要达到相同水平还需要时间。BizTalk Services 的未来光明，微软“云优先”愿景的基本原则是以一种在本地产品中不可能实现的方式提供频繁的更新和增强。因此，可以预期微软将更加关注客户，能够比以前更快地采取反馈和功能请求，所有这些都将使微软能够帮助你将现有解决方案迁移到云端。