为什么从 BizTalk Server 迁移到 Azure Logic Apps？

本指南概述了从 BizTalk Server 迁移到Azure Logic Apps的原因和优势、功能和其他信息。 按照本指南，您将找到更多指南，这些指南涵盖迁移策略、规划注意事项和最佳实践，以帮助您实现成功的结果。

原因和优势

通过将集成工作负载迁移到 Azure Logic Apps，可以受益于以下主要优势：

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 Logic Apps：BizTalk 的继任者

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

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

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

Azure Logic Apps提供以下示例优势：

• 设计器优先（声明性）

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

• 代码优先开发

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

• 灵活且可缩放

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

开发人员体验

本部分总结了从 BizTalk Server（以Visual Studio为中心的）迁移到Azure Logic Apps（以Visual Studio Code为中心的）时开发工具的变化，以及为什么许多团队发现Azure Logic Apps的工作流模型更容易构建和维护。

• 工具和创作模型

  借助 BizTalk，日常的集成工作在 Visual Studio 中进行，涉及多种项目类型，例如架构、映射、业务流程编排和管道，以及将部署打包（如 MSI 安装包和绑定）到共享的服务器环境中。

  借助 Azure Logic Apps，许多团队转向使用 Visual Studio Code，通过采用更简单的“工作流 + 连接器”方法来编辑工作流定义和相关文件，从而降低解决方案的复杂性，并鼓励进行更小、更逐步的更改。 在实践中，Visual Studio Code 通常比保持 BizTalk 和 Visual Studio 版本一致性的跨团队安装、更新和标准化速度更快。 相比于大型编译的 BizTalk 解决方案，文本型工作流定义往往能改进 Git 差异和合并、代码评审以及重用。

• 是什么使迁移到Azure Logic Apps成为一种改进

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

连接器

连接器提供可在工作流中用作步骤的操作。 使用 Azure Logic Apps 生成工作流时，连接器可帮助跨应用、服务、系统、协议和平台处理数据、事件和资源，而无需编写代码。 可以为来自 Microsoft 和其合作伙伴的服务与系统构建集成解决方案，包括 BizTalk Server、Salesforce、Office 365、IBM 大型机、SQL 数据库，以及许多 Azure 服务，如 Azure Functions、Azure Storage 和 Azure Service Bus，还支持本地应用程序、SaaS 和 API。 如果想要访问的资源没有预构建连接器，则可以使用通用 HTTP 操作与服务进行通信，或者创建自定义连接器。

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

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

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

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

• 托管连接器由Azure中的Microsoft进行部署、托管和管理。 这些连接器为云服务、本地系统或两者兼有提供触发器和动作。

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

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

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

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

有关详细信息，请参见:

• 内置连接器概述
• 托管连接器概述
• Azure Logic Apps 中提供的托管连接器

数据整形和伪影

将集成迁移到Azure Logic Apps时，通常需要以下各项：

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

• 用于存储和部署可重用工件（如架构、映射、模板和程序集）的明确策略。

以下部分总结了转换的主要内置选项，以及用于存储标准工作流和共享 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 portal中，可以将映射和架构直接上传到标准逻辑应用资源。 如果在 Visual Studio Code 中工作，可以将架构、映射和模板添加到project Artifacts目录下的相应文件夹，并将其与工作流一起部署。 此功能使你能够更轻松地将artifacts保留在源代码管理中。

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

• 将共享 B2B 工件存储在集成帐户中

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

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

• EDI 模式：用于 B2B 集成的专门 XSD 架构文档

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

Connectivity

Azure Logic Apps中的连接模型与 BizTalk Server 不同，部分原因是 API 经济的演变。 随着更多的组织公开基础系统和数据的访问权限，需要一种平台无关的策略。 REST 现在是设计新式 Web 服务的主要体系结构方法。

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

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

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

Microsoft 通过在传输过程中加密数据和进行静态数据加密来提供强大的保护层。 当 Azure 客户的流量在数据中心之间移动，超出 Microsoft 或代表 Microsoft 控制的物理边界时，将使用 IEEE 802.1AE MAC 安全标准（MACsec） 的数据链路层加密方法，从基础网络硬件的点到点进行加密。

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

虽然本部分重点介绍通过连接器实现 RESTful 连接，但可以通过自定义连接器体验或使用提供出色的 SOAP 功能的 API Management 体验来实现 SOAP Web 服务连接。 有关详细信息，请参阅 通过将 SOAP 遗留资产与 Azure Logic Apps 和 Azure API Management 集成来提高业务价值。

消息持久性

Azure Logic Apps通过以下方式提供消息持续性：

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

• 可以在 Azure portal 中或通过 API 重新提交或重新运行工作流运行。

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

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

• 使用 Azure Service Bus 中的 peek-lock 消息传送，接收方可以处理消息，然后显式确认该消息。 例如，接收方可以完成消息，然后将其从队列中删除，或者接收方可以放弃该消息并使其可用于重新传送。

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

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

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

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

发布-订阅体系结构

与 BizTalk Server 消息传递引擎相比，Azure Logic Apps 使用连接器和外部消息传送服务，在实现工作流编排的同时执行消息传递模式。 对于 Azure Logic Apps 中的发布-订阅（pub-sub）模式，常见的代理选项包括 Azure Service Bus（主题和订阅）和 RabbitMQ。 Azure Service Bus是一个完全托管的企业消息中转站，其中包含可用于分离应用程序和服务的队列和发布子主题，可提供以下优势：

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

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

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

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

业务规则引擎

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

网络

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

• 混合连接

  混合连接既是Azure服务中的一项服务，也是Azure App Service中的一项功能。它支持场景，并提供Azure App Service之外的额外功能。 有关Azure App Service外部使用情况的详细信息，请参阅 Azure Relay 混合连接。 在 Azure 应用服务中，您可以使用混合连接来访问任何通过端口 443 能够对 Azure 发出出站请求的网络中的应用程序资源。 混合连接提供从应用到 TCP 终结点的访问，并且没有启用访问应用的新方法。 在Azure App Service中，每个混合连接都与单个 TCP 主机和端口组合相关联。 通过此功能，应用可以在任何 OS 上access资源，前提是存在 TCP 终结点。 混合连接既不知晓也不关心应用程序协议或您想访问的内容。 此功能仅仅提供网络访问。

• 虚拟网络集成

  通过集成Azure 虚拟网络，您可以将 Azure 资源连接到 Azure 中配置的虚拟网络，从而使您的应用能够访问该虚拟网络中的资源。 Azure Logic Apps 中的虚拟网络集成仅用于从 Azure 资源进行到虚拟网络的出站调用。

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

  下图显示了一个标准逻辑应用程序资源，打开了“网络”页并启用了虚拟网络集成，如Outbound Traffic 框中所示。 此配置可确保所有出站流量通过此虚拟网络发送。

  

• 专用终结点

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

自定义代码

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

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

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

应用程序组

在Azure Logic Apps中，可以在标准逻辑应用资源中包含和运行多个工作流，从而导致一对多关系。 如果您在 Visual Studio Code 中本地处理标准逻辑应用项目，则逻辑应用资源将映射到此单个项目。 使用此方法，可以在同一project中轻松、逻辑地对相关工作负荷、代码和artifacts进行分组，并将该project部署为单个单元。

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

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

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

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

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

安全和调控

Azure Logic Apps支持以下安全功能：

• Azure Key Vault

  可以使用 Azure Key Vault 存储凭据、机密、API 密钥和证书。 在 Azure Logic Apps 中，可以使用 Azure Key Vault 连接器 访问此信息，并通过使用 安全输入和输出功能 将此信息排除在平台的日志和运行历史之外。

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

  

• 基于 OAuth 的集成

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

  BizTalk Server 本身不提供此功能。

• 托管身份

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

应用程序管理和访问管理

Azure portal 是管理员和支持人员用来查看和监视接口运行状况的常见工具。 对于 Azure Logic Apps，该体验包括可通过运行历史记录获取的丰富事务追踪。 还可以使用精细角色基础访问控制（RBAC），以便在不同级别管理和限制对Azure资源的访问。

存储

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

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

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

大型文件处理

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

文件大小限制

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

Azure Logic Apps不是唯一具有消息大小限制的服务。 例如，Azure Service Bus 也有类似的限制。 有关在 Azure Service Bus 中处理大型消息的详细信息，请参阅 Large 消息支持。

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

监视和警报

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

Serverless 360 是来自 Kovai 的外部解决方案，它通过映射 Azure 服务（如 Azure Logic Apps、Azure Service Bus、Azure API Management 和 Azure Functions）提供监视和管理。 可以使用 Azure Service Bus 中的死信队列来重新处理消息，启用自我修复功能以解决间歇性服务中断问题，并通过合成事务设置主动监控。

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

业务活动监视

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

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

跟踪

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

除了数据混淆之外，还可以使用 Azure RBAC 规则来保护数据访问。 Azure RBAC 包括 Azure Logic Apps（Standard）的特定内置角色。 除了 Azure RBAC，你还可以按 IP 地址范围限制对 Azure Logic Apps 运行历史记录的访问。

Hosting

• 托管计划

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

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

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

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

• 可用性和冗余

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

• 隔离的专用环境

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

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

• Azure Service Bus高级和标准消息传送层
• Azure API Management - 基于功能的层比较

部署

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

基础结构就绪后，可以部署实现端到端工作流程的逻辑。 由于 Azure Integration Services 提供了一系列工具来实现集成工作流，因此必须部署每个组件。 对于使用 Azure Integration Services 构建的解决方案，CI/CD 流水线通常基于组件的编排进行部署。 DevOps 工程师可以使用会抽象部署活动的内置操作，也可以使用运行 CLI 命令或自动化脚本（如 PowerShell 和 Bash）的通用操作。 在大多数情况下，工程师根据应用程序的需求自定义流水线，参考官方文档的指导，并使用示例代码库作为起点。

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

• 持续集成阶段

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

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

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

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

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

• 持续部署阶段

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

  2. 使用正确的环境值更新应用程序设置存储库，可以将其作为明文形式或密钥库中条目的引用进行更新。

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

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

特性对比

下表和关系图展示了 BizTalk Server、Azure Logic Apps（标准）以及其他服务之间的资源、工件、特性和功能的比较和匹配方式。 尽量使用Azure Logic Apps功能来构建一个具有凝聚力、更具成本效益的解决方案。

Azure Logic Apps标准版（云）

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

后续步骤

你了解了更多关于 Azure Logic Apps 与 BizTalk Server 之间的比较。 接下来，查看建议的方法和资源、规划注意事项和迁移最佳做法。