Pourquoi migrer de BizTalk Server vers Azure Logic Apps ?

Ce guide fournit une vue d’ensemble des raisons et des avantages, des comparaisons de produits, des fonctionnalités et d’autres informations pour vous aider à commencer à migrer d’une instance BizTalk Server locale vers Azure Logic Apps. En suivant ce guide, vous trouverez d’autres guides qui expliquent comment choisir les services qui correspondent le mieux à votre scénario, ainsi que des stratégies de migration, des considérations relatives à la planification et de meilleures pratiques pour vous aider à obtenir des résultats satisfaisants.

Raisons et avantages

En migrant vos charges de travail d’intégration vers Azure Logic Apps, vous pouvez profiter des principaux avantages suivants :

Avantage	Description
Plateforme d’intégration moderne as a service (iPaaS)	Azure Logic Apps fait partie des Services d’intégration Azure, qui fournissent des fonctionnalités qui n’existaient pas lorsque BizTalk Server a été créé, par exemple : - Possibilité de créer et de gérer des API REST - Infrastructure cloud évolutive - Schémas d’authentification modernes, plus sécurisés et plus faciles à implémenter - Outils de développement simplifiés, y compris de nombreuses expériences basées sur un navigateur web - Mises à jour automatiques de la plateforme et intégration à d’autres services natifs cloud - Possibilité de s’exécuter localement (modèle de déploiement hybride d’Azure Logic Apps)
Investissements dans les fonctionnalités BizTalk	Azure Logic Apps, qui succède à BizTalk Server, inclut certaines fonctionnalités de BizTalk Server principales. Par exemple, le moteur de règles Azure Logic Apps utilise le même runtime que le moteur de règles métier BizTalk (BRE). Pour vous aider à préserver les investissements des clients dans BizTalk Server, le concepteur de flux de travail dans Azure Logic Apps inclut des fonctionnalités supplémentaires telles que l’outil Data Mapper lorsque vous utilisez Visual Studio Code, la prise en charge de l’exécution de code personnalisé et la prise en charge XML native.
Tarification basée sur la consommation	Avec les plateformes d’intergiciels traditionnelles, vous devez souvent effectuer de lourds investissements en capital afin d’obtenir des licences et des infrastructures, ce qui vous oblige à créer une solution « surdimensionnée » et donc peu adaptée à vos besoins réels. Azure Integration Services fournit plusieurs modèles tarifaires qui vous permettent généralement de ne payer que ce que vous utilisez. Bien que certains modèles tarifaires permettent d’activer et d’accéder à des fonctionnalités plus avancées, vous avez la possibilité de payer que ce que vous consommez.
Prise en main rapide	BizTalk Server est un répartiteur d’intergiciels très compétent, mais dont la maîtrise nécessite beaucoup de temps. Azure Logic Apps réduit le temps nécessaire à la prise en main, à l’apprentissage, à la création et à la livraison des solutions. Par exemple, Azure Logic Apps inclut un concepteur visuel qui vous offre une expérience avec peu voire pas de code pour créer les workflows déclaratifs que vous souhaitez utiliser pour remplacer les orchestrations BizTalk.
Connectivité SaaS	Les API REST devenant la norme pour l’intégration d’applications, de plus en plus d’entreprises SaaS ont adopté cette approche pour l’échange de données. Microsoft a créé un écosystème de connecteurs étendu et en constante croissance avec des centaines d’API pour s’intégrer aux services, systèmes et protocoles Microsoft et tiers. Dans Azure Logic Apps, vous pouvez utiliser le concepteur de workflows pour sélectionner des opérations à partir de ces connecteurs, créer et authentifier facilement des connexions, et configurer les opérations qu’ils souhaitent utiliser. Cette fonctionnalité accélère le développement et offre plus de cohérence lors de l’authentification de l’accès à ces services à l’aide d’OAuth2.
Déploiements géographiques multiples	Azure offre actuellement plus de 60 régions annoncées, plus que tout autre fournisseur de cloud, ce qui vous permet de choisir facilement les centres de données et les régions qui conviennent à vous et à vos clients. Cette portée vous permet de déployer des solutions de manière cohérente dans de nombreuses zones géographiques et offre des opportunités à la fois du point de vue de l’évolutivité et de la redondance.

Qu’est-ce qu’Azure Logic Apps ?

Azure Logic Apps est un service cloud et hybride permettant d’automatiser les flux de travail et d’orchestrer des processus métier, des applications et des données dans des environnements hybrides à l’aide d’un concepteur visuel. Ce service fait partie des Services d’intégration Azure, qui sont un ensemble des blocs de construction cloud, serverless, évolutifs et gérés par Microsoft pour vous permettre de créer des solutions d’intégration complètes et de migrer des solutions BizTalk Server existantes :

Service	Description
Azure Logic Apps	Créez et automatisez des flux de travail d’application logique qui orchestrent vos applications, données, services et systèmes. Vous pouvez rapidement développer des solutions d’intégration hautement scalables pour vos scénarios d’entreprise et B2B (Business to business). Utilisez le concepteur de flux de travail visuel pour orchestrer les microservices, les API et les intégrations métier. Pour augmenter la mise à l’échelle et la portabilité tout en automatisant les workflows stratégiques, déployez et exécutez partout où Kubernetes peut s’exécuter. Vous pouvez créer des ressources d’application logique Consommation ou Standard. Une application logique Consommation comprend un seul workflow avec état qui s’exécute dans Azure Logic Apps multilocataire. Une application logique Standard peut inclure plusieurs flux de travail avec état ou sans état qui s’exécutent dans Azure Logic Apps monolocataire, un environnement App Service Environment v3, ou sur des clusters Kubernetes avec Azure Arc (modèle de déploiement hybride). Pour positionner Azure Logic Apps dans Azure Integration Services, ce guide se concentre sur les applications logiques Standard, qui offrent le meilleur compromis entre les fonctionnalités d’entreprise, le coût et l’agilité. Pour plus d’informations, consultez Apps](logic-apps-overview.md).
Azure Functions	Écrivez moins de code, maintenez une infrastructure moins importante et réduisez les coûts d’exécution de vos applications. Afin que vous n’ayez pas à déployer et à gérer des serveurs, l’infrastructure cloud fournit toutes les ressources à jour nécessaires pour maintenir l’exécution de vos applications. Pour plus d’informations, consultez Azure Functions.
Azure Data Factory	Intégrez visuellement toutes vos sources de données à l’aide de plus de 90 connecteurs intégrés ne nécessitant aucune maintenance et n’entraînant aucun surcoût. Construisez facilement des processus ETL (Extract, Transform, and Load) et Extract, Load, and Transform (ELT) sans code dans un environnement intuitif, ou écrivez votre propre code. Pour déverrouiller des insights métier, transmettez vos données intégrées à Azure Synapse Analytics. Pour plus d’informations, consultez Azure Data Factory.
Azure Service Bus	Transférez des données entre des applications et des services, même hors connexion, en tant que messages à l’aide de ce répartiteur de messages d’entreprise hautement fiable. Bénéficiez d’une plus grande flexibilité lors de la répartition de messages entre le client et le serveur à l’aide d’une messagerie FIFO (first-out) structurée, de fonctionnalités de publication-abonnement et d’opérations asynchrones. Pour plus d’informations, consultez Azure Service Bus.
Azure Event Grid	Intégrez des applications à l’aide d’événements fournis par un répartiteur d’événements à des destinations d’abonnés, telles que les services Azure, d’autres applications ou tout point de terminaison où Event Grid dispose d’un accès réseau. Les sources d’événements peuvent inclure d’autres applications, services SaaS et services Azure. Pour plus d’informations, consultez Azure Event Grid.
Gestion des API Azure	Déployez des passerelles d’API côte à côte et optimisez le flux de trafic avec des API hébergées dans Azure, d’autres clouds et localement. Répondez aux exigences de sécurité et de conformité, tout en bénéficiant d’une expérience de gestion unifiée et d’une observabilité complète sur toutes les API internes et externes. Pour plus d’informations, consultez Gestion des API Azure.

Services Azure complémentaires

Au-delà des services décrits précédemment, Microsoft propose également les services complémentaires suivants qui fournissent des fonctionnalités sous-jacentes pour Azure Integration Services et que vous utiliserez probablement dans un projet de migration :

Service	Description
Stockage Azure	Offre un stockage sécurisé, moderne, hautement disponible, hautement scalable et durable pour différents objets de données du cloud. Vous pouvez accéder à ces objets de données depuis n’importe où dans le monde via HTTP ou HTTPS à l’aide d’une API REST. Azure Integration Services utilise ces fonctionnalités pour stocker en toute sécurité les données de configuration et de télémétrie pendant que les transactions transitent par la plateforme. Pour plus d’informations, consultez Stockage Azure.
Contrôle d’accès en fonction du rôle Azure (Azure RBAC)	Gérez l’accès aux ressources cloud, ce qui constitue une fonction essentielle pour toute organisation qui utilise le cloud. Le contrôle RBAC Azure est un système d’autorisation basé sur Azure Resource Manager qui permet une gestion affinée de l’accès aux ressources Azure. Vous pouvez gérer qui peut accéder aux ressources Azure, ce que ces utilisateurs peuvent en faire ainsi que les zones auxquelles ils ont accès. Pour plus d’informations, consultez Azure RBAC.
Azure Key Vault	Fournit des fonctionnalités pour vous aider à résoudre les problèmes liés à la gestion des secrets, des clés et des certificats. Azure Integration Services fournit l’intégration à Azure Key Vault via des paramètres de configuration d’application et via un connecteur. Cette fonctionnalité vous permet de stocker des secrets, des informations d’identification, des clés et des certificats de manière sécurisée mais pratique. Pour plus d’informations, consultez Azure Key Vault.
Azure Policy	Fournit des fonctionnalités qui vous aident à appliquer les normes organisationnelles et à évaluer la conformité de manière évolutive. Le tableau de bord de conformité vous fournit une vue agrégée permettant d’évaluer l’état général de l’environnement, avec la possibilité d’explorer au niveau de chaque ressource et stratégie. Azure Integration Services s’intègre à Azure Policy pour vous permettre d’implémenter efficacement une gouvernance étendue. Pour plus d’informations, consultez Présentation d’Azure Policy.
Mise en réseau Azure	Fournit une grande variété de fonctionnalités de mise en réseau, notamment une connectivité, des services de protection des applications, des services de distribution d’applications et une surveillance réseau. Azure Integration Services utilise ces fonctionnalités pour garantir une connectivité entre les services à l’aide de réseaux virtuels et de points de terminaison privés. Pour plus d’informations, consultez Mise en réseau Azure.
Hubs d'événements Azure	Créez des pipelines de données dynamiques et relevez immédiatement les défis de l’entreprise en diffusant en continu des millions d’événements par seconde depuis n’importe quelle source avec ce service d’ingestion de données en temps réel entièrement managé, simple, fiable et évolutif. API Management effectue une journalisation personnalisée à l’aide d’Event Hubs, l’une des meilleures solutions lors de l’implémentation d’une solution de suivi découplée dans Azure. Pour plus d’informations, consultez Azure Event Hubs.
Azure SQL Database	À un moment donné, vous devrez peut-être créer des stratégies de journalisation personnalisées ou des configurations personnalisées pour prendre en charge vos solutions d’intégration. Même si SQL Server est couramment utilisé localement à cette fin, Azure SQL Database peut offrir une solution viable lors de la migration de bases de données SQL Server locales vers le cloud. Pour plus d’informations, consultez Azure SQL Database.
Azure App Configuration	Gérez de manière centralisée les paramètres et les indicateurs de fonctionnalités d’une application. Les programmes modernes, en particulier ceux qui s’exécutent dans un cloud, contiennent généralement de nombreux composants distribués par nature. La répartition des paramètres de configuration sur tous ces composants peut rendre les erreurs difficiles à corriger pendant le déploiement d’une application. Avec App Configuration, vous pouvez stocker tous les paramètres de votre application et sécuriser leur accès dans un même endroit. Pour plus d’informations, consultez Azure App Configuration.
Azure Monitor	Application Insights, qui fait partie d’Azure Monitor, permet de gérer et de surveiller les performances des applications en temps réel. Stockez les données de télémétrie des applications et surveillez l’intégrité globale de votre plateforme d’intégration. Vous avez également la possibilité de définir des seuils et d’obtenir des alertes lorsque les performances dépassent les seuils configurés. Pour plus d’informations, consultez Application Insights.
Azure Automation	Automatisez vos tâches de gestion Azure et orchestrez des actions sur des systèmes externes au sein d’Azure. S’appuie sur un workflow PowerShell pour vous permettre d’utiliser les nombreuses fonctionnalités de ce langage. Pour plus d'informations, consultez Azure Automation.

Expériences de développement prises en charge

Cette section décrit les outils de développement pris en charge par BizTalk Server et Azure Integration Services :

Offre	Produit ou service avec des outils pris en charge
BizTalk Server	Chaque version de BizTalk Server prend en charge une version spécifique de Visual Studio. Par exemple, BizTalk Server 2020 prend en charge Visual Studio 2019 Enterprise ou Professionnel. Toutefois, Visual Studio Community Edition n’est pas pris en charge.
Services d’intégration Azure	- Azure Logic Apps (Standard) : portail Azure et Visual Studio Code - Azure Logic Apps (Consommation) : portail Azure et Visual Studio Code - Azure Functions : portail Azure, Visual Studio Code et Visual Studio 2022 - Azure API Management : portail Azure et Visual Studio Code - Azure Service Bus : portail Azure et Service Bus Explorer - Azure Data Factory : portail Azure et Visual Studio 2015

BizTalk Server et Azure Logic Apps

Pour comparer BizTalk Server à Azure Logic Apps et décrire la migration, récapitulons d’abord brièvement le rôle de BizTalk Server. Disponible dès 2000, BizTalk Server est une plateforme d’intergiciels stable et locale qui connecte différents systèmes à l’aide d’adaptateurs. Cette plateforme fonctionne comme un répartiteur entre les entreprises, les systèmes ou les applications, et s’est imposée comme une plateforme d’intégration bien établie. Pour simplifier le défi qu’entraîne la combinaison de différents systèmes développés dans différents langages et pouvant être connectés à l’aide de divers protocoles et formats, BizTalk Server offre les principales fonctionnalités suivantes :

• Orchestration (flux métier)

  Permet de créer et d’exécuter des orchestrations ou des processus métier définis graphiquement.

• Messagerie

  Permet de communiquer avec un large éventail d’applications logicielles. Les adaptateurs permettent au composant de messagerie de BizTalk Server d’interagir avec différents protocoles et formats de données.

Le moteur BizTalk Server comprend les composants suivants :

Composant	Description
Business Rule Engine (BRE)	Évalue des ensembles de règles complexes.
Authentification unique de l'entreprise (SSO)	Permet de mapper des informations d’authentification entre des systèmes Windows et des systèmes tiers.
BAM (Business Activity Monitoring)	Permet aux travailleurs de l’information de surveiller un processus métier en cours d’exécution.
Hub du groupe	Permet au personnel de support de gérer le moteur et les orchestrations qui s’exécutent.

Comment fonctionne BizTalk Server ?

BizTalk Server utilise une architecture de moteur de messagerie de type publication-abonnement avec la base de données MessageBox en son cœur. MessageBox gère le stockage des messages, des propriétés de message, des abonnements, des états d’orchestration, des données de suivi et d’autres informations.

Quand BizTalk Server reçoit un message, le serveur transmet et traite le message via un pipeline. Cette étape normalise et publie le message dans MessageBox. BizTalk Server évalue ensuite tous les abonnements existants et détermine le destinataire prévu du message en fonction des propriétés du contexte du message. Pour finir, BizTalk Server achemine le message vers le destinataire prévu en fonction des abonnements ou des filtres. Ce destinataire est une orchestration ou un port d’envoi, qui représente une destination vers laquelle BizTalk Server envoie des messages ou une source d’où BizTalk Server peut recevoir des messages. BizTalk Server transmet des messages via un port d’envoi en les distribuant via un pipeline d’envoi. Le pipeline d’envoi sérialise les messages au format natif attendu par le récepteur avant d’envoyer les messages via un adaptateur.

La base de données MessageBox comporte les composants suivants :

• Agent de messagerie

  BizTalk Server interagit avec MessageBox à l’aide de cet agent, qui fournit des interfaces pour la publication de messages, l’abonnement aux messages, la récupération de messages, etc.

• Une ou plusieurs bases de données SQL Server

  Ces bases de données assurent le stockage permanent des messages, des parties et propriétés des messages, des abonnements, de l’état des orchestrations, des données de suivi, des files d'attente hôte pour le routage, entre autres.

L’image suivante montre comment fonctionne le moteur de messagerie BizTalk Server :

Lorsqu’un port de réception reçoit un message, MessageBox stocke ce message pour le traitement par les processus métier ou pour le routage vers tous les ports d’envoi qui ont des abonnements à des messages spécifiques.

Pour plus d'informations, reportez-vous à la section Architecture publication-abonnement plus loin dans ce guide.

Processus métier

Cette section décrit les options de conception et de création de processus métier que vous pouvez exécuter dans BizTalk Server et Azure Integration Services.

BizTalk Server

Dans BizTalk Server, les orchestrations sont des processus d'entreprise exécutables qui peuvent s'abonner à des messages (recevoir) et publier des messages (envoyer) via la base de données MessageBox. Les orchestrations peuvent créer de nouveaux messages et recevoir des messages à l’aide de l’infrastructure d’abonnement et de routage. Lorsque MessageBox remplit les abonnements pour les orchestrations, une nouvelle instance (exécution d’orchestration) s’active et MessageBox remet le message. Si nécessaire, l’instance est réactivée puis le message est remis. Lorsque des messages sont envoyés à partir d'une orchestration, ils sont publiés dans la base de données MessageBox de la même manière qu'un message qui arrive sur un emplacement de réception avec les propriétés appropriées et qui est ajouté à la base de données à des fins de routage.

Pour activer une messagerie de type publication-abonnement, les orchestrations utilisent des liaisons qui facilitent la création d’abonnements. Les ports d'orchestration sont des ports logiques qui décrivent une interaction. Pour remettre des messages, vous devez lier ces ports logiques à un port physique, mais ce processus de liaison revient en fait à configurer des abonnements pour le routage des messages.

BizTalk Server offre les avantages suivants :

• Orienté concepteur (déclaratif)

  Concevez des processus complexes à l’aide d’outils de conception faciles à comprendre pour implémenter des modèles et des workflows qui pourraient être difficiles à implémenter dans le code.

• Abstraction avec des systèmes finaux

  Concevez des processus axés sur les messages, et non sur le système final. Par exemple, lors du développement de vos solutions, vous n’avez pas à vous soucier de savoir si vous allez utiliser un adaptateur FILE ou un adaptateur FTP. Vous vous concentrez plutôt sur le type de communication, qu’il s’agisse d’une seule voie ou d’une demande-réponse, et sur le type de message que vous souhaitez traiter. Plus tard, lorsque vous déployez vos solutions, vous pouvez spécifier l’adaptateur et les systèmes finaux.

Azure Logic Apps

Dans Apps](logic-apps-overview.md), vous pouvez créer des processus métier exécutables et des applications en tant que flux de travail d’application logique en utilisant une méthode de programmation par « bloc de construction » avec un concepteur visuel et des opérations prédéfinies à partir de centaines de connecteurs, ce qui nécessite un code minimal. Un workflow d’application logique commence par une opération de déclencheur suivie d’une ou plusieurs opérations d’action, chaque opération fonctionnant comme une étape logique dans le processus d’implémentation du workflow. Votre workflow peut utiliser des actions pour appeler des logiciels, des services et des systèmes externes. Certaines actions effectuent des tâches de programmation, telles que les conditions (instructions if), les boucles, les opérations de données, la gestion des variables, etc.

Azure Logic Apps offre les avantages suivants :

• Orienté concepteur (déclaratif)

  Concevez des processus complexes à l’aide d’outils de conception faciles à comprendre pour implémenter des modèles et des workflows qui pourraient être difficiles à implémenter dans le code.

• Flexible et évolutif

  Azure Logic Apps est un service informatique basé sur le cloud, serverless, hautement évolutif, qui se met automatiquement à l’échelle et s’adapte pour répondre aux besoins en constante évolution de l’entreprise.

• Se connecte partout

  Faites votre choix dans une galerie en constante expansion comprenant des centaines de connecteurs prédéfinis pour créer vos workflows. Un connecteur fournit des opérations que vous pouvez utiliser comme étapes dans vos workflows. Vous pouvez créer des solutions d’intégration pour la plupart des services et systèmes proposés par Microsoft et les partenaires, notamment BizTalk Server, Salesforce, Office 365, bases de données SQL, la plupart des services Azure comme Azure Functions, Stockage Azure, Azure Service Bus, et un large éventail d’applications ou systèmes locaux, ordinateurs mainframe et midrange, infrastructures SaaS et API. Si aucun connecteur préconstruit n’existe pour la ressource à laquelle vous souhaitez accéder, vous pouvez utiliser l’opération HTTP générique pour communiquer avec le service ou vous pouvez créer un connecteur personnalisé.

Composants réutilisables

Les plateformes d’intégration offrent des moyens de résoudre les problèmes de manière cohérente et unifiée, ce que vous pouvez souvent obtenir par le biais de composants réutilisables. Cette section explique comment réutiliser des composants dans BizTalk Server et Azure Integration Services.

BizTalk Server

• Orchestrations

  Vous pouvez créer et partager une logique métier commune en tant qu’orchestrations sur différents workflows, en interne au sein de la même application ou avec plusieurs applications. Vous pouvez déclencher des orchestrations à l’aide du mécanisme natif publication-abonnement dans BizTalk Server (de manière découplée) ou en utilisant les formes d’orchestration nommées Appeler orchestration pour les appels synchrones, ou Démarrer orchestration pour les appels asynchrones.

• Adaptateurs

  Les adaptateurs sont des composants logiciels qui fournissent la connectivité entre BizTalk Server et les partenaires commerciaux à l'aide de protocoles de données et formats de document communément reconnus. Ces composants facilitent l’envoi et la réception de messages à l’aide d’un mécanisme de remise conforme à une norme communément reconnue comme SMTP, FTP, HTTP, etc. Comme les adaptateurs font partie de la plateforme principale, toutes les applications existantes les partagent. Vous pouvez également étendre cette couche en créant un adaptateur personnalisé, natif ou basé sur Windows Communication Foundation (WCF) à l’aide de BizTalk Adapter Framework.

• Schémas

  Les schémas XSD (XML Schema Definition) activent la messagerie basée sur des contrats dans BizTalk Server. Pour éviter de créer des schémas redondants, vous pouvez référencer des schémas à partir d’assemblys compilés. Pour utiliser des schémas partagés, vous devez ajouter une référence à l’assembly partagé à partir de votre projet BizTalk.

  Même si cette étape peut sembler simple, la gestion des modifications apportées aux assemblys partagés peut devenir difficile en raison du chaînage des dépendances. Si l’assembly partagé nécessite une mise à jour, vous devez supprimer tous les projets qui référencent l’assembly partagé de BizTalk Server pour installer la mise à jour. Mais pour éviter ces contraintes, vous pouvez implémenter le contrôle de version d’assembly dans lequel vous déployez une nouvelle version pour un schéma ou des schémas partagés, sans interrompre vos solutions existantes.

• Mappages et fonctoids personnalisés

  Les mappages activent la traduction ou la transformation de messages XML dans BizTalk Server. Vous pouvez partager des mappages, mais à l’instar des schémas partagés, des précautions similaires s’appliquent aux mappages partagés. En raison du chaînage des dépendances, procédez avec précaution et assurez-vous que vous disposez d’un cycle de vie de développement logiciel mature pour gérer les modifications.

  Dans les mappages, les fonctoids effectuent des calculs en utilisant des formules prédéfinies et des valeurs spécifiques, appelées arguments. BizTalk Server fournit de nombreux fonctoids pour prendre en charge une gamme d’opérations diverses. Les fonctoids personnalisés vous offrent un moyen pour étendre la gamme des opérations disponibles dans l'environnement de mappage de BizTalk Server.

  Si vous commencez à créer de nombreux mappages, vous réalisez que vous implémentez à plusieurs reprises une logique similaire. Par conséquent, vous passerez du temps à gérer plusieurs extraits de code équivalents que vous copiez et collez généralement dans plusieurs emplacements au sein d’un ou plusieurs mappages. Vous pouvez transformer ces extraits de code en un fonctoid personnalisé. De cette façon, vous ne créez le fonctoid qu’une seule fois, mais vous pouvez le réutiliser dans autant de mappages que vous le souhaitez et mettre à jour le fonctoid à un seul endroit. Chaque fonctoid personnalisé est déployé en tant qu'assembly .NET utilisant des classes dérivées de l’espace de noms Microsoft.BizTalk.BaseFunctoids. Un seul assembly peut contenir plusieurs fonctoids personnalisés.

• Assemblys .NET Framework

  Vous pouvez partager ces assemblys entre des projets BizTalk Server. Ces assemblys sont plus faciles à gérer du point de vue des dépendances. Si aucun changement cassant n’existe, une mise à jour d’un assembly .NET Fx nécessite la mise à jour de la DLL dans Global Assembly Cache (GAC), ce qui rend automatiquement les modifications disponibles pour d’autres assemblys. En cas de modifications majeures, vous devez également mettre à jour le projet dépendant pour prendre en charge les modifications apportées à l’assembly .NET Framework.

• Pipelines et composants de pipeline personnalisés

  Lorsque BizTalk Server reçoit et envoie des messages, le serveur peut avoir besoin de préparer et de transformer des messages pour l’entrée et la sortie, à des fins professionnelles. Dans BizTalk Server, les pipelines fournissent une implémentation du modèle d’intégration Canaux et filtres et incluent de nombreuses fonctionnalités telles qu’un encodeur et un décodeur JSON, un décodeur MIME ou SMIME, etc.

  Lorsque vous devez ajouter des informations au contexte d’un message qui nécessite une personnalisation de pipeline, BizTalk Server offre la possibilité de personnaliser ces pipelines en créant des composants de pipeline personnalisés. Un composant de pipeline personnalisé est une classe .NET que vous utilisez pour implémenter plusieurs interfaces BizTalk, puis que vous utilisez dans différentes étapes d’un pipeline personnalisé. Pour écrire du code pour un tel composant, vous pouvez utiliser C# ou Visual Basic pour .NET.

• Stratégie du moteur de règles

  Une stratégie de moteur de règles métier est un autre type d’artefact que vous pouvez partager entre des applications BizTalk Server déployées au sein du même groupe BizTalk. Si vous utilisez des règles courantes du moteur de règles métier, par exemple, liées au routage des messages, vous pouvez les gérer dans un emplacement et les partager dans l’ensemble des applications BizTalk installées. Le moteur de règles métier met en cache ces règles. Par conséquent, si vous effectuez des mises à jour de ces règles, vous devez redémarrer le service de mise à jour du moteur de règles métier. Sinon, les modifications sont extraites au prochain délai d’expiration du cache.

Azure Logic Apps

• Compte d’intégration

  Pour Azure Logic Apps, un compte d’intégration est un conteneur basé sur le cloud et une ressource Azure offrant un accès centralisé à des artefacts réutilisables. Pour les workflows d’application logique Consommation, ces artefacts incluent des partenaires commerciaux, des contrats, des schémas XSD, des mappages XSLT, des mappages basés sur des modèles Liquid, des certificats, des configurations de lots et des assemblys .NET Fx.

  Pour les workflows d’application logique Standard, Azure Logic Apps a récemment introduit la prise en charge de l’appel d’assemblys .NET Fx à partir de transformations XSLT sans nécessiter de compte d’intégration. Vous pouvez également ajouter des schémas, des mappages et des assemblys à un projet d’application logique Standard dans Visual Studio Code, puis le déployer sur Azure.

• API

  Les API permettent des expériences numériques, simplifient l’intégration d’applications, intègrent de nouveaux produits numériques et rendent les données et les services réutilisables et universellement accessibles. Compte tenu de la prolifération des API et de la dépendance croissante à leur égard, les organisations doivent les gérer comme des ressources de premier ordre tout au long de leur cycle de vie.

  Vous pouvez réutiliser les API, en particulier celles gérées avec Gestion des API Azure, dans Azure Logic Apps. Après avoir ajouté des API à Gestion des API Azure, vous pouvez utiliser le connecteur Gestion des API avec les flux de travail d’application logique pour accéder facilement aux API de manière managée et régie. Azure Logic Apps prend également en charge la création et l’utilisation d’API personnalisées afin que votre organisation puisse promouvoir la réutilisation au sein de l’entreprise et éviter les connecteurs redondants inutiles que les développeurs risqueraient de créer. Les API personnalisées facilitent également l’accès à ces API au lieu de laisser le développeur imaginer des mécanismes permettant d’utiliser une API particulière.

• Connecteurs personnalisés

  S’il n’existe aucun connecteur prédéfini pour les API que vous souhaitez utiliser, vous pouvez encapsuler une API externe ou externe avec un schéma OpenAPI pour créer un connecteur personnalisé et y accéder à partir de workflows d’application logique Consommation avec les autorisations appropriées. Le connecteur personnalisé crée un contrat entre Azure Logic Apps et l’API qui permet de créer facilement un assembly des messages de requête et à Azure Logic Apps de recevoir une réponse typée que vous pouvez utiliser dans les actions en aval. Les API REST et les API SOAP sont toutes deux prises en charge, et peuvent référencer des API publiques ou privées présentes sur votre réseau local.

  Pour les workflows d’application logique Standard, vous pouvez créer vos propres connecteurs personnalisés intégrés basés sur un fournisseur de services.

  En implémentant un connecteur personnalisé, vous simplifiez l’expérience de développement en créant une interface commune pour l’envoi de messages de demande et la réception de réponses typées. Pour plus d’informations, consultez la page Connecteurs personnalisés et API.

Adaptateurs et connecteurs

La section suivante décrit les concepts des adaptateurs et des connecteurs respectivement dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

Pour échanger des messages avec des systèmes, des applications et des entités externes, BizTalk Server fournit des adaptateurs, représentant des composants COM ou .NET Fx qui transfèrent des messages vers et depuis des points de terminaison métier tels que des systèmes de fichiers, des bases de données et des applications métier personnalisées à l’aide de différents protocoles de communication. BizTalk Server fournit des adaptateurs natifs qui prennent en charge différents protocoles, notamment :

• Un adaptateur File qui gère l'envoi et la réception des messages depuis un emplacement de fichier
• des adaptateurs pour les protocoles EDI, FTP, HTTP, MSMQ, SMTP, POP3 et SOAP ;
• Un adaptateur pour Windows SharePoint Services

L'infrastructure d'adaptateurs BizTalk offre un mécanisme ouvert et stable permettant à tous les adaptateurs d'implémenter des données ou d'y accéder à partir du moteur de messagerie BizTalk Server. Les interfaces de l'espace de noms Microsoft.BizTalk.Adapter.Framework permettent aux adaptateurs de modifier les pages de propriétés de configuration. L’infrastructure d’adaptateurs BizTalk offre également la possibilité d’importer des services et des schémas dans un projet BizTalk. Des adaptateurs partenaires sont également disponibles auprès de différents fournisseurs et membres de la communauté. Pour obtenir la liste des adaptateurs connus, consultez BizTalk Server : liste des adaptateurs tiers.

Azure Logic Apps

Lorsque vous générez des workflows avec Azure Logic Apps, vous pouvez utiliser des connecteurs préconstruits pour utiliser rapidement et facilement des données, des événements et des ressources dans d’autres applications, services, systèmes, protocoles et plateformes, généralement sans avoir à écrire de code. Azure Logic Apps fournit une galerie en constante expansion de centaines de connecteurs que vous pouvez utiliser. Vous pouvez créer des solutions d’intégration pour de nombreux services et systèmes, basés sur le cloud ou locaux, à partir de Microsoft et de partenaires, notamment BizTalk Server, Salesforce, Office 365, bases de données SQL, la plupart des services Azure, les ordinateurs mainframe, les API, etc. Certains connecteurs fournissent des opérations qui effectuent des opérations de programmation, telles que les instructions conditionnelles (if), les boucles, les opérations de données, la gestion des variables, etc. Si aucun connecteur n’est disponible pour la ressource recherchée, vous pouvez utiliser l’opération HTTP générique pour communiquer avec le service ou vous pouvez créer un connecteur personnalisé.

Techniquement, un connecteur est un proxy ou un wrapper autour d’une API que le service ou système sous-jacent utilise pour communiquer avec Azure Logic Apps. Ce connecteur fournit les opérations que vous utilisez dans vos workflows pour effectuer des tâches. Une opération est disponible dans un déclencheur ou une action avec des propriétés que vous pouvez configurer. Certains déclencheurs et actions nécessitent également la création et la configuration d’une connexion en premier lieu au service ou au système sous-jacent. Si nécessaire, vous authentifierez également l’accès à un compte d’utilisateur.

La plupart des connecteurs dans Azure Logic Apps représentent un connecteur intégré ou un connecteur managé. Certains connecteurs sont disponibles dans les deux versions. Les versions disponibles varient selon que vous créez un workflow d’application logique Consommation ou un workflow d’application logique Standard.

• Les connecteurs intégrés sont conçus pour s’exécuter en mode natif sur le runtime Azure Logic Apps et offrent généralement un niveau plus élevé de performances, de débit et de capacité, ou d’autres avantages par rapport aux connecteurs managés équivalents.

• Les connecteurs managés sont déployés, hébergés et managés par Microsoft dans Azure. Ces connecteurs fournissent des déclencheurs et des actions pour les services cloud, les systèmes locaux, ou les deux. Dans un workflow d’application logique Standard, tous les connecteurs managés sont regroupés comme connecteurs Azure. Toutefois, dans des workflows d’application logique Consommation, les connecteurs managés sont regroupés dans la catégorie Standard ou Entreprise, en fonction de leur niveau tarifaire.

Pour plus d’informations, consultez la documentation suivante :

• Vue d’ensemble des connecteurs intégrés
• Vue d'ensemble des connecteurs managés
• Connecteurs managés disponibles dans Azure Logic Apps

Connectivité d'application

La section suivante décrit les options permettant de se connecter à d’autres applications à partir de BizTalk Server et d’Azure Integration Services.

BizTalk Server

Les adaptateurs fournissent les fonctionnalités de connectivité dans BizTalk Server et s’exécutent localement sur le serveur BizTalk qui effectue l’opération d’envoi ou de réception. Environ 30 adaptateurs prêts à l’emploi sont disponibles, tandis qu’un petit écosystème d’adaptateurs ISV offre des fonctionnalités supplémentaires. Avec ces adaptateurs exécutés localement, l’authentification Windows est une méthode d’authentification populaire. Les adaptateurs couramment utilisés incluent FILE, SFTP, SQL, WCF (Basic-HTTP), HTTP et SMTP. Cette liste vous permet de déterminer que les adaptateurs dans BizTalk Server sont principalement des adaptateurs de protocole. Par conséquent, les adaptateurs utilisent généralement un modèle de messagerie orienté message dans lequel un message complet est échangé avec d’autres systèmes où ces systèmes sont chargés d’analyser les données avant de charger les données dans le magasin de données final.

Azure Logic Apps

Les connecteurs fournissent les fonctionnalités de connectivité dans Azure Logic Apps et offrent une abstraction par-dessus les API qui appartiennent généralement au système SaaS sous-jacent. Par exemple, les services comme SharePoint sont créés à l’aide d’une approche basée sur l’API, où les API fournissent des fonctionnalités au service pour les utilisateurs finaux, mais les mêmes fonctionnalités sont exposées pour que d’autres systèmes appellent via une API. Pour simplifier l’appel de ces API, les connecteurs utilisent des métadonnées pour décrire le contrat de messagerie afin que les développeurs sachent quelles données sont attendues dans la demande et dans la réponse.

La capture d’écran suivante montre l’expérience de recherche des opérations de connecteur dans le concepteur pour un flux de travail d’application logique Standard dans un environnement Azure Logic Apps monolocataire. Lorsque vous sélectionnez Dans l’application dans la liste Runtime, vous y trouverez des connecteurs intégrés comme Azure Functions, Azure Service Bus, IBM DB2, SQL Server, Stockage Azure, Système de fichiers, HTTP, etc. Si vous sélectionnez Partagé, vous trouverez plus de 1 000 connecteurs, y compris d’autres connecteurs Microsoft SaaS, des connecteurs SaaS partenaires, etc.

Services web et connectivité d’API

Les sections suivantes décrivent la prise en charge des services web et de la connectivité d’API dans BizTalk Server et Azure Logic Apps.

BizTalk Server

La prise en charge des services web est une fonctionnalité populaire dans BizTalk Server et qui est disponible en s’intégrant à Windows Communication Foundation (WCF). Cette prise en charge dans BizTalk se divise en deux catégories : publication et consommation de services WCF.

Les adaptateurs WCF assurent la prise en charge des normes WS-*, telles que WS-Addressing, WS-Security et WS-AtomicTransaction. Cependant, la norme WS-ReliableMessaging n'est pas prise en charge dans cette version des adaptateurs WCF.

Les adaptateurs WCF prennent en charge l’authentification unique (SSO) via l’emprunt d’identité et acquièrent le ticket Enterprise SSO pour l’utilisation de l’authentification unique avec les adaptateurs WCF. Cette fonctionnalité permet au contexte utilisateur de circuler entre les systèmes. Du point de vue de l’authentification, l’authentification du service prend en charge les types suivants : Aucun, Windows et Certificat. L’authentification du client prend en charge les types suivants : Anonyme, UserName, Windows et Certificat. Les modes de sécurité pris en charge incluent les types suivants : Transport, Message et Mixte.

WCF prend en charge les transactions à l’aide du protocole WS-AtomicTransaction, que vous trouverez dans les adaptateurs WCF tels que WCF-WsHttp, WCF-NetTcp et WCF-NetMsmq. Cette capacité est prise en charge dans les scénarios suivants :

• Envoi transactionnel de messages à la base de données MessageBox
• Transmission transactionnelle de messages à partir de la base de données MessageBox vers une destination transactionnelle

L'étendue transactionnelle est limitée par le composant MessageBox. Par exemple, une orchestration BizTalk ne peut pas participer à la transaction d'un client. De même, un point de terminaison de destination ne peut pas participer à une transaction initiée par une orchestration BizTalk.

L’extensibilité WCF est disponible via des liaisons personnalisées WCF. Vous devez compiler et ajouter du code personnalisé à Global Assembly Cache (GAC). Vous devez également mettre à jour le fichier machine.config pour inclure la nouvelle extension. Une fois la liaison installée, l’extension est visible pour les adaptateurs WCF-Custom et WCF-CustomIsolated.

BizTalk Server peut exposer les emplacements de réception WCF-BasicHTTP en tant que points de terminaison dans Azure API Management lorsque vous utilisez la console d’administration BizTalk. Vous pouvez également exposer vos points de terminaison SOAP via API Management à partir de BizTalk Server en utilisant API Management dans le portail Azure. Pour plus d’informations, consultez Publier des points de terminaison WCF-BasicHTTP BizTalk dans API Management.

Azure Logic Apps

Le modèle de connectivité dans Azure Logic Apps diffère de BizTalk Server, en partie en raison de l’évolution de l’économie des API. Comme de plus en plus d’organisations exposent l’accès aux systèmes et données sous-jacents, une approche indépendante de la plateforme était nécessaire. REST est maintenant l’approche architecturale privilégiée pour la conception de services web modernes.

Dans Azure Logic Apps, REST est l’approche par défaut pour connecter des systèmes. Comme Microsoft et d’autres éditeurs de logiciels exposent des services RESTful en plus de leurs systèmes et données, Azure Logic Apps peut exposer et consommer ce type d’informations. La spécification OpenAPI permet aux utilisateurs humains et aux ordinateurs de comprendre l’interaction entre un client et un serveur via des métadonnées. Dans le cadre de cette compréhension, les charges utiles de demande et de réponse sont dérivées, ce qui signifie que vous pouvez utiliser du contenu dynamique pour remplir les entrées d’une action de workflow et utiliser les sorties de la réponse dans les actions en aval.

En fonction du fournisseur de logiciels qui implémente le service sous-jacent appelé par un connecteur, les schémas d’authentification varient selon le connecteur. En général, ces schémas incluent les types suivants :

• De base
• Certificat client
• OAuth Active Directory
• Brut
• Identité gérée

Microsoft fournit de solides couches de protection en chiffrant les données pendant le transit et au repos. Chaque fois que le trafic du client Azure transite entre différents centres de données, en dehors des limites physiques non contrôlées par Microsoft ou pour le compte de Microsoft, une méthode de chiffrement de la couche de liaison de données utilisant les normes de sécurité MAC IEEE 802.1AE s’applique de point à point sur le matériel réseau sous-jacent.

Microsoft vous offre la possibilité d’utiliser le protocole TLS (Transport Layer Security) pour protéger les données qui transitent entre les services cloud et les clients. Les centres de données Microsoft négocient une connexion TLS avec les systèmes clients qui se connectent aux services Azure. TLS fournit une authentification forte, la confidentialité et l’intégrité des messages, qui permet la détection de falsification et l’interception des messages, ainsi que l’interopérabilité, la flexibilité des algorithmes, la facilité de déploiement et d’utilisation.

Bien que cette section se concentre sur la connectivité RESTful via des connecteurs, vous pouvez implémenter la connectivité du service web SOAP via l’expérience de connecteur personnalisé ou en utilisant l’expérience Gestion des API qui fournit de remarquables fonctionnalités SOAP. Pour plus d’informations, consultez Augmentation de la valeur métier en intégrant des ressources héritées SOAP à Azure Logic Apps et à Azure APIM (blog en anglais).

Utilisation de l’adaptateur de bloc ou du connecteur

Les sections suivantes décrivent les options permettant d’empêcher l’utilisation de l’adaptateur ou du connecteur respectivement dans BizTalk Server et dans Azure Logic Apps.

BizTalk Server

BizTalk Server n’inclut pas le concept de blocage d’adaptateurs spécifiques à partir de différentes applications, mais vous pouvez « bloquer » leur utilisation dans vos applications en supprimant ces adaptateurs de l’environnement. Les adaptateurs dans BizTalk Server faisant partie des paramètres de la plateforme, les adaptateurs installés sont donc disponibles pour tout le monde. Vous pouvez également définir des gestionnaires de réception et d’envoi spécifiques pour chaque adaptateur, ce qui définit les ordinateurs appartenant au groupe BizTalk et qui peuvent exécuter ou traiter ces gestionnaires.

Azure Logic Apps

Si votre organisation n’autorise pas la connexion à des ressources restreintes ou non approuvées à l’aide de connecteurs gérés dans Azure Logic Apps, vous pouvez bloquer la possibilité de créer et d’utiliser ces connexions dans vos workflows d’application logique. Azure Policy permet de définir et d’appliquer des stratégies qui empêchent la création ou l’utilisation de connexions pour les connecteurs à bloquer. Il peut par exemple être utile, pour des raisons de sécurité, de bloquer les connexions à certaines plateformes de réseaux sociaux ou à d’autres services et systèmes.

Durabilité des messages

La section suivante décrit la persistance des messages dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

La base de données MessageBox offre un autre avantage en agissant comme un point de persistance qui garantit qu’un message est conservé dans le stockage avant d’être envoyé si possible à un point de terminaison. Si le message ne parvient pas à être envoyé après l’épuisement des tentatives configurées, le message est suspendu et stocké dans MessageBox.

En tant qu’administrateur, vous pouvez reprendre les messages suspendus à partir de la console d’administration BizTalk. Le même comportement se produit lorsque vous utilisez des orchestrations. Le runtime d’orchestration conserve la logique métier, que vous pouvez reprendre en cas de problème. Par exemple, vous pouvez reprendre un message dans une orchestration dans les scénarios suivants :

• Message envoyé dans une étendue non atomique
• À la fin d'une étendue transactionnelle
• Au démarrage d’une nouvelle instance d’orchestration (forme Démarrer orchestration)
• Dans un point d’arrêt de débogage
• Quand le moteur décide de se mettre en attente
• Une fois l’orchestration terminée
• Quand le système s’arrête

BizTalk Server fournit toutes ces fonctionnalités prêtes à l’emploi. Vous n’avez pas à vous soucier de l’implémentation de la persistance, car BizTalk Server gère cet aspect pour vous.

Azure Logic Apps

Azure Logic Apps garantit la durabilité des messages comme suit :

• Les workflows avec état, qui sont la valeur par défaut dans les applications logiques Consommation et disponibles dans les applications logiques Standard, ont des points de contrôle qui suivent l’état du workflow et stockent les messages à mesure qu’ils passent par les actions de workflow. Cette fonctionnalité permet d’accéder aux données enrichies stockées dans l’historique des exécutions du déclencheur et de l’instance de workflow, où vous pouvez examiner les valeurs d’entrée et de sortie détaillées.

  Vous pouvez réexécuter une instance de flux de travail via le portail Azure ou une API. À ce stade, l’instance de flux de travail entière s’exécute, quel que soit l’endroit où une défaillance s’est produite lors de l’exécution précédente. Ce comportement implique que les messages sont remis au moins une fois et que le traitement idempotent se produit sur les consommateurs. Vous pouvez également réexécuter l’instance de flux de travail à partir d’une action spécifique, actuellement en préversion. Cette fonctionnalité est disponible pour toutes les actions, à l’exception des scénarios d’accès concurrentiel non séquentiels et complexes.

• Avec la messagerie peek-lock disponible dans Azure Service Bus, vous pouvez valider un message après une exécution réussie du message, ou abandonner le message en cas d’échec. Pour utiliser cette fonctionnalité dans Azure Logic Apps, sélectionnez le connecteur Azure Service Bus. Un message validé est supprimé de la file d’attente des messages, tandis qu’un message abandonné est déverrouillé et disponible pour traitement par les clients. Le mode peek-lock est un excellent moyen d’obtenir une messagerie de type « Une seule fois ».

Architecture publication-abonnement

Les sections suivantes décrivent les options permettant d’implémenter le modèle publication-abonnement dans BizTalk Server et dans Azure Logic Apps.

BizTalk Server

Les fonctionnalités publication-abonnement (pub-sub) existent via la base de données MessageBox, décrite plus haut dans la section Comment fonctionne BizTalk Server ?. Une méthode courante pour créer des abonnements consiste à utiliser des propriétés promues, qui vous permettent d’identifier des éléments ou des attributs spécifiques dans un schéma de message défini en tant que propriété promue. Vous pouvez ensuite établir des abonnements pour filtrer les messages en fonction de critères spécifiques par rapport à une propriété promue. Par exemple, si vous avez promu un élément de schéma nommé Ville, vous pouvez créer un abonnement qui filtre selon l’élément Ville pour des villes spécifiques. Si vos critères sont remplis, votre abonnement, un port d’envoi ou une orchestration reçoit une copie du message.

Azure Logic Apps

Avec une architecture complètement différente de BizTalk Server, la plupart des services d’Azure Integration Services sont basés sur des événements. Via Azure Service Bus, Azure Logic Apps prend en charge la création de solutions de publication-abonnement. Azure Service Bus est un répartiteur de messages d’entreprise complètement managé, avec des files d’attente de messages et des rubriques de publication-abonnement dans un espace de noms. Vous pouvez utiliser Azure Service Bus pour découpler les applications et les services les uns des autres, ce qui offre les avantages suivants :

• Travail d’équilibrage de charge entre les workers concurrents.
• Routage et transfert de façon sécurisée des données et du contrôle au-delà des limites des services et des applications.
• Travail transactionnel coordonné qui nécessite un degré élevé de fiabilité.

Azure Logic Apps inclut un connecteur Azure Service Bus que vous pouvez utiliser pour publier des messages et vous abonner à des messages. L’avantage est que vous pouvez utiliser la messagerie indépendamment de votre flux de travail. Contrairement à BizTalk Server, votre messagerie est dissociée de votre plateforme de workflow. Bien que les fonctionnalités de messagerie et de flux de travail soient découplées dans Azure Logic Apps, vous pouvez créer des abonnements aux messages dans Azure Service Bus, qui prend en charge les propriétés de message (propriétés utilisateur). Vous pouvez utiliser ces propriétés pour fournir des paires clé-valeur évaluées par des filtres créés sur un abonnement à une rubrique. Vous définissez ces propriétés utilisateur lorsque vous configurez une opération Azure Service Bus en ajoutant une ou plusieurs paires clé-valeur. Pour obtenir une démonstration, consultez la vidéo suivante : Pub Sub Messaging using Azure Integration Services - Part 2 Content Based Routing.

En dehors d’Azure Integration Services, vous pouvez également implémenter des scénarios de publication-abonnement à l’aide d’Azure Cache pour Redis.

Moteur des règles d’entreprise

La section suivante décrit les options de configuration des règles d’entreprise dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

BizTalk Server inclut un moteur de règles de chaînage avant qui vous permet de construire des règles « if-then-else » à l’aide d’un éditeur visuel. Vous pouvez regrouper ces règles dans une stratégie transportable vers d’autres environnements de votre paysage informatique. Ces stratégies peuvent également accéder aux schémas XSD, au code Fx .NET et aux tables de base de données SQL Server pour rechercher des données et enrichir les sorties.

Azure Logic Apps

Azure Logic Apps inclut le moteur de règles Azure Logic Apps, actuellement en préversion publique. Ce moteur de règles inclut le runtime du moteur de règles métier BizTalk (BRE) afin de pouvoir réutiliser des stratégies BizTalk BRE existantes. Actuellement, la prise en charge existe uniquement pour les faits XML et .NET Framework.

Transformation des données

Les sections suivantes décrivent les fonctionnalités de transformation des données dans BizTalk Server et dans Azure Logic Apps.

BizTalk Server

Fournit des outils complets pour transformer les messages XML d’un format à un autre. La transformation des données utilise des mappages XSLT, qui prennent en charge les objets d’extension qui permettent d’injecter du code .NET Fx personnalisé au milieu de ces mappages. Vous pouvez également utiliser des fonctoids prêtes à l’emploi qui fournissent des fonctionnalités réutilisables facilitant la création de mappages enrichis.

Au-delà des principales transformations XML, BizTalk Server fournit également l’encodage et le décodage pour les formats CSV et JSON, ce qui vous permet de convertir entre ces formats et XML et de prendre ainsi en charge différents formats.

Azure Logic Apps

• Enterprise Integration Pack

  Ce composant suit des concepts similaires dans BizTalk Server et facilite l’utilisation des fonctionnalités B2B dans Azure Logic Apps. Toutefois, l’une des principales différences réside dans le fait que l’Enterprise Integration Pack est basé sur l’architecture des comptes d’intégration. Ces comptes simplifient la façon dont vous stockez, gérez et utilisez des artefacts, tels que des partenaires commerciaux, des contrats, des mappages (modèles XSLT ou Liquid), des schémas et des certificats, pour les scénarios B2B.

• Modèles Liquid

  Pour les transformations de JSON de base dans des workflows d’application logique, vous pouvez utiliser des opérations de données intégrées, telles que les actions Composer ou Analyser JSON. Toutefois, certains scénarios peuvent nécessiter des transformations avancées et complexes incluant des éléments tels que des itérations, des flux de contrôle et des variables. Pour les transformations de JSON en JSON, de JSON en texte, de XML en JSON ou de XML en texte, vous pouvez créer un modèle Liquid décrivant le mappage ou la transformation requis à l’aide du langage de modèle open source Liquid.

• Opérations XML

  Pour les transformations XML dans les flux de travail d’application logique, vous pouvez utiliser des opérations XML intégrées, telles que les actions Composer XML avec schéma et Analyser XML avec schéma.

• Schémas EDI

  Les schémas de document EDI définissent le corps d'un type de document de transaction EDI. Pour vos workflows d’application logique, tous les schémas EDI BizTalk du référentiel Microsoft Integration GitHub sont accessibles au public.

• Applications logiques Standard

  Dans le portail Azure, vous pouvez charger des mappages et des schémas directement dans une ressource d’application logique Standard. Si vous utilisez un projet d’application logique Standard dans Visual Studio Code, vous pouvez charger ces artefacts dans leurs sous-dossiers respectifs dans le dossier Artifacts sans utiliser de compte d’intégration. Vous pouvez également appeler des assemblys compilés personnalisés à partir de mappages XSLT.

• Azure Functions

  Vous pouvez exécuter des transformations de modèle XSLT ou Liquid en utilisant C# ou tout autre langage de programmation pour créer une fonction Azure que vous pouvez appeler avec Gestion des API Azure ou Azure Logic Apps.

Connectivité réseau

La section suivante décrit les fonctionnalités et capacités de connectivité réseau dans BizTalk Server et Azure Integration Services.

BizTalk Server

Lorsque BizTalk Server est toujours installé dans un environnement serveur, la connectivité réseau dépend de la configuration réseau du serveur sous-jacent. Lorsque vous configurez la connectivité réseau pour BizTalk Server, vous devez généralement configurer les zones suivantes :

• Les dépendances
• Connectivité entrante et sortante aux systèmes finaux

Configuration des dépendances

Pour configurer entièrement BizTalk Server dans un environnement multiserveur, vous devez accorder une attention particulière à toutes les dépendances de connectivité réseau, ce qui implique généralement la configuration du pare-feu afin d’activer les ports TCP et UDP pour les services ou protocoles connus. Par exemple, ces services et protocoles incluent l’accès à un moteur SQL Server, Microsoft Distributed Transaction Coordinator (MSDTC), des lecteurs réseau en cluster, des services d’authentification unique en cas d’installation sur un autre serveur, et SharePoint. Tous ces services doivent être configurés en créant des règles de trafic entrant et sortant pour implémenter la connectivité.

Configuration de la connectivité entrante et sortante

Une fois que vous avez entièrement configuré BizTalk Server et que vous êtes prêt à déployer des applications, veillez à implémenter des règles de pare-feu permettant aux instances hôtes de se connecter et d’accéder à différents services, qu’elles fassent partie d’un réseau interne ou externe. Lorsque vous configurez la connectivité à des systèmes finaux en dehors du réseau de l’organisation, vous devez également inclure des considérations de sécurité. Différents systèmes s’appuient sur la définition d’une liste d’adresses IP autorisées comme première ligne de défense.Idéalement, BizTalk Server achemine donc toutes leurs communications sortantes via une liste bien définie d’adresses IP publiques.

Lorsque les services partenaires tentent de contacter BizTalk Server, assurez-vous qu’ils n’atteignent pas une instance située dans le réseau ou la couche interne de votre organisation où les principaux services d’organisation peuvent être disponibles. Donnez plutôt aux services partenaires l’accès à un point de terminaison qui existe au sein d’un réseau de périmètre, également appelé zone démilitarisée (DMZ), qui représente la limite maximale du réseau d’une organisation. Toutefois, les services vers lesquels BizTalk Server doit acheminer les messages existent généralement au sein du réseau de votre organisation. Ils doivent donc avoir accès à cette couche interne.

Pour réaliser ces scénarios, plusieurs approches existent, par exemple :

• Implémenter BizTalk Server dans un réseau de périmètre et autoriser uniquement ses propres services ou instances hôtes à accéder au réseau de votre organisation
• Configurer deux instances BizTalk Server, l’une dans un réseau de périmètre et l’autre dans le réseau de votre organisation. Le serveur dans le réseau de périmètre publie ensuite les messages que le serveur du réseau d’organisation consomme.
• Développer des applications personnalisées ou des logiciels d’appliance, tels que NetScaler et F5, qui peuvent faire office de proxys inverses, recevoir des messages pour le compte de BizTalk au sein du réseau de périmètre et rediriger ces appels vers BizTalk Server.

Azure Logic Apps

• Connectivité entrante et sortante

  Azure offre plusieurs façons d’isoler leurs services dans une limite réseau et de connecter des charges de travail locales et dans le cloud. La liste suivante décrit différentes façons d’intégrer des ressources Azure à des ressources à l’intérieur d’un réseau de périmètre :

  • Passerelle de données locale

    Cette passerelle sert de pont entre Azure et les ressources au sein d’un périmètre réseau, garantissant un transfert de données rapide et sécurisé entre des données locales et divers services cloud Microsoft. Ces services incluent Azure Logic Apps, Microsoft Power BI, Microsoft Power Apps, Microsoft Power Automate et Azure Analysis Services. Avec cette passerelle, vous pouvez conserver les bases de données et d’autres sources de données sur leurs réseaux locaux, tout en utilisant de façon sécurisée ces données locales dans des services cloud.

  • les connexions hybrides

    À la fois un service Azure et une fonctionnalité dans Azure App Service, les connexions hybrides prennent en charge des scénarios et offrent des fonctionnalités au-delà de celles utilisées dans Azure App Service. Pour plus d'informations sur l'utilisation en dehors d'Azure App Service, voir Connexions hybrides Azure Relay. Dans Azure App Service, vous pouvez utiliser des connexions hybrides pour accéder aux ressources d’application dans les réseaux qui peuvent effectuer des appels sortants vers Azure via le port 443. Les connexions hybrides permettent l’accès entre votre application et un point de terminaison TCP, et ne permettent pas d’accéder autrement à votre application. Dans Azure App Service, chaque connexion hybride correspond à une combinaison d’hôte et de port TCP unique. Cette fonctionnalité permet aux applications d’accéder à des ressources sur n’importe quel système d’exploitation, à condition qu’il existe un point de terminaison TCP. Les connexions hybrides ne connaissent pas ou ne se soucient pas du protocole d’application ou de ce à quoi vous souhaitez accéder. Cette fonctionnalité fournit simplement un accès réseau.

  • Intégration du réseau virtuel

    Avec l’intégration du réseau virtuel Azure, vous pouvez connecter votre ressource Azure à un réseau virtuel configuré dans Azure, ce qui donne à votre application l’accès aux ressources de ce réseau virtuel. L’intégration de réseau virtuel dans Azure Logic Apps est utilisée uniquement pour passer des appels sortants de votre ressource Azure vers votre réseau virtuel.

    Avec l’appairage de réseaux virtuels, vous pouvez connecter vos réseaux locaux à Azure et bénéficier ainsi d’une connectivité bidirectionnelle entre les ressources locales et les services Azure. Azure Integration Services fournit une connectivité de réseau virtuel, ce qui permet une intégration hybride. L’image suivante montre une ressource d’application logique Standard avec la page Mise en réseau ouverte et l’intégration de réseau virtuel activée, comme indiqué dans la zone Trafic sortant. Cette configuration garantit que tout le trafic sortant quitte ce réseau virtuel.

    

  • Points de terminaison privés

    Un point de terminaison privé est une interface réseau qui utilise une adresse IP privée de votre réseau virtuel. Cette interface réseau se connecte de manière privée et sécurisée à une ressource Azure fonctionnant avec Azure Private Link. En activant un point de terminaison privé, vous intégrez cette ressource Azure à votre réseau virtuel et autorisez les ressources du réseau à passer des appels entrants vers votre ressource Azure.

Le tableau suivant présente les méthodes de connectivité réseau que chaque ressource Azure Integration Services peut utiliser :

Ressource	Passerelle de données locale	les connexions hybrides	Intégration du réseau virtuel	Instances Private Endpoint
Gestion des API Azure	✅		✅	✅
Azure Logic Apps (Consommation)	✅
Azure Logic Apps (Standard)	✅ (avec connecteurs Azure)	✅ (avec connecteurs intégrés)	✅ (avec connecteurs intégrés)	✅
Azure Service Bus			✅	✅
Azure Event Grid

Code personnalisé

Les sections suivantes décrivent les options de création et d’exécution de votre propre code dans BizTalk Server et dans Azure Logic Apps.

BizTalk Server

Vous pouvez étendre BizTalk de plusieurs façons à l’aide d’un code .NET Fx personnalisé, par exemple :

Fonctionnalité	Description
Code en ligne	Vous pouvez écrire du code C# inline dans une forme Orchestration. Vous pouvez également écrire du code inline dans un mappage BizTalk. Dans les deux scénarios, les extraits de code sont généralement simples par nature et ne peuvent pas être débogués.
Assemblys compilés	Vous pouvez appeler ces assemblys depuis les emplacements suivants : - Formes d’expression dans une orchestration - Mappages BizTalk à l’aide du fonctoid Script - Stratégies du moteur de règles métier - Pipelines en tant que composants de pipeline personnalisés Vous pouvez déboguer des assemblys compilés en attachant le débogueur Visual Studio au processus Windows de l’instance d’hôte approprié.
Adaptateurs personnalisés	BizTalk Server inclut de nombreux adaptateurs prêts à l’emploi, mais vous pouvez toujours créer votre propre adaptateur si nécessaire.
Comportements WCF personnalisés	BizTalk Server inclut de nombreux adaptateurs prêts à l’emploi dont la majorité repose sur Windows Communication Foundation (WCF). Dans certains cas, vous devrez peut-être étendre leurs fonctionnalités en développant des comportements personnalisés, notamment l’application d’un en-tête OAuth à votre communication système.
Extensibilité dans les mappages BizTalk Server	- Vous pouvez créer du code inline à l’aide des modèles d’appel C#, JScript, Visual Basic, XSLT ou XSLT pour supprimer certaines limitations ou difficultés à utiliser les fonctoids prêts à l’emploi. - Vous pouvez appeler un assembly externe à l’aide du fonctoid Script. - Vous pouvez créer des fonctoids personnalisés à utiliser sur tous vos mappages.

Azure Logic Apps

Azure Logic Apps vous permet de créer et d’exécuter du code .NET à partir de votre flux de travail d’application logique Standard. Pour ce faire, vous devez utiliser Visual Studio Code avec l’extension Azure Logic Apps (Standard).

De plus, le connecteur Opérations de code inlined fournit les actions nommées Exécuter du code JavaScript, Exécuter le code de script CSharp (préversion) et Exécuter le code PowerShell (préversion). Vous pouvez utiliser ces actions pour écrire de petits extraits de code, qui prennent en charge les entrées et sorties de contenu dynamique. Le moteur Azure Logic Apps prévoit des temps d’exécution courts pour ces extraits de code. Une fois que l’exécution d’un extrait de code est terminée, la sortie peut être utilisée par des actions en aval dans le flux de travail. Bien qu’il n’existe actuellement aucune prise en charge directe du débogage pour cette action, vous pouvez afficher les entrées et les sorties dans l’historique des exécutions de l’instance du workflow.

Comme mentionné dans la section Composants réutilisables, la prise en charge de l’appel d’assemblys .NET Fx à partir d’un mappage XSLT est actuellement disponible dans les workflows d’application logique Consommation lorsque vous chargez ces assemblys dans un compte d’intégration. Cette capacité permet de prendre en charge les règles de transformation de données personnalisées. Pour les workflows d’application logique Standard, l’équipe Azure Logic Apps a récemment publié la prise en charge de l’appel de code .NET Fx à partir de mappages XSLT sans nécessiter de compte d’intégration. Vous pouvez également ajouter des assemblys et des mappages à un projet d’application logique Standard dans Visual Studio Code, puis les déployer sur Azure. Pour plus d’informations, consultez Prise en charge des assemblys .NET Framework ajoutée aux transformations XSLT Azure Logic Apps (Standard) et la section Feuille de route.

Vous pouvez également étendre les workflows en incluant des applications API Azure ou des applications web créées avec Azure App Service. Lorsque vous avez besoin d’héberger des applications web, des API REST et des back-ends mobiles, Azure App Service est la solution HTTP « idéale ». Vous pouvez intégrer des applications hébergées dans Azure App Service avec des services locaux ou cloud. Cette plateforme prend en charge les environnements Windows et Linux pour exécuter et mettre à l’échelle des applications, ainsi que divers langages et infrastructures, par exemple ASP.NET Core, Java, Ruby, Node.js, PHP et Python.

Groupes d’applications

Les sections suivantes décrivent les options d’organisation de vos charges de travail dans BizTalk Server et dans Azure Logic Apps.

BizTalk Server

Une partie de votre cycle de vie de développement logiciel comprend la création et la gestion de votre code et de vos artefacts dans des packages logiques. BizTalk Server prend en charge le concept d’application de sorte que vous puissiez déployer une solution Visual Studio dans une application BizTalk. Ainsi, si vous avez des scénarios de partage des ressources, vous pouvez référencer d’autres applications.

BizTalk Server utilise un modèle de partage explicite dans lequel vous pouvez ajouter des références à des assemblys compilés. Si ces assemblys se trouvent dans Global Assembly Cache (GAC), le runtime BizTalk recherche et charge les assemblys selon les besoins. Cette approche présente un inconvénient : lorsque vous devez mettre à jour les assemblys partagés, sauf si vous implémentez un schéma de contrôle de version, vous devez désinstaller tous les projets BizTalk qui référencent vos assemblys avant d’effectuer votre mise à jour. Cette limitation peut entraîner des délais de déploiement longs et une complexité dans la gestion de plusieurs installations et désinstallations.

Azure Logic Apps

Dans Azure Logic Apps, la ressource d’application logique Consommation inclut un seul workflow avec état, ce qui signifie que votre workflow et votre ressource d’application logique, qui représente votre application, affichent toujours une relation de type 1 à 1. Avec la ressource d’application logique Standard, le concept d’application a évolué. Même si votre ressource d’application logique Standard reste votre application, vous pouvez inclure et exécuter plusieurs workflows avec cette ressource, ce qui aboutit à une relation de type un-à-plusieurs. Si vous travaillez localement sur un projet d’application logique Standard dans Visual Studio Code, votre ressource d’application logique est mappée à ce projet unique. Avec cette approche, vous pouvez facilement et logiquement regrouper les charges de travail, le code et les artefacts associés dans le même projet et déployer ce projet comme une seule unité.

Les architectures cloud fonctionnent différemment des paradigmes basés sur le serveur tels que BizTalk. Azure Logic Apps (Standard) utilise un modèle d’extraction pour importer du code et des artefacts. Vous allez donc copier tous les artefacts supplémentaires nécessaires dans votre projet, puis les déployer avec votre code et d’autres artefacts. Dans certains cas, vous pouvez éviter d’avoir à copier tout le code et les artefacts nécessaires. Dans ce cas, vous pouvez transformer cette fonctionnalité en un service gérable séparément, mais que vous pouvez appeler à partir d’un workflow.

Par exemple, supposons que vous ayez une transformation de données largement utilisée par votre organisation. Au lieu d’inclure le mappage de la transformation dans plusieurs projets d’application logique, vous pouvez implémenter une interface qui fournit la transformation en tant que service. Vous pouvez ensuite gérer le cycle de vie de ce service séparément de vos projets d’application logique et appeler ce service à partir de vos workflows.

Avec la possibilité d’inclure plusieurs workflows dans un projet d’application logique Standard, vous vous demandez peut-être comment organiser ces workflows au sein d’un projet ou entre plusieurs projets ? La réponse dépend généralement de vos besoins, par exemple :

• Affinité de processus métier
• Supervision et support de bout en bout
• Sécurité, contrôle d’accès en fonction du rôle et isolement réseau
• Performances et caractère critique pour l’entreprise
• Géolocalisation et géoredondance

Pour plus d’informations, consultez Organisation des workflows d’applications logiques dans Azure Logic Apps (Standard).

Sécurité et gouvernance

La sécurité et la gouvernance sont naturellement importantes lors de la création de solutions intégrées. Par définition, l’intergiciel se place entre deux systèmes ou plus. Pour vous connecter à ces systèmes et y accéder lors de l’établissement d’une connexion, vous devez souvent transmettre des informations d’identification ou des secrets. La gestion de ces informations sensibles doit donc être prise en compte.

BizTalk Server

BizTalk inclut la fonctionnalité Authentification unique de l'entreprise (SSO) qui vous permet de stocker, de mapper et de transmettre les informations d’identification chiffrées utilisées par les adaptateurs. Ces informations chiffrées sont stockées dans la base de données SSO. Vous pouvez également configurer des applications associées SSO, qui sont des entités logiques représentant un système ou un système métier que vous souhaitez connecter.

Azure Logic Apps

Azure Logic Apps prend en charge les fonctionnalités de sécurité suivantes :

• Azure Key Vault

  Vous pouvez stocker des informations d’identification, des secrets, des clés API et des certificats à l’aide d’Azure Key Vault. Dans Azure Logic Apps, vous pouvez accéder à ces informations à l’aide du connecteur Azure Key Vault et exclure ces informations à partir des journaux de la plateforme et de l’historique des exécutions à l’aide de la fonctionnalité d’entrées et de sorties sécurisées.

  Plus loin dans la section Suivi, ce guide décrit la fonctionnalité d’historique des exécutions, qui décrit la réexécution pas à pas d’un workflow. Bien qu’Azure Logic Apps offre la proposition de valeur permettant de capturer chaque entrée et sortie dans une exécution de workflow, vous devez parfois gérer l’accès aux données sensibles de manière plus granulaire. Vous pouvez configurer le codage de ces données à l’aide de la fonctionnalité d’entrées et de sorties sécurisées sur les déclencheurs et les actions pour masquer ce contenu de l’historique des exécutions et empêcher l’envoi de ces données à Azure Monitor, en particulier Log Analytics et Application Insights. L’image suivante montre un exemple de résultat de l’activation d’entrées et de sorties sécurisées dans l’historique des exécutions.

  

• Intégration basée sur OAuth

  La plupart des connecteurs utilisent ce type d’authentification lors de la création de connexions. Cette approche facilite l’intégration à de nombreux services SaaS en fournissant votre adresse e-mail et votre mot de passe. Azure API Management prend également en charge OAuth, et vous pouvez donc utiliser les deux services ensemble en fournissant un schéma d’authentification unifié.

  Cette fonctionnalité n’est pas disponible en mode natif dans BizTalk Server.

• Identités managées

  Azure Logic Apps (Standard) peut authentifier l’accès aux comptes de stockage à l’aide d’une identité managée. De plus, certains connecteurs prennent en charge l’utilisation d’identités managées pour authentifier l’accès aux ressources protégées par Microsoft Entra ID. Quand vous utilisez une identité managée pour authentifier votre connexion, vous n’avez pas besoin de fournir d’informations d’identification, de secrets ni de jetons Microsoft Entra.

Gestion des applications et de l’accès

La section suivante décrit les options de gestion des applications et de l’accès dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

Les administrateurs utilisent la console Administrateur BizTalk Server pour gérer les applications BizTalk Server. Cet outil est une application cliente lourde Microsoft Management Console (MMC) que les administrateurs peuvent utiliser pour déployer des applications, passer en revue les transactions précédentes, actives et mises en file d’attente, et effectuer des activités de dépannage approfondies comme examiner des traces et renvoyer des transactions.

Azure Logic Apps

Le portail Azure est un outil courant que les administrateurs et le personnel de support utilisent pour afficher et surveiller l’intégrité des interfaces. Pour Azure Logic Apps, cette expérience inclut des traces de transactions enrichies disponibles via l’historique des exécutions.

Des contrôles d’accès en fonction du rôle (RBAC) granulaires sont également disponibles pour vous permettre de gérer et de restreindre l’accès aux ressources Azure à différents niveaux.

Stockage

La section suivante décrit les options de stockage de données dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

BizTalk Server s’appuie en grande partie sur SQL Server pour le magasin de données et la persistance des données. Tous les autres composants et hôtes de BizTalk Server ont des rôles spécifiques dans l'intégration d'applications commerciales disparates, notamment la réception, le traitement ou le routage de messages. Toutefois, l’ordinateur de base de données capture et conserve ce travail sur le disque. Par exemple, lorsque BizTalk Server reçoit un message entrant, l'hôte de réception stocke ce message dans la base de données MessageBox avant que d'autres hôtes le récupèrent pour le faire passer dans un processus d'orchestration avant de l'envoyer.

Comme vous êtes responsable de l’approvisionnement et de la gestion de vos bases de données SQL, la haute disponibilité est un composant architectural important pour garantir leur disponibilité. Pour fournir une haute disponibilité aux bases de données BizTalk Server, les clients utilisent souvent le clustering Windows afin de créer un cluster de serveurs avec au moins deux ordinateurs exécutant SQL Server. Ce cluster de serveurs fournit la redondance et la tolérance aux pannes pour les bases de données BizTalk Server. Dans un cluster à équilibrage de charge, un groupe d’ordinateurs fonctionnent ensemble dans le but d'augmenter la disponibilité et l'évolutivité de l'installation. En revanche, dans un cluster de serveurs, deux ordinateurs dédiés aux bases de données sont configurés sur un modèle actif/passif où l'une des machines fournit les ressources de sauvegarde à l'autre.

Azure Logic Apps

Azure Logic Apps s’appuie sur le Stockage Azure pour stocker et chiffrer automatiquement les données au repos. Ce chiffrement protège vos données et vous aide à répondre aux engagements de votre entreprise en matière de sécurité et de conformité. Par défaut, Stockage Azure utilise des clés managées par Microsoft pour chiffrer vos données. Pour plus d'informations, consultez Fonctionnalité de chiffrement du service Stockage Azure pour les données au repos.

Si vous utilisez le stockage Azure via le portail Azure, toutes les transactions se produisent via HTTPS. Vous pouvez également utiliser le stockage Azure avec l’API REST de stockage sur HTTPS. Pour appliquer l’utilisation du protocole HTTPS quand vous appelez les API REST afin d’accéder aux objets dans les comptes de stockage, activez le transfert sécurisé requis pour le compte de stockage.

Configuration des données

La séparation entre la configuration et le code devient importante lorsque vous souhaitez déplacer vos solutions d’intégration entre des environnements sans avoir à recompiler ou à réassembler votre code. Les informations de configuration sont généralement spécifiques à l’environnement. Vous pouvez donc définir des points de terminaison et d’autres détails qui doivent être modifiés à mesure que vous déployez des solutions dans votre paysage.

BizTalk Server

• Exécutable du service BizTalk NT

  Ce fichier exécutable appelle un fichier app.config nommé BTSNTSvc.exe.config. Ce fichier fournit des paires clé-valeur pour vous permettre de stocker des informations de configuration en texte clair. Mais tenez compte des considérations suivantes lorsque vous utilisez ce fichier :

  • Veillez à répliquer soigneusement la configuration sur tous les ordinateurs d’un groupe BizTalk.

  • Les modifications de configuration nécessitent le redémarrage des instances d’hôte pour récupérer les valeurs les plus récentes dans ce fichier de configuration.

  • Toutes les erreurs de syntaxe introduites dans ce fichier de configuration empêchent le démarrage des instances d’hôte et entraînent un temps d’arrêt.

• Outil Microsoft Enterprise Single Sign-On

  Vous pouvez également utiliser cet outil comme magasin de configuration. Des outils communautaires sont également disponibles pour activer la gestion des données à l’aide de l’authentification unique d’entreprise. Vous pouvez ensuite accéder à ces données via des outils sdk pour récupérer ces données lors de l’exécution.

• Composants de cache personnalisés

  Ces composants sont souvent introduits pour vous permettre de traiter des cas d’usage au-delà des paires clé-valeur. Par exemple, supposons que vous souhaitiez stocker des données tabulaires dans une base de données SQL Server et charger ces données en mémoire au démarrage d’une instance d’hôte. Cette implémentation permet à BizTalk Server d’obtenir ces informations lors de l’exécution à l’aide d’un code .NET Fx personnalisé. Vous pouvez ensuite accéder à ces données à partir d’orchestrations, de mappages BizTalk et de composants de pipeline personnalisés.

• Base de données personnalisée

  Les bases de données étant une technologie et un langage bien connus pour les développeurs et les administrateurs, une base de données personnalisée est une autre option courante pour stocker les données de configuration d’application.

• Moteur des règles d'entreprise BRE (Business Rules Engine)

  Bien qu’il ne s’agisse pas d’un cas d’usage principal, BRE peut également servir de magasin de configuration. Que vous appeliez le moteur à partir d’un composant d’orchestration ou de pipeline, vous pouvez définir des informations spécifiques à l’environnement dans les stratégies BRE, puis déployer la stratégie correspondante dans l’environnement approprié. Lors de l’exécution, un composant d’orchestration ou de pipeline peut accéder à ces informations et les utiliser dans des fonctions en aval telles que des mappages ou des situations de routage.

• Fichier de configuration personnalisé

  Vous pouvez utiliser des fichiers de configuration personnalisés (.config) pour stocker des données de configuration d’application, mais cette approche n’est pas courante, car vous devez probablement conserver un emplacement statique et fixe pour ces fichiers dans tous les environnements.

• Registre Windows

  Vous pouvez utiliser le registre Windows comme option valide pour stocker les valeurs de configuration de l’application. Ce registre est une base de données hiérarchique centrale utilisée par les systèmes d’exploitation Windows de Microsoft pour stocker les informations nécessaires à la configuration du système pour un ou plusieurs utilisateurs, applications et périphériques matériels. Le registre contient les éléments de base suivants : ruches, clés et valeurs. Mais la gestion des valeurs stockées dans le registre peut s’avérer complexe dans les environnements volumineux avec plusieurs registres et la difficulté de sauvegarder des paramètres d’application individuels.

Azure Logic Apps

• Azure Key Vault

  Ce service stocke et protège les clés de chiffrement et autres secrets utilisés par les applications et les services cloud. Comme la gestion sécurisée des clés est essentielle pour protéger les données dans le cloud, utilisez Azure Key Vault pour chiffrer et stocker des clés et des secrets, par exemple des mots de passe.

• Azure App Configuration

  Ce service gère de manière centralisée les paramètres d’application et les indicateurs de fonctionnalité. Vous pouvez stocker les configurations de toutes vos applications Azure dans un emplacement universel et hébergé. Gérez les configurations de manière efficace et fiable en temps réel et sans affecter les clients tout en évitant les redéploiements chronophages. Azure App Configuration est conçu pour la vitesse, la scalabilité et la sécurité.

• Azure Cosmos DB

  Ce service est une base de données NoSQL entièrement managée pour le développement d’applications modernes, avec des temps de réponse en millisecondes à un chiffre, ainsi qu’une extensibilité automatique et instantanée qui garantissent la vitesse à n’importe quelle échelle. Vous pouvez charger des données de configuration dans Azure Cosmos DB, puis y accéder à l’aide du connecteur Azure Cosmos DB dans Azure Logic Apps.

• Stockage de table Azure

  Ce service fournit une autre installation de stockage pour conserver les données de configuration à moindre coût. Vous pouvez facilement accéder à ces données à l’aide du connecteur Stockage Table Azure dans Azure Logic Apps. Pour plus d’informations, consultez Stockage Table Azure.

• Mise en cache personnalisée

  Vous pouvez également implémenter des solutions de mise en cache personnalisées avec Azure Integration Services. Les approches courantes incluent l’utilisation de stratégies de mise en cache dans Azure Gestion des API et dans Azure Cache pour Redis.

• Base de données personnalisée

  Les bases de données étant une technologie et un langage bien connus pour les développeurs et les administrateurs, une base de données personnalisée est une autre option courante pour stocker les données de configuration d’application.

Traitement des fichiers volumineux

La section suivante décrit les options de gestion de fichiers volumineux dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

Pour traiter les fichiers volumineux, BizTalk Server inclut des optimisations basées sur les profils suivants :

• Routage des messages uniquement

  Si vous utilisez BizTalk Server uniquement pour le routage des messages en fonction des propriétés de message promues, les messages sont diffusés en continu vers la base de données MessageBox à l’aide de l’interface XmlReader .NET. BizTalk Server ne charge pas de parties de message individuelles en mémoire. Dans ce scénario, les erreurs de mémoire insuffisante ne sont donc pas un problème. Cependant, la principale considération reste le temps nécessaire à l'écriture de messages très volumineux (plus de 100 Mo) dans la base de données MessageBox. L'équipe de développement de BizTalk Server a testé avec succès le traitement des messages d'une taille allant jusqu'à 1 Go pour le routage seul. Pour plus d’informations, consultez Optimisation des performances du pipeline.

• Transformation des données avec des mappages

  Lorsque BizTalk Server transforme un document à l’aide d’un mappage, cette opération nécessitant potentiellement beaucoup de mémoire transmet le message à la classe .NET XslCompiledTransform, qui charge la feuille de style XSL. Une fois l’opération de chargement terminée, plusieurs threads peuvent appeler simultanément la méthode Transform. Pour plus d'informations, consultez Classe XslCompiledTransform.

  BizTalk Server améliore considérablement la gestion de mémoire des documents volumineux en implémentant un seuil de taille de message configurable pour le chargement de documents en mémoire au cours de la transformation. Par défaut, le seuil de taille de message est de 1 Mo. Pour tout message dont la taille est inférieure à ce seuil, BizTalk Server gère le message en mémoire. Pour réduire les besoins en mémoire pour tout message dont la taille est supérieure à ce seuil, BizTalk Server place le message en mémoire tampon dans le système de fichiers.

Azure Logic Apps

Il existe des différences fondamentales entre le traitement de fichiers volumineux avec une plateforme intergiciel locale telle que BizTalk Server et une offre PaaS comme Azure Logic Apps. Par exemple, examinez attentivement les scénarios de messages volumineux pour trouver la bonne solution, car il existe potentiellement différentes façons de résoudre ce problème dans un environnement cloud moderne.

Limites de taille de fichiers

Dans Azure, des limites de taille de fichier existent pour garantir des expériences cohérentes et fiables. Pour valider votre scénario, veillez à consulter la documentation relative aux limites de service pour Azure Logic Apps. Certains connecteurs prennent en charge la segmentation des messages pour les messages qui dépassent la limite de taille de message par défaut, qui varie en fonction du connecteur. La segmentation des messages fonctionne en fractionnant un message volumineux en messages plus petits.

Azure Logic Apps n’est pas le seul service à imposer des limites de taille de message. Par exemple, Azure Service Bus comporte également de telles limites. Pour plus d’informations sur la gestion des messages volumineux dans Azure Service Bus, consultez Prise en charge des messages volumineux.

Modèle de réclamation-vérification

Pour éviter les limitations de taille de fichier, vous pouvez implémenter le modèle réclamation-vérification, qui fonctionne en fractionnant un message volumineux en une vérification de revendication et une charge utile. Vous envoyez la vérification des revendications à la plate-forme de messagerie et stockez la charge utile sur un service externe. De cette façon, vous pouvez traiter des messages volumineux, tout en protégeant le bus de messages et le client contre la surcharge. Ce modèle permet également de réduire les coûts, car le stockage est généralement moins cher que les unités de ressources utilisées par la plate-forme de messagerie.

Azure Data Factory

Azure Data Factory offre une autre option pour la gestion des fichiers volumineux. Ce service est l’offre ELT d’Azure pour l’intégration et la transformation des données serverless évolutives avec une expérience visuelle sans code pour la création intuitive ainsi que la surveillance et la gestion dans un volet unique. Vous pouvez également effectuer un lift-and-shift de packages SQL Server Integration Services (SSIS) existants vers Azure et les exécuter avec une compatibilité complète dans Azure Data Factory. SSIS Integration Runtime offre un service complètement managé, ce qui vous évite de vous soucier de la gestion de l’infrastructure. Pour plus d’informations, consultez Effectuer un « lift-and-shift » des charges de travail SQL Server Integration Services vers le cloud.

Dans les architectures locales, SSIS était une option populaire pour gérer le chargement de fichiers volumineux dans des bases de données. En tant qu’équivalent cloud de cette architecture, Azure Data Factory peut traiter la transformation et le déplacement de jeux de données volumineux entre différentes sources de données, notamment les systèmes de fichiers, les bases de données, SAP, Stockage Blob Azure, Azure Data Explorer, Oracle, DB2, Amazon RDS, etc. Lorsque vous avez des exigences importantes en matière de traitement des données, Azure Data Factory constitue une meilleure solution par rapport à Azure Logic Apps et à Azure Service Bus.

Supervision et alertes

BizTalk Server

• BizTalk Health Monitor

  Cet outil est un composant logiciel enfichable MMC que vous pouvez utiliser pour surveiller l’intégrité de vos environnements BizTalk Server et effectuer des tâches de maintenance. Les fonctionnalités incluent les rapports MsgBox Viewer (MBV), les tâches de l’outil Terminator, les notifications par e-mail, la collecte de rapports et l’intégration perfmon.

• Console Administration de BizTalk

  Cet outil est également un composant logiciel enfichable MMC permettant aux administrateurs de détecter les échecs, les instances suspendues, les transactions relancées, l’état, etc. L’expérience de cet outil est très réactive par nature, car vous devez constamment actualiser la console pour passer en revue les dernières informations.

• BizTalk360

  Solution web externe qui offre un contrôle total sur votre environnement BizTalk Server. Cet outil unique offre des fonctionnalités d’opérations, de surveillance et d’analyse pour BizTalk Server.

Azure Logic Apps

Dans Azure Logic Apps, les options suivantes sont disponibles :

• Pour les workflows d’application logique Consommation, vous pouvez installer la solution de gestion Logic Apps (préversion) dans le portail Azure et configurer les journaux Azure Monitor pour collecter des données de diagnostic. Une fois que vous avez configuré votre application logique pour envoyer ces données à un espace de travail Azure Log Analytics, les données de télémétrie sont transmises à l’emplacement où la solution de gestion Logic Apps peut fournir des visualisations d’intégrité. Pour plus d'informations, consultez Configurer les journaux d'activité Azure Monitor et collecter des données de diagnostic pour Azure Logic Apps. Les diagnostics vous permettent également d’utiliser Azure Monitor pour envoyer des alertes basées sur différents types de signal, par exemple en cas d’échec d’un déclencheur ou d’une exécution. Pour plus d’informations, consultez Surveiller l’état d’exécution, vérifier l’historique du déclencheur et configurer des alertes pour Azure Logic Apps.

• Pour les flux de travail d’application logique Standard, vous pouvez activer la prise en charge d’Application Insights, qui fournit des visualisations organisées comme base pour la surveillance des services Azure. Ces visualisations vous aident à surveiller plus efficacement les flux de travail Standard à l’aide de tableaux de bord spécifiquement conçus pour Azure Logic Apps (Standard). L’étendue du tableau de bord couvre les flux de travail à l’intérieur d’une application logique Standard. Le tableau de bord repose sur des classeurs Azure et offre différentes visualisations. Vous pouvez facilement étendre et personnaliser ces classeurs pour répondre à des besoins spécifiques.

Serverless 360 est une solution externe de Kovai qui fournit la surveillance et la gestion via le mappage des services Azure comme Azure Logic Apps, Azure Service Bus, Azure API Management et Azure Functions. Vous pouvez retraiter les messages à l’aide de files d’attente de lettres mortes dans Azure Service Bus, activer la réparation automatique pour résoudre les interruptions de service intermittentes et configurer une surveillance proactive par le biais de transactions synthétiques.

Vous pouvez configurer des règles de surveillance personnalisées et afficher les journaux dans une expérience de portail. Vous pouvez envoyer des notifications via différents canaux, notamment par e-mail, Microsoft Teams et ServiceNow. Pour déterminer visuellement l’intégrité de vos interfaces, des mappages de service sont disponibles.

Business Activity Monitoring

La section suivante décrit les options permettant de surveiller et de collecter des données de télémétrie pour les charges de travail dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

BizTalk Server inclut une fonctionnalité appelée Business Activity Monitoring (BAM) qui permet aux développeurs et aux analystes métier de définir des profils de suivi à appliquer aux orchestrations. Lorsque les messages transitent par les ports de réception et d’envoi, les attributs de données sont capturés et stockés dans une base de données BAM. Une implémentation personnalisée est également disponible via une API Fx .NET.

Azure Logic Apps

En tant que développeur ou analyste métier travaillant sur des solutions qui intègrent des services et des systèmes basés sur diverses ressources Azure, vous pouvez avoir des difficultés à visualiser la relation entre les composants techniques de votre solution et votre scénario métier. Pour inclure le contexte métier des ressources Azure dans votre solution, vous pouvez créer des processus métier qui représentent visuellement la logique métier implémentée par ces ressources. Dans Azure Business Process Tracking, un processus métier est une série de phases qui représentent les tâches se déroulant tout au long d’un scénario métier réel.

Vous pouvez également utiliser une solution externe de Kovai appelée Serverless 360. En plus de la plateforme de surveillance, vous pouvez utiliser la fonctionnalité de surveillance de l’activité métier qui fournit un suivi de bout en bout pour les flux de processus métier dans des intégrations natives cloud et hybrides. Cette fonctionnalité inclut un connecteur managé que les développeurs peuvent utiliser pour instrumenter le code et capturer des données métier importantes. Les administrateurs peuvent ensuite créer des tableaux de bord et les partager avec des analystes métier.

Suivi

La section suivante décrit les options permettant de suivre les artefacts pour l’analyse des performances et l’analyse de l’intégrité dans BizTalk Server et dans Azure Integration Services.

BizTalk Server

• Suivi des messages

  Les administrateurs BizTalk Server peuvent utiliser le suivi des corps de messages pour indiquer quand conserver les corps de messages dans le stockage à des fins de résolution des problèmes et d’audit. Le suivi du message étant une opération coûteuse du point de vue des performances et du stockage, utilisez cette fonctionnalité de manière sélective pour éviter les problèmes de performances. Lorsque vous activez le suivi des corps de messages sur les ports de réception et d’envoi, BizTalk Server copie les données dans la base de données de suivi BizTalk (BizTalkDTADb) à l’aide de la tâche SQL Server Agent nommée TrackedMessages_Copy_<message-box-name>.

  

  Vous pouvez appliquer le suivi à presque tous les artefacts BizTalk Server, y compris les orchestrations, les pipelines, les ports de réception, les ports d’envoi, les schémas et les règles d’entreprise. Ces options sont activées ou désactivées lors de l’exécution, sans affecter votre code (solution) ou nécessiter un redémarrage.

• Suivi des activités et du fonctionnement (HAT)

  Bien que l’outil HAT ait été supprimé de BizTalk Server à partir de l’édition 2009, la fonctionnalité existe toujours dans la console d’administration BizTalk. Les administrateurs peuvent rechercher des données via l’interface Nouvelle requête dans l’expérience Vue d’ensemble du groupe. Vous pouvez personnaliser les requêtes en fonction de différents critères, notamment le type d’événement, le nom de port, l’URI, le nom du schéma, etc. Si vous souhaitez passer en revue les corps de messages qui ont transité par un port de réception ou d’envoi, vous pouvez accéder à ces informations à condition d’activer le suivi au niveau du port. Pour plus d’informations, consultez Suivi des activités et du fonctionnement.

• Intégration à Application Insights et à Azure Event Hubs

  Depuis BizTalk Server 2016 Feature Pack 1, vous pouvez publier des données de télémétrie sur Application Insights dans Azure Monitor ou dans Azure Event Hubs. Cette approche évite les problèmes de capacité de disque SQL Server, ce qui vous permet d’utiliser à la place des magasins de données élastiques basés sur le cloud, notamment Application Insights, Log Analytics et l’historique des exécutions dans Azure Logic Apps.

Azure Logic Apps

Azure Logic Apps fournit également un historique complet des exécutions afin que les développeurs et les analystes de support puissent passer en revue les données de télémétrie action par action, y compris toutes les entrées et sorties traitées. Pour protéger les données sensibles, vous pouvez activer des entrées et des sorties sécurisées sur des actions individuelles dans les workflows. Cette fonctionnalité code ou masque les données dans les journaux et l’historique des exécutions de workflow pour éviter les fuites.

Au-delà du codage des données, vous pouvez utiliser des règles RBAC Azure pour protéger l’accès aux données. Azure RBAC inclut des rôles intégrés spécifiques pour Azure Logic Apps (Standard).

Outre Azure RBAC, vous pouvez également restreindre l’accès à l’historique des exécutions dans Azure Logic Apps par plage d’adresses IP.

Hébergement

La section suivante décrit les options d’hébergement pour BizTalk Server et Azure Integration Services.

BizTalk Server

BizTalk Server 2020 prend en charge les plateformes et produits Microsoft suivants, à partir de la mise à jour cumulative 6 :

• Windows Server 2022, Windows Server 2019 et Windows 11
• Visual Studio 2019 Enterprise et Visual Studio 2019 Professional
• SQL Server 2022, SQL Server 2019
• Office 2019 et Office 2016

Vous pouvez installer et exécuter BizTalk Server sur votre propre matériel, une machine virtuelle locale ou des machines virtuelles Azure. Les machines virtuelles Azure vous permettent d’utiliser la virtualisation pour un large éventail de solutions informatiques en prenant en charge BizTalk Server, Windows Server, SQL Server, entre autres. Toutes les machines virtuelles de génération actuelle incluent gratuitement l’équilibrage de charge et la mise à l’échelle automatique.

Azure Logic Apps

• Plans d’hébergement

  Dans Azure Logic Apps monolocataire, une application logique Standard est similaire à une fonction Azure ou à une application web avec laquelle vous pouvez utiliser un seul plan de service de workflow pour héberger plusieurs applications logiques Standard. Cette similitude signifie que vous n’avez pas besoin de déployer tous vos workflows dans une seule ressource d’application logique Standard. Au lieu de cela, vous pouvez organiser ces workflows en groupes logiques (applications logiques) pour vous aider à mieux gérer d’autres aspects de votre solution. Cette approche vous aide à tirer le meilleur parti de votre plan de service de workflow et à garantir la pérennité de vos applications, que vous pouvez implémenter pour qu’elles puissent être mises à l’échelle individuellement.

  Une application logique Standard propose les niveaux tarifaires suivants : WS1, WS2 et WS3. Sur le plan fonctionnel, chaque niveau fournit les mêmes fonctionnalités. Vos besoins en matière de calcul et de mémoire sont les mieux adaptés à votre scénario, par exemple :

  Niveau tarifaire	Processeur virtuel	Mémoire (Go)
  WS1	1	3,5
  WS2	2	7
  WS3	4	14

  Pour plus d’informations, consultez Niveaux tarifaires dans le modèle Standard.

• Modèle de déploiement hybride (préversion)

  Azure Logic Apps offre un modèle de déploiement hybride pour déployer et héberger des flux de travail d’application logique Standard dans des scénarios locaux, de cloud privé ou de cloud public. Ce modèle offre les fonctionnalités permettant d’héberger des solutions d’intégration dans des environnements partiellement connectés, lorsque vous devez utiliser le traitement local, le stockage de données et l’accès réseau. Avec l’option hybride, vous avez la liberté et la flexibilité de choisir le meilleur environnement pour vos flux de travail. Pour plus d’informations, consultez Configurer votre propre infrastructure pour des applications logiques Standard à l’aide d’un déploiement hybride (préversion).

• Disponibilité et redondance

  Dans Azure, les zones de disponibilité offrent une résilience, une disponibilité distribuée et une extensibilité des zones active-active-active. Pour augmenter la disponibilité de vos charges de travail d’application logique, vous pouvez activer la prise en charge des zones de disponibilité, mais uniquement lorsque vous créez votre application logique. Vous aurez besoin d’au-moins trois zones de disponibilité distinctes dans une région Azure prenant en charge et assurant la redondance de zone. La plateforme Azure Logic Apps distribue ces zones et les charges de travail d’application logique entre ces zones. Cette fonctionnalité est une condition essentielle pour obtenir des architectures résilientes et fournir une haute disponibilité si des défaillances de centre de données se produisent dans une région. Pour plus d’informations, consultez Créer des solutions pour la haute disponibilité à l’aide de zones de disponibilité.

• Environnements isolés/dédiés

  Pour les applications logiques Standard, vous avez la possibilité de sélectionner un système App Service Environment (ASE) v3 pour votre environnement de déploiement. Avec un système ASE v3, vous bénéficiez d’un environnement entièrement isolé et dédié pour exécuter des applications à grande échelle avec des tarifs prévisibles. Vous payez uniquement pour le plan App Service ASE, quel que soit le nombre d’applications logiques que vous créez et exécutez.

Pour les scénarios nécessitant des services d’intégration Azure supplémentaires, consultez la documentation suivante :

• Couches messagerie Azure Service Bus Premium et Standard
• Comparaison des fonctionnalités des niveaux de Gestion des API Azure
• Planification de la gestion des coûts d’Azure Data Factory et Comprendre les tarifs Azure Data Factory via des exemples

Déploiement

BizTalk Server

L’empaquetage du déploiement natif dans BizTalk Server est basé sur un fichier msi (Microsoft Installer) combiné à un fichier de configuration d’environnement, ou de liaisons. Ces deux fichiers créent une séparation entre l’installation des composants, qui sont déployés sur les référentiels BizTalk Server suivants et définissent les paramètres au niveau du port et du pipeline, notamment le point de terminaison, les secrets, la configuration du pipeline, etc.

• Base de données de gestion
• Dossiers locaux BizTalk Server
• .NET Global Assembly Cache

Bien que ce processus puisse s’avérer efficace, vous devez également gérer chaque configuration d’environnement séparément à partir du code. Le projet open source BTDF (BizTalk Deployment Framework) offre une solution à ce problème. Avec cet outil, vous pouvez gérer la configuration de l’environnement dans le cadre de votre solution BizTalk Server à l’aide d’un fichier de liaison avec jetons, que vous créez au moment du design, et d’une matrice de jetons, que vous créez en tant que fichier Excel, pour chaque environnement.

Le processus de génération crée ensuite un fichier MSI unifié et versionné. Ce fichier prend en charge le déploiement de composants et la configuration de l’environnement à partir du même package, ce qui vous permet de mieux contrôler la version de la solution que vous souhaitez implémenter dans tous les environnements.

La prise en charge d’un package BTDF dans un pipeline de déploiement continu d’intégration continue (CI/CD) est disponible dans BizTalk Server 2020, qui inclut cette fonctionnalité introduite avec les packs de fonctionnalités BizTalk Server 2016. Vous pouvez utiliser cette fonctionnalité et la plateforme Azure DevOps pour simplifier le déploiement automatique des solutions BizTalk Server entre les environnements.

Azure Logic Apps

Lorsque vous déployez une ressource Azure Logic Apps ou un autre composant ou une autre solution Services d’intégration Azure sur Azure, vous devez gérer les éléments suivants :

• Ressources Azure qui font office de conteneurs ou d’infrastructure pour les solutions que vous souhaitez déployer, par exemple, l’instance Gestion des API, la ressource d’application logique Standard, l’espace de noms Service Bus ou la rubrique Event Grid

• La logique réelle implémentée par chaque composant, comme les API, les flux de travail, les files d’attente et les abonnements

• Configuration spécifique à l’environnement associée à chaque composant, par exemple, autorisations, secrets, alertes, etc.

Lorsque vous conservez la définition d’infrastructure distincte du code, vous pouvez traiter la définition d’infrastructure comme un simple élément de code que vous pouvez versionner, stocker en toute sécurité dans un référentiel de contrôle de code source et déclencher un déploiement lorsque la définition change. Cette pratique, communément appelée Infrastructure as Code (IaC), améliore la qualité de l’environnement, car vous pouvez créer des versions pour chaque environnement et suivre les modifications apportées au contrôle de code source.

Azure Logic Apps prend en charge IaC en offrant la possibilité de créer des ressources d’infrastructure à l’aide de modèles Azure Resource Management. Bien que les modèles ARM puissent sembler complexes à comprendre et à implémenter en tant que solution unifiée, vous pouvez utiliser des outils d’abstraction comme Bicep, Terraform ou Pulumi, qui fournissent une expérience de type code pour créer votre définition d’infrastructure. Même si ces outils fournissent des couches d’abstraction sur les modèles ARM, ils génèrent finalement des modèles ARM et peuvent déployer ces modèles pour vous.

Une fois votre infrastructure en place, vous pouvez déployer la logique qui implémente vos workflows de bout en bout. Comme Azure Integration Services offre une collection d’outils pour vous permettre d’implémenter vos workflows d’intégration, vous devez déployer chaque composant. Pour les solutions créées avec Azure Integration Services, les pipelines CI/CD sont généralement basés sur le déploiement d’une orchestration de composants. Les ingénieurs DevOps peuvent utiliser des actions intégrées qui font abstraction des activités de déploiement, ou utiliser des actions génériques qui exécutent des commandes CLI ou des scripts d’automatisation comme PowerShell et Bash. Dans la plupart des cas, les ingénieurs personnalisent les pipelines en fonction des besoins de l’application, passent en revue les conseils de la documentation officielle et s’appuient sur des exemples de référentiels comme point de départ.

Le processus de préparation de chaque composant pour le déploiement suit généralement les étapes suivantes :

• Phase d’intégration continue

  1. Obtenez la dernière version du code source.

  2. Préparez le code avec la configuration spécifique à l’environnement.

     Les détails de cette étape dépendent de la prise en charge de chaque technologie pour l’injection externe de variables d’environnement. Le principe de base est que les informations de configuration basées sur l’environnement, telles que les chaînes de connexion et les références à des ressources externes, sont abstraites pour référencer un référentiel de paramètres d’application. Ainsi, dans ce scénario, vous stockez des références qui peuvent exister en texte clair directement dans le référentiel des paramètres d’application, mais vous stockez des valeurs sensibles, telles que des secrets, en tant que pointeurs de référence vers des entrées dans un magasin de secrets, par exemple un coffre de clés Azure.

     Azure Logic Apps rend cette approche possible pour une ressource d’application logique Standard en prenant en charge les références au référentiel de paramètres d’application, ce qui vous permet ensuite de mapper des paires nom-valeur aux entrées de votre coffre de clés.

  3. Empaquetez le code pour le déploiement dans différents environnements.

• Phase de déploiement continu

  1. Déployez du code empaqueté dans l’environnement de destination.

  2. Mettez à jour le référentiel de paramètres d’application avec les valeurs d’environnement correctes, en texte clair ou en tant que références aux entrées de votre coffre de clés.

  3. Mettez à jour toutes les autorisations requises qui dépendent du code.

  4. Préparez votre application pour l’exécution, si nécessaire.

Correspondance des fonctionnalités

Le tableau et le diagramme suivants présentent une comparaison et une correspondance approximatives des ressources, des artefacts, des fonctionnalités et des capacités entre BizTalk Server, Azure Logic Apps et les Services d’intégration Azure. Même si Azure Logic Apps est une plateforme clé pour les charges de travail d’intégration, veillez à prendre en compte toutes les fonctionnalités disponibles dans les Services d’intégration Azure et dans Azure dans son ensemble.

Fonctionnalité ou fonction	BizTalk Server	Azure
Orchestrations	- Orchestration BizTalk Server - Code C#	- Workflow Azure Logic Apps - Modèles de flux de travail Azure Logic Apps - Application de fonction Azure Functions
Pipelines	- Pipelines BizTalk Server - Composants de pipeline	- Workflows Azure Logic Apps (en tant que pipelines) - Azure API Management (en tant que pipelines) - Application de fonction Azure Functions - Application API Azure
Routage de messages	- MessageBox - Promotions de propriétés - Filtres	- Files d'attente et rubriques Azure Service Bus (en-têtes de messages, propriétés de messages et abonnements) - Azure Event Grid ou Azure API Management - SQL Server ou Azure Cache pour Redis
Connectivité d'application	- Adaptateurs BizTalk Server prêts à l’emploi et personnalisés - Internet Information Services (IIS) et Azure API Management (capacités hybrides)	- Connecteurs Azure Logic Apps - Azure API Management (en tant que connecteurs) - Application de fonction Azure Functions - Application API Azure
Références croisées	Tables xref_ * suir base de données de gestion BizTalk (BizTalkMgmtDb)	- Azure Functions - SQL Server - Personnalisé
Schémas (XSD)	- Schémas BizTalk Server - Schémas de fichiers XML, JSON et plats	- Azure Logic Apps (Standard) - Compte d’intégration Azure - Compte de stockage Azure - Application de fonction Azure Functions - Application API Azure
Maps	- Mapper BizTalk - Mappages XSLT - Azure API Management (capacités hybrides)	- Azure Logic Apps (Standard) - cartes XSLT, modèles Liquid - Compte d’intégration Azure (cartes XSLT, modèles Liquid) - Compte de stockage Azure - Application de fonction Azure Functions - Application API Azure - Outil Data Mapper (extension Azure Logic Apps Standard pour Visual Studio Code)
Règles d'entreprise	BizTalk Server Business Rules Engine	Moteur de règles Azure Logic Apps
Business Activity Monitoring	BAM (Business Activity Monitoring) BizTalk Server	Suivi des processus métiers Azure
Routage	- Fonctionnalités BizTalk Server prêtes à l’emploi - Parties, partenaires, contrats, AS2, X12, EDIFACT	Azure Logic Apps et compte d’intégration Azure (partenaires, contrats, AS2, X12, EDIFACT)
HL7, RosettaNet et SWIFT	Accélérateurs BizTalk Server pour HL7, RosettaNet et SWIFT	- Azure Logic Apps, compte d’intégration Azure et connecteurs RosettaNet et SWIFT - Azure API Management pour FHIR (HL7) - Azure Blueprint, qui permet la conformité CSP SWIFT sur Azure
Secrets	Authentification unique de l'entreprise (SSO)	- Azure Key Vault - SQL Server - Configuration de l’application
Sécurité et gouvernance	- Authentification unique de l’entreprise - Applications associées de l’authentification unique - Active Directory - Certificats de signature - Authentification de sécurité IIS - Sécurité réseau	- Microsoft Entra ID - Sécurité du réseau Azure - Contrôle d’accès en fonction du rôle Azure (RBAC Azure) - Revendications, jetons - Stratégies d’accès partagé
Configuration des données	- Fichiers de configuration - Configuration de l’application d’authentification unique d’entreprise - Composants de cache personnalisés - Base de données personnalisée - Moteur des règles d’entreprise - Registre Windows	- Azure Key Vault - Azure App Configuration - Azure Cosmos DB - Stockage Table Azure - Configuration d’Azure Logic Apps (Standard) - Configuration d’Azure Functions - Valeurs et back-ends Azure API Management nommés - SQL Server - Mise en cache personnalisée - Base de données personnalisée
Déploiement	- Fichier de liaison BizTalk Server	- Azure Pipelines - Scripts Bicep - Terraform
Suivi	- Capacités de suivi BizTalk Server (ports de réception, ports d’envoi, pipelines, orchestrations) - Suivi IIS - Analyse intégrée Azure API Management (capacités hybrides)	- Historique des exécutions d’Azure Logic Apps et propriétés suivies - Compte de stockage Azure - Azure Monitor (Application Insights) - Analyse intégrée Azure API Management - Solution personnalisée, par exemple, Azure Event Hubs plus Azure Functions plus SQL Server plus Azure Data Explorer
Surveillance	- Console Administration de BizTalk - BizTalk Health Monitor	Azure Monitor (Application Insights, Log Analytics)
Opérations	- Console Administration de BizTalk Server - Azure Pipelines - MSI, PowerShell - Infrastructure de déploiement BizTalk	- Portail Azure - Azure Monitor - Modèles Azure Resource Manager - Azure Pipelines - PowerShell, CLI, Bicep

Pour rester informé des derniers investissements, abonnez-vous au blog Azure sur les intégrations de la communauté technique.

Étapes suivantes

Vous en savez plus sur la comparaison entre Azure Logic Apps et BizTalk Server. Découvrez maintenant comment choisir les meilleures fonctionnalités Azure pour vos scénarios. Vous pouvez également passer en revue les approches et ressources suggérées, les considérations de planification ainsi que les meilleures pratiques pour votre migration.

Choisir les meilleures offres Azure Integration Services pour votre scénario

Approches de migration de BizTalk Server vers Azure Logic Apps