Approches de migration pour BizTalk Server vers Azure Integration Services
Ce guide décrit les stratégies et les ressources de migration, ainsi que les considérations de planification et les meilleures pratiques pour vous aider à fournir des solutions de migration réussies.
Notes
Pour obtenir une vue d’ensemble de la migration et un guide sur le choix des services dans Azure pour votre migration, consultez la documentation suivante :
Options de stratégie
La section suivante décrit les différentes stratégies de migration ainsi que leurs avantages et inconvénients :
Migration lift-and-shift
Dans le Place de marché Azure, vous trouverez la possibilité de provisionner des machines virtuelles qui incluent des licences BizTalk avec le modèle de paiement à l’utilisation. Cette offre propose l’avantage d’utiliser les fonctionnalités IaaS (Infrastructure as a Service) de Microsoft via un modèle tarifaire basé sur la consommation. Bien que l’utilisation de ces machines virtuelles puisse atténuer certains défis dans la gestion de BizTalk Server infrastructure, cette approche ne répond pas aux planifications de cycle de vie et aux échéances de support pour les BizTalk Server.
Avec les organisations qui adoptent la transformation numérique en passant au cloud ou en adoptant le cloud, de nombreuses organisations ont les tâches courantes pour interrompre leur infrastructure de serveur physique, VMware, Hyper-V ou physique et migrer cette fonctionnalité vers IaaS sur Azure. Ce choix permet de réduire les défis mentionnés précédemment, mais ne traite pas le codebase BizTalk.
Avec BizTalk Server 2013 et versions ultérieures, vous pouvez choisir d’exécuter vos serveurs BizTalk localement comme auparavant, ou de les exécuter sur un serveur virtuel dans Azure. L’exécution de votre environnement BizTalk Server dans le cloud offre les avantages suivants :
- Pas besoin de matériel privé ou d’infrastructure, donc pas de maintenance matérielle.
- Disponibilité accrue pour votre infrastructure de serveur, qui peut s’étendre sur plusieurs centres de données ou être répliquée dans des zones de disponibilité.
- Accédez à vos serveurs n’importe où via Internet.
- Microsoft sauvegarde vos images.
- Déploiement rapide pour les nouveaux serveurs à l’aide d’images intégrées disponibles sur Place de marché Azure.
- Scale-up rapide pour vos serveurs en modifiant la taille des machines virtuelles pour ajouter de la mémoire et du processeur, ajouter des disques durs, et ainsi de suite
- Amélioration de la sécurité de votre environnement à l’aide de Azure Security Center. Ce service identifie les menaces de sécurité et vous fournit un chemin d’investigation lorsque des incidents de sécurité se produisent
Intégration hybride
Bien que les fonctionnalités BizTalk Server et Azure Integration Services puissent se chevaucher, elles fonctionnent mieux lorsque vous les utilisez ensemble. La plupart des organisations qui ne déplacent pas toute leur infrastructure vers le cloud ont principalement les raisons suivantes :
- Politiques de la Société
- Stratégies nationales/régionales
- Stratégies spécifiques à un domaine d’activité
En outre, toutes les fonctionnalités ou applications n’existent pas dans le cloud, ou certaines qui sont disponibles peuvent ne pas être aussi robustes que celles locales. Toutefois, pour suivre le rythme de la révolution du cloud et étendre les fonctionnalités métier, de nombreuses organisations commencent par utiliser des offres SaaS en même temps que leurs systèmes locaux. De nombreux processus métier peuvent tirer parti des stratégies de développement et d’implémentation basées sur le cloud.
En adoptant une stratégie d’intégration hybride, vous pouvez toujours tirer parti des investissements technologiques dans les systèmes dont dépend votre organisation, mais tout en bénéficiant de nouvelles fonctionnalités, d’amélioration des performances et d’une structure de coût plus faible des applications cloud telles qu’Azure.
Avec BizTalk Server 2016, la version distincte de Microsoft BizTalk Server Adapteur pour Logic Apps vous a donné la possibilité d’implémenter une partie de votre logique d’intégration en tant que service sur Azure en utilisant Azure Logic Apps pour connecter des centaines de services cloud. Cet adaptateur a aidé à la fois les intégrations locales et les intégrations hybrides en offrant les fonctionnalités suivantes :
Intégrez des services cloud à BizTalk Server à l’aide d’adaptateurs intégrés tels qu’Azure Logic Apps, Azure Service Bus, Azure Event Hubs, Stockage Blob Azure et Office 365 Mail, Planification et Contacts.
Utilisez le connecteur BizTalk Server dans Azure Logic Apps pour vous connecter d’Azure Logic Apps à BizTalk Server.
Publiez des points de terminaison BizTalk Server à l’aide d’Azure Gestion des API afin que les organisations puissent exposer des points de terminaison à des développeurs internes et à des partenaires externes.
Avec BizTalk Server 2020, l’installation a automatiquement inclus l’adaptateur pour Azure Logic Apps ainsi que les adaptateurs intégrés pour se connecter facilement à l’environnement cloud.
Big Bang
Une approche de « big bang » ou de « basculement direct » nécessite beaucoup de planification et n’est pas recommandée pour les organisations qui ne sont pas familières avec Azure Logic Apps ou qui ont des systèmes ou des solutions volumineux à migrer. Lorsqu’une organisation implémente une nouvelle pile de technologies, de nouveaux apprentissages en résultent généralement. En investissant trop tôt ou trop, vous n’aurez pas la possibilité de tirer parti des leçons apprises et de vous ajuster sans risquer de retravailler de manière significative.
Cette approche peut également prendre plus de temps pour récolter ou accumuler de la valeur. Si vous avez déjà effectué certaines activités de migration, mais que vous ne les avez pas encore mises en production en raison d’autres travaux en attente ou en cours, vos artefacts migrés ne génèrent pas de valeur pour votre organisation.
Itération (recommandé)
Cette approche offre à votre organisation la possibilité d’obtenir de la valeur de manière incrémentielle, mais plus tôt qu’elle ne le pourrait autrement. Votre équipe de projet peut découvrir rapidement la pile technologique à l’aide de rétrospectives. Par exemple, vous pouvez déployer une interface ou un projet BizTalk existant en production, puis en savoir plus sur les besoins de la solution, notamment la gestion, la scalabilité, les opérations et la supervision. Une fois que vous aurez acquis ces connaissances, vous pouvez planifier des sprints pour optimiser les fonctionnalités existantes ou introduire de nouveaux modèles que vous pourrez ensuite utiliser dans des travaux futurs.
Quelle que soit votre approche, si vous envisagez de passer à Azure Integration Services ou à Azure en général, envisagez vivement de refactoriser vos solutions BizTalk Server en solutions serverless ou cloud natives avant de désactiver votre infrastructure serveur. Ce choix est une excellente stratégie si votre organisation souhaite transformer complètement l’entreprise vers le cloud.
Planifier la migration
La section suivante fournit des conseils sur la planification de la migration et les domaines à prendre en compte.
Planification de la préparation
La préparation représente un élément essentiel de votre processus de planification. Lorsque vous comprenez l’ampleur et la profondeur de votre projet, la prévisibilité s’améliore sur plusieurs dimensions, telles que les coûts, la complexité, les chronologies et la réussite globale de votre projet. La liste suivante inclut des domaines spécifiques à examiner et à traiter dans le cadre du processus de charte de votre projet.
| Domaine | Description |
|---|---|
| Inventaire | Capturez des données sur toutes vos interfaces et applications afin de connaître le nombre d’interfaces et d’applications que vous devez migrer. Pendant ce processus de catalogage, collectez les informations suivantes pour fournir un contexte : - Adaptateurs en cours d’utilisation - Fonctionnalités BizTalk Server utilisées, telles que l’analyse de l’activité métier, le moteur de règles métier, l’EDI, et ainsi de suite - Code personnalisé, comme des expressions, des mappages et des composants de pipeline - Débit de messages - Tailles des messages - Dépendances |
| Complexité | Pour vous aider à découvrir les niveaux de complexité de vos interfaces, examinez les types de règles métier dans ces interfaces et les exigences techniques qui nécessitent une personnalisation pour répondre à leurs besoins ou à leurs exigences de performances. |
| Valeur | Évaluez la valeur de vos interfaces afin de déterminer la priorité pour les interfaces à ré-implémenter. Bien que commencer avec des interfaces à faible risque peut être judicieux, une fois que vous êtes à l’aise avec Azure Integration Services, veillez d’abord à vous concentrer sur le travail le plus important. |
| Coûts | Établissez l’étendue du projet et évaluez les coûts, car un projet de migration nécessite des capitaux pour démarrer l’exécution. Sécurisez le budget du projet, qu’il soit atteint par le biais de la planification du budget d’investissement ou d’exploitation, et gérez l’étendue du projet en cours de route. |
| Dépendances de l’application et du système | Identifiez et comptez ces dépendances lorsque vous démarrez la planification du projet, afin d’éviter les surprises lorsque vous démarrez l’exécution du projet. |
| Registre des risques | Créez et utilisez cet artefact pour identifier et suivre tous les risques qui se produisent pendant que vous effectuez des exercices de planification de projet. Lorsque vous comprenez les risques, vous pouvez les atténuer de manière proactive et communiquer avec les dirigeants. Vous pouvez également supprimer les bloqueurs tôt lorsqu’ils sont moins coûteux à traiter. |
Outils de migration
L’outil en ligne de commande Azure Integration Migrator, également appelé outil de migration BizTalk, est un projet open source Microsoft qui peut vous aider dans les phases de planification et d’exécution de votre projet de migration, tout en déplaçant les applications BizTalk Server vers Azure Integration Services. Vous pouvez également utiliser cet outil pour découvrir des insights et des stratégies utiles pour migrer vos solutions vers le cloud.
Cet outil s’exécute au cours des phases suivantes :
Découvrez
Extrait les ressources BizTalk Server et identifie les artefacts BizTalk à migrer. Lit les assemblys et les informations de fichier de liaison.
Configuration requise : MSI pour l’application Biztalk Server et toutes les applications BizTalk Server référencées
Analyser.
Lit les artefacts BizTalk Server et génère un modèle de données source pour l’application BizTalk Server.
Analyser
Génère un modèle de données cible Azure Integration Services à l’aide du modèle de données source à partir de la phase Analyse. Fondamentalement, l’outil passe en revue les ressources BizTalk Server, identifie les éléments qui peuvent migrer et génère un modèle de données de la cible Azure Integration Services.
Report
Génère un rapport qui décrit les ressources BizTalk Server trouvées et les éléments qui peuvent migrer. Le rapport contient également des informations détaillées sur le contenu des applications sources et cibles, ainsi que des détails sur les éventuels problèmes liés à la conversion.
Convert
Génère des modèles de ressources Azure Manager et des scripts Azure CLI que vous pouvez utiliser pour générer les applications dans Azure à l’aide du modèle de données cible.
Vérifier
Cette phase n’est actuellement pas intégrée à l’outil, mais vous exécutez les scripts d’installation pour déployer votre application sur Azure. Vous pouvez ensuite déterminer si l’application générée fournit les mêmes fonctionnalités que votre application locale BizTalk Server.
Le diagramme suivant montre les phases que l’outil Azure Integration Migrator exécute :
Rôles d’équipe clés et compétences pour une migration réussie
Pour réussir la migration des flux de travail d’intégration de BizTalk Server vers Azure Integration Services, établissez une équipe qui possède les rôles et compétences importants suivants, qui couvrent plusieurs disciplines :
| Rôle | Compétences |
|---|---|
| Chefs de projet | Responsable de la gestion du projet global et fournit l’étendue convenue dans les limites du temps et du budget. |
| Leader Scrum | Gère activement le backlog et facilite la hiérarchisation des activités du projet. |
| Architectes | Assurez-vous que le projet s’aligne sur les principes architecturaux de l’entreprise et fournissez des conseils sur la façon de naviguer dans l’incertitude et les obstacles. |
| Développeurs | Travaillez activement sur la migration des composants de BizTalk Server vers Azure Integration Services. |
| Testeurs d’assurance qualité | Créez des plans de test et exécutez des tests sur ces plans. Suivez, communiquez et triez les bogues et les défauts dans le cadre de la planification du sprint de projet. |
| Test d'acceptation Utilisateur (UAT) | Fournissez les parties prenantes de l’entreprise qui vous aident à vous assurer qu’aucune régression n’est introduite en déplaçant les interfaces d’une plateforme existante vers une nouvelle plateforme. |
| Spécialistes de la gestion des changements | Évaluez l’impact sur les processus et rôles existants. Créez un plan pour aider à atténuer les problèmes perçus avant qu’ils apparaissent. |
Pour vous aider à fournir une partie ou l’ensemble des ressources décrites précédemment, envisagez les partenaires qui ont de l’expérience dans l’exécution de migrations. En tant que membres de l’équipe, ils peuvent contribuer à réduire les risques, à améliorer le délai de commercialisation et à rendre le projet plus prévisible grâce à leurs compétences et à leur expertise.
Planification des processus de génération
Pour la planification de build, Microsoft vous recommande d’inclure des sprints et des éléments de travail pour gérer les services de base, tels que l’authentification, la journalisation, la gestion des exceptions, etc. Cette inclusion permet d’éviter les remaniements ultérieurs dans les cycles de développement causés par le fait de ne pas répondre aux besoins sous-jacents. Vous souhaitez également éviter les développeurs bloqués en raison de décisions qui nécessitent la prise d’autres parties prenantes.
La liste suivante couvre uniquement quelques domaines à prendre en compte :
| Domaine | Description |
|---|---|
| Authentification | Répondez aux questions suivantes et à d’autres sur l’authentification avant d’approfondir les cycles de développement. - Votre organisation a-t-elle des normes concernant les schémas d’authentification ? - Pouvez-vous utiliser des identités managées et des principaux de service dans Azure ? - L’authentification de base et les clés API sont-elles autorisées ou non ? Cette activité peut être une bonne occasion de faire appel à vos architectes d’entreprise qui peuvent s’assurer d’obtenir des accords clairs sur les schémas d’authentification à utiliser. |
| Journalisation | Envisagez de collecter et de stocker des données de télémétrie dans un référentiel de données centralisé, qui est un modèle populaire utilisé par les solutions d’intégration. Par exemple, Azure Logic Apps (Standard) peut envoyer des données de télémétrie à Application Insights dans Azure Monitor. Azure Logic Apps (Consommation) peut envoyer des données de télémétrie à Log Analytics, également dans Azure Monitor. Vous pouvez également inclure des propriétés suivies afin que les développeurs puissent inclure davantage de contexte à mesure que les messages transitent par la plateforme d’intégration. Par exemple, ces données peuvent inclure des numéros de bon de travail, des informations sur le bon de commande ou tout autre élément qui peut être utile, utile et pertinent pour votre organisation. On peut soutenir que la solution de chaque organisation peut différer en fonction des besoins de l’organisation. Par exemple, certaines organisations veulent un contrôle total sur ce que et quand les données sont journalisées. Dans ce scénario, vous pouvez créer des API ou des connecteurs personnalisés, puis instrumenter votre code en fonction de jalons spécifiques. Quelle que soit l’approche que vous choisissez, assurez-vous que vos développeurs comprennent clairement les attentes afin d’éviter les remaniements futurs. |
| Gestion des exceptions | Traitez d’avoir une stratégie et un modèle cohérent tôt pour gérer les exceptions et les erreurs afin d’éviter les remaniements futurs. Veillez à clarifier cette zone avant de créer des applications logiques. La liste suivante comprend quelques questions auxquelles répondre lorsque vous traitez de la gestion des exceptions : - Comment utiliser les étendues et les paramètres « Exécuter après » pour détecter les exceptions ? - Comment utiliser l’expression result() pour mieux comprendre où une exception se produit dans un flux de travail et trouver plus d’informations sur la cause racine sous-jacente ? - Après avoir choisi comment intercepter les exceptions, comment voulez-vous enregistrer ces données et communiquer avec les parties prenantes ? Assurez-vous que ces décisions s’alignent sur votre stratégie de journalisation, comme mentionné précédemment. Dans l’idéal, vous avez établi un processus qui recherche activement les nouveaux événements d’erreur dans votre magasin de données de journalisation. À partir de là, vous pouvez répondre à ces événements et orchestrer un processus d’exception. Vous devrez peut-être filtrer ou agréger les événements d’erreur en double, enregistrer un ticket dans la solution de management des services informatiques de votre organisation et choisir comment envoyer des notifications. Vous pouvez avoir des chemins différents pour les notifications, en fonction de la gravité du problème et de l’heure de la journée. Vous pouvez atteindre l’agilité en créant un flux de travail pour gérer ce processus. |
| Analyse | Pour montrer la santé et l’hygiène globales de votre solution à vos parties prenantes, tenez compte des différentes lentilles que vos parties prenantes utilisent pour examiner, par exemple : - Les cadres peuvent être plus intéressés par l’intégrité globale, le nombre de transactions ou le volume, et la valeur métier que ces transactions génèrent, mais pas par les nuances techniques globales. - Un gestionnaire de première ligne peut être plus intéressé par l’intégrité globale, mais peut également s’intéresser aux détails techniques, tels que les caractéristiques de performances, pour s’assurer que les SLA sont respectés. - Les analystes de support sont probablement intéressés par l’intégrité globale du service, les exceptions et les goulots d’étranglement des performances. Pendant que vous mettez en place votre stratégie d’analytique, tenez compte de vos parties prenantes et du type de données qui les intéresse. Ce processus réfléchi vous permet de vous assurer que vous suivez les informations utiles et utiles et de rendre ces données accessibles à des fins de création de rapports. Si vous constatez des lacunes de couverture, vous devrez peut-être revenir sur vos éléments de travail liés à la journalisation et ajouter des tâches appropriées pour combler ces lacunes. |
| Cadence | Lorsque vous expédiez vos projets d’intégration et que vous apprenez de ces expériences, veillez à capturer les leçons qui se dégagent inévitablement. Planifiez des sprints ou des cycles de correction au début de votre parcours afin de pouvoir corriger le cours tôt, avant que le coût ne devienne trop élevé. De cette façon, vous pouvez éviter d’introduire trop de dettes techniques dans votre nouvelle plateforme. |
Planification de déploiement
Lorsque vous prévoyez et préparez un plan de déploiement, vous augmentez vos possibilités de réussite du déploiement. Avec BizTalk Server, après avoir créé l’ensemble de l’infrastructure et des environnements, vous vous êtes concentré sur le déploiement de la solution.
Avec Azure, cette expérience diffère avec certaines activités à prendre en compte en premier, telles que l’adressage du déploiement d’infrastructure entre différents environnements, qui peuvent inclure différents abonnements Azure, groupes de ressources Azure ou une combinaison, par exemple :
- Azure Key Vault : secrets et stratégies d’accès
- Azure Service Bus : files d’attente, rubriques, abonnements, filtres et stratégies d’accès
- Azure App Service : plans, mise en réseau et authentification
Vous pouvez ensuite vous concentrer sur le déploiement de solution entre différents environnements.
Planification des tests
Pour vous assurer que vos parties prenantes sont satisfaites de la solution que vous fournissez, il est important de prendre en compte les tests pour tout projet de migration. Une nouvelle solution doit fournir plus de valeur par rapport à la solution précédente, sans aucune régression susceptible d’avoir un impact sur l’entreprise.
Tenez compte des recommandations de test suivantes pour votre projet de migration :
Établissez votre base de référence en répondant aux questions suivantes :
- Avez-vous des tests existants ?
- Les tests s’exécutent-ils sans erreurs ?
- Les résultats des tests sont-ils exacts ?
Pour être sûr que votre équipe n’a pas introduit de régressions, vous avez besoin de la possibilité de comparer les résultats de la nouvelle plateforme aux tests fiables de votre plateforme existante. Par conséquent, si vous n’avez pas de base de référence, veillez à en établir une.
Naturellement, vous ne voulez pas dépenser beaucoup de ressources pour établir des tests sur une plateforme qui prend sa retraite, mais vous devez répondre à la question « Comment faire savez que tout fonctionne correctement ? » Si vous êtes dans cette situation, commencez à établir votre base de référence en fonction des priorités et créez un plan pour atténuer les zones où vous avez des lacunes.
Configurez votre stratégie de test pour la nouvelle plateforme.
En supposant que vous êtes à l’aise avec votre base de référence, vous pouvez maintenant réfléchir à la façon de tester sur votre nouvelle plateforme. Si vous avez eu des difficultés à établir votre base de référence, profitez-en pour mettre en place une base solide pour votre nouvelle plateforme.
Lorsque vous envisagez de tester votre nouvelle plateforme, gardez l’automatisation à l’esprit. Bien que le fait d’avoir une plateforme vous permet de créer rapidement des interfaces, le fait de s’appuyer sur des tests manuels érode ces gains de productivité.
Automatisez vos tests.
Azure Logic Apps (Standard) inclut la possibilité d’effectuer des tests automatisés. La liste suivante comprend des informations et des ressources supplémentaires qui sont disponibles gratuitement sur GitHub :
Tests automatisés avec Azure Logic Apps (Standard) de l’équipe Azure Logic Apps
Avec Azure Logic Apps (Standard), les tests automatisés ne sont plus difficiles à effectuer, en raison de l’architecture sous-jacente, qui est basée sur le runtime Azure Functions et peut s’exécuter partout où Azure Functions pouvez exécuter. Vous pouvez écrire des tests pour les workflows qui s’exécutent localement ou dans un pipeline CI/CD. Pour plus d’informations, consultez l’exemple de projet pour Azure Logic Apps Test Framework.
Cette infrastructure de test comporte les fonctionnalités suivantes :
- Écrire des tests automatisés pour les fonctionnalités de bout en bout dans Azure Logic Apps.
- Effectuez une validation affinée aux niveaux d’exécution et d’action du workflow.
- Vérifiez les tests dans un référentiel Git et exécutez localement ou dans des pipelines CI/CD.
- Fonctionnalités de test fictif pour les actions HTTP et les connecteurs Azure.
- Configurez les tests pour utiliser différentes valeurs de paramètre à partir de la production.
Playbook d’intégration : Tests standard Logic Apps de Michael Stephenson, Microsoft MVP
L’infrastructure de test du playbook d’intégration s’appuie sur l’infrastructure de test fournie par Microsoft et prend en charge d’autres scénarios :
- Connectez-vous à un workflow dans une application logique Standard.
- Obtenez l’URL de rappel afin de pouvoir déclencher le flux de travail à partir d’un test.
- Vérifiez les résultats de l’exécution du flux de travail.
- Vérifiez les entrées et sorties d’opération à partir de l’historique des exécutions du workflow.
- Connectez-vous à des frameworks de test automatisé que les développeurs d’applications logiques peuvent utiliser.
- Connectez-vous à SpecFlow pour prendre en charge le développement piloté par le comportement (BDD) pour les applications logiques.
Quelles que soient les approches ou les ressources que vous utilisez, vous êtes en bonne voie d’avoir des tests d’intégration automatisés reproductibles et cohérents.
Configurez le test des réponses simulées à l’aide de résultats statiques.
Que vous configurez ou non des tests automatisés, vous pouvez utiliser la fonctionnalité de résultats statiques dans Azure Logic Apps pour définir temporairement des réponses fictives au niveau de l’action. Cette fonctionnalité vous permet d’émuler le comportement d’un système spécifique que vous souhaitez appeler. Vous pouvez ensuite effectuer des tests initiaux de manière isolée et réduire la quantité de données que vous créez dans les systèmes métier.
Exécutez des tests côte à côte.
Dans l’idéal, vous disposez déjà de tests d’intégration de base pour votre environnement BizTalk Server et de tests automatisés établis pour Azure Integration Services. Vous pouvez ensuite exécuter des tests côte à côte de manière à vous aider à vérifier vos interfaces en utilisant les mêmes jeux de données et à améliorer la précision globale des tests.
Démarrer
Une fois les tests terminés par votre équipe, réfléchissez aux tâches nécessaires pour mettre votre nouvelle plateforme d’intégration en production :
Créer un plan de communication.
Bien que vous ayez une petite équipe qui implémente les aspects techniques et les détails d’un projet de modernisation de la plateforme d’intégration, vous avez probablement besoin de nombreuses parties prenantes pour vous tenir informé du projet de migration. Si vous n’avez pas de stratégie de communication claire, vous créez de l’anxiété pour les autres personnes impliquées. Tenez également compte des parties prenantes externes que vous devez inclure dans votre plan de communication. Par exemple, vous pouvez inclure d’autres partenaires commerciaux ou clients susceptibles d’être affectés par les événements à venir. N’oubliez pas ces parties prenantes aussi.
Par conséquent, communiquez tôt et souvent en fournissant une clarté dans les domaines qui affectent vos parties prenantes, par exemple, ce que vous attendez d’eux, quand ils sont nécessaires, combien de temps ils sont nécessaires, etc. En fournissant un plan concis et clair, vous créez de la confiance pour les parties prenantes et maintenez une énergie positive autour de votre projet. Supprimez tout doute en vous assurant que votre équipe est prête à s’exécuter. Sinon, vous risquez de ruiner le moral en raison de perceptions, de spéculations et de rumeurs selon lesquelles votre projet pourrait échouer.
Effectuez un plan de basculement.
Un plan de basculement couvre les détails des tâches et des activités nécessaires pour passer de la plateforme actuelle à la nouvelle plateforme, y compris les étapes que votre équipe prévoit d’exécuter. Incluez les considérations suivantes dans votre plan de basculement :
Étapes préalables
Identifiez les actions que vous pouvez ou devez effectuer à l’avance, afin de ne pas tout laisser pour un jour de basculement. En règle générale, un basculement vers une nouvelle plateforme d’intégration signifie généralement que vous disposez d’un déploiement de « champ vert », ce qui vous permet de mettre en place de nombreux composants et configurations au début du cycle. Plus vous pouvez effectuer avant la fenêtre de maintenance de votre plateforme d’origine, plus vous pouvez supprimer et améliorer le résultat global de votre événement de basculement.
Répétition
Les parties prenantes veulent généralement une certaine prévisibilité concernant les événements à venir. Alors, comment pouvez-vous fournir une prévisibilité autour de quelque chose que vous n’avez jamais fait auparavant ? En exécutant une répétition générale qui déploie votre plateforme d’intégration dans un environnement de préproduction, vous pouvez valider votre plan de basculement et le calendrier prévu pour chaque étape du processus.
Sinon, la sous-estimation du temps qu’une étape peut prendre peut entraîner un effet d’entraînement dans les retards. Cumulativement, ces retards peuvent coûter beaucoup de temps et perturber l’entreprise. Lorsque vous exécutez une répétition générale, vous pouvez baser votre planification sur des données réelles. Votre équipe peut également trouver des problèmes qui auraient provoqué des problèmes lors de la mise en production. Lorsque votre équipe intercepte et documente les problèmes tôt, ils sont mieux préparés et risquent moins de surprises pendant l’événement de basculement réel.
Personnes
Assurez-vous qu’il existe une responsabilité claire en ce qui concerne la personne propriétaire de chaque étape du plan. En tant que stratégie d’atténuation judicieuse, identifiez et préparez les personnes de secours au cas où la personne principale n’est pas disponible pour effectuer la tâche, en raison de circonstances inattendues.
Planifier des estimations
Une fois que vous avez exécuté une seule répétition, votre équipe doit mieux comprendre le temps nécessaire à l’exécution de chaque tâche. Vous pouvez utiliser ces estimations pour prévoir une planification afin que les utilisateurs sachent quand vous en avez besoin et approximativement combien de temps ils ont pour terminer leur tâche.
Désactivation des interfaces dans l’ancienne plateforme
À condition de comprendre toutes les dépendances existantes, vous pouvez commencer à désactiver les interfaces dans votre ancienne plateforme d’intégration avant d’activer les interfaces dans la nouvelle plateforme. Certaines architectures complexes peuvent nécessiter la désactivation des interfaces séquentielles dans un ordre spécifique pour éviter les surprises. Selon la nature de l’interface, il se peut également que vous ne puissiez pas désactiver toutes les interfaces de votre ancienne plateforme d’intégration. Par exemple, si vous avez un système métier qui envoie des messages à votre plateforme d’intégration, veillez à tenir compte de ces situations dans votre plan de basculement.
Activation des interfaces dans la nouvelle plateforme
Comme vous pouvez avoir des interfaces séquentielles qui vous obligent à désactiver dans un ordre spécifique, vous pouvez avoir de nouvelles interfaces séquentielles à activer avec la même exigence. Avant de commencer à activer les interfaces, assurez-vous que vous comprenez toutes les dépendances et que vous avez identifié l’ordre requis pour activer les nouvelles interfaces séquentielles.
Notes
Veillez à exécuter des étapes pour activer les interfaces de manière méthodique et systématique afin d’éviter les faux pas qui risquent la réussite de votre projet.
Test de validation
Cette activité étant extrêmement importante, incluez ce travail dans votre plan de basculement. Après avoir activé vos interfaces, vérifiez que les interfaces fonctionnent comme prévu avant de passer à l’étape « Go or No-go ». Dans l’idéal, vous pouvez effectuer des tests de validation qui n’affectent pas les données métier principales. Ce guide fournit plus d’informations sur les tests de validation pour vos nouvelles interfaces dans une section ultérieure.
Déterminez un plan de restauration.
Nous espérons que vous disposez maintenant d’une approche structurée et détaillée pour implémenter votre nouvelle plateforme d’intégration. Toutefois, des surprises peuvent se produire. Déterminez donc les étapes nécessaires pour revenir à votre plateforme d’intégration précédente. De cette façon, vous avez un plan prêt à partir, juste au cas où.
Lorsque vous réfléchissez à ces étapes, tenez compte des événements susceptibles de déclencher une restauration. En outre, alignez votre plan sur les personnes dont vous avez besoin pour prendre la décision de restauration. Ce guide fournit plus d’informations dans la section sur la prise de décision « Go or No go ».
Exécutez des tests de validation.
Votre plan de basculement doit inclure les détails de ce travail. Après avoir activé vos interfaces, vérifiez que les interfaces fonctionnent comme prévu avant de passer à l’étape « Go or No-go ». Dans l’idéal, vous pouvez effectuer des tests de validation qui n’affectent pas les données métier principales.
Dans l’idéal, par exemple, vos tests de validation peuvent lire les données d’un système métier de ligne de production, mais ils ne peuvent pas écrire de données, ce qui crée un problème de conformité. Sinon, vous devrez attendre qu’une transaction commerciale transite par vos interfaces et valider que tout fonctionne comme prévu par votre équipe.
Planifiez la prise en charge des opérations ou de la production.
Bien que le travail de migration des interfaces entre les plateformes consomme généralement la plupart des ressources de projet, tenez compte de la prise en charge continue de vos interfaces et de la nouvelle plateforme.
Veillez à partager la quantité et le niveau de connaissances appropriés entre l’équipe de projet et l’équipe des opérations.
Créez et conservez une liste de contacts actuelle qui contient des coordonnées techniques et professionnelles afin que tout le monde puisse joindre les membres de l’équipe appropriés si nécessaire.
Pour une réponse de support plus fluide et rapide aux clients, préparez vos processus de support et votre documentation avant d’être mis en ligne. Vous pouvez aider à réduire le stress des clients, de votre équipe de support et de votre équipe de projet lorsque vous pouvez éviter qu’un membre du support technique tente de tout comprendre lorsqu’un incident réel se produit.
Choisissez « Go or No-go » pour passer en production.
Pour cette étape, collaborez avec les parties prenantes concernées pour décider si le projet peut passer en production. Par exemple, les parties prenantes peuvent inclure le leadership, la gestion de projet, les opérations et les représentants d’entreprise.
Célébrez le succès de votre équipe.
Félicitations ! Une fois que vous avez terminé un projet qui a un impact positif sur votre organisation ou votre entreprise, le moment est venu de reconnaître votre équipe pour tout son travail acharné et de célébrer une étape importante! Veillez à créditer votre équipe de manière appropriée et significative. Aucune reconnaissance n’est un moyen sûr de détruire le moral.
Organisez une rétrospective.
Comme toute activité d’ingénierie, votre équipe obtient des informations précieuses et étend ses connaissances en tirant des enseignements de l’expérience. Rencontrez votre équipe pour discuter et capturer les domaines qui se sont bien passés, qui ne se sont pas bien passés, et ceux qui peuvent changer pour le mieux. Veillez à héberger cette conversation dans un environnement non menaçant et favorable, et restez concentré sur l’objectif d’apprendre et de grandir, pas de blâmer. Partagez vos leçons avec votre direction et d’autres parties prenantes intéressées. Cet exercice renforce la confiance au sein de votre équipe et représente la maturité de l’ingénierie.
Bonnes pratiques pour la migration
Bien que les meilleures pratiques puissent varier d’une organisation à l’autre, envisagez un effort conscient pour promouvoir la cohérence, ce qui permet de réduire les efforts inutiles qui « réinventent la roue » et la redondance de composants communs similaires. Lorsque vous aidez à activer la réutilisation, votre organisation peut créer plus rapidement des interfaces qui deviennent plus faciles à prendre en charge. Le délai de commercialisation étant un élément clé de la transformation numérique, une priorité absolue est de réduire les frictions inutiles pour les développeurs et les équipes de support.
Lorsque vous établissez vos propres meilleures pratiques, envisagez de vous aligner sur les conseils suivants :
Conventions de nommage générales pour les ressources Azure
Veillez à configurer et à appliquer de manière cohérente des conventions de nommage correctes sur toutes les ressources Azure des groupes de ressources à chaque type de ressource. Pour jeter des bases solides en matière de facilité de découverte et de prise en charge, une bonne convention d’affectation de noms permet de communiquer un objectif. Le point le plus important pour les conventions d’affectation de noms est que vous les avez et que votre organisation les comprend. Chaque organisation a des nuances qu’elle peut avoir à prendre en compte.
Pour obtenir des conseils sur cette pratique, passez en revue les recommandations et ressources Microsoft suivantes :
- Exemples d’abréviations pour les ressources Azure
- Azure Naming Tool, qui génère des noms conformes à Azure, vous aide à normaliser les noms et à automatiser votre processus d’affectation de noms.
Conventions d’affectation de noms pour les ressources Azure Logic Apps
La conception de votre application logique et de votre workflow constitue un point de départ clé, car ce domaine offre aux développeurs la possibilité de créer des noms uniques.
Noms des ressources d’application logique
Pour différencier les ressources d’application logique Consommation et Standard, vous pouvez utiliser différentes abréviations, par exemple :
- Consommation : LACon
- Standard : LAStd
Du point de vue de l’organisation, vous pouvez concevoir un modèle de nommage qui inclut l’unité commerciale, le service, l’application et éventuellement, l’environnement de déploiement, comme DEV, UAT, PRODet ainsi de suite, par exemple :
LAStd-<*business-unit-name*>-<*department-name* or *application-name*>-<*environment-name*>
Supposons que vous ayez une application logique Standard en développement qui implémente des flux de travail pour le service RH de l’unité commerciale Services d’entreprise. Vous pouvez nommer la ressource d’application logique LAStd-CorporateServices-HR-DEV et utiliser la notation Cas Pascal si nécessaire pour la cohérence.
Noms de flux de travail d’application logique
Une ressource d’application logique Consommation est toujours mappée à un seul workflow. Vous n’avez donc besoin que d’un seul nom. Une ressource d’application logique Standard peut inclure plusieurs flux de travail. Concevez donc une convention de nommage que vous pouvez également appliquer aux workflows membres. Pour ces flux de travail, envisagez une convention d’affectation de noms basée sur le nom du processus, par exemple :
Process-<*process-name*>
Par conséquent, si vous aviez un workflow qui implémente des tâches d’intégration des employés, telles que la création d’un enregistrement d’employé, vous pouvez nommer le workflow Process-EmployeeOnboarding.
Voici d’autres considérations à prendre en compte pour la conception de votre convention d’affectation de noms de flux de travail :
- Suivez le modèle Parent-Child pour les applications logiques où vous souhaitez mettre en évidence une relation entre un ou plusieurs flux de travail.
- Prenez en compte si un flux de travail publie ou consomme un message.
Noms des opérations de flux de travail
Lorsque vous ajoutez un déclencheur ou une action à votre flux de travail, le concepteur attribue automatiquement le nom générique par défaut pour cette opération. Toutefois, les noms d’opération doivent être uniques au sein de votre flux de travail, de sorte que le concepteur ajoute des suffixes numériques séquentiels sur les instances d’opération suivantes, ce qui rend difficile la lisibilité et le déchiffrement de l’intention d’origine du développeur.
Pour rendre les noms d’opérations plus explicites et plus faciles à comprendre, vous pouvez ajouter un bref descripteur de tâche après le texte par défaut et utiliser la notation Cas Pascal pour la cohérence. Par exemple, pour l’action Analyser JSON, vous pouvez utiliser un nom tel que Analyser JSON-ChangeEmployeeRecord. Avec cette approche ou d’autres approches similaires, vous continuerez à vous rappeler que l’action est Analyser JSON et l’objectif spécifique de l’action. Par conséquent, si vous devez utiliser les sorties de cette action plus loin dans les actions de flux de travail en aval, vous pouvez plus facilement identifier et trouver ces sorties.
Notes
Pour les organisations qui utilisent largement des expressions, envisagez une convention d’affectation de noms qui ne promeut pas l’utilisation d’espaces blancs (' '). Le langage d’expression dans Azure Logic Apps remplace les espaces blancs par des traits ('_') de soulignement , ce qui peut compliquer la création. En évitant les espaces à l’avance, vous contribuez à réduire les frictions lors de la création d’expressions. Utilisez plutôt un tiret ou un trait d’union ('-), qui offre une lisibilité et n’affecte pas la création d’expressions.
Pour éviter les éventuels remaniements et problèmes liés aux dépendances en aval, qui sont créées lorsque vous utilisez des sorties d’opération, renommez vos opérations immédiatement lorsque vous les ajoutez à votre flux de travail. En règle générale, les actions en aval sont automatiquement mises à jour lorsque vous renommez une opération. Toutefois, Azure Logic Apps ne renomme pas automatiquement les expressions personnalisées que vous avez créées avant d’effectuer le renommage.
Noms de connexion
Lorsque vous créez une connexion dans votre workflow, la ressource de connexion sous-jacente obtient automatiquement un nom générique, tel que sql ou office365. Comme les noms d’opération, les noms de connexion doivent également être uniques. Les connexions suivantes du même type obtiennent un suffixe numérique séquentiel, par exemple sql-1, sql-2, etc. De tels noms n’ont pas de contexte et rendent extrêmement difficile la différenciation et le mappage des connexions à leurs applications logiques, en particulier pour les développeurs qui ne connaissent pas l’espace et qui doivent prendre en charge la maintenance de ces applications logiques.
Par conséquent, les noms de connexion significatifs et cohérents sont importants pour les raisons suivantes :
- Readability
- Faciliter le transfert des connaissances et la prise en charge
- Gouvernance
Là encore, il est essentiel d’avoir une convention d’affectation de noms, même si le format n’est pas trop important. Par exemple, vous pouvez utiliser le modèle suivant comme guide :
CN-<*connector-name*>-<*logic-app-or-workflow-name*>
Par exemple, vous pouvez renommer une connexion Service Bus dans une application logique ou un workflow OrderQueue avec CN-ServiceBus-OrderQueue comme nouveau nom. Pour plus d’informations, consultez le billet de blog Turbo360 (anciennement Serverless360) Bonnes pratiques, conseils et astuces pour les applications logiques : convention d’affectation de noms des connecteurs #11.
Gérer les exceptions avec des étendues et des options « Exécuter après »
Les étendues fournissent la possibilité de regrouper plusieurs actions afin que vous puissiez implémenter le comportement Try-Catch-Finally. La fonctionnalité de l’action Étendue est similaire au concept Région dans Visual Studio. Sur le concepteur, vous pouvez réduire et développer le contenu d’une étendue pour améliorer la productivité des développeurs.
Lorsque vous implémentez ce modèle, vous pouvez également spécifier quand exécuter l’action Étendue et les actions à l’intérieur, en fonction de l’état d’exécution de l’action précédente, qui peut être Réussi, Échec, Ignoré ou TimedOut. Pour configurer ce comportement, utilisez les options Exécuter après () de l’action runAfterÉtendue :
- A réussi
- A échoué
- Est ignoré
- A expiré
Consolider les services partagés
Lorsque vous créez des solutions d’intégration, envisagez de créer et d’utiliser des services partagés pour des tâches courantes. Vous pouvez faire en sorte que votre équipe crée et expose une collection de services partagés que votre équipe de projet et d’autres peuvent utiliser. Tout le monde gagne en productivité, en uniformisation et en capacité d’appliquer la gouvernance aux solutions de votre organisation. Les sections suivantes décrivent certains domaines dans lesquels vous pouvez envisager d’introduire des services partagés :
| Service partagé | Raisons |
|---|---|
| Journalisation centralisée | Fournissez des modèles courants pour la façon dont les développeurs instrumentent leur code avec une journalisation appropriée. Vous pouvez ensuite configurer des vues de diagnostic qui vous aident à déterminer l’intégrité et la prise en charge de l’interface. |
| Suivi de l’entreprise et surveillance des activités commerciales | Capturez et exposez des données afin que les experts métier puissent mieux comprendre l’état de leurs transactions métier et effectuer des requêtes analytiques en libre-service. |
| Données de configuration | Séparez vos données de configuration d’application de votre code afin de pouvoir déplacer plus facilement votre application d’un environnement à l’autre. Veillez à fournir une approche unifiée cohérente et facilement réplicable pour accéder aux données de configuration afin que les équipes de projet puissent se concentrer sur la résolution du problème métier plutôt que de consacrer du temps aux configurations d’application pour le déploiement. Sinon, si chaque projet abordait cette séparation d’une manière unique, vous ne pouvez pas tirer parti des économies d’échelle. |
| Connecteurs personnalisés | Créez des connecteurs personnalisés pour les systèmes internes qui n’ont pas de connecteurs prédéfinis dans Azure Logic Apps afin de simplifier votre équipe de projet et d’autres personnes. |
| Jeux de données ou flux de données courants | Exposez des jeux de données et des flux courants sous forme d’API ou de connecteurs que les équipes de projet peuvent utiliser, et évitez de réinventer la roue. Chaque organisation a des jeux de données communs dont elle a besoin pour intégrer des systèmes dans un environnement d’entreprise. |
Passer en revue, réfléchir et apprendre
De temps en temps, évaluez et évaluez vos applications logiques existantes, en particulier en cas d’échec. Non seulement analysez le processus métier pour trouver ce que vous pouvez améliorer et où vous pouvez améliorer, mais également analyser l’historique des exécutions de votre workflow pour apprendre des échecs, des erreurs et des erreurs qui se sont produites. Azure Logic Apps fournit un historique des exécutions aussi riche que vous avez une forte probabilité de découvrir de nouvelles choses sur votre application lorsque vous passez en revue l’historique des exécutions de votre flux de travail. Comme tout développement de code, certains cas de périphérie ou d’angle peuvent apparaître. Au fur et à mesure que vous effectuez des découvertes, mettez à jour vos interfaces pour tenir compte de ces situations et améliorer la fiabilité globale de vos solutions.
Une réalité pour les équipes de projet est que les développeurs essaient de capturer génériquement les erreurs pour obtenir au moins une protection contre les problèmes. À mesure que votre équipe découvre et comprend mieux où les problèmes peuvent se poser, vous pouvez obtenir des instructions plus précises sur la façon de vous protéger contre les problèmes.
À l’instar de la façon dont les organisations effectuent régulièrement des exercices de « red team », tels que des tests d’intrusion ou des tentatives d’hameçonnage, la sécurité n’est pas une activité « set-and-forget ». À mesure que de nouveaux schémas et approches d’authentification deviennent disponibles, revisitez régulièrement vos interfaces, passez en revue vos mesures de sécurité et incorporez les nouveaux développements pertinents et appropriés qui fournissent les approches les plus sécurisées.
DevOps est un autre domaine que vous souhaitez évaluer régulièrement. À mesure que Microsoft ou la communauté introduisent de nouveaux modèles ou approches, évaluez ces mises à jour pour déterminer si vous pouvez bénéficier d’avantages supplémentaires.
Étapes suivantes
Vous avez maintenant découvert les approches de migration disponibles, les considérations relatives à la planification et les meilleures pratiques pour déplacer les charges de travail BizTalk Server vers Azure Integration Services. Pour fournir des commentaires détaillés sur ce guide, vous pouvez utiliser le formulaire suivant :