Migration vers Azure Logic Apps Étape 3 - Conversion : Générer des flux de travail

S’applique à : Azure Logic Apps (Standard)

Le processus de migration des projets d’intégration peut se bloquer lorsque des artefacts sources complexes sont difficiles à transformer en ressources déployables dans Azure Logic Apps (Standard). Lors de la phase de conversion, l’Agent de migration Azure Logic Apps dans Visual Studio Code utilise les résultats de planification approuvés pour créer et exécuter un plan de conversion ordonné. Ce processus crée des artefacts incluant des définitions de flux de travail standard, des configurations de connexion et des fichiers de support.

Cet article décrit comment l’agent de migration Azure Logic Apps crée des tâches de conversion qui mappent les artefacts d’intégration source aux ressources de projet de logic apps standard prêtes à déployer, et comment l’agent exécute ces tâches pour produire des artefacts de projet prêts à l’exécution.

Actions de phase de conversion

Dans l’agent de migration Azure Logic Apps, après avoir terminé l’activité Plan Logic App Design, l’activité Create Conversion Tasks devient disponible. Lorsque vous sélectionnez l’activité Create Conversion Tasks, la @migration-converter GitHub assistant Copilot crée les tâches de conversion nécessaires pour générer les artefacts de projet d’application logique cible.

Après avoir examiné ces tâches et sélectionné l’activité Exécuter les tâches de conversion, l’agent @migration-converter GitHub assistant Copilot traite les tâches requises dans l’ordre des dépendances. La tâche optionnelle Déploiement et Tests Cloud n’est pas incluse dans cette action et nécessite une approbation séparée.

1 : Générer des artefacts de projet d’application logique

L’agent @migration-converter génère les sorties décrites dans les sections suivantes.

Structure d'échafaudage du projet

L’agent @migration-converter crée d’abord un espace de travail Visual Studio Code et un projet d’application Standard Logic sous le out dossier. Les tâches de conversion ultérieures ajoutent une ou plusieurs définitions de workflow, connexions, artefacts et un projet .NET Functions lorsque le plan approuvé les exige :

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

L’exemple suivant montre l’agent @migration-converter qui crée la structure et les fichiers de structure du projet :

Fichier de définition de flux de travail

Pour chaque flux de travail dans le plan approuvé, l’agent @migration-converter génère un workflow.json fichier contenant les opérations de flux de travail suivantes :

Configurations de connexion

L’agent @migration-converter génère un connections.json fichier qui stocke les configurations nécessaires pour les opérations de connecteur dans vos flux de travail.

Le tableau suivant décrit les groupes de connecteurs de haut niveau :

Pour plus d’informations, Quels sont les connecteurs dans Azure Logic Apps.

fonctions locales .NET

Si vous avez des composants de plateforme source qui n'ont pas d'équivalent direct dans Azure Logic Apps (Standard), l'@migration-converteragent peut créer un projet .NET Functions séparé et intégrer des fonctions locales dans le dossier du lib/custom projet Logic App. Ce comportement se produit généralement dans les scénarios où vous disposez des éléments suivants :

• Logique de transformation de données personnalisée
• Règles d’analyse ou de validation complexes
• Appels à des systèmes locaux via des protocoles personnalisés
• Évaluation des règles d’entreprise

2. Vérifier l’exhaustivité et la qualité de la sortie

L’agent @migration-converter utilise la compétence no-stubs-code-generation, qui exige que la sortie générée ne contienne aucune implémentation factice, aucun code fictif ni aucun commentaire TODO. Cette exigence ne remplace pas la revue manuelle ou les tests à l’exécution.

La compétence applique les normes suivantes aux fichiers générés :

Pour préparer la sortie générée pour la phase de validation où vous exécutez localement les flux de travail à des fins de test, vérifiez que vous inspectez manuellement les définitions de flux de travail, les connexions et toutes les fonctions locales générées .NET pour des inexactitudes.

Pour plus d’informations, consultez Démarrage rapide : Migrer un projet d'intégration en utilisant l'agent de migration Azure Logic Apps.

Contenu connexe

• Automatisation de la migration des plateformes d’intégration vers Azure Logic Apps
• Quickstart : Migrer un projet d’intégration à l’aide de l’agent de migration Azure Logic Apps

Étapes suivantes