通过

你当前正在访问 Microsoft Azure Global Edition 技术文档网站。 如果需要访问由世纪互联运营的 Microsoft Azure 中国技术文档网站，请访问 https://docs.azure.cn。

将 BizTalk Server 迁移到 Azure Integration Services 的迁移方法

  • 项目

本指南介绍迁移策略和资源，以及规划注意事项和最佳做法，以帮助你交付成功的迁移解决方案。

注意

有关在 Azure 中为迁移选择服务的迁移概述和指南，请查看以下文档：

策略选项

以下部分介绍各种迁移策略及其优点和缺点：

直接迁移

在Azure 市场中，可以找到使用即用即付模型预配包含 BizTalk 许可的虚拟机的选项。 此产品/服务通过基于消费的定价模型提供了使用 Microsoft 的基础结构即服务 (IaaS) 功能的好处。 尽管使用这些虚拟机可以缓解管理 BizTalk Server 基础结构方面的一些挑战，但此方法不能解决 BizTalk Server 的支持生命周期计划和截止时间。

随着组织通过迁移到或采用云来接受数字化转型，许多组织需要执行一些常见任务，即停止其 VMware、Hyper-V 或物理服务器基础结构，并将此功能迁移到 Azure 上的 IaaS。 此选项有助于减少前面提到的挑战，但不能解决 BizTalk 代码库问题。

使用 BizTalk Server 2013 及更高版本时，可以选择像以前一样在本地运行 BizTalk 服务器，或在 Azure 中的虚拟服务器上运行它们。 在云中运行 BizTalk 服务器环境具有以下优点：

  • 无需专用硬件或基础结构，因此无需硬件维护。
  • 提高了服务器基础结构的可用性，可以跨多个数据中心或在可用性区域中复制。
  • 通过 Internet 从任意位置访问服务器。
  • Microsoft 将备份你的映像。
  • 使用 Azure 市场上提供的内置映像快速部署新服务器。
  • 通过更改虚拟机大小以添加内存和 CPU、添加硬盘驱动器等，为服务器快速纵向扩展
  • 使用 Azure 安全中心提高了环境的安全性。 此服务可识别安全威胁，并在发生安全事件时提供调查路径

混合集成

尽管 BizTalk Server 和 Azure 集成服务功能可能重叠，但将它们一起使用时效果会更好。 大多数没有将其整个基础架构迁移到云的组织主要有以下原因：

  • 公司政策
  • 国家/地区政策
  • 行业领域特定的策略

此外，并非所有功能或应用程序都存在于云中，或者某些可用的功能或应用程序可能不如本地功能或应用程序可靠。 但是，为了跟上云革命的步伐并扩展业务功能，许多组织首先将 SaaS 产品/服务与其本地系统一起使用。 许多业务流程都可以从基于云的开发和实施策略中受益。

通过采用混合集成策略，你仍然可以从组织所依赖的系统的技术投资中获得价值，但仍可以从基于云的应用程序（如 Azure）的新功能、改进的性能和更低的成本结构中受益。

在 BizTalk Server 2016 中，适用于逻辑应用的 Microsoft BizTalk Server 适配器的独立版本使你有机会使用 Azure 逻辑应用连接数百个云服务，从而在 Azure 上作为服务而实现集成逻辑的一部分。 此适配器通过提供以下功能，帮助实现本地集成和混合集成：

  • 使用内置适配器（如 Azure 逻辑应用、Azure 服务总线、Azure 事件中心、Azure Blob 存储和 Office 365 邮件、计划和联系人）将云服务与 BizTalk Server 集成。

  • 使用 Azure 逻辑应用中的 BizTalk Server 连接器从 Azure 逻辑应用连接到 BizTalk 服务器。

  • 使用 Azure API 管理发布 BizTalk Server 终结点，以便组织可以向内部开发人员和外部合作伙伴公开终结点。

使用 BizTalk Server 2020，安装会自动包括 Azure 逻辑应用的适配器以及用于轻松连接到云环境的内置适配器。

大爆炸

“大爆炸”或“直接转换”方法需要大量规划，不建议不熟悉 Azure 逻辑应用或有大型系统或解决方案进行迁移的组织使用。 当组织实施新技术堆栈时，通常需要学习新的知识。 如果投资过早或过多，你将没有机会从经验教训中受益，并且无法在不冒大量返工风险的情况下进行调整。

此方法可能还需要更长的时间才能获得或累积价值。 如果已完成某些迁移活动，但由于其他挂起或正在进行的工作而尚未将其发布到生产中，则迁移的项目不会为组织产生价值。

这种方法为你的组织提供了增量实现价值的机会，但比其他方法更快。 项目团队可以使用回顾来尽早了解技术堆栈。 例如，可以将现有的 BizTalk 接口或项目部署到生产环境，然后了解解决方案的需求，包括管理、可伸缩性、操作和监视。 获得这些知识后，可以规划冲刺以优化现有功能或引入可在后续工作中使用的新模式。

无论采用哪种方法，如果计划迁移到 Azure 集成服务或一般的 Azure，请在停用服务器基础结构之前，强烈建议考虑将 BizTalk Server 解决方案重构为无服务器或云原生解决方案。 如果你的组织希望将业务完全转变为云，则此选择是一个很好的策略。

规划迁移

以下部分提供有关规划迁移和要考虑的方面的指导。

就绪规划

就绪是规划过程中的关键部分。 了解项目的广度和深度后，可预测性会提高多个维度，例如成本、复杂性、时间线和项目的整体成功率。 以下列表包括作为项目章程流程的一部分要审查和解决的特定领域。

区域 说明
库存 捕获有关所有接口和应用程序的数据，以便了解需要迁移的接口和应用程序的数量。 在此编录过程中，请收集以下信息以提供上下文：

- 正在使用的适配器
- 正在使用的 BizTalk Server 功能，例如业务活动监视、业务规则引擎、EDI 等
- 自定义代码，例如表达式、映射和管道组件
- 消息吞吐量
- 消息大小
- 依赖项
复杂性 为了帮助你了解接口中的复杂程度，请检查这些接口中的业务规则类型以及需要自定义以满足其需求或性能要求的技术要求。
值 评估接口的价值，以便确定要重新实现的接口的优先级。 虽然从低风险接口开始可能有意义，但熟悉 Azure Integration Services 后，请确保首先专注于最高价值的工作。
成本 确定项目的范围并估算成本，因为迁移项目需要资金才能开始执行。 确保项目预算（无论是通过资本还是运营预算规划实现），并在此过程中管理项目的范围。
应用程序和系统依赖项 在开始项目规划时识别并考虑这些依赖项，以便在开始执行项目时避免意外情况。
风险登记表 创建并使用此项目来识别和跟踪在完成项目规划练习时出现的任何风险。 了解风险后，可以主动缓解风险，并传达给领导层。 还可以及早消除阻碍因素，以免之后的解决成本过高。

迁移工具

Azure Integration Migrator 命令行工具（也称为 BizTalk 迁移工具）是一个 Microsoft 开源项目，可在迁移项目的规划和执行阶段以及将 BizTalk Server 应用程序迁移到 Azure Integration Services 时为你提供帮助。 还可以使用此工具发现将解决方案迁移到云的有用见解和策略。

此工具在以下阶段中运行：

  1. 发现

    拉取 BizTalk Server 资源，并标识要迁移的 BizTalk 项目。 读取程序集和绑定文件信息。

    要求：BizTalk Server 应用程序的 MSI 和所有引用的 BizTalk Server 应用程序

  2. Parse

    读取 BizTalk Server 项目并为 BizTalk Server 应用程序生成源数据模型。

  3. 分析

    使用“分析”阶段中的源数据模型生成 Azure 集成服务目标数据模型。 基本上，该工具会查看 BizTalk Server 资源，确定哪些项可以迁移，并生成 Azure 集成服务目标的数据模型。 

  4. Report

    生成一个报表，其中概述了找到的 BizTalk Server 资源和可以迁移的项。 该报告还包含有关源和目标应用程序中内容的详细信息，以及有关转换的任何潜在问题的详细信息。

  5. 转换

    生成 Azure 管理器资源模板和 Azure CLI 脚本，可用于使用目标数据模型在 Azure 中生成应用程序。

  6. 验证

    此阶段当前未内置于该工具中，但你可以运行安装脚本以将应用程序部署到 Azure。 然后，可以评估生成的应用程序是否提供与 BizTalk Server 本地应用程序相同的功能。

下图显示了 Azure Integration Migrator 工具运行的各个阶段：

显示 Azure 集成服务成员服务的阶段的图。

成功迁移的关键团队角色和技能

若要成功将集成工作流从 BizTalk Server 迁移到 Azure Integration Services，请建立一个具有以下重要角色和技能的团队，这些角色和技能跨越多个学科：

角色 技能
项目经理 负责领导整个项目，并在时间和预算的范围内交付商定的范围。
Scrum 领导者 主动管理积压工作，促进项目活动的优先顺序。
架构师 确保项目符合企业体系结构原则，并提供有关如何应对不确定性和障碍的指导。
开发人员 积极致力于将组件从 BizTalk Server 迁移到 Azure Integration Services。
质量保证测试人员 创建测试计划并针对这些计划执行测试。 在项目冲刺规划过程中跟踪、沟通和会审 bug 和缺陷。
用户验收测试人员 (UAT) 提供业务利益干系人，他们可将接口从现有平台移动到新平台，从而确保不会引入回归。
变更管理专家 评估对现有流程和角色的影响。 制定计划，帮助及早缓解任何察觉到的问题。

为了帮助提供前面所述的部分或所有资源，请考虑具有迁移实践经验的合作伙伴。 作为团队成员，他们可以利用他们的技能和专业知识帮助降低风险，缩短上市时间，并使项目更具可预测性。

生成过程规划

对于规划制定，Microsoft 建议包括冲刺和工作项来处理身份验证、日志记录、例外情况处理等基础服务。 包含这些内容有助于避免在开发周期后期因未满足基础需求而导致的返工。 你还希望避免由于需要其他利益干系人做出的决策而阻止开发人员。

以下列表仅涵盖要考虑的一些方面：

区域 说明
身份验证 在深入了解开发周期之前，请解决以下有关身份验证的问题和其他问题。

- 你的组织是否对身份验证方案有任何标准？
- 是否可以在 Azure 中使用托管标识和服务主体？
- 是否允许基本身份验证和 API 密钥？

此活动可能是引入你的企业架构师的好机会，他们可以确保就使用哪种身份验证方案达成明确的协议。
日志记录 请考虑在集中式数据存储库中收集和存储遥测数据，这是集成解决方案使用的常用模式。

例如，Azure 逻辑应用（标准型）可以将遥测数据推送到 Azure Monitor 中的 Application Insights。 Azure 逻辑应用（消耗型）也可以将遥测数据推送到 Log Analytics（也是在 Azure Monitor 中）。 还可以包含跟踪的属性，以便开发人员可以在消息流经集成平台时包含更多上下文。 例如，此数据可能包括工作订单编号、采购订单信息或其他可能对组织有用、有用且相关的任何内容。

可以说，根据组织的需求，每个组织的解决方案可能有所不同。 例如，某些组织希望完全控制记录数据的内容和时间。 在此方案中，可以创建 API 或自定义连接器，然后根据特定的里程碑检测代码。

无论选择哪种方法，请确保开发人员清楚地了解预期，以避免将来的返工。
异常处理 尽早制定策略和一致的模式来处理例外情况和错误，以避免将来返工。 在创建任何逻辑应用之前，请确保尽早明确此区域。 以下列表包括一些在进行异常处理时需要回答的问题：

- 如何使用范围和“在之后运行”设置来检测例外情况？
- 如何使用 result() 表达式更好地了解工作流中发生例外情况的位置，并查找有关根本原因的详细信息？
- 在选择如何捕获例外情况后，希望如何记录此数据并传达给利益干系人？

确保这些决策与前面提到的日志记录策略一致。 理想情况下，你已经建立了一个流程，用于主动在日志记录数据存储中查找新的错误事件。 从那里，你可以响应这些事件并协调例外情况流程。 可能需要筛选出或聚合重复的错误事件，在组织的 IT 服务管理解决方案中记录票证，并选择发送通知的方式。 根据问题的严重性和一天中的时间，你可能会采取不同的通知路径。 可以通过构建工作流来管理此流程，从而实现敏捷性。
分析 为了向利益干系人展示解决方案的整体运行状况和卫生状况，请考虑可供利益干系人用来查看的不同镜头，例如：

- 管理人员可能更感兴趣的是整体运行状况、事务计数或数量，以及这些事务产生的业务价值，而不是整体技术细微差别。
- 一线经理可能对整体运行状况更感兴趣，但也可能对技术细节（如性能特征）感兴趣，以确保满足 SLA。
- 支持分析师可能对整体服务运行状况、例外情况和性能瓶颈感兴趣。

在组合分析策略时，请考虑利益干系人以及他们感兴趣的数据类型。 这种思维过程有助于确保跟踪有用和实用的信息，并使该数据可用于报告目的。 如果发现覆盖范围缺口，可能需要重新访问与日志记录相关的工作项，并添加适当的任务来解决这些缺口。
Cadence 在交付集成项目并从这些经验中学习时，请确保捕获不可避免的教训。 在旅程的早期计划修正冲刺或周期，以便尽早更正过程，避免成本过高。 这样，就可以避免在新平台中引入过多的技术债务。

部署规划

在预测和准备部署计划时，可以增加成功部署的机会。 使用 BizTalk Server，在创建所有基础结构和环境后，你将重点转移到解决方案部署上。

使用 Azure 时，这种体验根据要首先考虑的一些活动而异，例如，解决不同环境之间的基础结构部署，其中可能包括不同的 Azure 订阅、Azure 资源组或某种组合，例如：

  • Azure 密钥保管库：机密和访问策略
  • Azure 服务总线：队列、主题、订阅、筛选器和访问策略
  • Azure 应用服务：计划、网络和身份验证

然后，可以专注于不同环境之间的解决方案部署。

测试计划

为了确保利益干系人对你提供的解决方案感到满意，对于任何迁移项目，都需要考虑测试。 与以前的解决方案相比，新解决方案应提供更多价值，且不会出现任何可能影响业务的回归。

对于迁移项目，请考虑以下测试建议：

  • 回答以下问题来建立基线：

    1. 你有现有的测试吗？
    2. 测试是否在没有错误的情况下运行？
    3. 测试结果是否准确？

    若要确信你的团队未引入回归，你需要能够将新平台的结果与现有平台的可靠测试进行比较。 因此，如果还没有基线，请确保建立一个基线。

    当然，你不希望花费大量资源针对即将停用的平台建立测试，但你需要回答以下问题：“如何知道一切都正常运行？”如果出现这种情况，请根据优先级开始建立基线，并创建一个计划来缓解存在差距的领域。

  • 为新平台设置测试策略。

    假设你对基线感到满意，现在可以考虑如何在新平台上进行测试。 如果在建立基线时遇到问题，请借此机会为新平台打下坚实的基础。

    考虑测试新平台时，请将自动化放在首位。 尽管使用平台可以快速生成接口，但依赖手动测试会削弱这些生产力提升。

  • 自动执行测试。

    Azure 逻辑应用（标准型）包括执行自动测试的功能。 以下列表包含在 GitHub 上免费获取的详细信息和资源：

    • 使用 Azure 逻辑应用团队提供的 Azure 逻辑应用（标准型）进行自动测试

      使用 Azure 逻辑应用（标准版），由于底层体系结构基于 Azure Functions 运行时，并且可以在 Azure Functions 可以运行的任何位置运行，因此不再难以执行自动化测试。 可以为在本地或在 CI/CD 管道中运行的工作流编写测试。 有关详细信息，请参阅 Azure 逻辑应用测试框架的示例项目。

      此测试框架包括以下功能：

      • 为 Azure 逻辑应用中的端到端功能编写自动测试。
      • 在工作流运行和操作级别执行精细验证。
      • 将测试签入 Git 存储库，并在本地或在 CI/CD 管道中运行。
      • 模拟 HTTP 操作和 Azure 连接器的测试功能。
      • 将测试配置为使用生产环境中不同的设置值。

    • 集成演练手册：逻辑应用标准测试，作者 Michael Stephenson，Microsoft MVP

      集成演练手册测试框架基于 Microsoft 提供的测试框架，并支持其他方案：

      • 在标准逻辑应用中连接到工作流。
      • 获取回调 URL，以便可以从测试触发工作流。
      • 检查工作流运行的结果。
      • 检查工作流运行历史记录中的操作输入和输出。
      • 插入逻辑应用开发人员可能使用的自动化测试框架。
      • 插入 SpecFlow 以支持逻辑应用的行为驱动开发 (BDD)。

    无论你使用哪种方法或资源，都可以顺利完成可重复、一致的自动化集成测试。

  • 使用静态结果设置模拟响应测试。

    无论是否设置自动测试，都可以使用 Azure 逻辑应用中的静态结果功能在操作级别临时设置模拟响应。 此功能使你可以模拟要调用的特定系统的行为。 然后，你可以单独执行一些初始测试，并减少在业务线系统中创建的数据量。

  • 并行运行测试。

    理想情况下，你已经为 BizTalk Server 环境设置了基线集成测试，并为 Azure Integration Services 建立了自动测试。 然后，你可以并行运行测试，以帮助使用相同的数据集检查接口并提高测试的整体准确性。

投入使用

团队完成测试后，请考虑将新的集成平台投入生产所需的任务：

  1. 创建通信计划。

    尽管你可能有一个小型团队实现集成平台现代化项目的技术方面和详细信息，但你可能有许多利益干系人需要随时了解迁移项目。 如果没有明确的沟通策略，会让其他参与其中的人感到焦虑。 此外，请考虑需要在沟通计划中包括的外部利益干系人。 例如，你可能希望包括可能受即将发生的事件影响的其他贸易合作伙伴或客户。 也不要忘记这些利益干系人。

    因此，通过明确影响利益干系人的领域（例如，你对他们的期望、何时需要、需要他们多长时间等）来尽早和经常沟通。 通过提供简洁明了的计划，你可以让利益干系人充满信心，并围绕项目保持正能量。 确保团队已准备好执行，以此来消除任何疑问。 否则，你可能会因为项目可能失败的观念、猜测和谣言而破坏士气。

  2. 制定“直接转换”计划。

    直接转换计划涵盖了从当前平台切换到新平台所需的任务和活动的详细信息，包括团队计划要执行的步骤。 在直接转换计划中包含以下注意事项：

    • 必备的步骤

      确定你可以或必须提前执行的操作，这样你就不会将所有任务都拖到转换日。 通常，直接转换到新的集成平台通常意味着你将进行一个“绿地”部署，因此你可以在周期的早期暂存许多组件和配置。 在原始平台的维护时段之前可以完成任务的越多，你就越能消除焦虑，并改善直接转换事件的总体结果。

    • 彩排

      利益干系人通常希望对即将发生的事件具有一些可预测性。 那么，如何针对从未做过的事情提供可预测性呢？ 通过运行将集成平台部署到预生产环境的彩排，可以验证直接转换计划和流程中每个步骤的预期时间。

      否则，低估某一步骤可能花费的时间可能会导致延迟的连锁反应。 累计起来，这些延迟可能会花费大量时间并导致业务中断。 运行彩排时，可以根据实际数据安排日程。 你的团队还可能会发现在生产环境中上线期间会导致问题的问题。 如果团队能及早发现并记录问题，他们会做好更充分的准备，并在真正的直接转换事件期间减少意外的风险。

    • 人员

      确保明确责任：哪个人负责计划中的每个特定步骤。 作为明智的缓解策略，确定并准备备用人员，以防主要人员因意外情况而无法执行任务。

    • 计划估算

      运行一次排练后，团队应该更好地了解每个任务可能需要多长时间才能完成。 你可以使用这些估计值来预测计划，以便团队成员知道你何时需要他们及他们完成任务的大致时间。

    • 在旧平台中禁用接口

      如果了解所有现有依赖项，则可以在旧集成平台中开始禁用接口，然后再在新平台中启用接口。 某些复杂的体系结构可能需要按特定顺序禁用顺序接口，以避免出现意外情况。 根据接口的性质，你也可能无法在旧集成平台中禁用所有接口。 例如，如果你有一个业务线系统将消息推送到集成平台，请确保在直接转换计划中考虑到这些情况。

    • 在新平台中启用接口

      类似于可能需要按特定顺序禁用的顺序接口，你的某些接口可能要按顺序启用，要求相同。 在开始启用接口之前，请确保了解所有依赖项，并确定启用新的顺序接口所需的顺序。

      注意

      请注意，以有条不紊和系统的方式执行启用接口的步骤，以避免造成危及项目成功的失误。

    • 验证测试

      此活动非常重要，因此请将此工作纳入直接转换计划中。 启用接口后，请先确认接口按预期工作，然后再进入“通过或不通过”阶段。 理想情况下，可以执行不影响核心业务数据的验证测试。 本指南在后面的部分中提供有关新接口的验证测试的详细信息。

  3. 确定回滚计划。

    希望你现在有一种结构化且详细的方法来实现新的集成平台。 但可能会出现意外情况，因此请确定回退到以前的集成平台的必要步骤。 这样，你就准备好了一个计划，以防万一。

    在考虑这些步骤时，请考虑可能会触发回滚的事件。 此外，请就你的计划与做出回滚决策所需的人员达成一致。 本指南在有关做出“通过或不通过”决定的部分中提供了更多信息。

  4. 运行验证测试。

    你的直接转换计划应包含此工作的详细信息。 启用接口后，请先确认接口按预期工作，然后再进入“通过或不通过”阶段。 理想情况下，可以执行不影响核心业务数据的验证测试。

    例如，理想情况下，验证测试可以从业务系统的生产线读取数据，但不能写入数据，写入数据会产生合规性问题。 另一方面，你必须等待业务事务流经接口，并验证一切是否按团队预期的方式运行。

  5. 规划运营或生产支持。

    尽管在平台之间迁移接口的工作通常会消耗大部分项目资源，但还要考虑对接口和新平台持续提供支持。

    • 请确保在项目团队和运营团队的成员具有相当水平的知识。

    • 创建并保留包含技术和业务联系人详细信息的当前联系人列表，以便任何人都可以在必要时联系相应的团队成员。

    • 为了更顺畅、及时地响应客户支持，请在上线前准备好支持流程和文档。 当可以避免支持成员在实际事件发生时试图弄清楚所有问题时，可以帮助客户、你的支持团队和你的项目团队减轻压力。

  6. 选择“通过或不通过”以移动到生产环境。

    对于此步骤，请与相关利益干系人协作，以确定项目是否可以进入生产环境。 例如，利益干系人可以包括领导层、项目管理层、运营部门和业务代表。

  7. 庆祝团队的成功。

    恭喜！ 完成对组织或业务产生积极影响的项目后，便可以表彰你的团队的所有辛勤工作，并庆祝进度达到一个惊人的里程碑！ 确保以适当且有意义的方式赞扬你的团队。 缺乏认可是摧毁士气的必经之路。

  8. 进行回顾。

    与任何工程活动一样，你的团队通过从经验中学习来获得宝贵的见解并扩展他们的知识。 与你的团队会面，讨论并捕获进展顺利、不顺利以及需要改善的方面。 注意在一个没有威胁和支持性的环境中主持这次对话，专注于学习和成长的目标，而不是责备。 与领导和其他感兴趣的利益干系人分享你的经验教训。 这实践可在整个团队中建立信任，并表示工程成熟度。

迁移的最佳做法

虽然最佳实践可能因组织而异，但请考虑有意识地努力促进一致性，这有助于减少“重新发明轮子”的不必要工作和类似通用组件的冗余。 当你帮助启用可重用性时，你的组织可以更快地构建更易于支持的界面。 上市时间是数字化转型的关键推动因素，因此当务之急是减少开发人员与支持团队之间不必要的摩擦。

建立自己的最佳做法时，请考虑遵循以下指南：

Azure 资源的常规命名约定

请确保在从资源组到每种资源类型的所有 Azure 资源中设置并一致地应用良好的命名约定。 为了为可发现性和可支持性打下扎实的基础，良好的命名约定可传达目的。 命名约定最重要的一点是，你已经规定了命名约定，并且你的组织理解这些命名约定。 每个组织都有可能需要考虑的细微差别。

有关此做法的指导，请查看以下 Microsoft 建议和资源：

Azure 逻辑应用资源的命名约定

逻辑应用和工作流的设计提供了一个关键起点，因为此区域为开发人员提供了创建唯一名称的灵活性。

逻辑应用资源名称

若要区分消耗型和标准型逻辑应用资源，可以使用不同的缩写，例如：

  • 消耗型：LACon
  • 标准型：LAStd

从组织的角度来看，可以设计一个命名模式，包括业务部门、部门、应用程序以及部署环境（例如 DEV、UAT、PROD 等），例如：

LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>

假设你正在开发一个标准逻辑应用，该应用为企业服务业务部门的人力资源部门实现工作流。 可以将逻辑应用资源命名为 LAStd-CorporateServices-HR-DEV，并在适当的情况下使用帕斯卡大小写表示法以保持一致性。

逻辑应用工作流名称

消耗型逻辑应用资源始终仅映射到一个工作流，因此只需一个名称。 标准型逻辑应用资源可以包含多个工作流，因此请设计一个也适用于成员工作流的命名约定。 对于这些工作流，请考虑基于流程名称的命名约定，例如：

Process-<*process-name*>

因此，如果你有实现员工入职任务的工作流（例如创建员工记录），则可以将工作流命名为 Process-EmployeeOnboarding。

下面是设计工作流命名约定的更多注意事项：

  • 遵循逻辑应用的父子模式：在其中突出显示一个或多个工作流之间的某种关系。
  • 考虑工作流是发布还是消耗消息。

工作流操作名称

将触发器或操作添加到工作流时，设计器会自动为该操作分配默认通用名称。 但是，操作名称在工作流中必须是唯一的，因此设计器会在后续操作实例上附加连续的数字后缀，这会降低可读性并导致难以理解开发人员的原始意图。

若要使操作名称更有意义且更易于理解，可以在默认文本后面添加一个简短的任务描述符，并使用帕斯卡大小写表示法实现一致性。 例如，对于“分析 JSON”操作，可以使用 Parse JSON-ChangeEmployeeRecord 等名称。 使用此方法或其他类似方法，你将继续记住操作是“分析 JSON”以及操作的具体用途。 因此，如果需要稍后在下游工作流操作中使用此操作的输出，则可以更轻松地识别和查找这些输出。

注意

对于广泛使用表达式的组织，请考虑不提倡使用空格的命名约定。 Azure 逻辑应用中的表达式语言会将空格替换为下划线 (_) ，这可能会使创作复杂化。 通过事先避免使用空格，有助于减少创作表达式时的摩擦。 请改用短划线或连字符 (-)，这可提供可读性，并且不会影响表达式创作。

为了避免以后可能的返工和有关下游依赖项的问题（使用操作输出时产生），请在将操作添加到工作流时立即重命名操作。 通常，在重命名某个操作后，下游操作会自动更新。 但是，Azure 逻辑应用不会自动重命名在执行重命名之前创建的自定义表达式。

连接名称

在工作流中创建连接时，基础连接资源会自动获取一个通用名称，例如 sql 或 office365。 与操作名称一样，连接名称也必须是唯一的。 具有相同类型的后续连接将获取顺序数字后缀，例如 sql-1、 sql-2 等。 此类名称没有任何上下文，因此便很难区分和映射其逻辑应用的连接，尤其是对于不熟悉空间但又必须为这些逻辑应用进行维护的开发人员。

因此，有意义且一致的连接名称非常重要，原因如下：

  • 可读性
  • 知识转移和可支持性更轻松
  • 调控

同样，规定命名约定至关重要，尽管格式并不重要。 例如，可以使用以下模式作为指导：

CN-<*connector-name*>-<*logic-app-or-workflow-name*>

作为具体示例，可以在 OrderQueue 逻辑应用或工作流中重命名服务总线连接，并将 CN-ServiceBus-OrderQueue 作为新名称。 有关详细信息，请参阅 Turbo360（以前称为 Serverless360）博客文章：逻辑应用最佳做法、提示和技巧：#11 连接器命名约定。

使用作用域和“在以下阶段后运行”选项处理例外情况

作用域提供对多个操作进行分组的功能，以便你可以实现 Try-Catch-Finally 行为。 “作用域”操作的功能类似于 Visual Studio 中的“区域”概念。 在设计器中，可以折叠并展开范围的内容，以提高开发人员的工作效率。

实现此模式时，还可以根据前面操作的执行状态（可以是“成功”、“失败”、“跳过”或“超时”）指定何时运行“作用域”操作以及其中的操作。 若要设置此行为，请使用“作用域”操作的“此后运行”(runAfter) 选项：

  • 成功
  • 失败
  • 已跳过
  • 已超时

合并共享服务

生成集成解决方案时，请考虑为常见任务创建和使用共享服务。 你可以进行自己的团建活动，并公开你的项目团队和其他人可以使用的共享服务集合。 每个人都能提高工作效率、统一性，并增强对组织解决方案实施治理的能力。 以下各节介绍了可以考虑引入共享服务的一些方面：

共享服务 原因
集中式日志记录 提供了有关开发人员如何使用适当的日志记录检测其代码的常见模式。 然后，你可以设置诊断视图，帮助你确定接口运行状况和可支持性。
业务跟踪和业务活动监视 捕获和公开数据，以便业务主题专家可以更好地了解其业务事务的状态，并能够执行自助分析查询。
配置数据 将应用程序配置数据与代码分开，以便更轻松地在环境之间移动应用程序。 请确保提供统一一致且易于重现的方法来访问配置数据，以便项目团队可以专注于解决业务问题，而不是将时间花在应用程序配置上进行部署。 否则，如果每个项目都以独特方式实现这种分离，则无法从规模经济中获益。
自定义连接器 针对在 Azure 逻辑应用中没有预生成连接器的内部系统创建自定义连接器，以便为项目团队和其他人员简化。
常见数据集或数据馈送 作为 API 或连接器公开常见的数据集和源以供项目团队使用，并避免重新发明轮子。 每个组织都有在企业环境中集成系统所需的通用数据集。

回顾、反思和学习

经常评估和评审现有逻辑应用，尤其是在出现问题时。 不仅是分析业务流程以查找可以改进的内容和改进领域，还要分析工作流的运行历史记录，以便从发生的故障、错误和错误中吸取教训。 Azure 逻辑应用提供非常丰富的运行历史记录，你很有可能在查看工作流的运行历史记录时发现有关应用的新内容。 与所有代码开发一样，可能会出现一些边缘或极端情况。 发现这些情况后，请更新接口以应对这些情况，并提高解决方案的整体可靠性。

项目团队面临的一个现实是，开发人员试图笼统捕获错误，至少获得对某些问题的一定防护。 随着团队发现并更好地了解问题可能出现在哪里，你可以更深入地了解如何防范问题。

类似于组织定期执行“红队”练习（如渗透测试或网络钓鱼尝试），安全性也不是“一劳永逸”的活动。 当新的身份验证方案和方法可用时，请定期重新访问接口、查看安全措施，并纳入提供最安全方法的相关适当新开发。

你想要定期评估的另一个领域是 DevOps。 当 Microsoft 或社区引入新的模板或方法时，请评估这些更新以确定你是否可以获得更多益处。

后续步骤

现在，你已详细了解将 BizTalk Server 工作负载迁移到 Azure Integration Services 的可用迁移方法、规划注意事项和最佳做法。 若要提供有关本指南的详细反馈，可以使用以下表单：

提供有关 BizTalk Server 到 Azure Integration Services 的迁移指南的反馈