Migración a Azure Logic Apps Fase 3 - Conversión: Generar flujos de trabajo

Se aplica a: Azure Logic Apps (Estándar)

El proceso de migración para proyectos de integración puede detenerse cuando los artefactos de origen complejos son difíciles de transformar en recursos implementables en Azure Logic Apps (Estándar). En la fase de Conversión, el Agente de Migración de Azure Logic Apps en Visual Studio Code utiliza los resultados aprobados de la planificación para crear y ejecutar un plan ordenado de tareas de conversión. Este proceso crea artefactos que incluyen definiciones estándar de flujo de trabajo, configuraciones de conexión y archivos de soporte.

En este artículo se describe cómo el agente de migración de Azure Logic Apps crea tareas de conversión que asignan los artefactos de integración de origen a recursos de proyecto de aplicación lógica estándar listos para implementar y cómo ejecuta el agente estas tareas para generar artefactos de proyecto listos para implementar y ejecutar.

Acciones de fase de conversión

En el agente de migración de Azure Logic Apps, después de finalizar la actividad Plan Logic App Design, la actividad Crear tareas de conversión estará disponible. Al seleccionar la actividad Crear tareas de conversión, el @migration-converter GitHub agente de Copilot crea las tareas de conversión necesarias para generar los artefactos del proyecto de aplicación lógica de destino.

Después de revisar estas tareas y seleccionar la actividad Ejecutar Tareas de Conversión, el @migration-converter agente de Copilot de GitHub procesa las tareas requeridas en orden de dependencias. La tarea opcional Despliegue y Prueba en la Nube no está incluida en esta acción y requiere aprobación separada.

1: Generar artefactos de proyecto de aplicación lógica

El @migration-converter agente genera las salidas descritas en las secciones siguientes.

estructura de andamio de proyecto

El @migration-converter agente primero crea un espacio de trabajo para Visual Studio Code y un proyecto de aplicación de lógica estándar bajo la out carpeta. Las tareas de conversión posteriores añaden una o más definiciones de flujo de trabajo, conexiones, artefactos y un proyecto de Funciones .NET cuando el plan aprobado las requiere:

out/
└── <workspace-name>/
    ├── <workspace-name>.code-workspace
    ├── <logic-app-name>/
    │   ├── host.json
    │   ├── local.settings.json
    │   ├── connections.json                 # Added when connectors are configured
    │   ├── <workflow-name>/
    │   │   └── workflow.json
    │   ├── Artifacts/                       # Added only when required
    │   └── lib/custom/                      # Added when local functions are built
    └── Functions/                           # Added only when local functions are required

En el ejemplo siguiente se muestra el agente @migration-converter creando la estructura y los archivos de andamiaje del proyecto:

Captura de pantalla que muestra la fase de conversión que genera archivos de flujo de trabajo estándar de Logic Apps.

Archivo de definición de flujo de trabajo

Para cada flujo de trabajo en el plan aprobado, el @migration-converter agente genera un workflow.json archivo que contiene las siguientes operaciones de flujo de trabajo:

Operation Description
Trigger Cada flujo de trabajo siempre comienza con un único desencadenador, que es el punto de entrada del flujo de trabajo. El agente asigna este desencadenador desde los puertos de recepción o los agentes de escucha en el origen.
Action Cada flujo de trabajo tiene una o varias acciones que realizan tareas. El agente mapea estas acciones a partir de las formas de orquestación, los procesadores de flujo o las actividades del origen.
Condiciones o bucles Acciones que realizan lógica de flujo de control, como If, For each y Until. El agente traduce estas acciones a partir de formas de decisión y bucles en el origen.
Ámbitos Acciones con run-after configuraciones que puede usar para configurar el control de errores.

Configuraciones de conexión

El @migration-converter agente genera un connections.json archivo, que almacena las configuraciones necesarias para las operaciones del conector en los flujos de trabajo.

En la tabla siguiente se describen los grupos de conectores de alto nivel:

Grupo de conectores Descripción y ejemplos
Integrado Conectores con operaciones que se ejecutan en el mismo proceso que el entorno de ejecución de Azure Logic Apps (estándar). Por ejemplo, estos conectores incluyen Request, File System, HTTP, Azure Blob Storage, Service Bus, SQL Server, AS2, EDIFACT, X12 y otros.

Para obtener más información, consulte:

- Conectores integrados en Azure Logic Apps
- Azure Logic Apps (Estándar) referencia de conectores integrados
Compartido o "administrado" Conectores con operaciones que se ejecutan en Azure multiinquilino. Por ejemplo, estos conectores incluyen Salesforce, SAP, Office 365 Outlook, Power BI, SharePoint etc. Azure Logic Apps admite conectores compartidos de 1,400+ para Microsoft, Azure y otras plataformas en la nube, locales y entornos híbridos.

Para obtener más información, consulte: Conectores administrados o compartidos en Azure Logic Apps.
Personalizado Conectores de otros editores o de su organización que usted crea para API personalizadas u otros servicios. Para más información, consulte Creación de conectores integrados personalizados para flujos de trabajo estándar.

Para obtener más información, ¿Qué son los conectores en Azure Logic Apps.

.NET funciones locales

Si tienes componentes de la plataforma de origen que no tienen un conector equivalente directo en Azure Logic Apps (Estándar), el agente @migration-converter puede crear un proyecto de .NET Functions independiente y compilar funciones locales en la carpeta lib/custom del proyecto de aplicación lógica. Este comportamiento suele ocurrir en escenarios en los que dispone de lo siguiente:

  • Lógica de transformación de datos personalizada
  • Reglas de análisis o validación complejas
  • Llamadas a sistemas locales a través de protocolos personalizados
  • Evaluación de reglas de negocio

2. Comprobar la integridad y la calidad de la salida

El agente @migration-converter utiliza la habilidad no-stubs-code-generation, lo que requiere que la salida generada no contenga implementaciones de stub, código de marcador de posición ni TODO comentarios. Este requisito no sustituye la revisión manual ni las pruebas en tiempo de ejecución.

La habilidad aplica los siguientes estándares a los archivos generados:

Estándar Description
No hay código auxiliar ni de marcador de posición Todo el código generado es completo y funcional.
JSON válido Todos los archivos /workflow.json y connections.json son válidos y se ajustan al esquema de Azure Logic Apps.
Referencias correctas Las acciones de flujo de trabajo hacen referencia a las conexiones y parámetros correctos.
Gestión de errores Los flujos de trabajo incluyen los ámbitos de control de errores adecuados.

Para preparar la salida generada para la fase de validación en la que ejecuta localmente los flujos de trabajo para realizar pruebas, asegúrese de inspeccionar manualmente las definiciones de flujo de trabajo, las conexiones y las funciones locales generadas .NET para detectar imprecisiones.

Importante

Como un procedimiento recomendado, revise siempre los resultados generados por IA antes de usarlos. Estas salidas pueden incluir información incorrecta.

Para obtener más información, consulte Quickstart: Migración de un proyecto de integración mediante Azure Logic Apps Migration Agent.

Contenido relacionado

Pasos siguientes

Fase 4 del agente de migración: validación: flujos de trabajo de prueba

  • Se actualizó por última vez el