Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Azure Logic Apps est le successeur de BizTalk Server. Azure Logic Apps Standard offre l’orchestration des flux de travail, l’intégration en entreprise et l’extensibilité pour les solutions cloud et hybrides. Cet article résume les raisons de la migration, les options d’hébergement disponibles et les capacités BizTalk que vous devez évaluer.
Pour les stratégies de migration, les considérations de planification et les conseils de livraison, consultez Migrer BizTalk Server avec Azure Logic Apps Migration Agent.
Cycle de vie du BizTalk Server
BizTalk Server 2020 est la dernière version de BizTalk Server. Microsoft prévoit que les ventes de BizTalk Server 2020 se termineront le 31 mars 2027. Le support grand public se poursuit jusqu’au 12 avril 2028, après quoi le produit reste soumis à la politique fixe du cycle de vie fixe de Microsoft.
Microsoft prévoit également d’offrir aux clients éligibles un support étendu optionnel, payant, du 13 avril 2028 au 10 avril 2030. Cette offre est destinée à une couverture temporaire de migration, devrait exclure certaines fonctionnalités de BizTalk, et reste soumise à l’éligibilité finale, à la couverture, aux prix et aux conditions d’achat.
Commencez la planification des migrations tôt, surtout si vos solutions dépendent de la surveillance de l’activité métier (BAM), de la boîte à outils Enterprise Service Bus (ESB), des accélérateurs industriels, des adaptateurs d’entreprise hérités, des outils de gestion du cycle de vie des applications spécifiques à BizTalk, ou des versions Visual Studio après Visual Studio 2022. Ces capacités devraient être exclues du support étendu rémunéré ou nécessiter une refonte.
Pour les dates et conditions les plus récentes, voir :
- Mise à jour du cycle de vie du produit Microsoft BizTalk Server
- Annonce de fin de vente BizTalk Server 2020
- Politique de cycle de vie fixe Microsoft
Pourquoi Logic Apps Standard s’adapte aux charges de travail de BizTalk
Les applications BizTalk combinent couramment une orchestration durable, la messagerie, les transformations, le traitement business-to-business (B2B), du code personnalisé et l’accès à des systèmes privés. Azure Logic Apps Standard offre ces capacités d’intégration dans un runtime à locataire unique et prend en charge à la fois les flux de travail avec états et sans état. Contrairement à une application de logique de consommation, une application logique standard peut contenir plusieurs flux de travail partageant le calcul, le stockage, le réseau et la configuration.
Les capacités suivantes font de Standard le type de ressource privilégié pour les applications logiques pour la plupart des projets de modernisation BizTalk :
| Configuration requise pour BizTalk | Capacité standard des applications logiques |
|---|---|
| Processus métier durables et de longue durée | Les flux de travail avec état persistent dans l’état d’exécution et peuvent récupérer des exécutions interrompues. Les flux de travail sans état supportent un traitement en mémoire à faible latence lorsque la persistance n’est pas nécessaire. |
| Processus d’intégration associés | Plusieurs flux de travail peuvent s’exécuter dans une seule application de logique standard et partager des ressources, des configurations et des frontières de déploiement. |
| Messagerie d’entreprise et formats de données | Les connecteurs et actions intégrés prennent en charge des services tels que Azure Service Bus, Event Hubs, SQL Server, XML, fichiers plats, transformations et scénarios B2B. |
| Logique d’implémentation personnalisée | Les fonctions locales .NET exécutent du code à portée de flux de travail parallèlement aux workflows situés dans la même frontière de projet et d’application. Les scripts en ligne, les connecteurs intégrés personnalisés et les services externes offrent d’autres options d’extensibilité. |
| Connectivité privée et locale | L’exécution dédiée mono-locataire prend en charge l’intégration à un réseau virtuel et les points de terminaison privés. Le déploiement hybride exécute des flux de travail sur une infrastructure gérée par le client lorsque le traitement local est nécessaire. |
| Gestion du cycle de vie des applications | Le développement Visual Studio Code, les tests locaux, l’infrastructure en tant que code et le CI/CD séparent le déploiement des applications de workflow du provisionnement d’infrastructure. |
| Choix de déploiement | Utilisez Workflow Service Plan pour l’hébergement Azure géré, App Service Environment v3 pour l’hébergement Azure isolé, ou Hybrid pour les environnements Kubernetes gérés par le client. |
Logic Apps Standard fournit la plupart des capacités de base nécessaires à la modernisation des solutions BizTalk et sert de plateforme principale d’orchestration et d’intégration pour l’architecture cible, qu’elle soit hébergée en Azure ou déployée dans un environnement hybride. Les autres services ne sont pas requis par défaut. Pour les solutions hébergées sur Azure, ajoutez uniquement des services Azure tels que Azure Service Bus, Gestion des API Azure ou Azure Event Grid lorsque la solution refactorée nécessite un courtage de messages indépendant, une gestion du cycle de vie de l’API ou une distribution d’événements. Pour les déploiements hybrides, utilisez des services gérés par le client compatibles pour toutes les capacités ou limites architecturales que la solution exige en dehors de la norme Logic Apps.
Raisons de migrer
| Avantage | Descriptif |
|---|---|
| Plateforme d’intégration moderne | Construisez des flux de travail avec orchestration managée, connecteurs d’entreprise, capacités B2B, intégration API et sécurité et surveillance cloud-native. Évaluer l’automatisation assistée par IA et l’automatisation agente lorsque cela est supporté. |
| Préserver certains investissements | Réutiliser ou adapter de nombreux schémas, cartes, règles, assemblages et composants .NET personnalisés de BizTalk plutôt que de reconstruire chaque artefact. |
| Hébergement flexible | Exécutez des flux de travail standards dans Azure ou utilisez un déploiement hybride pour le traitement local, l’accès au réseau, la résidence des données ou les exigences réglementaires. |
| Développement low-code et pro-code | Combinez le concepteur visuel de workflow avec des définitions de workflow contrôlées par source, des scripts en ligne, des fonctions locales .NET, des connecteurs personnalisés et des services externes. |
| Opérations modernes | Utilisez le contrôle d’accès basé sur les rôles Azure (Azure RBAC), l’infrastructure en tant que code, et les pipelines automatisés. Les flux de travail hébergés sur Azure s’intègrent avec Azure Monitor et Application Insights, tandis que les déploiements hybrides utilisent OpenTelemetry et présentent des limitations de fonctionnalités différentes. |
| Contrôle des coûts | Partagez la capacité entre les flux de travail associés, choisissez un modèle d’hébergement qui correspond à la demande de charge de travail, et utilisez les opérations intégrées ainsi que les fonctions locales autant que possible. |
Construire une architecture de cible rentable
La rentabilité dépend du volume de travail, de l’isolation requise, de l’infrastructure existante, de l’utilisation des connecteurs et des responsabilités opérationnelles. Comparez le coût total de possession plutôt que les frais d’hébergement des applications logiques. Une base BizTalk peut inclure les licences BizTalk Server, Windows Server et SQL Server ; le calcul et le stockage ; la haute disponibilité et la reprise après sinistre ; les correctifs ; la surveillance ; les outils de déploiement ; et le support opérationnel spécialisé.
Utilisez les pratiques suivantes lorsque vous construisez le modèle de coût cible :
- Regrouper les flux de travail liés avec des exigences compatibles en matière de sécurité, de cycle de vie et de mise à l’échelle dans la même application de logique standard afin de pouvoir partager le calcul réservé et les ressources de support. Gardez les charges de travail séparées lorsqu’elles nécessitent une mise à l’échelle indépendante, de l’isolation, du déploiement ou de la propriété.
- Privilégiez les opérations de connecteurs intégrés lorsqu’elles répondent à vos besoins. Le modèle Standard inclut des opérations intégrées illimitées, tandis que les opérations de connecteur géré sont facturées par appel.
- Conservez le code .NET limité à la portée du workflow dans des fonctions locales lorsque cela est approprié. Les fonctions locales utilisent la frontière d’application Logic Apps Standard et ne nécessitent pas une application de fonction distincte, un point de terminaison, un flux d’authentification, un pipeline de déploiement ou une frontière de surveillance séparée. Le code consomme toujours de la capacité dans le plan Standard.
- Dimensionnez correctement la capacité du plan de service Workflow et examinez le taux d’utilisation à mesure que les vagues de migration passent en production. Le forfait est facturé pour la capacité réservée même lorsque les flux de travail sont inactifs.
- Utilisez App Service Environment v3 lorsque l’isolation, le réseau dédié, la conformité ou la consolidation justifient un plan d’application v2 isolé. Ne supposez pas que l’ASE v3 est l’option la moins coûteuse pour les charges de travail plus petites.
- Utilisez l’hybride lorsque l’exécution locale, la résidence de données ou l’infrastructure existante apportent une valeur suffisante. Incluez dans le calcul l’environnement Kubernetes compatible Azure Arc, la licence SQL Server, le stockage SMB, le réseau, les opérations et l’utilisation du vCPU de Logic Apps.
- Prenez en compte les opérations de stockage, les comptes d’intégration, le réseau, la surveillance, ainsi que le coût temporaire d’exécuter BizTalk et Logic Apps en parallèle lors de la migration.
Pour plus de détails sur la tarification, consultez les modèles de tarification et de facturation d’Azure Logic Apps ainsi que la page de tarification d’Azure Logic Apps.
Choisir une option d’hébergement
Azure Logic Apps a des types de ressources de consommation et de ressource standard séparés. Pour la migration de BizTalk, utilisez les fonctionnalités Azure Logic Apps Standard et choisissez une option d’hébergement hébergée sur Azure ou hybride selon vos besoins.
Important
Si vous utilisez actuellement Azure Logic Apps Consumption et prévoyez de migrer des charges de travail BizTalk Server, vous devez migrer vers Azure Logic Apps Standard. Les capacités de migration BizTalk ne sont pas prises en charge pour les flux de travail de Consommation.
| Option d’hébergement | Meilleur ajustement | Coût et propriété | Considérations importantes |
|---|---|---|---|
| Plan de service de flux de travail | Le choix par défaut pour les migrations BizTalk hébergées sur Azure nécessitant une capacité Standard dédiée et des capacités Azure gérées. | Capacité réservée WS1, WS2 ou WS3 dans un environnement géré par Microsoft. | Prend en compte plusieurs flux de travail par application logique, l’intégration réseau virtuel, les points de terminaison privés et l’accès aux capacités de surveillance Azure. |
| App Service Environment v3 | Des charges de travail nécessitant un hébergement Azure isolé, un réseau dédié, des frontières de conformité ou une consolidation avec d’autres charges de travail de services applicatifs. | Des instances isolées v2 App Service Plan dans un environnement dédié. | Nécessite un ASE v3 existant ou nouveau et doit être justifié par des exigences d’isolation, d’échelle ou de consolidation. |
| Hybride | Des charges de travail nécessitant un traitement local, un accès à faible latence aux systèmes locaux, la résidence des données, le placement en périphérie ou une infrastructure gérée par le client. | Utilisation des vCPU dans Logic Apps ainsi que Kubernetes, SQL Server, stockage SMB, réseautage et opérations gérés par le client. | Utilise Kubernetes compatible Azure Arc avec l’extension Azure Container Apps et nécessite une connectivité Azure sortante. Certaines fonctionnalités cloud ne sont pas prises en charge. |
Considérations de déploiement hybride
Le déploiement hybride est partiellement connecté, et non isolé du réseau. L’environnement nécessite une connectivité sortante pour Azure Arc et les opérations de gestion Azure. Les connecteurs gérés hébergés dans le cloud nécessitent également une connectivité à Azure. Les interruptions temporaires de connectivité n’arrêtent pas nécessairement le traitement local des flux de travail, mais peuvent affecter la gestion, la télémétrie et les opérations dépendantes du cloud.
Pour l’infrastructure requise, les configurations prises en charge, les prix et les limitations actuelles, voir Configurer votre propre infrastructure pour les applications logiques standard en utilisant un déploiement hybride.
Faire correspondre les fonctionnalités de BizTalk à Logic Apps
BizTalk Server et Azure Logic Apps utilisent des architectures différentes. Utilisez l’Agent de migration pour inventorier chaque application BizTalk, associer ses artefacts et schémas d’intégration aux capacités des applications logiques, et identifier les composants que vous devez réutiliser, refactoriser, remplacer ou repenser.
| Capacité BizTalk | Chemin de modernisation des applications logiques | Évaluation typique | Conseils connexes |
|---|---|---|---|
| Orchestrations | Flux de travail standard avec ou sans état | Refactoriser la logique des processus métier en flux de travail. | Créer un flux de travail standard |
| Pipelines et code utilitaire | Actions de workflow, fonctions locales .NET, code en ligne, connecteurs personnalisés ou services externes | Réutiliser ou refactoriser en fonction du cycle de vie requis et du périmètre de mise à l’échelle. | Créer et exécuter des fonctions locales .NET |
| Routage de MessageBox | Rubriques et abonnements Azure Service Bus, échanges RabbitMQ, rubriques Apache Kafka ou routage de flux de travail | Reconcevez la messagerie indépendamment du moteur d’exécution du workflow. | Files d’attente, rubriques et abonnements Service Bus |
| Schémas et mappages | artefacts du projet, mappages XSLT, modèles Liquid et le Data Mapper | Réutilisez des artefacts compatibles et validez les transformations. | Schémas et mappages |
| Règles d’entreprise | Moteur de règles Azure Logic Apps | Réutiliser les politiques prises en charge par le moteur de règles métier BizTalk ou refactorer des faits non étayés. | Aperçu de Azure Logic Apps Rules Engine |
| EDI et B2B | Flux de travail standard, connecteurs et comptes d’intégration | Évaluez les partenaires, les accords, les certificats, les schémas et les exigences du protocole. | Flux de travail d’intégration B2B pour les entreprises |
| Adaptateurs | Connecteurs et API intégrés, gérés ou personnalisés | Confirmez la disponibilité des connecteurs, l’authentification, le débit et le support de l’hébergement. | Vue d’ensemble des connecteurs |
| BAM | Suivi des processus métiers Azure pour les solutions hébergées sur Azure prises en charge, ou une conception d’observabilité externe | Redesign pour un déploiement hybride, où Suivi des processus métiers Azure n'est pas pris en charge. | Aperçu de Suivi des processus métiers Azure |
| Suivi et surveillance | Historique des exécutions, propriétés suivies, Azure Monitor, Application Insights et OpenTelemetry | Refactoriser le modèle opérationnel et de soutien. | Surveillez les applications logiques et les flux de travail |
Le schéma suivant offre une autre vue d’ensemble des capacités courantes de BizTalk Server et de leurs chemins de modernisation hébergés sur Azure :
Pour la disponibilité détaillée des fonctionnalités, voir connecteurs Azure Logic Apps, aperçu de l’intégration entreprise, et limites et configuration d’Azure Logic Apps.
Considérations clés sur la migration
Architecture et fiabilité
- Commencez par Azure Logic Apps Standard comme application cible. Utilisez des fonctionnalités natives de workflow, des connecteurs intégrés et des fonctions locales lorsque cela est approprié, et ajoutez d’autres services d’intégration Azure uniquement lorsqu’une exigence architecturale spécifique les justifie.
- Pour les modèles publish-subscribe, utilisez un courtier de messages tel que Azure Service Bus, RabbitMQ ou Apache Kafka plutôt que de reproduire la boîte de messages BizTalk dans un flux de travail.
- Conception pour les nouvelles tentatives et le traitement au moins une fois. Utilisez l’idempotence, la déduplication et les écritures sûres pour éviter les effets en double lorsque les opérations sont réessayées ou les exécutions sont resoumises.
- Vérifiez les limites des messages et des connecteurs. Pour les charges utiles volumineuses, utilisez le découpage en blocs du connecteur lorsqu’il est pris en charge ou implémentez le modèle claim-check pattern.
- Utilisez passerelle VPN, ExpressRoute ou un autre design de connectivité hybride pour connecter les réseaux locaux à Azure. Le peering de réseau virtuel connecte les réseaux virtuels Azure ; il ne connecte pas à lui seul un réseau sur site à Azure.
Code personnalisé
Avoir du code personnalisé dans une solution BizTalk ne signifie pas automatiquement que l'architecture cible nécessite une ressource Azure Functions séparée. Utilisez des fonctions locales .NET pour le code qui appartient à un flux de travail d’intégration. Les fonctions locales résident dans le même projet que les flux de travail et s’exécutent dans la limite de l’application Logic Apps Standard. Les flux de travail, les connecteurs, la configuration et le code peuvent être construits, déployés, évolués et opérés ensemble.
Les fonctions locales conviennent à la validation des messages à l’échelle du flux de travail, à l’enrichissement, aux calculs, à l’analyse syntaxique personnalisée, à la mise en forme et au traitement spécifique à l’activité. Ils peuvent également aider à moderniser les assemblages d’aide BizTalk, les utilitaires d’orchestration et la logique adjacente au pipeline lorsque ce code appartient à une application d’intégration spécifique. Cette approche évite d’introduire un point de terminaison séparé, un flux d’authentification, une ressource d’hébergement, un pipeline de déploiement et une frontière de surveillance uniquement pour exécuter du code spécifique au workflow.
Utilisez les conseils suivants pour sélectionner le modèle d’hébergement de code approprié :
| Utilisez les fonctions locales lorsque | Utilisez une ressource Azure Functions séparée lorsque |
|---|---|
| Le code est spécifique à une application standard Logic Apps. | Le code est partagé par plusieurs applications, flux de travail ou équipes. |
| Le code valide, enrichit, analyse, formate ou calcule les données au sein d’un flux de travail. | Le code fournit une API, un service ou une capacité de calcul pilotée par les événements, gérés de manière indépendante. |
| Le workflow et le code doivent être déployés, évolués et fonctionner ensemble. | Le code nécessite une mise à l’échelle, un système de versions, un déploiement ou une propriété opérationnelle indépendante. |
| Le code n’a pas besoin d’un point de terminaison réseau séparé ni d’une frontière d’authentification. | Le code doit exposer et sécuriser son propre point d’extrémité ou frontière d’identité. |
| L’assistant BizTalk ou la logique adjacente au pipeline appartient au flux d’intégration migré. | Le code est la charge de travail principale de calcul et le flux de travail des applications logiques ne concerne qu’un seul consommateur. |
Les fonctions locales consomment la capacité de calcul attribuée à l’application logique standard et ne remplacent pas toutes les fonctions ou services autonomes. Leur avantage en coût et en fonctionnement provient de l’évitement d’une limite de ressources inutile lorsque le code fait partie du flux de travail. Les flux de travail standards prennent également en charge JavaScript en ligne, C# et PowerShell pour le code à court terme, ainsi que des connecteurs personnalisés et des appels vers des API externes. Pour des conseils architecturaux, voir Coding with Logic Apps Standard : Local Functions.
Sécurité et identité
Utilisez Microsoft Entra ID, Azure RBAC, Azure Key Vault, le réseau privé, ainsi que des entrées et sorties sécurisées pour protéger les flux de travail et les données. Les connexions OAuth utilisent une autorisation basée sur un jeton et peuvent nécessiter une connexion interactive et un consentement. Ne considérez pas OAuth comme le stockage de l’adresse e-mail et du mot de passe d’un utilisateur dans le flux de travail.
Pour les connecteurs pris en charge dans les flux de travail Standard hébergés sur Azure, les identités gérées suppriment le besoin de stocker des identifiants ou des jetons d’accès. Lors du développement local, l’extension Azure Logic Apps Standard peut utiliser l’identité du développeur connecté via la chaîne d’identifiants Azure Identity, tandis que le flux de travail déployé utilise son identité gérée assignée par le système ou par l’utilisateur. Les deux identités nécessitent des autorisations appropriées sur la ressource cible. Cette fonctionnalité de Visual Studio Code ne modifie pas la limitation hybride existante pour l’authentification par identité managée dans les opérations de connecteur. Pour plus d’informations, voir Utiliser des connecteurs avec identité gérée dans l’extension Logic Apps Standard.
Déploiement et opérations
Stockez les définitions de flux de travail, la configuration et les artefacts dans le contrôle de version et utilisez des pipelines automatisés de compilation et de déploiement. Bicep compile vers des modèles Azure Resource Manager. Terraform et Pulumi sont des outils alternatifs d’infrastructure en tant que code qui gèrent les ressources Azure via leurs fournisseurs respectifs.
Planifiez la surveillance, le contrôle d’accès, la configuration de l’environnement, la reprise après sinistre et la gestion du support avant la première vague de migration en production. Sécurisez les entrées et sorties sensibles des actions afin qu’elles n’apparaissent pas dans l’historique d’exécution ni dans la télémétrie.
Étapes suivantes
Utilisez une approche de migration itérative pour gérer les dépendances d’inventaire, prioriser les charges de travail, valider les conceptions cibles et libérer en vagues gérables. L’Azure Logic Apps Migration Agent peut vous aider à la découverte, l’analyse, la planification, la conversion, la validation et le déploiement tout en conservant le contrôle de l’architecture et des décisions d’implémentation.