BizTalk : comment migrer efficacement vers Azure Integration Services ?

Avec l’évolution rapide des technologies cloud, de nombreuses entreprises cherchent à moderniser leurs plateformes d’intégration. Microsoft BizTalk Server montre aujourd’hui ses limites face aux exigences actuelles de flexibilité, de scalabilité et d’agilité. Cette réflexion devient d’autant plus urgente que la fin du support étendu de BizTalk Server est officiellement annoncée pour 2030, poussant les organisations à anticiper leur transition vers une solution d’intégration plus moderne, capable de répondre aux nouveaux besoins tels que le streaming ou l’event-driven architecture. 

C’est dans ce contexte que Azure Integration Services (AIS) s’impose comme une alternative moderne, cloud-native. Mais migrer de BizTalk vers AIS ne se résume pas à un simple lift-and-shift. Il s’agit d’un véritable changement de paradigme. Cet article a pour objectif de mettre en lumière les correspondances techniques entre BizTalk et les composants Azure, afin de vous aider à mieux appréhender cette transition. Nous verrons comment les orchestrations, adaptateurs, mappings, pipelines ou encore la gestion des erreurs trouvent leurs équivalents ou évolutions dans l’écosystème Azure. 

En préambule avant de plonger dans les correspondances entre les fonctionnalités de BizTalk et les services Azure, nous allons voir quelles sont les plus-values des plateformes d’intégration Azure. 

Les plus-values des plateformes d’intégration Azure 

Migrer sa plateforme d’intégration BizTalk vers Azure amène un certain nombre d’avantage qui sont :  

• Une plateforme managée et hautement scalable
  Azure Integration Services repose sur des services entièrement managés, libérant les équipes des contraintes liées à l’infrastructure. La plateforme s’adapte automatiquement aux charges de travail, permettant une mise à l’échelle horizontale et verticale selon les besoins, tout en garantissant une haute disponibilité et une résilience native. 

• Une sécurité native et complète
  Azure offre une sécurité intégrée de bout en bout, avec une authentification centralisée via Azure EntraID, le chiffrement automatique des données en transit et au repos, ainsi qu’une gestion fine des accès et des identités (RBAC, Managed Identities).  

• Une architecture modulaire et sur-mesure
  Grâce à une approche basée sur des services découplés (Logic Apps, API Management, Service Bus…), la solution s’ajuste aux cas d’usage spécifiques de chaque organisation. Elle permet de composer une plateforme d’intégration sur-mesure, évolutive dans le temps. 

• Une interopérabilité étendue et moderne
  Azure prend en charge une large variété de protocoles et de formats d’échange, comme REST, JSON, EDIFACT, …. Cela permet une intégration fluide avec les systèmes existants, qu’ils soient on-premise ou dans le cloud. Azure permet également d’adopter de nouveaux patterns modernes comme l’event-driven et le streaming. 

• Un socle technologique robuste basé sur les services Azure mainstream
  La plateforme s’appuie sur des composants largement utilisés de l’écosystème Azure, tels que Key Vault (gestion des secrets), Storage Account (stockage cloud), ou Log Analytics Workspace et App Insight (pour la centralisation et l’exploitation des logs). 

Après avoir examiné les plus-values d’une migration vers Azure, il est désormais pertinent d’analyser les correspondances entre BizTalk Server et Azure. Bien identifier ces équivalences, tout en comprenant les différences induites par le changement de paradigme, est essentiel pour se projeter sereinement dans ce chantier de transformation. Cela permet également de poser les bases d’une stratégie de migration claire et structurée. 

Migration BizTalk : quels composants Azure pour remplacer quoi ? 

À la différence de BizTalk, qui est une solution EAI (Enterprise Application Integration) packagée, où toutes les fonctionnalités sont regroupées dans un outil unique, Azure propose un ensemble de services modulaires à assembler selon les besoins pour construire sa propre plateforme d’intégration. Ce changement peut être déroutant pour les équipes habituées à une approche monolithique. 

C’est pour répondre à cette complexité que Microsoft a regroupé plusieurs de ses services d’intégration sous la suite Azure Integration Services (AIS), afin de clarifier l’offre et de faciliter la mise en œuvre de solutions d’intégration cloud modernes. 

Azure Integration Services (AIS) est une boîte à outils complète contenant tout le nécessaire pour concevoir des interfaces d’intégration. Elle se compose de six services clés :
Logic Apps, Azure Functions, API Management, Service Bus, Event Grid et Azure Data Factory. Pour une description détaillée de chacun de ces services et de leurs cas d’usage, vous pouvez consulter notre article de blog : Comment décliner sa plateforme d’intégration en services Azure avec AIS ? 

Pour répondre aux enjeux de sécurité, de supervision et de connectivité réseau, AIS est complété par d’autres services Azure mainstream tels que : 

• Azure Key Vault pour la gestion des secrets, 

• Azure Storage Account pour le stockage de fichiers et messages, 

• et des composants réseau comme Azure Virtual Network (VNet). 

Nous allons maintenant passer en revue les principales fonctionnalités de BizTalk Server et présenter leurs équivalents dans l’univers Azure, afin de vous aider à mieux comprendre les correspondances et les adaptations nécessaires pour réussir votre migration. 

 Orchestration 

Le principal atout de BizTalk est la particularité d’enchainer des actions de manière séquentielle. Ce composant est l’“Orchestration”, fonctionnalité majeure dans la création et l’ordonnancement des flux…  

Côté Azure, c’est le composant LogicApp qui remplit ce rôle.  

Ces actions séquentielles peuvent se faire de manière synchrone, c’est-à-dire que le flux se déroule “en temps réel”, coordonnées.  

Bien entendu la possibilité de développer des flux asynchrones est présente. Dans cette situation, le comportement naturel de BizTalk permet de persister et sauvegarder les messages dans la “MessageBox”. Il permet grâce aux orchestrations de pouvoir retourner un message après un certain délai. Dans ce cas, il est possible d’envoyer un appel au partenaire source après avoir reçu la réponse du partenaire destination.  

Dans le cas des LogicApps, il est possible de sauvegarder/persister un message grâce au ServiceBus dans le but de le consommer plus tard en le stockant temporairement dans une queue par exemple (utilisation du pattern publish/subscribe). 

Connecteurs-adapteurs et ports 

Contrairement à BizTalk, LogicApp concentre à la fois la notion d’orchestrations mais aussi celle de port (send ou receive). Là où BizTalk possède plusieurs éléments à configurer pour qu’un flux soit pleinement fonctionnel, Azure LogicApp permet de centraliser l’ensemble des composants. 

Par conséquent, le développement peut être plus rapide et les erreurs moins difficiles à monitorer. 

En détail : 

La notion de connecteur dans LogicApp, correspond à la configuration des Send et/ou Receive Port dans BizTalk. Ces artefacts permettent de choisir les connecteurs à utiliser en fonction des besoins.  

Il est à noter que dans BizTalk, il y a un nombre très restreint de choix en comparaison avec Azure. On se limite à une dizaine de connecteurs fournis par Microsoft. Néanmoins, nous faisons parfois face à des situations qui demandent l’utilisation de connecteurs spéciaux développés par des éditeurs tiers permettant la communication avec certains applicatifs. Et qui dit éditeurs, dit, bien entendu, coût supplémentaire… Nous pouvons aussi noter que la maintenabilité n’est pas garantie ne serait-ce qu’avec d’anciennes versions ou bien les dernières en date. 

Dans LogicApp Azure les connecteurs sont nombreux et maintenus ; c’est une très grande force de ce composant 

1.Les connecteurs dit “Managed” 

Les connecteurs “Managed” s’exécutent dans des clusters de connecteurs partagés dans le cloud Azure mutualisés. Ils sont accessibles via appel HTTP.  Ces connecteurs possèdent souvent des fonctionnalités supplémentaires et avancés mais sont facturés à l’utilisation.  

2. Les connecteurs dit “Built-In” 

Les connecteurs “Built-In” s’exécutent dans le même cluster et runtime que la Logic App Standard car ils sont préinstallés dans l’environnement. Ces connecteurs ont la possibilité de se connecter à des VNETs et sont tenu à jour par Microsoft. Et dernier détail important, ils n’entrainent pas de surcoût. 

3.Les connecteurs dit “Custom” 

Azure vous donne la possibilité de créer vos propres connecteurs. On les appelle les connecteurs “custom”. Les paramétrages se font via le composant “Logic App Custom Connector”. Une fois créé il est utilisable par l’ensemble des LogicApp du même tenant. Et, de surcroit, il peut être partagé à plusieurs utilisateurs ou groupes Entra ID. Et bien sûr il est possible de gérer le versionning du composant. 

Attention toutefois, les connecteur Managed et Custom engendre des coûts supplémentaires à l’utilisation.  

Mapping 

Enjeu important dans la communication entre applicatif la transformation des messages. 

Dans LogicApp il est possible d’utiliser un « DataMapper », qui est un héritage du DataMapper BizTalk. 

Nous avons donc 2 composants relativement identiques pour nos 2 applicatifs à ceci près que concernant le data mapper de LogicApp, celui-ci est compatible avec le XSLT 3.0. Or BizTalk, lui, ne supporte que le 1.0. 

Chose importante à prendre en compte, Azure LogicApp Standard et BizTalk utilise le même mécanisme de mapping. Les maps sont développées via le XSLT et les schémas sont au format XSD. Cela assure une compatibilité entre les deux. 

Par conséquent, un “lift & shift” des maps XSLT et des schéma XSD depuis BizTalk est très rapide. Pas besoin de redéveloppement. 

Un point a noté tout de même, ce lift & shift avec l’utilisation LogicApp Consumption nécessite l’utilisation du service Integration Account qui peut s’avérer onéreux. 

 APIs  

Il est bien entendu possible d’utiliser des APIs et de permettre aux différents partenaires de les utiliser.  

Au sein de BizTalk, il est nécessaire d’utiliser IIS (le serveur web Microsoft). Il faut configurer l’API et se synchroniser avec les équipes infrastructures et/ou réseaux pour permettre aux partenaires de pouvoir les utiliser (credentials, whitelisting, etc.). 

Au contraire, dans Azure on peut utiliser API Management avec tous les avantages que ça procure. La facilité de pouvoir déployer rapidement une API par exemple. Il est tout aussi complet en termes de configuration réseau et de règles firewall ou load balancing. En résumé plus simple et mieux intégré. 

Le rôle de Backend peut être endossé par une LogicApp comme mentionner ci-dessus, mais il est tout à fait envisageable de créer des Azure Function pour remplir ce rôle. 

« Helpers » C# 

Il est possible que les actions disponibles dans une LogicApp ne permettent pas de résoudre une problématique donnée.  

Pour y répondre, il est possible de développer un “module” encapsulant du code (dans le cas de BizTalk, uniquement en C#). 

Dans cette situation, dans un environnement BizTalk on utilisera Visual Studio et le framework .Net. 

Il existe deux possibilités pour exécuter du code dans une Logic App : 

1. Le “Inline C#” : permet d’intégrer du code directement dans la Logic App, idéal pour des traitements simples et ponctuels, sans nécessiter de déploiement externe. 

1. Les Azure Functions : permettent d’exécuter des traitements plus complexes. Deux approches sont possibles : 

• Azure Function Embedded : la fonction s’exécute dans le même runtime que la Logic App Standard à laquelle elle est rattachée. Aucun appel réseau n’est nécessaire, ce qui réduit la latence. Ce mode est recommandé lorsque le traitement est spécifique à une seule Logic App. Il permet également de mutualiser le pipeline CI/CD avec celui de la Logic App, simplifiant le déploiement. 

• Azure Function Externe : il s’agit d’un composant propre de la plateforme, avec son runtime, sa configuration et son cycle CI/CD. Cette approche est pertinente lorsque la fonction est partagée entre plusieurs composants (Logic Apps, APIs, etc.). Elle favorise la réutilisabilité du code et une meilleure séparation des responsabilités. 

Durable messaging/persistence 

Les messages peuvent être durablement sauvegarder dans la “MessageBox” BizTalk pour les traiter à nouveaux en cas d’erreur. Il est possible de configurer les orchestrations en “long running” pour ce type de traitement. 

Une possibilité similaire est proposée avec LogicApp en utilisant la configuration Stateful. 

Là ou un une LogicApp en mode Stateless doit avoir une durée maximum de 5 minutes, une LogicApp en mode Stateful est limité à 90 jours ! 

Il existe un autre composant intervenant dans la persistance de données : le ServiceBus. Celui-ci est l’un des éléments centraux pour mettre en place le pattern publish-subscribe. C’est un message broker, un intermédiaire entre différents composants. Il permet la réception/stockage de messages dans une queue ou un topic. Ils sont sauvegardés suivant le paramètre TTL (Time To Live). A noter que pour le Basic Tier il est de 14 jours. Dans le cas du premium tier, le TTL est paramétrable. 

 Monitoring 

Azure bénéficie du service de AppInsight permettant de développer son propre monitoring des flux. Il existe aussi l’outil Log Analytics qui permet de connecter les logs qui prend leur source depuis différents composants. L’atout de Log Analytics est le langage de requête (KQL) qui facilite l’exploitation des données stockées. 

Concernant BizTalk plusieurs alternatives peuvent être envisagé. L’exploitation des données stocker dans le BAM par une application tierce (a développé en interne ou grâce à un produit du marché) ou alors l’utilisation seul de la Console d’Administration BizTalk qui, quant à elle, n’est à usage strictement technique. 

Le BHM ou BizTalk Health Monitor peut s’apparenté au composant HealthCheck utilisable par plusieurs composant AIS. Il donne des métriques de « bonne santé » de la plateforme. Il s’agit d’un monitoring orienté technique. 

Routing/Special rules 

Avec le BRE (Business Rules Engine) il est possible d’appliquer des règles particulières. Il permet de découpler la logique métier à la logique technique. 

En ce qui concerne Azure un composant en « Preview » est disponible, le Azure Logic Apps Rules Engine 

Security 

Du fait des différences structurelles entre un environnement on-premise et le cloud, le volet sécurité ne peut pas être abordé de la même manière dans BizTalk et Azure. 

Dans BizTalk, la sécurité repose généralement sur le Single Sign-On (SSO), qui centralise la gestion des connexions entre les différentes briques de la solution. 

En revanche, dans Azure, chaque composant doit gérer son accès de manière autonome. Pour cela, la plateforme s’appuie sur deux mécanismes clés : 

• Managed Identity, qui permet à un service Azure de s’authentifier auprès d’un autre sans stocker de secrets, 

• RBAC (Role-Based Access Control), qui permet de définir précisément les droits d’accès à chaque ressource. 

Le stockage des informations sensibles (mots de passe, clés, chaînes de connexion, etc.) s’effectue via le service Azure Key Vault qui est dédié à la gestion des secrets, des certificats et des clés de chiffrement. 

Pour conclure ce comparatif entre les fonctionnalités de BizTalk et celles d’Azure, voici un résumé graphique réalisé par Harold Campos, Principal Product Manager – Azure Logic Apps chez Microsoft, qui permet de visualiser clairement les équivalences entre les deux environnements : 

Lien : https://www.linkedin.com/feed/update/urn:li:activity:7271841022974783488/

Cet article, met en lumière les équivalences entre BizTalk Server et les composants Azure, montrant que la majorité des concepts clés de l’intégration (orchestrations, adaptateurs, mapping, pipelines, etc.) trouvent leur place – parfois repensée, souvent enrichie – dans l’écosystème Azure : LogicApp, ServiceBus, APIM. Ce comparatif permet de démystifier la migration vers Azure, de mieux comprendre la transition, d’identifier les points d’attention, et de poser les bases d’une migration structurée. 

Au-delà de cette correspondance technique, migrer vers une plateforme cloud comme AIS ouvre la voie à de nombreux avantages : une infrastructure managée, hautement scalable, sécurisée nativement, et bâtie sur des services Azure mainstream (KeyVault, LogAnalytics, StorageAccount, …). C’est aussi l’opportunité d’adopter des approches modernes (event-driven, microservices, DevOps), mieux alignées avec les besoins d’agilité et d’interopérabilité d’aujourd’hui.