快速入门：自动化将集成项目迁移到 Azure 逻辑应用（标准版）（预览）

适用于：Azure 逻辑应用（标准）

注释

此预览版功能受 Microsoft Azure 预览版补充使用条款的约束。

当团队需要将工作负载从旧平台（如BizTalk Server）迁移到云时，你可能会发现该过程非常复杂、耗时且具有挑战性。 为了帮助简化此任务，Azure 逻辑应用迁移代理在Visual Studio Code中通过五个引导阶段自动执行此过程。

本快速入门介绍如何使用 Visual Studio Code 中的 Azure 逻辑应用 迁移代理将示例集成工作负荷从BizTalk Server迁移到 Azure 逻辑应用 中的标准工作流。 了解如何安装扩展、打开源项目并按照代理进行操作，因为它将引导你完成迁移阶段：发现、规划、转换、验证和部署。

注释

尽管迁移代理几乎可以自主运行，但它可能会提示你为所需任务运行特定的命令。 若要让代理继续，请选择 “允许”。

有关详细信息，请参阅从集成平台迁移到 Azure 逻辑应用 的自动化。

Prerequisites

在开始之前，请确保满足以下要求：

Requirement	Purpose
Azure 订阅 - 获取免费帐户	部署到Azure（阶段 5）
Azure CLI	Azure资源预配和部署
Visual Studio Code 1.85.0 或更高版本	本地开发体验
Azure 逻辑应用迁移代理扩展	Visual Studio Code 迁移智能体所需的扩展
Azure 逻辑应用（标准）扩展	Azure 逻辑应用迁移代理扩展所需的依赖项
Azure Functions 扩展	本地函数运行时和开发任务
Azure Functions Core Tools	Azure 逻辑应用的本地运行时主机（标准）
GitHub Copilot 订阅	AI 驱动的分析、规划和转换
Docker Desktop	用于测试和运行连接的本地连接器资源部署
包含BizTalk Server项目的文件夹	包含带有源工件和文件的集成项目文件夹的文件夹。 例如，BizTalk 项目文件夹包括具有以下文件扩展名的文件：.btproj、、.odx.btm、和.xsd.btp。

1：安装迁移代理扩展

1. 打开Visual Studio代码。

   （可选）但建议从集成项目所在的文件夹或目录中打开Visual Studio Code，例如，C：\Migration\<project-folders>。

   

2. 在活动栏上，选择“ 扩展”。 （键盘：Ctrl+Shift+X）

3. 在 Extensions：Marketplace 搜索框中，找到 Azure 逻辑应用 迁移代理扩展，然后选择 Install。

   

   安装完成后，活动栏会显示用于 Azure 逻辑应用 迁移代理（） 的图标。

2：选择源文件夹

1. 在Visual Studio Code，在活动栏上，选择Azure 逻辑应用迁移代理图标（）。

2. 在“Azure 逻辑应用迁移代理窗口中的”发现结果部分中，选择选择源文件夹。

   小窍门

   若要以命令的形式运行此操作，请打开命令面板（键盘：Ctrl+Shift+P）。 输入并运行 Azure 逻辑应用 迁移代理：选择源文件夹。

3. 找到包含 BizTalk、MuleSoft 或其他集成项目的源文件夹并选择，然后选择 选择源项目文件夹或 MSI。

   显示 Visual Studio Code 的屏幕截图，其中包含 Azure 逻辑应用 迁移代理和带有项目的源文件夹。

   该扩展会自动检测源平台并开始迁移工作流，从发现阶段开始。

4. 关注智能体如何完成每个迁移阶段，首先从发现阶段开始。

迁移阶段 1：发现

在此阶段，迁移代理查找并编录您源项目中的集成工件。 在发现阶段，迁移代理按描述的顺序执行以下操作，偶尔需要您的输入。 有关详细信息，请参阅 迁移代理：发现阶段。

步骤 1：检测源平台

迁移代理根据文件类型（如 BizTalk Server.btproj 文件）确定源平台。

以下屏幕截图显示了已识别的平台，其中显示了检测到的项目和依赖项示例：

截屏，显示 Azure 逻辑应用 迁移代理扩展和发现阶段中的检测到的项目和依赖关系。

步骤 2：扫描源文件

迁移代理使用平台的内置分析器扫描检测到的源文件。 扫描完成后，@migration-analyser Copilot 代理会分析发现的构件，并检测出逻辑流动组，这些组是协同工作的构件集。

以下屏幕截图显示了每个示例集成项目如何映射到逻辑流组：

生成的逻辑流并不总是反映与旧集成应用程序的 1：1 关系。 迁移代理推断出最能反映旧系统的集成项目（如 BizTalk 工作负载）的流，如Azure 逻辑应用中的标准工作流。

小窍门

若要编辑这些逻辑流，以便将 1：1 映射到集成工作负载，请使用GitHub Copilot并指定流必须映射到 BizTalk 应用程序。 但是，请考虑 BizTalk 的最优项与 Azure 逻辑应用中标准工作流的最优项并不相同。 这个概念是现代化中第一个范式变化之一。

步骤 3：分析源设计

迁移代理完成扫描并显示生成的逻辑流组后，请执行以下步骤：

1. 在“ 开始 ”选项卡上，对于所需的逻辑流组，选择“ 分析源设计”，例如：

   

   代理执行以下任务：

   1. 构建包含业务流程、架构、映射、管道和绑定的工件清单。

   2. 生成一个依赖项图，该关系图显示项目之间的关系。

      若要生成依赖项关系图，迁移代理将运行以下任务：

      • 生成显示消息流和组件的体系结构（美人鱼）关系图。
      • 标识缺少的依赖项。
      • 对特性执行间隙分析。
      • 检测集成模式，例如发布-订阅、请求-回复和批处理。
      • 为 Azure 逻辑应用或其他服务替代项建议映射。
      • 根据发现结果生成发现报告。

      迁移代理成功生成依赖项关系图后，流可视化工具将打开并显示以下交互式选项卡：

      • 体系结构图
      • 消息流
      • 组件
      • 缺少依赖项
      • 差距分析
      • 模式
      • 了解 BizTalk

      以下示例显示了一个示例生成的流可视化效果：

      

      有关详细信息，请参阅 源设计分析和结果。

2. 若要查看分析结果，请选择一个选项卡以查看相关信息。

步骤 4：更新或导出分析

1. 查看分析结果后，在流可视化工具标题栏上，选择以下操作之一：

   Action	Description
   建议更改	请求对分析进行直接更改。 提示：若要讨论流可视化工具中任何流组的潜在更新或更正，请使用Copilot聊天窗口。 选择一个流组，并询问 @migration-analyser 有关检测到的体系结构的代理问题。 提供有关任何缺失差距的信息，然后重新生成分析。
   重新生成分析	更新分析后，例如添加缺少的依赖项、项目或规范，重新运行分析。
   导出报表	使用发现结果生成可共享格式的报表。

   或者，若要分析更多流，请选择“ 开始 ”选项卡或主页图标。

2. 完成后，转到“规划”阶段的下一部分。

迁移阶段 2：规划

完成分析后，通过创建迁移路线图来启动“规划”阶段。 有关详细信息，请参阅 迁移代理阶段 2：规划。

1. 在“ 开始 ”选项卡上，选择所需的逻辑流组，然后选择“ 规划逻辑应用设计”。

   

   代理 @migration-planner 生成通常包含以下部分的迁移计划：

   • 建筑
   • 其他 Azure 组件
   • 操作映射
   • 工件处置
   • 迁移差距
   • 集成模式
   • 总结
   • 工作量估计
   • 任务计划

   以下示例演示了示例生成的迁移计划：

   

   有关详细信息，请参阅 “规划阶段”操作。

2. 在继续进入转换阶段之前，请仔细查看每个计划。 请根据需要进行更新。

   计划的准确性极大地影响转换输出的质量。

   为了帮助你确定计划是否需要任何更新，请通过与 @migration-planner GitHub Copilot 代理进行交互，并使用 Copilot 聊天来完成以下任务：

   • 询问有关特定映射的问题。
   • 请求寻找解决差距的替代方法。
   • 调整工作量估算。
   • 在进行转换之前请求对计划进行修改。

3. 准备就绪后，选择 “主页 ”或返回到“ 开始 ”选项卡，继续进入转换阶段。

迁移阶段 3：转换

如果对迁移计划感到满意，请启动转换阶段，创建并运行将源项目转换为标准工作流、连接和其他Azure 逻辑应用支持文件的转换任务。

3.1：创建转换任务

1. 在“ 开始 ”选项卡上，对于逻辑流，选择“ 创建转换任务”。

   

   代理 @migration-converter 会创建转换任务，这些任务因特定的逻辑流组而异。 以下列表描述了名为 Method Call Processing： 的逻辑流组的示例转换任务：

   Step	任务	Description
   1	搭建逻辑应用项目	使用所需的文件夹层次结构和文件创建标准逻辑应用项目结构。
   2	转换输入架构	将 InputSchema.xsd 文件从 BizTalk 格式（带有 BizTalk 注释的 UTF-16）迁移到标准 XSD，即没有 BizTalk 注释的 UTF-8。
   3	转换输出架构	将 OutputSchema.xsd 文件从 BizTalk 格式（带有 BizTalk 注释的 UTF-16）迁移到标准 XSD，即没有 BizTalk 注释的 UTF-8。
   4	生成 <连接器名称> 连接	创建或更新包含每个所需连接的配置 connections.json 文件。
   5	生成 <工作流名称> 工作流	创建 workflow.json 文件，该文件包含逻辑流组Azure 逻辑应用中的标准工作流定义。
   6	生成本地函数（<函数名称>）	为源代码中的自定义逻辑创建.NET 8 个本地函数。
   7	验证运行时 （func start）	通过运行 func start 来验证逻辑应用项目，以确认所有函数和工作流都已准备就绪。
   8	E2E 测试 （快乐路径和错误路径）	针对理想路径、错误路径和字段级验证运行端到端测试。
   9	黑盒测试 （可选）	运行使用你提供的外部测试数据的测试。
   10	云部署和测试（可选）	部署到Azure并运行云 E2E 测试。

   以下示例为Method Call Processing 逻辑流组展示了生成的示例转换任务：

   

2. 对于下一部分，请选择 “主页 ”或返回到“ 开始 ”选项卡。

3.2：运行转换任务

1. 若要让 @migration-converter 代理运行每个转换任务，请选择“ 执行”，但在 云部署和测试之前停止。 或者，选择“全部执行”，其工作方式与在“首页”选项卡上选择“执行转换任务”相同。

   注释

   在转换任务执行期间，智能体可能会提示输入访问权限或编辑文件的权限。 查看可用选项并相应地做出响应。

2. 对于下一部分，请选择 “主页 ”或返回到“ 开始 ”选项卡。

3.3 检查输出是否完整和质量

代理 @migration-converter 生成现成的标准工作流定义和可部署的项目工件。 此代理使用 no-stubs-code-generation 技能来确保所有生成的代码都完整、完全正常运行，并且不存在存根实现、占位符代码或 TODO 注释。

若要为本地运行工作流进行测试的验证阶段准备生成的输出，请确保手动检查工作流定义、连接以及任何生成的.NET本地函数的不准确情况。

重要

最佳做法是，在使用这些输出之前，请始终查看任何 AI 生成的输出。 此类输出可能包含不正确的信息。

若要查看生成的输出，请执行以下步骤：

1. 在 Home 选项卡上，为逻辑流选择 Open in Visual Studio Code。

2. 在迁移文件夹中，转到 out 目录，然后选择生成的解决方案文件夹，例如：

   

3. 检查每个 workflow.json 文件以验证触发器和操作是否与源行为匹配。

   小窍门

   若要询问有关生成的输出、请求修改或重新生成特定工作流的问题，请使用Copilot聊天与 @migration-converter 代理进行交互。

4. 检查 connections.json 文件以查看正确的连接器配置。

5. 查看任何生成的.NET本地函数，了解正确性。

迁移阶段 4：验证

对于验证阶段，根据源规范测试生成的工作流。 可以自带测试用例和规范。 代理 @migration-converter 提供运行时验证和测试指南。 目标是确认转换后的工作流按预期执行，并且与源流行为匹配。

小窍门

为了帮助你轻松进行直接比较，请在验证期间随时提供源平台的测试数据和预期输出。

例如，迁移计划提供可选的黑盒测试功能，使你能够使用外部输入：

在本地测试工作流的要求

在开始验证步骤之前，请确保已安装以下测试要求：

Requirement	Purpose
Azure 逻辑应用（标准）扩展	所需的扩展依赖项
Azure Functions Core Tools	Azure 逻辑应用的本地运行时主机（标准）
Docker Desktop	用于测试和运行连接的本地连接器资源部署

在本地测试工作流

若要在本地运行生成的工作流，请执行以下步骤：

1. 在 Home 选项卡上，为逻辑流选择 Open in Visual Studio Code。

2. 在迁移文件夹中，转到 out 目录，然后选择生成的解决方案文件夹。

3. 打开生成的逻辑应用项目文件夹。

4. 检查 Docker Desktop 是否正在运行。

5. 在 Run 菜单上，选择 开始调试（键盘：F5）以在本地启动 Azure 逻辑应用 的运行时。

   运行环境启动，工作流在本地端点可用。

6. 使用示例输入数据发送测试请求或触发工作流。

7. 将生成的工作流行为与源行为进行比较，以便识别任何差异或不准确之处。

   以下清单描述了要验证的行为：

   • 所有触发器在使用预期的输入格式时均能正确触发。
   • 操作序列按正确的顺序运行。
   • 数据转换生成预期的输出。
   • 条件逻辑根据输入数据与预期结果正确分支。
   • 循环构造按预期处理所有项。
   • 错误处理的范围可以适当地捕获和处理异常。
   • 连接配置解析为正确的终结点。
   • .NET本地函数返回预期结果。

8. 调查并解决你发现的任何差异或问题。

   小窍门

   若要帮助完成解决过程，请通过 Copilot 对话助手与 @migration-converter 智能体讨论差异或问题。

   1. 在Copilot聊天中，描述预期行为与实际行为。
   2. 查看代理的修复建议。
   3. 如果接受代理的建议并进行更改，请让代理重新生成工作流的更新部分。

迁移阶段 5：部署

部署阶段将迁移的标准解决方案部署到Azure门户中的Azure 逻辑应用。

部署工作流的要求

在开始部署步骤之前，请确保满足以下要求：

Requirement	Purpose
Azure CLI	预配和部署Azure资源。
Azure订阅	要用于部署的目标订阅。
参与者访问权限	基于角色的访问以在目标资源组中创建资源。

确保完成迁移代理阶段 1（发现）到 4 阶段（验证），包括在本地运行生成的工作流并确认其行为与源行为匹配。

步骤 1：设置部署的扩展设置

1. 在Visual Studio Code中，打开扩展设置。 在 File 菜单中， 转到 Preferences>Settings>Extensions>Azure 逻辑应用 迁移代理。

2. 根据需要更新以下部署设置值：

   设置名称	JSON 名称	Description	默认	Action
   位置	logicAppsMigrationAssistant.azure.location	用于预配资源的Azure区域。	eastus	将此值更改为所需的区域。
   资源组	logicAppsMigrationAssistant.azure.resourceGroup	用于预配和测试的Azure资源组。	integration-migration-tool-test-rg	将此值更改为所需的资源组名称。
   订阅 ID	logicAppsMigrationAssistant.azure.subscriptionId	用于部署的 Azure 订阅 ID。	（空）	输入Azure订阅的 GUID。
   部署模型	logicAppsMigrationAssistant.deploymentModel	Azure 逻辑应用（标准）的目标部署模型。	workflow-service-plan	如果适用，请将此值更改为 hybrid。

步骤 2：启动部署过程

开始部署到 Azure，按照以下步骤：

1. 使用Azure订阅登录Azure CLI，例如：

   az login
   

2. 在“Azure 逻辑应用 迁移代理”窗口中，转到迁移计划并通过选择 Execute 来运行 Cloud 部署和测试 任务。

   

   迁移代理预配必要的基础结构，并使用Azure CLI部署标准逻辑应用资源和工作流。

   以下示例展示一个完全迁移的方案示例：

   

步骤 3：验证部署

部署完成后，验证标准工作流是否显示在Azure门户中。

1. 在 Azure 门户搜索框中，输入 logic apps，然后选择 Logic apps。

2. 在 “逻辑应用 ”页上，选择标准逻辑应用资源。

3. 在逻辑应用边栏的 “工作流”下，展开 “工作流”。 在 “工作流 ”页上，确认显示所有预期的工作流。 确认其状态为已启用。

   注释

   对于任何禁用的工作流，请选中工作流复选框。 在 “工作流 ”工具栏上，选择“ 启用”。

4. 使用示例输入测试每个工作流，以确保它们按预期工作。

5. 若要查找任何运行时错误或性能问题，请转到标准逻辑应用资源的 Application Insights 页。

   1. 在逻辑应用边栏的 “监视”下，选择 “Application Insights”。

   2. 在 “链接到 Application Insights 资源”中，选择该链接以访问 Application Insights 资源。

   有关详细信息，请参阅 Application Insights 中的“查看工作流指标”。

重置迁移

可以从头开始重启迁移。 以下命令清除迁移状态，并允许你再次开始使用发现阶段。

1. 在Visual Studio Code中，打开命令面板（键盘：Ctrl+Shift+P）。

2. 在提示符下，输入 Azure 逻辑应用 迁移代理：重置迁移。

相关内容

• 从集成平台到 Azure 逻辑应用 的迁移自动化
• 迁移代理阶段 1：发现
• 迁移代理阶段 2：规划
• 迁移代理阶段 3：转换
• 迁移代理阶段 4：验证
• 迁移代理阶段 5：部署
• 通过为不受支持的集成平台创建自定义分析程序来扩展迁移代理