Migration de BizTalk 2016 vers BizTalk 2020

Depuis sa commercialisation, Microsoft a mis à disposition de multiples versions de BizTalk Server. Chacune apportant son lot de nouveautés, il est devenu courant de faire la migration des serveurs BizTalk d’une ancienne version vers une autre plus récente. Cela reste une opération délicate et très importante du cycle de vie de la plateforme d’intégration pour une société. Délicate, car elle peut engendrer de régressions et, de fait, avoir des impacts importants sur les flux en production.

L’objectif de cet article est de donner les éléments clés pour effectuer une migration correctement.

Prérequis à la migration de Biztalk 2016 vers 2020

Avant de pouvoir installer et configurer BizTalk, un certain nombre de prérequis sont nécessaires au bon fonctionnement de BizTalk sur les futurs serveurs. Ces prérequis peuvent varier en fonction des spécificités et des besoins des échanges interapplicatifs.

Cependant, les prérequis minimaux et obligatoires sont les suivants :

• Microsoft Windows Server 2016/2019 ou Windows 10
  À noter : BizTalk Server n’est pas compatible avec Microsoft Server 2022.
• Microsoft .NET 4.7.2 (minimum)
• Microsoft Visual Studio 2019 (v16.4.0 minimum)
• Microsoft SQL Server 2019 ou, à défaut, Microsoft OLE DB Driver 18.3.0
  Il n’est pas obligatoire d’avoir Microsoft SQL Server 2019 installé pour disposer des outils permettant les développements BizTalk. Le driver OLE DB suffit. Attention, ce composant peut être installé à la fois sur la machine de développement et sur le serveur applicatif. Néanmoins, Microsoft SQL Server 2019 reste obligatoire sur le serveur hébergeant les bases de données BizTalk.
• WinSCP v5.15.4
  Une attention particulière doit être portée à la version du logiciel installé.

Une dernière information importante est à noter : il est nécessaire que le compte utilisateur ou le groupe dans lequel il se trouve pour faire l’upgrade ou l’installation :

• Aie les droits administrateurs sur la machine locale ;
• Fasse partie du groupe sysadmin SQL Server ;
• Fasse partie du groupe BizTalk Server admin ;
• Fasse partie du groupe SSO admin.

Une fois les prérequis installés, deux solutions s’offrent à nous. En fonction des besoins, nous avons listé ci-dessous deux modes opératoires qui ont des objectifs distincts.

Modus operandi de la migration des flux

Dans cette partie, nous allons présenter deux façons de migrer votre plateforme. Une première permettant de rebâtir une plateforme en redéployant l’ensemble des applications BizTalk (méthode conseillée par Microsoft). Une seconde permettant de faire un “lift and shift”. La philosophie de cette dernière approche permet de “transférer” les applications BizTalk depuis votre plateforme actuelle vers la nouvelle plateforme.

Best practices depuis une plateforme “from scratch”

Une fois la plateforme déployée et opérationnelle, plusieurs tâches sont à effectuer.

Depuis la nouvelle version de Visual Studio (celle compatible avec le nouvel environnement, voir les Prérequis), il faut :

• Mettre à jour les versions du framework .NET des projets BizTalk ;
• Recompiler l’ensemble des projets ;
• Déployer les dlls compilés dans le nouvel environnement BizTalk.

Néanmoins, cette méthode peut poser plusieurs problèmes, notamment si vous avez des développements en cours. En effet, cette méthode ne permet pas de dissocier vos différents environnements. Cela implique donc de déployer le même état sur chaque environnement. Par conséquent, si des développements sont en cours de test, vous serez obligé de les déployer en production.

Une seconde méthode existe. Elle n’est pas recommandée, car cela implique de migrer du code qui utilise une version du framework antérieure au prérequis Microsoft. Il y a donc un risque que le code source existant utilise des outils du framework dépréciés.

Nous allons ici détailler cette méthode qui permet plus de flexibilité si les environnements de Qualité et Production ne sont pas identiques. Elle permet aussi de maintenir cette différence pour cette migration.

Une alternative à étudier : une migration “lift and shift”

Une alternative est possible pour respecter les différences entre chaque environnement : c’est le déploiement “lift and shift”, c’est-à-dire une migration dont l’état final est identique à l’état des anciennes plateformes.

C’est la solution qui a été adoptée au cours d’une intervention chez un de nos clients. Dans cette situation, il y avait des développements en cours déployés sur l’environnement de Qualité, mais pas encore validés pour être déployés en production. De ce fait, un delta subsistait entre ces deux plateformes. La solution envisagée et déployée a été la méthode lift and shift.

Voici le protocole utilisé pour cette migration :

Étape 1 : les dlls

Les dlls étant les fichiers possédant le code source des applications BizTalk, l’objectif ici est d’en faire la liste puis de les récupérer depuis le Global Assembly Cache (GAC).

• Lister les dlls de chaque Application (ne pas oublier les dépendances) ;
• Exporter ces dlls en récupérant les dlls présents dans le GAC ;
• Générer un MSI (via MSBuilds par exemple) contenant ces dlls. Il faut garder en tête qu’à la fin, il faudra redéployer ce MSI créé dans le nouvel environnement.

Étape 2 : la configuration des applications BizTalk

Le fichier de configuration BizTalk contient des informations nécessaires lors du traitement des données dans les orchestrations. Il faut impérativement récupérer ces fichiers, et les sauvegarder pour les déployer dans le nouvel environnement.

Étape 3 : le binding des applications BizTalk

Pour que les artefacts BizTalk (receive location, sendport, parties, configuration ochestration) soient configurés à l’identique entre les deux plateformes, il faut sauvegarder les bindings de chaque application.

Attention cependant : les mots de passe et certaines autres informations ne sont pas sauvegardés lors de l’extraction des bindings. Il faut donc penser à retrouver et stocker ces informations. Il est possible, en modifiant directement le fichier de bindings, d’insérer les mots de passe en clair dans le fichier ; sinon ne pas oublier de reconfigurer à la main après le déploiement du fichier de bindings.

Étape 4 (facultatif) : les business rules utilisées par les applications BizTalk

Si vous utilisez le BRE (Business Rules Engine) dans vos flux, pensez à extraire l’ensemble des rules afin que l’exécution de votre orchestration ne soit pas bloquée par cette étape.

Le BRE n’ayant pas de dépendance forte, vous pouvez déployer les rules quand vous le souhaitez.

DevOps : CI/CD avec “Deploy BizTalk Application”

Aujourd’hui, le CI/CD est omniprésent,e et les développements BizTalk ne dérogent pas à la règle. Le CI/CD permet l’automatisation du déploiement, assez complexe en ce qui concerne BIzTalk, et facilite les déploiements fréquents des évolutions techniques apportées aux flux. Il permet aussi une gestion des versions plus claire et améliore le travail d’équipe.

Grâce à Azure DevOps, nous avons une plateforme qui permet de centraliser et de faciliter le CI/CD pour tous les développements. Azure DevOps permet aux développements BizTalk, malgré qu’ils soient significativement différents des développements “classiques”, d’avoir plusieurs possibilités pour leur déploiement.

Le composant “Deploy BizTalk Application”

Le composant “Deploy BizTalk Application” fourni par Microsoft s’intègre au pipeline DevOps. C’est le composant le plus simple d’utilisation. Néanmoins certaines critiques peuvent lui être faites.

Inconvénients de « Deploy BizTalk Application »

L’ensemble de l’application BizTalk est arrêté par le composant. Cela bloque donc l’entièreté des flux durant le temps de déploiement, et ce même si le déploiement en cours ne concerne qu’une petite partie (un demi-flux sortant par exemple).

Les options proposées par ce composant sont peu nombreuses.

Avantages de « Deploy BizTalk Application »

Ce composant présente toutefois plusieurs avantages.

Premièrement, il possède une rapidité de mise en place non négligeable, et est disponible dans le visualstudio marketplace. De plus, il utilise la méthode du BTDF (BizTalk Deployment Framework) : un framework déjà utilisé qui centralise les données de déploiement dans un projet (.btaproj) et qui contient un fichier “BizTalkServerInventory.json” contenant les informations relatives au déploiement.

Deuxièmement, il est pleinement compatible Azure DevOps ; pas besoin de passer par une phase de configuration comme cela peut être le cas avec les scripts PowerShell par exemple. Il suffit d’ajouter le composant à son pipeline de release, et il est rapidement utilisable.

Les scripts PowerShell

Toujours dans le cadre de l’intervention chez notre client, après la tentative d’utilisation du composant intégré DevOps, nous avons opté pour une nouvelle approche. L’objectif était d’avoir plus de flexibilité et de permettre un déploiement spécifique à notre besoin.

La solution adoptée a été de développer des scripts PowerShell “custom” inclus dans des “Task Groups”, et recensant les actions à mener dans les pipelines de déploiement.

De ce fait, les pipelines de déploiement restent simples à configurer et sont toujours à jour au gré des différentes mises à jour.

Aucun script n’est disponible sur Internet, il faut donc les concevoir.

Le principal défaut est donc le temps de développement et les différentes itérations à opérer pour obtenir un déploiement qui sied aux habitudes de développement de l’équipe en place.

L’avantage en revanche est la flexibilité qu’offre cette méthode. Tout est customisable et permet certaines opérations pouvant être indispensables, qui ne sont pas possibles avec le composant de déploiement BizTalk. Prenons un exemple simple : l’arrêt partiel d’une application BizTalk lors d’un déploiement pour la retouche d’un demi-flux, ou encore l’ajout d’un nouveau demi-flux. Dans ces deux cas de figure, il est inutile – voire problématique – d’arrêter l’application BizTalk dans son ensemble surtout si elle contient des flux critiques (flux de commande, finance, etc.).

Malgré ces avantages certains, la complexité de mise en œuvre reste le principal défaut. Il faut avoir aussi une bonne connaissance du fonctionnement de la plateforme pour prendre en compte tous les aspects et éviter tout oubli lié à l’aspect “custom”.

De plus, le temps pour développer les scripts est non négligeable et doit être pris en compte dans le choix de cette solution.

L’essentiel à retenir sur la migration de BizTalk 2026 vers 2020

En conclusion, nous avons développé ici deux méthodes permettant la migration BizTalk : une méthode recommandée par Microsoft, et une méthode que nous avons utilisée dans le cadre d’une situation complexe.

Néanmoins, en sachant que les technologies de l’intégration évoluent et que Microsoft a annoncé depuis quelque temps la fin du support de BizTalk, il est judicieux de penser dès à présent aux solutions Cloud. Avec les opportunités qu’offrent les Cloud providers aujourd’hui, une plateforme iPaaS (Integration Plateform As A Service) peut être combinée ou bien remplacer BizTalk via l’utilisation d’AIS (Azure Integration Services) et son lot de fonctionnalités et de composants.

Vous souhaitez en savoir plus ? Être accompagné dans votre projet d’intégration ?? Contactez-nous !