Modernisez les charges de travail mainframe et intermédiaires en utilisant Azure Logic Apps Standard

Azure Logic Apps Standard aide les organisations à étendre et moderniser progressivement les charges de travail mainframe et intermédiaires sans d’abord réécrire les programmes hôtes établis ni déplacer tout le traitement vers Azure. Utilisez des flux de travail et des connecteurs intégrés pour exposer les transactions, données, messages, fichiers et applications à écran existants aux consommateurs modernes. Exécutez la couche d’intégration dans Azure, dans App Service Environment v3 (ASE v3), ou sur une infrastructure gérée par le client via un déploiement hybride sur Kubernetes compatible Azure Arc.

Les clients migrant depuis BizTalk Server peuvent préserver des métadonnées compatibles avec l’intégration hôte et utiliser les configurations d’adaptateurs existantes comme entrées pour de nouvelles connexions intégrées. Cette approche favorise la coexistence progressive entre les systèmes existants et modernisés tandis que les équipes déplacent les interfaces et les capacités métier en vagues gérables.

Valeur du client

Azure Logic Apps Standard fournit la valeur suivante pour la modernisation des mainframes et des moyens de gamme :

Objectif du client	valeur Azure Logic Apps Standard
Préserver les systèmes fonctionnels	Réutiliser les programmes hôtes existants, les structures de données, les files d’attente, les fichiers et les métadonnées compatibles tout en modernisant la couche d’intégration environnante.
Modernisation progressive	Introduisez les flux de travail comme façades d’intégration, déplacez une interface ou une capacité métier à la fois, et maintenez les systèmes hérités et modernes en fonctionnement pendant la transition.
Réduire le code d’intégration personnalisé	Utilisez des flux de travail visuels, des connecteurs intégrés, des transformations et du code à portée de workflow au lieu de construire chaque composant d’intégration de zéro.
Choisissez où le traitement s’exécute	Hébergez les flux de travail dans Azure ou exécutez-les sur Kubernetes compatible Arc près de systèmes locaux lorsque la latence, la résidence des données ou les exigences réseau favorisent le traitement local.
Soutenir différentes caractéristiques de charge de travail	Utilisez des flux de travail avec états pour des processus durables et longs et des flux sans état pour un traitement en mémoire à faible latence lorsque la persistance n’est pas requise.
Adopter des pratiques modernes de prestation	Stockez les définitions de flux de travail, la configuration, les métadonnées et le code de support dans le contrôle de version, et utilisez des pipelines automatisés de compilation et de déploiement.

Azure Logic Apps Standard est le principal runtime d’orchestration et d’intégration de la solution. D’autres services de messagerie, gestion d’API, distribution d’événements, bases de données ou services gérés par le client ne sont pas nécessaires par défaut. Ajoutez-les uniquement lorsque l’architecture refactorisée nécessite une capacité indépendante, une limite d’échelle, un cycle de vie ou un modèle de propriété.

Pourquoi utiliser Azure Logic Apps Standard

La norme offre des capacités adaptées à l’intégration hôte-système qui ne sont pas toutes disponibles ensemble dans le type de ressource Consommation :

• Des connecteurs intégrés, basés sur le fournisseur de services, s’exécutent dans l’environnement d’exécution Azure Logic Apps et offrent un accès direct aux systèmes mainframe et de milieu de gamme pris en charge.
• Une application de logique standard peut contenir plusieurs flux de travail connexes qui partagent des frontières de calcul, de stockage, de réseau, de configuration et de déploiement.
• Les flux de travail avec et sans état supportent des processus durables et des scénarios requête-réponse à faible latence.
• Les flux de travail Standard hébergés sur Azure supportent l’intégration virtuelle du réseau et les points de terminaison privés pour l’accès aux systèmes privés.
• Le déploiement hybride exécute des flux de travail et des opérations de connecteurs intégrées sur une infrastructure gérée par le client.
• Le développement de Visual Studio Code prend en charge les tests locaux, le contrôle de version et le CI/CD.

Azure Logic Apps Standard fournit des implémentations natives cloud de nombreuses capacités d’intégration clés historiquement fournies par Host Integration Server (HIS), y compris l’accès aux programmes de transactions IBM, aux systèmes de messagerie, aux bases de données, aux fichiers hôtes et aux applications 3270. Certains protocoles et scénarios, comme la connectivité LU6.2, nécessitent toujours le HIS.

Choisissez où exécuter les flux de travail

Les connecteurs intégrés mainframe et midrange de cet article sont pris en charge avec chaque option d’hébergement Standard. Choisissez l’option qui répond aux exigences de la charge de travail en matière de propriété de l’infrastructure, d’isolement, de connectivité, de latence et de localisation des données.

Option d’hébergement	Meilleur ajustement	Considérations importantes
Plan de service de flux de travail	Hébergement Azure géré pour les flux de travail qui se connectent aux systèmes hôtes via des chemins réseau privés ou publics.	Utilise une capacité réservée WS1, WS2 ou WS3 et prend en compte l’intégration réseau virtuel, les terminaux privés et la surveillance Azure.
App Service Environment v3	Des charges de travail hébergées sur Azure qui nécessitent une isolation dédiée, un réseautage, des frontières de conformité ou une consolidation avec d’autres charges de travail de services applicatifs.	Cela nécessite un ASE v3 et un plan de service d’application isolé v2.
Hybride	Traitement local, résidence des données, accès à faible latence aux systèmes hôtes ou infrastructure gérée par le client.	Fonctionne sur Kubernetes compatible Azure Arc et nécessite Kubernetes géré par le client, SQL Server, stockage SMB, réseau, scaling et opérations.

Le déploiement hybride est partiellement connecté, et non isolé du réseau. Les opérations intégrées des connecteurs s’exécutent avec l’exécution locale d’Azure Logic Apps, tandis que la gestion Azure et tout connecteur géré hébergé dans le cloud nécessitent une connectivité sortante. Pour les besoins et limitations actuels de l’infrastructure, voir Configurez votre propre infrastructure pour les applications logiques standard en utilisant un déploiement hybride.

Préserver les investissements d’intégration existants

Depuis des décennies, Microsoft fournit des capacités d’intégration mainframe et intermédiaire via Microsoft Host Integration Server. Azure Logic Apps Standard s’appuie sur cette expérience avec des outils et connecteurs basés sur les métadonnées qui aident à préserver les investissements existants dans les applications.

Microsoft HIS Designer pour Azure Logic Apps

Cet outil Visual Studio crée les métadonnées XML du Host Integration Designer (HIDX) que les connecteurs Azure Logic Apps utilisent pour interagir avec les programmes et structures de données mainframe et intermédiaires. Le concepteur graphique vous permet de créer, visualiser, éditer et cartographier des interfaces, méthodes, paramètres, enregistrements et types de données de programme. Vous pouvez aussi importer des copybooks COBOL et RPG. Pour plus d’informations, voir HIS Designer for Azure Logic Apps.

Outil de conception Microsoft 3270

Cet outil enregistre les écrans, les chemins de navigation, les méthodes et les paramètres des tâches dans une application 3270. L’outil génère des métadonnées HIDX que le connecteur IBM 3270 utilise pour exécuter le plan de navigation enregistré. Pour plus d’informations, consultez l’outil de conception 3270.

Migrer les intégrations BizTalk au système hôte

Si vos applications BizTalk Server utilisent des adaptateurs pour les systèmes hôtes, vous pouvez utiliser de nombreux artefacts existants et détails de configuration pour accélérer la migration vers Azure Logic Apps Standard :

• Réutilisez les métadonnées HIDX compatibles avec les connecteurs intégrés CICS, IMS, IBM i, IBM 3270 et IBM Host File.
• Utilisez les copybooks COBOL et RPG existants pour créer ou mettre à jour les métadonnées HIDX.
• Utilisez l’Azure Logic Apps Migration Agent pour découvrir les artefacts BizTalk pris en charge, y compris les liaisons, les configurations de terminaux et les fichiers HIDX, et utilisez-les lors de l’analyse, de la planification et de la conversion.

Les paramètres existants ne sont pas transférés en tant que connexions Azure Logic Apps déployables sans examen préalable. Recréer la configuration, les identifiants, les certificats et les paramètres réseau spécifiques à l’environnement d’hébergement cible, et valider le comportement résultant. Les intégrations BizTalk qui dépendent de LU6.2 nécessitent une refactorisation ou une refonte. Pour plus d’informations, consultez Migrer BizTalk Server avec Azure Logic Apps Migration Agent.

Mapper les actifs existants vers des connecteurs intégrés

Les connecteurs intégrés suivants basés sur les fournisseurs de services fonctionnent avec l’exécution standard. Certains connecteurs disposent également de versions gérées qui fonctionnent dans Azure global, mais cet article se concentre sur les versions intégrées.

Actif existant ou intégration	Azure Logic Apps Chemin de modernisation standard	Investissement à préserver
Application IBM 3270	Utilisez le connecteur IBM 3270 pour effectuer une navigation d’écran enregistrée sur un flux de données TN3270. Cette option convient aux applications qui ne proposent pas d’interface au niveau du programme.	Métadonnées de navigation HIDX et exigences de connexion TN3270. Voir Intégrer les applications IBM 3270.
Programme de transactions CICS	Utilisez le connecteur d’appel de programme CICS pour exposer les transactions existantes aux flux de travail et applications modernes via TCP/IP ou HTTP. Utilisez HIS quand LU6.2 est nécessaire.	Métadonnées HIDX, copybooks et exigences de connexion à l’hôte et à CICS. Voir Intégrer les programmes CICS.
Base de données IBM DB2	Utilisez le connecteur IBM DB2 pour lire et modifier les bases de données DB2 prises en charge directement sur TCP/IP sans passerelle de données sur site.	Serveurs, bases de données, paquets, pages de codes et exigences d’authentification. Voir Connecter aux ressources IBM DB2.
Fichier hôte IBM	Utilisez le connecteur IBM Host File pour analyser du contenu binaire en données structurées ou générer du contenu binaire de fichier hôte. Le connecteur ne nécessite pas de connexion directe à l’hôte.	Dispositions HIDX, copybooks et informations sur les pages de codes. Voir Analyser et générer des fichiers hôtes IBM.
IBM i COBOL ou programme RPG	Utilisez le connecteur IBM i Program Call pour réutiliser la logique métier établie via le serveur Distributed Program Calls via TCP/IP. Utilisez HIS quand LU6.2 est nécessaire.	Métadonnées HIDX, cahiers de copies et exigences de connexion IBM i. Voir Intégrer les programmes IBM i.
Programme de transaction IMS	Utilisez le connecteur d’appel de programme IMS pour appeler des programmes via IMS Connect via TCP/IP. En coulisses, IMS Connect utilise des files d’attente de messages IMS pour acheminer les requêtes et les réponses.	Métadonnées HIDX, cahiers de copies et paramètres IMS Connect. Voir Intégrer les programmes IMS.
Messagerie IBM MQ	Utilisez le connecteur IBM MQ pour connecter les files d’attente et messages existants aux processus de flux de travail modernes.	Gestion de file, canal, file d’attente, TLS et exigences de format de messages. Voir Connecter à IBM MQ.

Modernisation progressive

Les environnements mainframe et intermédiaires contiennent souvent des programmes, des données, des fichiers, des planificateurs et des interfaces externes étroitement connectés. Une migration de type big bang vise à remplacer le périmètre sélectionné lors d’un déploiement coordonné unique. Cette approche peut convenir à un petit environnement bien maîtrisé, mais les risques liés à la livraison et à la bascule augmentent avec le nombre de dépendances et la durée du projet.

Pour la plupart des domaines, utilisez des vagues itératives pour préserver le comportement de travail et apporter de la valeur plus rapidement :

1. Inventez les programmes, les données, les interfaces, les tâches, les dépendances, les objectifs de service et les exigences opérationnelles.
2. Sélectionnez un flux d’intégration de bout en bout avec une valeur commerciale claire et des dépendances gérables.
3. Introduisez Azure Logic Apps Standard comme façade d’intégration tant que le système hôte reste opérationnel.
4. Réutilisez les métadonnées compatibles et configurez les connecteurs intégrés nécessaires.
5. Testez le comportement fonctionnel, le débit, la récupération, la sécurité et la coexistence avec l’implémentation héritée.
6. Redirigez les consommateurs vers l’interface modernisée et surveillez le flux de production.
7. Répétez l’opération pour les vagues suivantes et ne retirez les interfaces héritées qu’une fois que leurs consommateurs et leurs dépendances ont migré.

Chaque vague peut fournir une caractéristique ou un groupe apparenté de flux d’intégration. Les tâches partagées et les applications hautement interconnectées pourraient rester jusqu’aux vagues suivantes, après que des interfaces à moindre risque auront établi des flux de travail réutilisables, des schémas de sécurité, de déploiement et d’opérations.

Appliquer les schémas de modernisation

Utilisez des patrons d’architecture selon la charge de travail cible plutôt que de considérer un seul motif comme obligatoire.

Modèle de couche de lutte contre la corruption

Envisagez d’utiliser Azure Logic Apps Standard comme couche anti-corruption entre les interfaces héritées et les consommateurs modernes. Les flux de travail peuvent traduire protocoles, formats et modèles d’interaction sans que les consommateurs comprennent les détails spécifiques à chaque hôte. La façade peut fonctionner en Azure ou sur Kubernetes compatible Arc près de l’environnement hôte.

Pour plus d’informations, voir le motif de la couche anti-corruption.

Modèle Figuier étrangleur

Utilisez le motif Strangler Fig pour router des interfaces ou capacités sélectionnées à travers la nouvelle couche d’intégration pendant que la charge de travail restante continue d’être exécutée sur l’hôte. Remplacer progressivement les implémentations, valider chaque bascule et ne mettre hors service les composants hérités qu’une fois leurs dépendances migrées.

Pour plus d’informations, consultez Modèle Fig Strangler.

Modèles Saga et de chorégraphie

Utilisez le modèle Saga lorsqu’un processus métier englobe des systèmes qui ne peuvent pas participer à une seule transaction distribuée. Un workflow avec état peut agir comme l’orchestrateur central d’une saga en coordonnant les participants et en gérant explicitement les nouvelles tentatives, les échecs et les actions compensatoires. Chaque participant effectue sa propre transaction locale. Les actions de workflow ne sont pas automatiquement atomiques en groupe, et Azure Logic Apps n'annule pas automatiquement les changements dans les systèmes externes. Concevez des opérations de manière idempotente et implémentez la compensation à l’aide d’actions, de portées et de conditions d’exécution ultérieure.

Dans une saga basée sur la chorégraphie, les services participants échangent des événements via une infrastructure de messagerie sans un flux de travail central coordonnant l’ensemble de la transaction. Ajouter des services tels que Azure Service Bus ou Azure Event Grid uniquement lorsque l’architecture nécessite une messagerie indépendante ou une distribution d’événements. Pour plus d’informations, consultez le modèle de transactions distribuées Saga et le modèle Chorégraphie.

Sécurité du plan, opérations et coûts

• Utilisez la connectivité réseau privée et une authentification sécurisée adaptée à l’environnement d’hébergement et au système hôte. Stockez les secrets dans des espaces de stockage des secrets approuvés plutôt que dans des définitions de flux de travail.
• Conservez les définitions de workflow, les fichiers HIDX, les modèles de configuration et le code de support dans le contrôle de versions. Séparez les valeurs spécifiques à l’environnement des artefacts déployables et utilisez des pipelines automatisés.
• Conception pour les nouvelles tentatives et le traitement au moins une fois. Utilisez l’idempotence, la déduplication, les identifiants de corrélation et les écritures sûres pour éviter les effets en double.
• Définissez la surveillance, les alertes, la rétention de l’historique d’exécution, la reprise après sinistre et la gestion du support avant la coupure de production. Les déploiements hébergés Azure et hybrides présentent des capacités et des limites de surveillance différentes.
• Comparez le coût total de possession entre hébergement, utilisation des connecteurs, réseau, stockage, surveillance et infrastructure gérée par le client. La norme inclut des exécutions d’opérations intégrées, tandis que les opérations de connecteurs gérées et les ressources de soutien peuvent ajouter des charges.

Pour connaître les limites et les tarifs actuels, consultez les limites et la configuration d’Azure Logic Apps ainsi que les tarifs et les modèles de facturation d’Azure Logic Apps.

Exemples de scénarios de modernisation

Exposer une transaction CICS à une application moderne

Créer un flux de travail standard qui appelle un programme CICS existant via le connecteur intégré, transforme la réponse et renvoie une interface moderne à une couche application ou API. Conservez le programme CICS comme système de référence tandis que les applications clientes abandonnent progressivement la connectivité propre à l’hôte.

Rendre les données DB2 accessibles à l’analyse

Utilisez un flux de travail standard pour lire les données opérationnelles approuvées de DB2, valider et transformer les enregistrements, puis les envoyer à un service de données ou d’analyse Azure. Cette approche évite de créer un programme d’extraction de mainframe distinct pour chaque consommateur tout en préservant la gouvernance sur le moment et la manière dont les données quittent l’hôte.

Exécuter une intégration près des systèmes hôtes

Déploiez Azure Logic Apps Standard sur Kubernetes compatible Azure Arc lorsque les flux de travail nécessitent un traitement local, une résidence de données ou un accès à faible latence aux systèmes IBM. Les opérations de connecteurs intégrées s’exécutent avec l’exécution locale, tandis que le flux de travail peut se connecter sélectivement aux services Azure lorsque l’architecture et la politique réseau le permettent.

Étapes suivantes

• Créer des workflows Standard avec Visual Studio Code
• Mettre en place une infrastructure de déploiement hybride
• Examinez les connecteurs intégrés pour les flux de travail standards
• Migrer BizTalk Server avec Azure Logic Apps Migration Agent
• Découvrez les conseils du Centre d’architecture Azure pour les mainframes et les systèmes de milieu de gamme