为什么要从 BizTalk Server 迁移到 Azure 逻辑应用？

本指南概述了从 BizTalk Server 迁移到 Azure 逻辑应用的原因和优势、功能和其他信息。 按照本指南，你将找到更多指南，这些指南涵盖了迁移策略、规划注意事项和最佳做法，以帮助你取得成功的结果。

原因和优势

通过将集成工作负载迁移到 Azure 逻辑应用，可获得以下主要优势：

BizTalk Server 的工作原理？

BizTalk Server 使用以 MessageBox 数据库为核心的发布-订阅消息传送引擎体系结构。 MessageBox 负责存储消息、消息属性、订阅、业务流程状态、跟踪数据和其他信息。

当 BizTalk Server 收到消息时，服务器将通过管道传递并处理该消息。 此步骤规范化消息并将其发布到 MessageBox。 然后，BizTalk Server 根据消息上下文属性评估任何现有订阅并确定消息的预期收件人。 最后，BizTalk Server 根据订阅或筛选器将消息路由到目标收件人。 此收件人可以是一个业务流程编排或发送端口，即 BizTalk Server 发送消息的目标或 BizTalk Server 接收消息的源。 BizTalk Server 通过发送管道传递消息到发送端口进行传输。 在通过适配器发送消息之前，发送管道会先将消息序列化为接收方所需的本地格式。

MessageBox 数据库具有以下组件：

• 消息代理

  BizTalk Server 使用此代理与 MessageBox 交互，它提供用于发布消息、订阅消息、检索消息等的接口。

• 一个或多个 SQL Server 数据库

  这些数据库为消息、消息部件、消息属性、订阅、业务流程状态、跟踪数据、用于路由的主机队列等提供持久性存储。

下图显示了 BizTalk Server 消息传送引擎的工作原理：

接收端口收到消息后，MessageBox 会存储该消息，以便供业务流程处理或路由到任何订阅了特定消息的发送端口。

有关详细信息，请参阅本指南后面的发布-订阅体系结构。

Azure 逻辑应用：BizTalk 的继任者

Azure 逻辑应用 是来自微软的企业级工作流编排和集成平台。 此平台专为跨云和混合环境确定性、长时间运行的有状态进程而设计。 关键区别在于将低代码视觉工作流与一流的 Azure 平台功能相结合：安全性、标识、网络、监视和治理。 Azure 逻辑应用支持多个部署模型（消耗、标准、混合），使客户能够在 Azure 中完全托管或靠近本地系统运行工作流，同时保持可靠性、状态管理和可审核的执行。 这种灵活性使平台成为实现 BizTalk Server 资产现代化、协调 B2B/EDI 集成以及连接 SaaS、ERP、CRM 和传统系统（持久性和可观测性不可协商）的自然主干。

但是，Azure 逻辑应用不只是“低代码”。 客户经常将专业代码扩展功能与可视化工作流一起使用：内联 C#、JavaScript 和 PowerShell，通过在 Azure 逻辑应用中运行的本地函数及自定义连接器实现的自定义代码。 通过这种扩展性，团队可以直接在业务流程中嵌入复杂的业务逻辑、转换、协议处理和验证，而无需中断工作流模型。 在实际环境中，例如索赔处理、员工入职、合规管道、大型机和医疗保健集成，客户依赖于 Azure 逻辑应用作为受控执行层，结合确定性编排与自定义代码，并越来越多地借助 AI 辅助决策，同时保持大规模的治理、安全性和运营信心。

在 Azure 逻辑应用中，可以通过使用可视化设计器和来自数百个连接器的预生成作的“构建基块”方法来创建可执行的业务流程和应用程序作为逻辑应用工作流，这需要最少的代码。 逻辑应用工作流从一个触发器操作开始，后跟一个或多个措施操作，每个操作都作为工作流实现过程中的一个逻辑步骤。 工作流可以使用操作来调用外部软件、服务和系统。 某些动作执行编程任务，例如条件、循环、数据操作、变量管理等。

Azure 逻辑应用具有以下优势（示例）：

• 设计器优先（声明性）

  通过使用易于理解的设计工具来设计复杂的流程，以实施可能难以在代码中实施的模式和工作流。

• 代码优先开发

  使用 Visual Studio Code 创建基于代码的综合解决方案，使你能够重复使用现有的旧版 .NET Framework 代码并合并最新的 .NET 版本。

• 灵活且可缩放

  Azure 逻辑应用是一种基于云的、无服务器、高度可缩放的计算服务，可自动缩放和适应不断变化的业务需求。

开发人员体验

本部分总结了从 BizTalk Server（以 Visual Studio 为中心的）迁移到 Azure 逻辑应用（以 Visual Studio Code 为中心的）时开发工具的更改，以及许多团队为何更快地找到 Azure 逻辑应用工作流模型来生成和维护。

• 工具和创作模型

  借助 BizTalk，日常集成工作是在 Visual Studio 中进行的，并分布于多个工件类型（例如架构、映射、业务流程和管道），以及部署打包（MSI/绑定）到共享服务器环境。

  借助 Azure 逻辑应用，许多团队迁移到 Visual Studio Code，以便使用更简单的“工作流 + 连接器”方法编辑工作流定义和相关文件，从而减少解决方案复杂性，并鼓励进行更小、更增量的更改。 实际上，与保持 BizTalk 和 Visual Studio 版本一致性相比，在团队中安装、更新和标准化 Visual Studio Code 通常更快。 相比于大型编译的 BizTalk 解决方案，文本型工作流定义往往能改进 Git 差异和合并、代码评审以及重用。

• 使迁移到 Azure 逻辑应用成为一种改进的措施是什么

  Azure 逻辑应用将基于 Visual Studio Code 的开发与云原生诊断配对。 可以快速验证和更新工作流，然后使用工作流运行历史记录查看作输入和输出，而无需依赖服务器端控制台和主机实例进行故障排除。 在迁移项目中，此优势通常加快迭代（编辑、部署、更新、验证），改进了协作，因为工作流更易于查看和版本控制，并通过外部化连接和设置支持更清洁的环境分离，从而减少“它在服务器上工作”配置偏移。

连接器

连接器提供可在工作流中用作步骤的操作。 使用 Azure 逻辑应用生成工作流时，连接器可帮助你跨应用、服务、系统、协议和平台处理数据、事件和资源，而无需编写代码。 您可以为 Microsoft 和合作伙伴的服务和系统构建集成解决方案，这包括 BizTalk Server、Salesforce、Office 365、IBM 大型机、SQL 数据库，以及许多 Azure 服务，如 Azure Functions、Azure 存储和 Azure 服务总线。此外，还包括本地应用程序、SaaS 和 API。 如果想要访问的资源不存在预生成连接器，则可以使用通用 HTTP作与服务通信，也可以创建自定义连接器。

从技术上看，连接器是基础服务或系统用来与 Azure 逻辑应用通信的 API 的代理或包装器。 连接器在 Azure 逻辑应用中提供连接能力，并在通常由底层 SaaS 系统拥有的 API 之上进行抽象。 为了简化对这些 API 的调用，连接器使用元数据来描述消息传送协定，以便开发人员了解请求和响应中需要哪些数据。 然后，连接器将操作公开为触发器或操作，并且这些具有可配置属性。 某些触发器和作要求首先创建和配置与基础服务或系统的连接，并验证对用户帐户的访问权限。

Azure 逻辑应用中的大多数连接器都是内置或托管的。 某些连接器在两个版本中都可用，可用性取决于是创建消耗应用还是标准逻辑应用工作流。 对于 BizTalk Server 迁移方案，建议使用标准逻辑应用工作流，因为 BizTalk 迁移功能在标准级别可用。

对于许多 BizTalk 迁移，选择的连接器由常见的集成要求（如本地连接、文件传输（如 SFTP、消息系统和业务线系统）驱动。

• Azure 逻辑应用运行时原生运行的内置连接器。 与托管连接器相比，内置连接器通常会减少延迟，并避免对托管连接器服务的按连接调用，具体取决于连接器和方案。

• 托管连接器由 Microsoft 在 Azure 中部署、托管和管理。 这些连接器提供用于云服务、本地系统或两者皆是的触发器和操作。

在设计器的连接器库中，内置连接器显示在 “ 内置”标签下，而托管连接器显示在 “共享 ”标签下。 对于消耗逻辑应用工作流，托管连接器遵循标准或企业定价模型。

• 当不存在预生成连接器时，可以使用自定义连接器，通过使用 OpenAPI 定义来包装 REST API，或通过使用 WSDL 来包装 SOAP API。 如果要使用的 API 不存在预生成连接器，则可以创建自定义连接器，并通过具有相应权限的逻辑应用工作流访问该连接器。

对于 REST API，通常使用 OpenAPI 定义来描述 API。 对于 SOAP API，请使用 WSDL。 自定义连接器在 Azure 逻辑应用和 API 之间创建一个协定，该协定可帮助你组装请求消息并接收可在下游作中使用的类型响应。 自定义连接器可以引用公共 API 或专用 API，包括本地网络上的 API。

实现自定义连接器时，提供用于发送请求和接收类型化响应的通用接口，这简化了开发体验。

有关详细信息，请参见:

• 内置连接器概述
• 托管连接器概述
• Azure Logic Apps 中可用的托管连接器

数据整形和伪影

将集成迁移到 Azure 逻辑应用时，通常需要以下各项：

• 工作流内数据整形，例如分析、撰写和映射。

• 用于存储和部署可重用项目（如架构、地图、模板和程序集）的明确策略。

以下部分概述了用于转换的主要内置选项及其在标准工作流和共享B2B场景中支持构件的存储位置。

• 工作流中的数据整形：数据操作、表达式和 Liquid 模板

  对于逻辑应用工作流中的大多数 JSON 转换，请使用内置的数据操作（例如 Compose 操作和 Parse JSON 操作），结合表达式和工作流控制操作（例如条件和循环），来塑造数据。 对于更高级的映射方案，尤其是希望将可重用模板用于 JSON 到 JSON、JSON 到文本、XML 到 JSON 或 XML 到文本等转换时，可以使用 Liquid 模板。 Liquid 模板使用开源 Liquid 模板语言描述映射。 可以将模板作为工件与工作流一起进行版本控制和部署。

• 基于模式的 XML 操作：解析 XML 和 编写 XML

  对于逻辑应用工作流中的 XML 创建和验证方案，可以使用内置 XML 操作，例如 使用架构撰写 XML 和 使用架构解析 XML 操作。 在需要进行强类型 XML 处理（基于 XSD）而不是将负载视为纯文本时，这些操作最为有用。 例如，需要跨多个工作流一致的元素名称、数据类型和结构。

• 在标准逻辑应用中存储工件

  对于标准逻辑应用工作流，可以将集成项目存储在逻辑应用资源本身中。 在 Azure 门户中，可以将映射和架构直接上传到标准逻辑应用资源。 如果在 Visual Studio Code 中工作，可以将架构、映射和模板添加到项目项目目录下的相应文件夹，并将其与工作流一起部署。 此功能使你能够更轻松地将工件保留在源代码管理中。

  标准工作流支持从 XSLT 映射调用自定义编译程序集，例如 .NET Framework 程序集。 此支持可帮助你了解依赖于现有转换逻辑的 BizTalk 迁移方案。

• 将共享 B2B 项目存储在集成帐户中

  集成帐户是一种 Azure 资源，它提供对多个工作流可以共享的可重用 B2B 和集成项目的集中访问。 工件可以包括贸易合作伙伴、协议、XSD 架构、XSLT 映射、基于 Liquid 模板的映射、证书、批处理配置和 .NET Framework 程序集。

  通常在 B2B/EDI 场景下使用集成账户，其中希望拥有一个独立于任何单个工作流且受控管理的共享工件库。 对于标准工作流，通常可以通过使用标准逻辑应用项目打包架构、映射和模板并将其一起部署来避免集成帐户。 标准工作流还支持 从 XSLT 转换调用 .NET Framework 程序集，这在移植现有 BizTalk 映射和帮助程序库时会有所帮助。 如果更喜欢基于项目的方法，请在 Visual Studio Code 中添加架构、映射和程序集，然后部署到 Azure。

• EDI 架构：用于 B2B 集成的专用 XSD 工件

  EDI 文档架构定义 EDI 事务文档类型的结构或正文。 在 BizTalk 迁移项目中，团队通常首先重用相同的 XSD 定义，然后迭代验证特定于贸易合作伙伴的变体。 对于 Azure 逻辑应用中的工作流， Microsoft Integration GitHub 存储库 中的许多 BizTalk EDI 架构可供你公开使用。 根据实现方法，可以将这些架构与标准逻辑应用一起存储为项目项目，也可以集中存储在集成帐户中，以便跨多个工作流重复使用。

Connectivity

Azure 逻辑应用中的连接模型与 BizTalk Server 不同，部分原因是 API 经济的演变。 随着越来越多的组织公开对底层系统和数据的访问方式，需要一种与平台无关的方法。 REST 现在是设计新式 Web 服务的主要体系结构方法。

在 Azure 逻辑应用中，用于连接系统的默认方法是 REST。 由于 Microsoft 和其他软件供应商在其系统和数据的基础上公开 RESTful 服务，因此 Azure 逻辑应用可以公开和使用此类信息。 OpenAPI 规范能够实现此功能，使人类和计算机都可以通过元数据了解客户端和服务器之间的交互。 可以这样理解：请求和响应有效负载都是派生的，这意味着你可以使用动态内容来填充工作流操作的输入，并在下游操作中使用响应的输出。

身份验证方案取决于实现基础服务（由连接器调用）的软件供应商，因连接器而异。 通常，这些方案包括以下类型：

• 基本
• 客户端证书
• Active Directory OAuth
• 原始
• 托管标识

Microsoft 通过在传输过程中加密数据和进行静态数据加密来提供强大的保护层。 当 Azure 客户流量在数据中心之间（在不受 Microsoft 控制或代表 Microsoft 的某方控制的物理边界之外）移动时，会在底层网络硬件上点对点应用使用 IEEE 802.1AE MAC 安全标准 (MACsec) 的数据链路层加密方法。

Microsoft 允许你选择使用传输层安全性 (TLS) 协议来保护在云服务和客户之间传输的数据。 Microsoft 的数据中心与连接到 Azure 服务的客户端系统协商建立 TLS 连接。 TLS 提供严格的身份验证，消息隐私性和完整性强（允许检测消息篡改、拦截和伪造），此外还有良好的互操作性，算法灵活，易于部署和使用。

虽然本部分重点介绍通过连接器实现 RESTful 连接，但你也可以通过自定义连接器体验或使用 API 管理体验来实现 SOAP Web 服务连接，其中API 管理体验提供强大的 SOAP 功能。 有关详细信息，请参阅 通过将 SOAP 旧资产与 Azure 逻辑应用和 Azure API 管理集成来提高业务价值。

消息持久性

Azure 逻辑应用通过以下方式提供消息持久性：

• 标准逻辑应用中的有状态工作流使用检查点将工作流状态和作输入和输出保存到存储。 此持久性提供稳固的执行和丰富的工作流运行历史记录，以便您可以查看详细的操作输入和输出。

• 可以在 Azure 门户中或使用 API 重新提交 或重新运行工作流运行。

  重新提交可能会导致工作流再次处理相同的消息，因此请确保设计假定至少一次处理并实现 幂等性。 例如，在目标位置使用重复数据删除键、更新插入 (upsert) 或确保仅执行一次的效果。

  根据工作流类型和配置，还可以从运行中的特定点重新提交。 但是，请确保下游系统可以安全地处理重试操作和潜在重复。

• 使用 Azure 服务总线中的 窥视锁定消息传递 ，接收方可以处理消息，然后显式确认该消息。 例如，接收方可以完成消息，然后将其从队列中删除，或者接收方可以放弃该消息并使其可用于重新传送。

  若要在 Azure 逻辑应用中使用此功能，请使用 Azure 服务总线连接器。 Peek-lock 模式可提高可靠性，并支持重试或重新传送模式。 端到端精确一次处理通常仍然需要下游系统中的幂等性。

• 在使用 RabbitMQ 时，您通常可以通过使用持久队列或交换与持久消息结合的方法实现持久性，并依赖于消费者确认。这样，如果在发送确认之前处理失败，系统可以重新发送消息。 在使用 RabbitMQ 连接器进行集成时，应用与其他消息代理相同的设计原则：假设会发生重试和可能的重复，从而使下游处理实现幂等性。

• 使用 IBM MQ，通常可以通过使用持久性消息和事务处理（工作单元）解决持久性和可靠的传递问题。 然后，你能够一起提交或回滚已接收的消息及其后续工作。 如果在提交工作之前发生故障，或者确认了消息，则消息可能可用于重新传送。

  使用 IBM MQ 连接器时，请针对至少一次交付进行设计，并在目标处处理可能的重复项。 在 BizTalk 迁移方案中，此模式通常映射到设计逻辑应用工作流和下游终结点进行安全重新处理，例如，通过使用相关标识符、重复数据删除和幂等写入，而不是仅依赖代理进行端到端（恰好一次）的行为。

发布-订阅体系结构

与 BizTalk Server 消息传送引擎相比，Azure 逻辑应用使用连接器和外部消息传送服务来实现与工作流业务流程一起的消息传送模式。 对于使用 Azure 逻辑应用的发布-订阅（pub-sub）模式，常见的中转站选项包括 Azure 服务总线（主题和订阅）和 RabbitMQ。 Azure 服务总线 是一个完全托管的企业消息代理，具有队列和发布-订阅主题，可以用于解耦应用程序和服务，从而提供以下优势：

• 跨竞争工作者进行负载均衡。
• 通过控制在服务和应用程序边界之间安全地路由和传输数据。
• 协调需要高度可靠性的事务性工作。

Azure 逻辑应用包括一个可用于发布和订阅消息的 Azure 服务总线连接器。 使用它的优势是，可以独立于工作流使用消息传送。 与 BizTalk Server 不同，消息传送与工作流引擎分离。 可以在 Azure 服务总线中创建消息订阅，并使用 消息属性（用户属性） 作为由 主题订阅上的筛选器评估的键值对。 通过添加一个或多个键值对来设置 Azure 服务总线操作时，可以定义这些用户属性。 有关演示，请参阅视频：使用 Azure Integration Services 的发布/订阅消息传递 - 第 2 部分：基于内容的路由。

具有标准工作流的 Azure 逻辑应用还包括一个 RabbitMQ 内置连接器，可用于发送和接收消息。 在 RabbitMQ 中，通常通过发布到一个交换器来实现发布-订阅模式，并让多个消费者通过绑定到该交换器的单独队列接收消息，通常使用基于交换器类型的路由键或基于消息头的路由。 此方法支持扇出和基于路由的分发模式，类似于服务总线主题和订阅规则，但使用 RabbitMQ 交换、绑定和队列设置进行配置。 如果现有的本地 RabbitMQ 部署、在 Azure 服务总线不可用的环境中需要代理功能，或者想要将消息传输限制在生产者和消费者运行的网络中，则 RabbitMQ 通常是一个强有力的选择。 与任何基于代理的集成一样，应针对重试和潜在的重复项进行设计，例如，在适当情况下使用确认、持久队列和持久消息，并且使后续处理保持幂等性。

对于许多 BizTalk 迁移项目，Azure 服务总线是用于云原生发布-订阅（pub-sub）的常见默认选择，因为该服务是完全托管的，并提供带有过滤功能的内置主题和订阅语义。 对于本地发布-订阅需求，RabbitMQ 可能更适合，尤其是在 Azure Logic Apps 混合部署模式中，因为 Azure 服务总线是一种云服务，并不提供本地部署选项。 在这些情况下，标准化持久性和重试语义，并在工作流和终结点边界上应用幂等性。

业务规则引擎

Azure 逻辑应用包括 Azure 逻辑应用规则引擎。 该规则引擎包含 BizTalk 业务规则引擎 (BRE) 运行时，因此你可重复使用现有的 BizTalk BRE 策略。 目前，仅支持 XML 和 .NET Framework。

网络

对于入站和出站连接，Azure 提供了多种方式来隔离其网络边界内的服务，并连接本地和云工作负载。 以下列表描述了将 Azure 资源与网络边界内的资源集成的不同方式：

• 混合连接

  混合连接既是一个 Azure 服务，也是 Azure 应用服务中的一个功能，支持的场景和提供的能力超越了 Azure 应用服务。 若要详细了解如何在 Azure 应用服务之外使用，请参阅 Azure 中继混合连接。 在 Azure 应用服务中，可以使用混合连接访问可通过端口 443 对 Azure 进行出站调用的任何网络中的应用程序资源。 混合连接提供从应用到 TCP 终结点的访问权限，但并不提供新的访问应用的方式。 在 Azure 应用服务中，每个混合连接都与单个 TCP 主机和端口组合相关联。 此功能使应用能够访问任何 OS 上的资源，前提是存在 TCP 终结点。 混合连接不知道或不关心应用程序协议或你要访问的内容。 此功能只提供网络访问。

• 虚拟网络集成

  通过 Azure 虚拟网络集成，可以将 Azure 资源连接到 Azure 中配置的虚拟网络，使应用能够访问该虚拟网络中的资源。 Azure 逻辑应用中的虚拟网络集成仅用于从 Azure 资源向虚拟网络发出出站调用。

  使用虚拟网络对等互连，你可以将本地网络连接到 Azure，从而在本地资源和 Azure 服务之间提供双向连接。 Azure 集成服务提供虚拟网络连接，允许混合集成。

  下图显示了标准逻辑应用资源，其中打开了“网络”页面并启用了虚拟网络集成，如“出站流量”框中突出显示的那样。 此配置可确保所有出站流量都从此虚拟网络流出。

  

• 专用终结点

  专用终结点是使用虚拟网络中的专用 IP 地址的网络接口。 此网络接口通过专用且安全的方式连接到由 Azure 专用链接提供支持的 Azure 资源。 通过启用专用终结点，你将该 Azure 资源引入虚拟网络并允许网络中的资源对 Azure 资源进行入站调用。

自定义代码

在 Azure 逻辑应用中，可以在标准逻辑应用工作流中创作和运行 .NET 代码。 为此，你需要使用具有 Azure 逻辑应用（标准版）扩展的 Visual Studio Code。

内联代码操作连接器提供名为“执行 JavaScript 代码”的动作、“执行 CSharp 脚本代码”的动作和“执行 PowerShell 代码”的动作。 可以使用这些操作来添加支持动态内容输入和输出的代码。 Azure 逻辑应用引擎预期此代码的执行时间较短。 代码执行完成后，输出可用于工作流中的下游操作。

如前所述，将这些程序集上传到集成帐户时，当前在逻辑应用工作流中提供了从 XSLT 映射调用 .NET Framework 程序集的支持。 此功能有助于支持自定义数据转换规则。 对于标准逻辑应用工作流，无需集成帐户即可从 XSLT 映射调用 .NET Framework 代码。 你还可以将程序集和映射添加到 Visual Studio Code 中的标准逻辑应用项目，然后部署到 Azure。 有关详细信息，请参阅 在 Azure 逻辑应用（标准）XSLT 转换中添加的 .NET Framework 程序集支持。

应用程序组

在 Azure 逻辑应用中，可以在标准逻辑应用资源中包括和运行多个工作流，从而导致一对多关系。 如果你在本地处理 Visual Studio Code 中的标准逻辑应用项目，你的逻辑应用资源将映射到此单个项目。 使用这种方法，你可以轻松且合乎逻辑地将同一项目中的相关工作负荷、代码和生成工件分组，并将该项目作为一个单元进行部署。

云体系结构的工作方式不同于基于服务器的范例，例如 BizTalk。 Azure 逻辑应用（标准）使用拉取模型引入代码和工件。 因此，你将把任何其他必要的工件复制到你的项目中，然后与代码和其他工件一起部署它们。 在某些情况下，你可能希望避免复制必要的代码和工件。 如果是这样，可以考虑将此功能转变为一项可以单独管理但可以从工作流调用的服务。

例如，假设你有一个被组织广泛使用的数据转换。 与其在多个逻辑应用项目中包含转换映射，不如实现一个将转换作为服务提供的接口。 然后，你可以独立于逻辑应用项目管理该服务的生命周期，并从工作流中调用该服务。

由于能够在标准逻辑应用项目中包含多个工作流，你可能会问：如何在一个项目内或跨多个项目组织这些工作流？ 答案通常取决于你的要求，例如：

• 业务流程相关性
• 端到端监控和支持
• 安全性、基于角色的访问控制和网络隔离
• 性能和业务关键性
• 地理位置和异地冗余

有关详细信息，请参阅在 Azure 逻辑应用（标准）中组织逻辑应用工作流。

安全和调控

Azure 逻辑应用支持以下安全功能：

• Azure Key Vault

  可以使用 Azure 密钥保管库存储凭据、机密、API 密钥和证书。 在 Azure 逻辑应用中，可以使用 Azure 密钥保管库连接器访问此信息，并可使用安全输入和输出功能从平台的日志和运行历史记录中排除此信息。

  在跟踪部分的后面部分，本指南介绍运行历史记录功能，该功能提供工作流执行的分步重播。 尽管 Azure 逻辑应用提供了捕获工作流运行中的每个输入和输出的价值主张，但有时你需要更精细地管理对敏感数据的访问。 可以通过对触发器和操作使用安全输入和输出功能来为此数据设置模糊处理，以在运行历史记录中隐藏此类内容，并防止将此数据发送到 Azure Monitor，特别是 Log Analytics 和 Application Insights。 下图显示了在运行历史记录中启用安全输入和安全输出的示例结果。

  

• 基于 OAuth 的集成

  大多数连接器在创建连接时使用此身份验证类型。 这种方法使得与许多 SaaS 服务的集成就像提供电子邮件地址和密码一样简单。 Azure API 管理还支持 OAuth，因此你可以通过提供统一的身份验证方案来同时使用这两种服务。

  BizTalk Server 本身不提供此功能。

• 托管身份

  Azure 逻辑应用（标准版）可以使用托管标识对存储帐户的访问进行身份验证。 此外，某些连接器支持使用托管标识对 Microsoft Entra ID 保护的资源的访问权限进行验证。 使用托管标识对连接进行身份验证时，无需提供凭据、密码或 Microsoft Entra 令牌。

应用程序管理和访问管理

Azure 门户是管理员和支持人员用来查看和监视接口运行状况的常用工具。 对于 Azure 逻辑应用，此体验包括可通过运行历史记录获得的丰富事务跟踪。 此外还提供精细的基于角色的访问控制 (RBAC)，因此你可以管理和限制对各个级别的 Azure 资源的访问。

存储

Azure 逻辑应用依赖 Azure 存储来存储和自动加密静态数据。 此加密可保护数据，并帮助你履行组织的安全性和符合性承诺。 默认情况下，Azure 存储使用 Microsoft 托管密钥来加密数据。 有关详细信息，请参阅静态数据的 Azure 存储加密。

在 Azure 门户中使用 Azure 存储时， 所有事务都通过 HTTPS 进行。 还可以通过 HTTPS 使用存储 REST API 来使用 Azure 存储。 若要在调用 REST API 以访问存储帐户中的对象时强制使用 HTTPS，请启用存储帐户所需的安全传输。

Azure 逻辑应用（标准）混合部署模型依赖于 SQL Server。 通过此依赖项，可以将现有的本地 SQL Server 环境与 BizTalk Server 配合使用。

大型文件处理

使用 BizTalk Server 处理大型文件与 Azure 逻辑应用之间存在一些基本差异。 例如，仔细检查大型消息方案以找到正确的解决方案，因为在新式云环境中可能存在解决此问题的不同方法。

文件大小限制

在 Azure 中，存在文件大小限制是为了确保一致和可靠的体验。 若要验证方案，请务必查看 Azure 逻辑应用的服务限制文档。 某些连接器支持对超过默认消息大小限制的消息进行消息分块，该限制因连接器而异。 消息分块是指将大消息拆分为较小的消息。

Azure 逻辑应用不是唯一具有消息大小限制的服务。 例如，Azure 服务总线也有此类限制。 若要详细了解如何在 Azure 服务总线中处理大型消息，请参阅大型消息支持。

为避免文件大小限制，可以实现认领凭证模式，该模式的工作方式是将大消息拆分为认领凭证和有效负载。 请将认领凭证发送到消息传送平台，并将有效负载存储到外部服务。 这样你就可以处理大型消息，同时保护消息总线和客户端，使之免于过载。 此模式还有助于降低成本，因为存储通常比消息传送平台使用的资源单位更便宜。

监视和警报

在 Azure 逻辑应用中，可以启用 Application Insights 支持，该支持提供特选可视化效果作为监视 Azure 服务的基础。 这些可视化效果使用专为 Azure 逻辑应用（标准版）设计的仪表板，帮助你更有效地监视标准工作流。 该仪表板范围涵盖标准逻辑应用中的工作流。 仪表板基于 Azure 工作簿构建，提供各种可视化效果。 可以轻松扩展和自定义这些工作簿来满足特定需求。

Serverless 360 是来自 Kovai 的外部解决方案，它通过映射 Azure 服务（例如 Azure 逻辑应用、Azure 服务总线、Azure API 管理和 Azure Functions）来提供监视和管理。 你可以使用 Azure 服务总线中的死信队列重新处理消息、启用自我修复以解决间歇性服务中断问题，以及通过综合事务设置主动监视。

你可以在门户体验中配置自定义监视规则和查看日志。 你可以通过各种渠道（例如电子邮件、Microsoft Teams 和 ServiceNow）发送通知。 若要直观地确定接口的运行状况，可以使用服务映射。

业务活动监视

作为使用各种 Azure 资源集成服务和系统的解决方案的开发人员或业务分析师，你可能难以直观了解解决方案中的技术组件与业务方案之间的关系。 为了在解决方案中包含有关 Azure 资源的业务上下文，你可以构建业务流程，以直观呈现这些资源实现的业务逻辑。 在 Azure 业务流程跟踪中，业务流程是一系列阶段，代表流经实际业务方案的任务。

另一种选择是你可以使用来自 Kovai 的名为 Serverless 360 的外部解决方案。 除了监视平台，还可以使用业务活动监视功能，该功能为跨云原生集成和混合集成的业务流程提供端到端跟踪。 该功能包括一个托管连接器，开发人员可以使用它来检测代码和捕获重要的业务数据。 管理员随后可以构建仪表板并将其与业务分析师共享。

跟踪

Azure 逻辑应用提供丰富的工作流运行历史，以便开发人员和支持分析师可以查看逐个操作的遥测数据，包括所有已处理的输入和输出。 为帮助保护任何敏感数据，你可以对工作流中的各个操作启用安全输入和输出。 此功能会对日志和工作流运行历史记录中的数据进行模糊处理或将其隐藏，以避免泄漏。

除了对数据进行模糊处理之外，还可以使用 Azure RBAC 规则来保护数据访问。 Azure RBAC 包括 Azure 逻辑应用（标准版）的特定内置角色。 除了 Azure RBAC，还可以 按 IP 地址范围限制对 Azure 逻辑应用中的运行历史记录的访问。

Hosting

• 托管计划

  在单租户 Azure 逻辑应用中，可以使用单个工作流服务计划托管多个标准逻辑应用。 这意味着无需在单个标准逻辑应用资源中部署所有工作流。 而是可以将这些工作流组织成逻辑组（逻辑应用），以便更好地管理解决方案的其他方面。 这种方法可帮助你充分利用工作流服务计划，并使你的应用程序在未来仍具竞争力。你可以实施这些应用程序，以便它们能够单独扩展。

  标准逻辑应用具有以下定价层：WS1、WS2 和 WS3。 从功能上讲，每一层都提供相同的功能。 计算和内存的要求决定了最适合你的方案，例如：

  定价层	虚拟 CPU (vCPU)	内存 (GB)
  WS1	1	3.5
  WS2	2	7
  WS3	4	14

  有关详细信息，请参阅标准模型中的定价层。

• 可用性和冗余

  在 Azure 中，可用性区域提供复原能力、分布式可用性和主动-主动-主动区域的可伸缩性。 若要提高逻辑应用工作负载的可用性，可以启用可用性区域支持，但前提是你要创建逻辑应用。 在任何支持和启用区域冗余的 Azure 区域中，至少需要三个单独的可用性区域。 Azure 逻辑应用平台跨这些区域分发这些区域和逻辑应用工作负载。 如果某个区域发生数据中心故障，此功能是启用可复原体系结构和提供高可用性的关键要求。 有关详细信息，请参阅使用可用性区域构建高可用性解决方案。

• 隔离的专用环境

  对于标准逻辑应用，你可以为部署环境选择应用服务环境 (ASE) v3。 使用 ASE v3，你将获得一个完全隔离的专用环境，以可预测的价格大规模运行应用程序。 无论你创建和运行多少逻辑应用，都只需为 ASE 应用服务计划付费。

有关需要其他 Azure 集成服务的场景，请参阅以下文档：

• Azure 服务总线高级和标准消息传送层
• Azure API 管理 - 基于功能的层级比较

部署

Azure 逻辑应用通过提供使用 Azure 资源管理模板创建基础结构资源的功能来支持基础结构即代码（IaC）。 尽管 ARM 模板作为一个统一的解决方案来理解和实现似乎很复杂，但你可以使用抽象工具（例如 Bicep、Terraform 或 Pulumi），它们为创建基础结构定义提供了类似代码的体验。 尽管这些工具提供了基于 ARM 模板的抽象层，但这些工具最终会生成 ARM 模板并可为你部署这些模板。

基础结构就绪后，可以部署实现端到端工作流程的逻辑。 由于 Azure 集成服务为你提供了一组工具来实现集成工作流，因此你必须部署每个组件。 对于使用 Azure 集成服务构建的解决方案，CI/CD 管道通常基于组件编排的部署。 DevOps 工程师可以使用会抽象部署活动的内置操作，也可以使用运行 CLI 命令或自动化脚本（如 PowerShell 和 Bash）的通用操作。 在大多数情况下，工程师会根据应用程序的需求自定义管道、查看官方文档中的指南，并从使用示例存储库着手。

若要使每个组件都做好部署准备，通常需考虑以下步骤：

• 持续集成阶段

  1. 获取源代码的最新版本。

  2. 使用特定于环境的配置来准备代码。

     此步骤的细节取决于每种技术是否支持外部注入环境变量。 基本前提是基于环境的配置信息（例如连接字符串和对外部资源的引用）被抽象为引用应用程序设置存储库。 因此，在这种情况下，您可以将可以明文存在的引用直接存储在应用程序设置存储库中，而将敏感信息（例如机密）作为引用指针存储到机密存储中，例如 Azure 密钥保管库。

     Azure Logic Apps 通过支持对应用程序设置存储库的引用，使得标准逻辑应用资源能够使用这种方法。然后，您可以将名称-值对映射到密钥保管库中的相应条目。

  3. 打包代码以在各种环境中进行部署。

• 持续部署阶段

  1. 在目标环境中部署打包的代码。

  2. 使用正确的环境值更新应用程序设置存储库，这些值可以是明文形式，也可以是对密钥保管库中条目的引用。

  3. 更新任何依赖于代码的必需权限。

  4. 让应用程序准备好执行（如果需要）。

特性对比

下表和关系图显示了如何比较和匹配 BizTalk Server、Azure 逻辑应用（标准）和其他服务之间的资源、项目、特性和功能。 尽量使用 Azure 逻辑应用功能构建一个具有凝聚力、更具成本效益的解决方案。

Azure 逻辑应用标准版（云）

若要及时了解最新投资，请订阅 Azure 博客上的集成 - 技术社区。

后续步骤

你了解了 Azure 逻辑应用与 BizTalk Server 的比较方式的详细信息。 接下来，查看建议的方法和资源、规划注意事项和迁移最佳做法。