Approches de migration de BizTalk Server vers Azure Logic Apps
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
Les sections suivantes décrivent les différentes stratégies de migration ainsi que leurs avantages et inconvénients :
Big Bang
Un « big bang » ou « basculement direct » est une approche qui 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.
Nous vous recommandons d'envisager cette approche uniquement si vous avez des charges de travail BizTalk peu complexes, des experts en la matière qui connaissent votre environnement BizTalk et des correspondances directes entre les fonctionnalités BizTalk que vous utilisez actuellement et Azure Logic Apps. L'expérience acquise avec Azure Logic Apps réduit aussi considérablement les risques liés à cette approche.
Itératif ou à base de vagues (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 Logic Apps 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.
BizTalk Server et Azure Logic Apps ont des architectures différentes. Pour moderniser davantage vos solutions, vous pouvez utiliser les Services d’intégration Azure pour étendre les capacités d'Azure Logic Apps qui répondent aux besoins d'intégration des clients.
Pour un meilleur retour sur investissement (ROI), nous recommandons que toute migration BizTalk utilise autant que possible les capacités natives d'Azure Logic Apps (Standard) et les étende à d'autres Services d’intégration Azure si nécessaire. Cette combinaison permet d'envisager d'autres scénarios, par exemple :
- Capacités hybrides natives du cloud avec Azure Logic Apps (Standard) avec déploiement hybride
- Capacités de flux de travail avec ou sans état dans Azure Logic Apps (Standard)
- Intégration native et intégrée (dans l'application) des ordinateurs centraux et intermédiaires avec des connecteurs dans Azure Logic Apps (Standard)
- Messagerie Pub-sub avec Azure Service Bus
- Fonctionnalités SOAP avancées dans Gestion des API Azure
Réaliser un projet de migration BizTalk
Pour effectuer un tel projet, nous vous recommandons de suivre l’approche itérative ou basée sur les vagues et d’utiliser le processus Scrum. Bien que Scrum n'inclue pas de concept de Sprint Zéro (Sprint 0) pour les activités préalables au sprint, nous vous recommandons de concentrer votre premier sprint sur l'alignement de l'équipe et la découverte technique. Après le Sprint 0, suivez l'exécution de plusieurs sprints de migration et concentrez-vous sur la publication de fonctionnalités en vue d'un produit minimum viable (MVP).
Sprint 0
Au cours de ce sprint, nous vous recommandons d'exécuter BizTalk Server Environments Discovery avec Waves Planning. La compréhension de l'ampleur et de la profondeur du projet est essentielle à sa réussite. La liste suivante comprend les domaines spécifiques à traiter au cours du Sprint 0 :
| Domaine | Description |
|---|---|
| Découverte | 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. Vous devez également attribuer une complexité à chaque interface ou processus. Pendant ce processus de catalogage, collectez les informations suivantes pour classer par ordre de priorité le travail : - 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 - Dépendances de l’application et du système |
| Conception de l'architecture | Créer l'architecture de haut niveau qui servira de point focal pour la migration. Cette conception comprend des éléments qui répondent à des besoins fonctionnels et non fonctionnels de haut niveau. |
| Définition du produit minimum viable (MVP) | Définir les caractéristiques de la première vague. En d'autres termes, les processus qui ont besoin d'être soutenus après la première vague. |
| Backlog de migration initial | Définir les caractéristiques de la première vague et leurs éléments de travail avec une élaboration technique. |
Outils de découverte
Pour vous aider à découvrir la migration, vous pouvez utiliser l'outil de ligne de commande Azure Integration Migrator, également appelé outil BizTalk Migration, qui est un projet Microsoft open-source. Cet outil utilise une approche par phases pour vous aider à découvrir des insights et des stratégies utiles pour migrer vos solutions vers le cloud. Nous recommandons d'utiliser l'outil de migration uniquement pour la découverte et la génération de rapports. Vous pouvez également envisager d'utiliser d'autres produits de découverte provenant de partenaires qui fournissent des solutions dans ce domaine.
Pour une autre façon de générer un inventaire avec des éléments BizTalk Server, vous pouvez utiliser Document BizTalk, qui est développé par Mark Brimble. Cet outil fonctionne avec BizTalk Server 2020, bien qu'il soit indiqué que seul BizTalk Server 2016 est pris en charge.
Conception de l'architecture
Bien qu’Azure Logic Apps offre des fonctionnalités qui vous permettent de réutiliser les ressources BizTalk Server, vous devez disposer d'une architecture moderne pour profiter des avantages offerts par les fonctionnalités plus modernes. D'un point de vue fonctionnel, utilisez autant que possible votre logique d'entreprise. Du point de vue de la modernisation des produits, utilisez autant que possible les Services d’intégration Azure. Pour des problèmes de qualité et de coupe croisée, nous vous recommandons d’utiliser Azure Well-Architected Framework.
Dans ce cadre, les migrations BizTalk sont des charges de travail stratégiques. Ce terme décrit des ensembles de ressources d'application qui nécessitent une haute disponibilité sur la plateforme, ce qui signifie qu'elles doivent toujours être disponibles, opérationnelles et résistantes aux pannes.
Pour terminer la conception de l’architecture de votre migration BizTalk, suivez Méthodologie de conception pour les charges de travail stratégiques sur Azure. Pour une architecture et une topologie initiales, passez en revue et utilisez l’architecture de référence décrite dans Intégration d’entreprise Essentiel sur Azure dans le Centre des architectures Azure.
Pour configurer votre environnement initial, utilisez l’accélérateur de zone d’atterrissage des Services d’intégration Azure, qui est ciblé pour la création et le déploiement d’une plateforme d’intégration à l’aide d’une conception de zone d’atterrissage d’entreprise classique.
Définition du projet minimum viable (MVP)
Un MVP est une version du produit qui comporte juste assez de fonctionnalités utilisables par le client. Cette version montre les possibilités du produit et le potentiel de recueillir les commentaires des clients et de poursuivre le travail. Pour une migration BizTalk, votre définition du MVP reflète les itérations, les vagues ou les groupes de sprints dont vous avez besoin pour progresser vers des fonctionnalités fonctionnelles et pour répondre aux charges de travail d'intégration initiales.
Nous recommandons que votre définition de Microsoft MVP inclue les résultats métier suivants, qui sont exprimés en tant que Épopées dans la terminologie Scrum :
Résultats opérationnels (épopées)
- Quel est l'objectif principal que vous souhaitez atteindre ?
- Quelles sont les capacités ou les caractéristiques à prendre en compte pour ce MVP ?
- Quels sont les flux de processus métier ? Cette question permet d'optimiser les processus existants supportés par BizTalk Server.
- Quelles sont les décisions commerciales, par exemple les résultats commerciaux qui affectent le MVP, ou quelle est la disponibilité des ressources ?
Nous recommandons que votre Microsoft MVP inclue les processus suivants dans l’étendue, qui sont exprimés en tant que Fonctionnalités dans la terminologie Scrum :
Processus dans l’étendue (fonctionnalités)
| Fonctionnalité | Description |
|---|---|
| Système de fonctionnement général | Vous pouvez extraire ces informations à l'aide des outils de découverte et exprimer les descriptions en termes de caractéristiques. |
| Acteurs ou personnages | Utilisez ces informations pour déterminer les personnes concernées par les scénarios soutenus par le MVP. |
| Orchestrations | Vous pouvez extraire ces informations à l'aide des outils de découverte. |
| Entités de données et messages | Ces éléments vous permettent de savoir si vous pouvez apporter des améliorations supplémentaires aux données échangées par l'environnement BizTalk Server. |
| Mappages des données | Le monde d'aujourd'hui repose sur JSON. Cependant, BizTalk Server utilise XML. Ce moment est une excellente occasion de décider du format des données et des besoins de conversion pour la nouvelle plateforme. |
| Règles d’entreprise | Ces règles centrées sur les données vous permettent de repenser leur approche ou de les réutiliser en utilisant les fonctionnalités d'Azure Logic Apps. |
| Considérations relatives à la confidentialité des données | Vous devez faire de la protection de la vie privée une priorité absolue. À moins que votre client ne choisisse le modèle de déploiement hybride dans Azure Logic Apps (Standard), vous devez traiter cette question à chaque vague en raison des changements potentiels de l'environnement de déploiement. |
| Considérations réglementaires | Cet aspect est plus pertinent si vos clients n'ont pas de charges de travail basées sur le cloud. |
| Sécuriser par conception | Vous devez concevoir chaque fonctionnalité en gardant à l'esprit la sécurité. |
| Caractéristiques proposées pour la coexistence | Lorsque vous délivrez chaque vague, vous obtenez un certain degré de coexistence. Vous devez aligner cette architecture hybride sur les indicateurs de niveau de service (SLI) et les objectifs de niveau de service (SLO) existants. |
| Considérations non fonctionnelles | Les processus d'entreprise peuvent avoir des exigences non fonctionnelles différentes. Tout ne doit pas se passer en temps réel. Inversement, tout n'est pas un processus par lots. |
| Métriques métier | Une occasion facultative de montrer l'état d'avancement du travail de migration. |
Vous devrez également identifier et énumérer les différentes variables hors champ qui déterminent la portée de votre travail MVP, par exemple :
- La disponibilité des ressources
- Risques
- Documentation
- Délai de commercialisation
Carnet de commandes initial
Le carnet de commandes initial est un ensemble de récits utilisateur que vous regroupez en fonctionnalités pour générer les processus dans l’étendue de votre MVP. En d'autres termes, un MVP est représenté par des éléments Scrum appelés Epics, Features et User Stories. Idéalement, chaque Epic englobe un groupe d'applications BizTalk ou de projets BizTalk. Vous pouvez utiliser la règle simple qui associe une application BizTalk ou un projet BizTalk à une fonctionnalité.
Par exemple, supposons que vous ayez un projet BizTalk Server avec une orchestration appelée « LoanRequests » que les clients utilisent pour demander des prêts bancaires. Vous avez donc la proposition de fonctionnalité et d'histoire d'utilisateur suivante :
Fonctionnalité : traitement des prêts
Récit utilisateur : « En tant que client, je souhaite soumettre une demande de prêt afin que la banque puisse ajouter des fonds à mon compte sécurisé ».
Cette histoire d'utilisateur, qui pourrait actuellement exister en tant qu'implémentation dans BizTalk Server, a les tâches suivantes à mettre en œuvre en utilisant Azure Logic Apps et les Services d’intégration Azure :
- Collecter les artefacts réutilisables de BizTalk.
- Créer un flux de travail de requête de prêt à l’aide d'Azure Logic Apps.
- Configurer la messagerie asynchrone en utilisant Azure Service Bus ou IBM MQ.
- Mapper des données JSON à des données XML à l'aide d'un flux de travail Azure Logic Apps.
- Personnalisez les Services d’intégration Azure en fonction des modèles de messagerie.
Le diagramme suivant montre les durées suggérées pour les épopées, les caractéristiques, les histoires d'utilisateurs et les tâches, qui subdivisent les histoires d'utilisateurs. Bien que les décisions de mise en œuvre affectent ces durées, elles supposent que vous utilisez des artefacts BizTalk existants dans Azure Logic Apps. Créez vos flux de travail Standard à l’aide des modèles de flux de travail prédéfinis autant que possible.
Vagues de migration (sprints)
Une fois que votre équipe a terminé le Sprint 0, vous devriez avoir une vision claire du MVP à construire. Une vague est un ensemble de sprints. Votre carnet de commandes initial doit comprendre des éléments de travail qui suivent autant que possible le diagramme suivant :
Au cours d'une vague, votre équipe réalise les activités de migration, de test et de mise en production. Examinons de plus près ce qui se passe dans chaque vague.
Migrer
Au cours de chaque vague, la migration se concentre sur les histoires d'utilisateurs convenues. Pour la première vague, votre équipe se concentre sur le backlog initial. Les décisions technologiques doivent utiliser les informations du mappage des fonctionnalités BizTalk Server, décrites par Correspondance des fonctionnalités : pourquoi migrer de BizTalk Server vers Azure Logic Apps ?
Le diagramme suivant montre les événements qui doivent se produire pendant les vagues de migration :
| Étape | Description |
|---|---|
| 1 | Découvrir les applications et interfaces BizTalk existantes. Bien qu'introduite dans le Sprint 0, cette activité devrait avoir lieu au début de chaque vague. Les clients peuvent continuer à apporter des modifications à votre environnement BizTalk. Ressources : - Outil de migration BizTalk - Outil de documentation BizTalk |
| 2 | Configurer votre environnement de migration initial. Vous pouvez utiliser l’accélérateur de zone d’atterrissage des Services d’intégration Azure, qui est un cadre d’adoption cloud pour la création et le déploiement d’une plateforme d’intégration qui possède une conception de zone d’atterrissage d’entreprise classique. En tant que propriétaire de la charge de travail, vous pouvez obtenir en toute confiance votre état technique cible à l’aide des conseils architecturaux fournis et des ressources de migration BizTalk. Pour obtenir un exemple d’architecture, consultez Exemple d’environnement de migration. |
| 3 | Créer et tester des workflows d'applications logiques standard qui s'exécutent dans des Azure Logic Apps à locataire unique à l'aide du Portail Microsoft Azure ou de Visual Studio Code avec l'extension Azure Logic Apps (Standard). Avec Visual Studio Code, vous pouvez développer, tester et stocker localement votre projet d'application logique en utilisant n'importe quel système de contrôle de la source. Pour plus d’informations, consultez la documentation suivante : - Créer un exemple de workflow d’application logique Standard à l’aide du Portail Azure - Créer un exemple de workflow d’application logique Standard à l’aide de Visual Studio Code Pour obtenir un diagramme montrant un exemple d’application logique et de connexions, consultez Exemple d’environnement de migration. |
| 4 | Pour bénéficier des avantages complets du déploiement facile et cohérent de vos workflows d’application logique Standard dans différents environnements et plateformes, vous devez également automatiser votre processus de génération et de déploiement. L’extension Azure Logic Apps (Standard) pour Visual Studio Code fournit des outils pour créer et gérer des processus de génération et de déploiement automatisés à l’aide d'Azure DevOps. Pour plus d’informations, consultez Automatiser la génération et le déploiement pour les flux de travail d’application logique Standard avec Azure DevOps. |
| 5 | Pour déployer des applications logiques Standard stratégiques toujours disponibles et réactives, même durant les mises à jour ou la maintenance, activez le déploiement sans temps d’arrêt en créant et en utilisant des emplacements de déploiement. Aucun temps d’arrêt signifie qu’au moment où vous déployez de nouvelles versions de votre application, les utilisateurs finaux ne doivent pas être confrontés à des interruptions ou des temps d’arrêt. Pour plus d’informations, consultez Configurer des emplacements de déploiement pour permettre un déploiement sans temps d’arrêt dans Azure Logic Apps. |
Le diagramme suivant montre un exemple d'environnement de migration initiale avec une application logique Standard qui orchestre des flux de travail communiquant avec des API, des services, des solutions hybrides et des ressources sur site :
Test
Chaque vague a ses propres activités de test, qui sont incorporées dans chaque article utilisateur. Si vous souhaitez utiliser le test shift-left, assurez-vous d'effectuer les tâches suivantes :
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 d’automatisation 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 Logic Apps. 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.
Mise en production
Une fois que votre équipe a terminé et satisfait à la « définition de fait » pour les User Stories, envisagez les tâches suivantes :
Créer un plan de communication pour la mise en production.
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
- Répétition
- Contacts
- Planifier des estimations
- Désactivation des interfaces dans l’ancienne plateforme
- Activation des interfaces dans la nouvelle plateforme
- Test de validation
Déterminez un plan de restauration.
Exécutez des tests de validation.
Planifiez la prise en charge des opérations ou de la production.
Choisir des critères « validation ou refus » pour la mise en production.
Célébrez le succès de votre équipe.
Organisez une rétrospective.
Meilleures pratiques pour une migration BizTalk
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-enfant pour les flux de travail 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. Ces noms ne fournissent aucun contexte, ce qui rend la différenciation et la mise en correspondance des connexions avec leurs flux de travail extrêmement difficiles, en particulier pour les développeurs qui ne connaissent pas l'espace de solution et doivent maintenir ces flux de travail.
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 un flux de travail d’application logique 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. 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. |
Étapes suivantes
Vous avez maintenant découvert les approches de migration disponibles et les meilleures pratiques pour déplacer les charges de travail BizTalk Server vers Azure Logic Apps. Pour fournir des commentaires détaillés sur ce guide, vous pouvez utiliser le formulaire suivant :