Internet Data Center : Conception de BizTalk Server

Sur cette page

Microsoft Internet Data Center : Conception de BizTalk Server
Résumé
Introduction
À qui s'adresse ce chapitre
Portée du chapitre
Besoins en termes de personnel
Configuration requise
Architecture
Vue d'ensemble de l'architecture
Architecture des documents entrants
Architecture de traitement professionnel
Architecture des documents sortants
Scénarios d'applications BizTalk Server
Solutions de chaîne d'approvisionnement entre entreprises (côté client)
Solutions de chaîne d'approvisionnement entre entreprises (côté fournisseur)
Solutions d'intégration d'applications d'entreprises
Combinaison de modèles de solutions
Composants d'une solution BizTalk Server
Groupes BizTalk Server
Bases de données SQL Server
Base de données de configuration de messagerie
Base de données de file d'attente partagée
Base de données de suivi
Base de données de persistance de planning d'orchestration
Service d'échanges BizTalk Server
Référentiel WebDAV
Protocoles de transport
Planification du groupe BizTalk Server
Matériel requis pour les serveurs BizTalk Server
Utilisation de plusieurs serveurs BizTalk Server
Optimisation des performances sur les serveurs de réception
Optimisation des performances sur les serveurs de traitement
Planification d'un emplacement pour le groupe BizTalk Server
Placement de BizTalk Server dans la zone DMZ
Placement de BizTalk Server derrière le pare-feu de deuxième couche
Configuration des bases de données BizTalk Server
Planification de l'emplacement des bases de données
Planification de la sécurité Internet
Planification de communications sécurisées
Sécurité des canaux et des documents
Prise en charge de PKI dans BizTalk Server
Enregistrement d'un certificat
Enregistrement des certificats de vos partenaires commerciaux
Configuration de canaux et de ports de messagerie pour la messagerie sécurisée
Autorités de certification et serveurs de certificats
Détermination des exigences en termes de sécurité
Planification de la fonctionnalité Message Queuing
Planification de l'installation de Message Queuing
Planification de la disponibilité élevée de Message Queuing
Planification de files d'attente pour une évolutivité élevée
Planification de la sécurité
Planification de vos files d'attente
Planification de l'envoi de messages
Configuration de la messagerie BizTalk Server pour l'utilisation de files d'attente
Réception de documents à l'aide d'une file d'attente
Envoi de documents à l'aide d'une file d'attente
Interfonctionnement avec les environnements IBM
Planification de communications HTTP/HTTPS
Réception de documents à l'aide de HTTP ou HTTPS
Prise en charge de connexions SSL
Envoi de documents à BizTalk Server
Envoi de documents à l'aide de HTTP ou HTTPS
Planification des communications via FTP et via le système de fichiers
Création d'un site FTP
Envoi de documents FTP à BizTalk Server
Configuration d'une fonction de réception de fichier pour le dossier FTP
Utilisation du système de fichiers pour communiquer avec les applications
Planification de communications SMTP
Planification de la sécurité
Zone de relais SMTP dans la zone DMZ
Exchange Server dans le réseau VLAN de l'infrastructure
Planification de la réception de courrier électronique SMTP
Planification de l'envoi de courrier électronique SMTP
Planification de l'orchestration
Planification d'une architecture BizTalk Orchestration
Optimisation de la base de données XLANG
Optimisation des plannings XLANG
Planification de la gestion et de l'exploitation
Outils de gestion
Sauvegarde des bases de données BizTalk Server
Vidage de la base de données InterchangeDTA
Contrôle d'une solution BizTalk Server
Surveillance des serveurs BizTalk Server
Fournisseur WMI
Contrôle des performances des plannings XLANG
Optimisation des performances par l'intermédiaire du Registre
Résumé

Microsoft Internet Data Center : Conception de BizTalk Server

Cet article est tiré du Guide de référence Internet Data Center

Résumé

Ce chapitre étudie certaines des décisions d'architecture et de conception qui doivent être prises lors de la conception d'une solution Microsoft® BizTalk™ Server 2000 dans un environnement Microsoft Internet Data Center.

Introduction

Microsoft® BizTalk™ Server 2000 offre des services d'orchestration des processus professionnels et de messagerie de documents, lesquels peuvent être utilisés pour faciliter les échanges de documents entre entreprises (BtoB, Business-to-Business) ainsi que l'intégration des applications d'entreprises (EAI, Enterprise Application Integration).

Ce chapitre étudie comment une infrastructure BizTalk Server peut être développée à partir de l'architecture de base de Microsoft Internet Data Center et décrit les principales décisions architecturales que vous devez prendre par rapport à votre implémentation.

À qui s'adresse ce chapitre

Toute personne souhaitant déployer une solution BizTalk Server 2000 dans un environnement de commerce électronique sécurisé doit lire ce chapitre. Il s'agit notamment des administrateurs réseau, des architectes de solutions de commerce électronique et des développeurs expérimentés qui doivent concevoir une infrastructure pour une solution BizTalk Server.

Remarque : Ce chapitre étudie les problèmes liés à la conception d'une infrastructure adaptée à BizTalk Server ; elle ne contient toutefois pas d'instructions détaillées sur le développement d'une application BizTalk Server.

Portée du chapitre

L'architecture décrite dans ce chapitre a été conçue pour être compatible avec IDC et pour prendre en charge la plupart des applications. Cependant, chaque application présente ses propres besoins et vous devrez donc adapter cette structure à vos propres exigences.

Les principales décisions architecturales que vous devez prendre concernent l'emplacement du groupe BizTalk Server (qui peut se trouver dans le DMZ ou dans le réseau VLAN Infrastructure) ainsi que les protocoles de transport pris en charge par votre infrastructure. Lorsque ces décisions essentielles sont nécessaires, ce chapitre décrit les raisons qui dictent telle ou telle solution, les autres options disponibles ainsi que les avantages de chaque approche.

Cependant, Microsoft recommande fortement de placer le groupe BizTalk Server dans le réseau VLAN Infrastructure et la plupart des conseils relatifs à l'architecture sont basés sur cette recommandation.

Besoins en termes de personnel

Pour concevoir une infrastructure BizTalk Server efficace, vous avez besoin de personnel avec des compétences et des connaissances dans les domaines suivants :

• installation et configuration de BizTalk Server 2000 ;

• configuration de Microsoft SQL Server™ 7.0 et SQL Server 2000 ;

• configuration de Message Queuing 2.0 ;

• mise en réseau et sécurité pour le système d'exploitation Microsoft Windows® 2000

Remarque : il est vivement recommandé d'appliquer les service packs les plus récents pour BizTalk Server 2000, SQL Server 7.0 ou 2000, ainsi que Windows 2000 dans l'environnement de production.

Configuration requise

Ce chapitre suppose que vous avez développé une infrastructure de commerce électronique basée sur le centre IDC. Cependant, tous les éléments du centre IDC ne sont pas requis pour implémenter l'infrastructure BizTalk Server décrite dans ce chapitre.

Architecture

Le schéma suivant illustre les éléments de la solution BizTalk Server dans l'architecture IDC.

Figure 1. Éléments de la solution BizTalk Server dans l'architecture IDC

Vue d'ensemble de l'architecture

L'architecture Internet Data Center définit une plate-forme de commerce électronique constituée de plusieurs segments réseau ou réseaux locaux virtuels (VLAN, Virtual Local Area Network) : Le réseau VLAN de la zone DMZ (Demilitarized Zone) contient des serveurs Web tournés vers Internet, derrière un pare-feu. Ce segment est à son tour divisé en deux sous-réseaux : un réseau Web frontal et un réseau Web dorsal. Tandis que le réseau Web frontal est conçu pour exposer les serveurs IIS à Internet, le réseau Web dorsal est destiné à l'exposition des serveurs IIS aux réseaux internes derrière un deuxième pare-feu. Derrière la seconde paire de pare-feu redondants, le réseau VLAN Infrastructure contient les serveurs d'applications, tels que les serveurs BizTalk Server, et les réseaux VLAN Groupe de stockage contiennent les serveurs de bases de données et de gestion, notamment les serveurs de sauvegarde. En plus des réseaux VLAN représentés, il existe dans la conception IDC la possibilité d'ajouter un autre réseau VLAN pour la connexion au réseau de l'entreprise. Ce réseau peut contenir les systèmes internes de l'entreprise, tels que les systèmes de gestion de production.

L'architecture BizTalk Server de l'illustration précédente représente les principales décisions de conception prises lors de l'implémentation d'une solution BizTalk Server sur la plate-forme IDC. L'architecture a été conçue pour permettre d'héberger une application dans laquelle des partenaires commerciaux peuvent envoyer des documents professionnels en les publiant vers un site Web IIS (Internet Information Services) via le protocole HTTP ou HTTPS, en les envoyant sous forme de message électronique SMTP ou en les envoyant sur un site FTP. Les documents reçus peuvent être traités à l'aide de plannings d'orchestration BizTalk Server et les documents sortants peuvent être envoyés aux partenaires commerciaux via les protocoles HTTP ou SMTP.

Architecture des documents entrants

Les documents envoyés au site Web IIS sont envoyés à une file d'attente de messages sur un serveur en cluster, dans laquelle un service personnalisé lit le message et le transfère à une file d'attente sur un des serveurs BizTalk Server du groupe, par l'intermédiaire d'un algorithme transactionnel de répétition alternée. Une fonction de réception sur l'ordinateur BizTalk Server lit alors le message et l'envoie en vue du traitement.

Les documents qui sont envoyés en tant que messages électroniques SMTP sont routés par un serveur de relais SMTP dans la zone DMZ vers un serveur Exchange se trouvant derrière le deuxième pare-feu. Un script personnalisé envoie ensuite les documents reçus vers la file d'attente de messages contrôlée par une fonction de réception du serveur BizTalk Server.

Les racines FTP virtuelles des serveurs IIS sont toutes associées à un dossier physique unique dans le cluster de file d'attente de messages. Les documents publiés ici sont extraits par une fonction de réception du serveur BizTalk Server en vue de leur traitement.

Architecture de traitement professionnel

Un cluster de serveurs BizTalk Server exécutant des services d'orchestration est utilisé pour traiter les plannings XLANG qui renferment des processus professionnels. Ces plannings opèrent en général sur un document envoyé aux serveurs d'orchestration via la mise en file d'attente des messages.

Architecture des documents sortants

Lorsque BizTalk Server doit envoyer des documents à des partenaires commerciaux, il peut le faire en les publiant vers une adresse HTTP ou HTTPS, ou en envoyant un message électronique SMTP au serveur Exchange du réseau VLAN Infrastructure. Le message est ensuite transféré au serveur de relais SMTP de la zone DMZ, puis vers Internet.

Bien que votre application spécifique ne nécessite peut-être pas tous les éléments de la solution étudiée dans ce chapitre, vous devez baser votre architecture sur le raisonnement de conception présenté dans ce document.

Scénarios d'applications BizTalk Server

Avant de planifier une infrastructure pour BizTalk Server, vous devez étudier les besoins de l'application que vous développez. BizTalk Server peut être utilisé dans de nombreux scénarios d'applications et vous devez identifier la configuration de déploiement qui offrira le meilleur environnement pour répondre à vos exigences professionnelles.

BizTalk Server offre des services qui vous aident à automatiser les processus professionnels et à intégrer vos applications et partenaires commerciaux. Bien que les problèmes professionnels pour lesquels BizTalk Server peut être utilisé soient quasiment illimités, ces applications peuvent être regroupées en plusieurs structures générales de conception :

• intégration de chaîne d'approvisionnement entre entreprises (côté client) ;

• intégration de chaîne d'approvisionnement entre entreprises (côté fournisseur) ;

• intégration d'applications d'entreprises.

Solutions de chaîne d'approvisionnement entre entreprises (côté client)

Si votre organisation doit prendre des commandes de clients et les envoyer à un ou plusieurs fournisseurs, vous avez besoin d'une solution de chaîne d'approvisionnement entre entreprises (côté client). La plupart des organisations côté client effectuent des opérations de détail (bien que le modèle de conception s'applique à toute organisation qui doit envoyer des documents professionnels à des partenaires commerciaux), et en particulier sur des sites Web de commerce électronique entre entreprise et consommateur.

Par exemple, un site de détail entre entreprise et consommateur basé sur Microsoft Commerce Server 2000 peut permettre aux clients d'acquérir des biens auprès de différents fournisseurs. Lorsque la commande est traitée par un pipeline Commerce Server, les articles peuvent être regroupés par fournisseur, puis Commerce Server peut utiliser BizTalk Server pour envoyer les commandes aux différents fournisseurs à l'aide des protocoles Internet appropriés, tels que HTTP, HTTPS ou SMTP. Ce type d'application est illustré à la figure 2.

Figure 2. Chaîne d'approvisionnement entre entreprises (côté client)

Solutions de chaîne d'approvisionnement entre entreprises (côté fournisseur)

Bien entendu, si les clients peuvent envoyer des commandes aux fournisseurs, les fournisseurs doivent pouvoir recevoir et traiter ces commandes. Dans ce cas, une solution de chaîne d'approvisionnement entre entreprises (côté fournisseur) doit être développée.

Les solutions côté fournisseur doivent permettre de recevoir les documents professionnels entrants (lesquels peuvent être envoyés par l'intermédiaire de divers protocoles), d'effectuer le suivi des échanges de documents et de traiter les messages reçus. BizTalk Server peut être utilisé pour recevoir les documents entrants qui ont été publiés sur un site Web, envoyés à l'aide de messages électroniques SMTP, envoyés à un site FTP ou envoyés grâce à la technologie Message Queuing dans le réseau extranet d'un partenaire. La figure 3 illustre ce scénario.

Figure 3. Chaîne d'approvisionnement entre entreprises (côté fournisseur)

Solutions d'intégration d'applications d'entreprises

Dans une même organisation, les processus professionnels nécessitent souvent l'échange de données entre les applications internes. Dans les événements dans lesquels plusieurs plates-formes (matériel et systèmes d'exploitation) sont utilisées, ou dans lesquelles différents protocoles d'applications sont requis, cette intégration peut représenter un défi très complexe.

Avec BizTalk Server, vous pouvez utiliser plusieurs API, telles que COM+, Message Queuing, HTTP, SMTP, le système de développement Microsoft Visual Studio® 6.0 avec le kit d'outils SOAP, ou le système de fichiers, pour gérer les échanges de données entre les applications internes. La figure 4 illustre ce scénario.

Figure 4. Intégration d'applications d'entreprises

Combinaison de modèles de solutions

En réalité, de nombreuses organisations doivent développer une solution qui utilise deux de ces modèles, voire les trois. Par exemple, vous pouvez être amené à développer un portail de commerce électronique qui nécessite le traitement des commandes pour votre propre site de détail, la réception des commandes en provenance des sites de vos partenaires commerciaux, l'envoi de demandes de livraison à un transporteur et l'intégration à des systèmes dorsaux de gestion de la production ou à des applications professionnelles. Dans ce cas, vous devez planifier soigneusement votre infrastructure BizTalk Server afin de vous assurer du meilleur compromis possible entre évolutivité, disponibilité, sécurité et simplicité de gestion de votre solution professionnelle globale.

Composants d'une solution BizTalk Server

De nombreux aspects d'une solution BizTalk Server 2000 doivent être pris en considération lors de la planification d'une infrastructure. Vous devez planifier avec soin où chaque élément du système sera déployé, de quelle façon il sera configuré et comment il va communiquer avec les autres éléments du système. Les décisions que vous prenez lors de la planification de votre infrastructure peuvent avoir des conséquences importantes pour l'évolutivité, la disponibilité, la sécurité et la simplicité de gestion de la solution ; il est donc essentiel de comprendre l'objectif de chaque élément de l'infrastructure ainsi que les options disponibles pour le déploiement.

Groupes BizTalk Server

Les groupes BizTalk Server sont des regroupements d'un ou plusieurs serveurs BizTalk Server. Les serveurs d'un groupe utilisent une file d'attente partagée et des bases de données de suivi, ainsi que les mêmes analyseurs, fonctions de réception et autres configurations de messagerie.

Les serveurs du groupe coopèrent pour traiter les messages entrants, répartissant ainsi la charge entre eux. Cela offre un niveau naturel d'équilibrage de charge. Si un des serveurs connaît une défaillance, les autres continuent de traiter les messages entrants.

Bases de données SQL Server

BizTalk Server stocke la configuration, les éléments de travail, l'état des processus longs et les documents suivis dans des bases de données SQL Server.

Base de données de configuration de messagerie

Chaque infrastructure BizTalk Server dispose d'une base de données de gestion unique (nommée InterchangeBTM par défaut) dans laquelle est stockée la configuration de la solution. Cela inclut toutes les configurations de messagerie, telles que les canaux, les ports de messagerie et les définitions de documents.

Base de données de file d'attente partagée

La base de données de file d'attente partagée (nommée InterchangeSQ par défaut) est une zone de stockage de tous les éléments de travail qui doivent être traités par BizTalk Server. Cette base de données offre une file d'attente de travail dans laquelle sont stockés les documents à traiter, une file d'attente planifiée pour les documents sortants en attente d'un intervalle de service pour la transmission, une file d'attente de nouvelle tentative pour les documents n'ayant pas encore été traités avec succès, ainsi qu'une file d'attente d'interruption pour les documents qui ont dépassé le nombre de nouvelles tentatives configuré ou qui contiennent des erreurs.

Base de données de suivi

La base de données de suivi (nommée InterchangeDTA par défaut) est utilisée pour stocker les informations d'échange de documents en vue de l'audit et de l'analyse.

Base de données de persistance de planning d'orchestration

La base de données de planning d'orchestration (nommée XLANG par défaut) contient les données suivantes :

• Plannings de déshydratation XLANG inactive utilisés par le service d'orchestration de BizTalk Server pour automatiser les processus professionnels. Ces données sont utilisées pour stocker l'état d'un processus professionnel long, de sorte que l'instance du processus puisse être supprimée de la mémoire.

• L'état des instances de planification en cours. En cas d'échec d'un planning, le service de redémarrage du planificateur XLANG consulte cette base de données afin de déterminer où le planning doit reprendre.

Service d'échanges BizTalk Server

BizTalk Server se base sur un service Windows appelé le service d'échanges BizTalk Server. Ce service est utilisé pour traiter toutes les fonctions d'échange de messages. Les services d'échanges se basent sur des objets configurés, tels que les canaux, les ports de messagerie et les définitions de documents. Pour en savoir plus sur la création d'objets de messagerie BizTalk Server, consultez la documentation BizTalk Server 2000.

Référentiel WebDAV

Le référentiel WebDAV est un site Web IIS qui prend en charge les extensions HTTP-DAV pour la création de documents. BizTalk crée un site Web appelé BizTalkServerRepository au cours de l'installation. Celui-ci est utilisé pour stocker les spécifications et mappages de documents utilisés par votre solution de messagerie BizTalk Server.

Utilisez le référentiel WebDAV lors de la création ou de la modification de spécifications et de mappages de documents. Utilisez le Gestionnaire de messagerie BizTalk lors de la création de définitions de documents basée sur les spécifications de documents stockées dans le référentiel WebDAV. Ces définitions de documents sont utilisées pour configurer les documents entrants et sortants dans les canaux.

Protocoles de transport

BizTalk Server utilise divers protocoles de transport pour recevoir et transmettre des messages. Il s'agit notamment des protocoles Internet standard, tels que HTTP, HTTPS et SMTP, ainsi que Microsoft Message Queuing, le système de fichiers et COM. Lors de la planification de votre infrastructure BizTalk Server, vous devez identifier les protocoles que vous allez utiliser pour communiquer avec BizTalk Server et configurer votre environnement en conséquence.

Planification du groupe BizTalk Server

Le groupe BizTalk Server de votre infrastructure est le concentrateur de votre solution d'intégration BizTalk Server. En tant que tel, il doit être configuré afin d'offrir les niveaux requis d'évolutivité, de disponibilité, de sécurité et de simplicité de gestion pour votre environnement.

Matériel requis pour les serveurs BizTalk Server

La première étape dans l'obtention de performances optimales pour votre solution BizTalk Server consiste à vous assurer que vos serveurs disposent d'une configuration matérielle adéquate. Vous pouvez pour cela effectuer des opérations de planification de capacité en fonction de la charge de production prévue sur le système. Bien que plusieurs éléments puissent contribuer aux performances globales, vous devez tenir compte des éléments suivants lors de la planification de capacité, afin d'obtenir la configuration matérielle optimale :

• nombre prévu de documents à traiter par jour par BizTalk Server ;

• la taille de chaque type de document à traiter ;

• la complexité des processus professionnels requis par les documents.

En raison de ces divers éléments, il n'est pas aisé de donner dans ce chapitre des chiffres précis pour obtenir la configuration matérielle optimale. En revanche, une réflexion sur ces différents éléments lors de la phase de planification de capacité ainsi que des tests vous aideront à obtenir une configuration raisonnable.

Les recommandations suivantes doivent être considérées comme des spécifications minimales dans un environnement de production.

Chaque serveur BizTalk Server doit être un serveur à deux processeurs dédié avec la configuration suivante :

• cache processeur de niveau 2 de 1 à 2 mégaoctets (Mo) ;

• 512 Mo de RAM ;

• une carte réseau 100 Mbps (ou plus rapide) connectée à des ports de commutateur 100 Mbps ;

• des disques haute vitesse distincts pour le service DTC (Distributed Transaction Coordinator), la journalisation et les opérations Message Queuing (les journaux DTC doivent être écrits sur un serveur de journalisation distant central afin d'éviter les conflits d'E/S des fichiers du serveur BizTalk Server).

Remarque : BizTalk Server permet d'obtenir des résultats optimaux lorsqu'il est configuré avec un système à quatre processeurs.

Utilisation de plusieurs serveurs BizTalk Server

En créant un groupe BizTalk Server contenant plusieurs serveurs, vous améliorez immédiatement l'évolutivité et la disponibilité, car les serveurs répartissent de façon dynamique la charge entre eux et procurent les uns aux autres une redondance naturelle. Vous devez prévoir l'installation d'au moins deux serveurs dans votre groupe BizTalk Server, même si pour les solutions d'échange de volumes élevés, vous pouvez améliorer la disponibilité et la redondance en ajoutant des serveurs.

Les serveurs BizTalk Server du groupe partagent une file d'attente de travail, laquelle est implémentée en tant que table dans la base de données de file d'attente partagée. Les échanges dans la file d'attente sont traités par les serveurs selon un ordre "premier entré, premier sorti" (FIFO, First In, First Out).

Vous devez configurer au moins deux serveurs dans le groupe, à la fois en tant que serveur de réception (un serveur qui lit les messages entrants et les place dans la file d'attente des éléments de travail) et en tant que serveur de traitement (un serveur qui lit les éléments de travail dans la file d'attente et les traite). Par défaut, tous les serveurs se comportent comme des serveurs de traitement, et tout serveur sur lequel une fonction de réception est définie (ou sur lequel des applications d'envoi utilisent l'interface d'échange) fonctionne en tant que serveur de réception et serveur de traitement.

Dans les applications très exigeantes, la configuration optimale consiste à avoir plusieurs serveurs de réception dédiés et plusieurs serveurs de traitement dédiés. Le rapport doit toutefois être de 1 pour 2 (un serveur de réception doit être accompagné de deux serveurs de traitement). Pour qu'un serveur se comporte uniquement comme serveur de réception, vous pouvez le configurer afin qu'il ne participe pas au traitement des éléments de travail, à l'aide de l'outil d'administration de BizTalk Server.

Vous pouvez équilibrer la charge des fonctions de réception afin d'améliorer l'évolutivité et la disponibilité, via la création de fonctions de réception sur plusieurs serveurs BizTalk Server du groupe, qui interrogent le même emplacement (partage de fichiers ou file d'attente de messages). Grâce à cette technique, vous pouvez partager la charge de traitement pour la réception de documents à partir d'une file d'attente ou d'un dossier sur plusieurs serveurs. Pour les emplacements de type système de fichiers, vous pouvez choisir de configurer différents serveurs pour l'interrogation de différents types de fichiers.

Optimisation des performances sur les serveurs de réception

Vous pouvez optimiser les performances des serveurs de réception en augmentant le nombre de threads de réception sur le serveur correspondant. Ce paramètre peut également être configuré par l'intermédiaire de l'outil d'administration de BizTalk Server et doit être défini à une valeur comprise entre 2 et 4 (par processeur) pour des circonstances normales. La valeur doit être augmentée pour les serveurs de réception dédiés, les scénarios faisant appel au cryptage ou à la signature numérique, ainsi que les échanges impliquant des documents volumineux.

Un paramètre trop faible risque de provoquer une sous-utilisation du processeur. Un paramètre trop élevé risque de réduire les performances en raison de conflits de threads.

Optimisation des performances sur les serveurs de traitement

Les serveurs de traitement peuvent être optimisés par les configurations suivantes :

• Affectation de priorités dans l'ordre selon lequel les analyseurs de documents sont organisés, à l'aide de l'outil d'administration de BizTalk Server. Par exemple, si votre organisation reçoit principalement des documents XML, vous pouvez déplacer l'analyseur BizTalk.ParserXML.1 en début de liste.

• Augmentation de la valeur par défaut (4) du paramètre de threads actives à une valeur comprise entre 8 et 10.

• Ajustement du paramètre Time Between BizTalk Server Scheduler Calls (Intervalle entre les appels du planificateur BizTalk Server) afin de contrôler la fréquence à laquelle BizTalk Server interroge la file d'attente des éléments de travail dans la base de données InterchangeSQ. Les solutions avec un faible volume de messages entrants bénéficieront d'une valeur de fréquence plus élevée. Cette valeur empêche toute requête de base de données inutile.

Planification d'un emplacement pour le groupe BizTalk Server

L'emplacement du groupe BizTalk Server au sein de votre environnement réseau aura un impact considérable sur les performances de votre solution et sur votre capacité à la sécuriser et à la gérer. Plusieurs emplacements au sein du centre IDC peuvent être utilisés pour héberger le groupe BizTalk Server, chacun avec ses propres avantages et inconvénients.

L'emplacement choisi pour vos serveurs BizTalk Server dépend de plusieurs facteurs. En voici quelques exemples :

• Les protocoles qui seront utilisés pour échanger des messages. Ce paramètre permet de déterminer si BizTalk Server doit ou non permettre l'envoi de données vers Internet.

• Les applications professionnelles avec lesquelles BizTalk Server interagit. Ce paramètre aide à déterminer la méthode de communication.

• BizTalk Server doit fréquemment accéder à des données dans ses différentes bases de données de configuration, de sorte que ces bases de données doivent idéalement se trouver à proximité du groupe BizTalk Server, afin d'éviter les problèmes de performances.

Le centre IDC comporte deux segments réseau dans lesquels BizTalk Server peut être déployé : la zone DMZ, qui contient un groupe de serveurs Web IIS, et le réseau VLAN Infrastructure.

Placement de BizTalk Server dans la zone DMZ

Lorsque votre solution d'échange de documents nécessite de communiquer avec des partenaires commerciaux externes via Internet, vous pouvez choisir de déployer votre groupe BizTalk Server dans la zone DMZ. Cela permet à BizTalk Server d'envoyer des documents à l'aide des protocoles HTTP, HTTPS ou SMTP avec peu de problèmes de configuration de pare-feu, car les ordinateurs qui exécutent BizTalk Server ont un accès direct à Internet.

Ainsi, si votre serveur BizTalk Server nécessite une interopérabilité minimale avec les systèmes dorsaux, la zone DMZ peut constituer un emplacement logique dans lequel déployer les serveurs. Par exemple, si vous hébergez un site de détail de type entreprise vers consommateur, basé sur Commerce Server 2000, vous pouvez simplement utiliser BizTalk Server pour transférer les commandes aux fournisseurs externes ; dans ce cas, le fait de placer BizTalk Server derrière un pare-feu de deuxième couche risquerait d'introduire une complexité inutile.

Cependant, il est nécessaire d'étudier certains points avant de placer votre groupe BizTalk Server dans la zone DMZ, le plus important d'entre eux étant la sécurité. Si votre application requiert BizTalk Server pour communiquer avec un serveur dorsal (par exemple, pour accéder à des données ou pour faire appel à une logique de traitement), vous devez permettre l'accès par l'intermédiaire du deuxième pare-feu. Dans certains cas, cela nécessite simplement l'ouverture d'un port TCP/IP spécifique (tel que le port 1801 pour Message Queuing), mais dans d'autres cas, cela requiert une configuration beaucoup plus complexe. L'ouverture du pare-feu peut constituer un risque inacceptable en termes de sécurité.

Vous devez activer DCOM à travers un ou plusieurs pare-feu lorsque BizTalk Server est configuré pour utiliser un composant AIC (Application Integration Component) pour faire appel à un autre composant COM situé dans l'infrastructure ou dans le réseau VLAN du groupe de stockage derrière le deuxième pare-feu, ou dans le réseau d'entreprise derrière le troisième pare-feu.

Par exemple, si le composant AIC est conçu pour communiquer avec le système SAP par l'intermédiaire du connecteur DCOM SAP, le fait de placer le serveur BizTalk Server dans la zone DMZ affecte de manière significative les performances, la sécurité et la simplicité de gestion, car vous devez activer DCOM à travers le deuxième et le troisième pare-feu. En général, un système tel que le système de gestion de production SAP se trouve dans le réseau de l'entreprise.

Pour éviter d'activer DCOM par l'intermédiaire des pare-feu, vous pouvez exposer les serveurs COM, tels que les serveurs COM SAP, sous la forme de services Web, les rendant ainsi accessibles via le protocole HTTP.

Vous devez également envisager la sécurisation des parties administratives de BizTalk Server. Deux sites Web sont créés par BizTalk Server pendant l'installation :

1. Le site Web contenant le référentiel WebDAV, dans lequel sont stockés les spécifications et mappages des documents. Ce site Web est présent dans la zone DMZ, ce qui le rend accessible pour les éventuels intrus (en particulier parce que les autorisations par défaut permettent l'exploration anonyme des répertoires).

2. BizTalk Server crée également un site Web nommé BizTalkTracking, lequel contient une application ASP utilisée pour analyser les échanges qui ont été effectués par le groupe BizTalk Server.

Vous devez sécuriser ces sites soit à l'aide de votre pare-feu et de la sécurité NTFS pour empêcher l'accès non autorisé aux données de votre serveur BizTalk Server, soit en déplaçant le référentiel WebDAV et les sites BizTalkTracking vers un serveur IIS interne.

Enfin, si vous choisissez de placer les serveurs BizTalk Server dans la zone DMZ, vous devez étudier sérieusement l'impact, en termes de performances, de l'accès à SQL Server via le deuxième pare-feu. Il est rarement judicieux de placer SQL Server dans la zone DMZ.

La figure 5 illustre une infrastructure avec BizTalk Server dans la zone DMZ.

Figure 5. BizTalk Server dans la zone DMZ

Placement de BizTalk Server derrière le pare-feu de deuxième couche

Votre groupe BizTalk Server peut également être disposé sur le réseau VLAN de l'infrastructure, derrière le deuxième pare-feu. Il s'agit de l'emplacement recommandé de BizTalk Server, qui résout nombre des problèmes de sécurité liés au placement de BizTalk Server dans la zone DMZ.

Dans une configuration où BizTalk Server se trouve derrière la zone DMZ, les messages entrants doivent être routés vers BizTalk Server par l'intermédiaire du pare-feu. En général, il ne s'agit pas d'un problème majeur, étant donné que BizTalk Server prend en charge des protocoles, tels que Message Queuing, qui peuvent être autorisés à franchir un pare-feu relativement facilement.

Le principal problème à résoudre lorsque BizTalk Server est déployé derrière un deuxième pare-feu est la nécessité pour BizTalk Server d'envoyer des messages via Internet à l'aide des protocoles HTTP, HTTPS ou SMTP. Si votre application ne nécessite pas de messages sortants vers Internet, aucune configuration supplémentaire n'est requise. Cependant, si un trafic Internet sortant doit être pris en charge, vous devez activer l'accès sortant uniquement à Internet à partir du réseau VLAN où se trouve BizTalk Server. En général, cela se fait par le chaînage des pare-feu et l'autorisation du seul trafic sortant.

La figure 6 illustre une infrastructure dans laquelle BizTalk Server est déployé à l'intérieur du réseau VLAN de l'infrastructure.

Figure 6. Placement de BizTalk Server derrière la zone DMZ

Configuration des bases de données BizTalk Server

Les serveurs BizTalk Server de votre solution utilisent des bases de données SQL Server pour stocker leurs données de configuration et de gestion. Comme dans le cas des serveurs BizTalk Server, vous devez planifier avec soin l'installation et la configuration des serveurs SQL Server qui seront utilisés dans votre environnement.

Un point important dont vous devez tenir compte est que les serveurs SQL Server utilisés par le service d'échanges de BizTalk Server 2000 doivent prendre en charge l'authentification SQL Server standard. Pour permettre cela, vous devez configurer les serveurs SQL Server avec la sécurité en mode mixte. Vous pouvez faire cela au cours de l'installation de SQL Server, ou après l'installation à l'aide de l'outil Enterprise Manager. Les serveurs SQL Server utilisés pour stocker les données de vos applications professionnelles doivent généralement être configurés pour prendre en charge uniquement l'authentification intégrée de Windows afin d'offrir le niveau le plus élevé de sécurité.

Planification de l'emplacement des bases de données

Dans la mesure où les serveurs BizTalk Server doivent accéder fréquemment aux données de configuration, aux éléments de travail et aux plannings XLANG, et étant donné qu'ils doivent écrire chaque échange enregistré dans la base de données de suivi, les serveurs SQL Server qui hébergent les bases de données InterchangeBTM, InterchangeSQ, XLANG et InterchangeDTA doivent se trouver à proximité du groupe BizTalk Server.

Les quatre bases de données associées à BizTalk Server peuvent être installées sur un même serveur SQL Server, ou être répartis sur plusieurs serveurs SQL Server dans le cas d'environnements à volume élevé. Si vous choisissez d'utiliser une seule instance de serveur SQL Server pour toutes les bases de données BizTalk Server, vous devez installer les bases de données InterchangeSQ et InterchangeDTA sur des disques distincts, chacune avec son propre canal E/S, afin d'éviter les conflits de ressources et d'optimiser les performances. La base de données InterchangeSQ nécessite une forte activité de lecture et d'écriture, dans la mesure où chaque message entrant y est enregistré par un serveur de réception, puis lu par un serveur de traitement. La base de données InterchangeDTA connaît des écritures fréquentes lors de l'enregistrement des échanges de messages, ce qui signifie que la taille de la base de données croît rapidement, nécessitant donc une activité d'archivage et de vidage. Vous devez évaluer la taille moyenne des documents pour une transaction unique, plus multiplier ce chiffre par le nombre de transactions prévu avant le vidage de la base de données, afin de prévoir la taille de la base de données InterchangeDTA.

La base de données InterchangeBTM contient des données de configuration du service d'échanges qui sont généralement mises en cache, réduisant ainsi l'activité de cette base de données. Par conséquent, la base de données InterchangeBTM peut se trouver sur le même disque que la base de données InterchangeSQ ou InterchangeDTA, pour une surcharge minimale. En fonction de la quantité d'orchestration effectuée par votre application, vous pouvez choisir d'installer la base de données XLANG sur son propre disque sur un serveur de bases de données central, ou d'installer une base de données XLANG sur chaque machine qui exécute BizTalk Orchestration. Quoi qu'il en soit, elle doit au moins être installée sur son propre canal de disque, car elle nécessite de fréquentes opérations de lecture et d'écriture.

Vous pouvez améliorer les performances de ces bases de données à l'aide de configurations de disque RAID. En particulier, les performances et la fiabilité de la base de données InterchangeSQ peuvent être optimisées à l'aide d'une combinaison de RAID 1 (mise en miroir de disques) et RAID 0 (agrégats par bandes).

Afin d'obtenir le niveau le plus élevé de disponibilité, mettez en cluster les serveurs SQL Server utilisés par BizTalk Server. Pour optimiser l'utilisation du matériel disponible, vous pouvez envisager l'utilisation d'une configuration de cluster avec basculement à plusieurs instances, dans laquelle l'un des nœuds héberge les bases de données InterchangeSQ et InterchangeBTM, tandis que l'autre héberge les bases de données InterchangeDTA et XLANG. Ce scénario est illustré à la figure 7.

Figure 7. Cluster SQL Server avec basculement à plusieurs instances

Remarque : lorsque vous prévoyez d'utiliser un cluster avec basculement à plusieurs instances, comme le montre la figure 7, vous devez vous assurer que chaque nœud est suffisamment puissant pour pouvoir prendre en charge le traitement des quatre bases de données en cas de basculement. Si le volume des transactions est très élevé, vous devez envisager l'utilisation de plusieurs clusters avec basculement à instance unique, afin d'optimiser les performances de SQL Server.

Planification de la sécurité Internet

BizTalk Server peut être utilisé pour communiquer avec des partenaires commerciaux via Internet. Lors de la conception d'une solution BizTalk Server, vous devez planifier avec soin les besoins de votre organisation en termes de sécurité.

Planification de communications sécurisées

Lors de la planification de communications sécurisées, vous devez tenir compte des aspects suivants :

• L'authentification valide l'identité des personnes qui envoient des documents professionnels entrants.

• La confidentialité empêche les personnes non autorisées d'intercepter et d'exploiter les informations contenues dans les documents professionnels transmis via Internet.

• L'intégrité des données garantit que le document n'a pas été modifié au cours de sa transmission via Internet.

Chaque transport ou type de document présente des exigences différentes en termes de sécurité, et chacun prend en charge des modèles de sécurité différents. Il est donc impératif de bien comprendre les questions suivantes liées à la sécurité avant d'implémenter un modèle de sécurité pour vos applications :

• la sécurité des canaux et des documents ;

• la prise en charge de l'infrastructure à clé publique (PKI, Public Key Infrastructure) par BizTalk Server ;

• les autorités de certification et les serveurs de certificats.

Sécurité des canaux et des documents

La sécurité des canaux fait référence à la sécurisation de la connexion physique entre deux points de terminaison. Cette connexion physique est appelée le canal. La sécurité des documents implique l'application de la sécurité aux documents individuels, laquelle a généralement lieu au niveau de la couche d'application. La sécurité des canaux est invisible pour l'application.

Lorsque cela est possible, vous devez appliquer la sécurité au niveau du canal. Les protocoles tels que HTTPS offrent un cryptage du canal. Vous devez également utiliser l'authentification offerte par IIS (Internet Information Services). Les certificats client et les autres fonctionnalités de sécurité offertes par le système d'exploitation sont invisibles pour l'application BizTalk Server et doivent être utilisés autant que possible.

La sécurité TCP/IP (IPSec, IP Security) et le protocole SFTP (Secured File Transfer Protocol) sont des options de sécurité de canal exclues de cette solution BizTalk Server. L'adoption du protocole IPSec progresse, mais celui-ci n'est pas encore largement disponible. SFTP n'est pas pris en charge par Windows 2000 et se rencontre principalement dans les environnements UNIX. Si vous avez un grand nombre de partenaires commerciaux, vous pouvez choisir d'écarter IPSec et SFTP comme solutions possibles, afin de sélectionner des options de sécurité ayant une portée maximale. À l'inverse, vous pouvez envisager l'utilisation de IPSec et SFTP si vous n'avez que quelques partenaires commerciaux dotés d'environnements informatiques contrôlés.

La sécurité des documents dans BizTalk Server se base sur la fonctionnalité PKI intégrée à Windows 2000. La sécurité des documents est généralement assurée au niveau de la couche d'application, ce qui signifie que BizTalk Server ou votre application individuelle verront ces documents au format crypté.

Prise en charge de PKI dans BizTalk Server

La prise en charge de PKI dans BizTalk Server se divise en deux domaines, le cryptage et la signature. Le cryptage d'un document permet d'assurer la confidentialité du document en empêchant des tiers de décrypter les informations stockées dans le document. Le cryptage garantit également l'intégrité des données, dans la mesure où le contenu du document ne peut pas être modifié lorsqu'il est crypté.

La signature, également appelée signature numérique, vérifie l'authentification, car seul le propriétaire d'un certificat numérique peut signer un document. Elle garantit également l'intégrité des données en calculant une valeur de hachage et en incluant cette valeur dans le bloc de signature. Lors de la vérification de la signature, la valeur de hachage est recalculée et comparée à la valeur d'origine, garantissant ainsi que le document n'a pas été modifié après l'application de la signature.

PKI utilise abondamment les certificats numériques. Ces certificats contiennent les clés de cryptage utilisées pour crypter, décrypter et signer les documents. On distingue deux types de clés : La clé privée est connue uniquement du propriétaire du certificat. Les certificats contenant des clés privées doivent être traités comme des informations secrètes qui ne doivent pas être divulguées. La clé publique est disponible librement pour tout un chacun.

La fonction la plus importante de PKI est le concept de clé publique et de clé privée, ainsi que leur relation avec le cryptage. Les documents peuvent être cryptés avec l'une ou l'autre des clés, mais les informations ne peuvent être décryptées qu'avec l'autre clé. Par exemple, si vous cryptez un document à l'aide de votre clé privée, seule la clé publique peut être utilisée pour décrypter le document. Cela signifie que si vous pouvez décrypter avec succès un document, il doit avoir été crypté par le détenteur de la clé privée. De la même façon, si vous cryptez un document à l'aide de la clé publique de votre partenaire commercial, vous êtes certain que lui seul pourra décrypter le document, à l'aide de sa clé privée. Cela permet de garantir la confidentialité des informations. Le cryptage et la signature des documents sont basés sur ces concepts importants.

Les documents doivent être cryptés afin de garantir la confidentialité des informations qu'ils contiennent. Cela permet également de garantir l'intégrité des données, car celles-ci ne peuvent pas être modifiées lorsqu'elles sont cryptées, et doivent donc d'abord être décryptées pour être modifiées.

Les documents doivent être signés afin de garantir qu'ils sont authentiques et qu'ils émanent de la personne qui a signé le document. Vous êtes également assuré que le document n'a pas été modifié après avoir été signé. Les valeurs de hachage sont comparées et la signature n'est pas valide si le document a été modifié.

Pour que BizTalk Server puisse utiliser ces fonctionnalités de PKI, des certificats numériques doivent être installés sur les serveurs. Les serveurs BizTalk Server qui reçoivent des documents ont besoin de la clé privée de votre organisation pour décrypter les documents entrants, car votre partenaire commercial a crypté ces documents avec votre clé publique. Vos serveurs de réception ont besoin des clés publiques de chacun de vos partenaires commerciaux afin de vérifier les signatures numériques des documents entrants.

Les serveurs BizTalk Server qui traitent et envoient les documents sortants ont besoin de votre clé privée pour signer ces documents. Vos serveurs de traitement ont également besoin des clés publiques de chacun de vos partenaires commerciaux afin de crypter les documents sortants.

Il est indispensable de veiller à empêcher toute personne non autorisée de se procurer votre clé privée. Si un serveur BizTalk Server possédant votre clé privée est attaqué, le pirate ne doit pas pouvoir extraire cette clé. Lorsque vous installez ce certificat, paramétrez l'option de configuration empêchant l'exportation de la clé privée, de sorte que le pirate ne puisse pas usurper votre identité.

Il est également important que vos serveurs BizTalk Server se trouvent derrière le deuxième pare-feu. Cela augmente considérablement la difficulté pour un pirate d'attaquer ces serveurs. Même si vous avez protégé votre clé privée et que vous n'avez pas autorisé son exportation, un pirate peut utiliser votre serveur BizTalk Server pour crypter ou signer des documents, et ainsi usurper votre identité à partir de ce serveur. Il est important de verrouiller vos serveurs et de les contrôler activement afin de détecter toute tentative d'attaque, à l'aide de logiciels de détection d'intrusion.

Enregistrement d'un certificat

Vous devez ajouter votre propre certificat de clé privée au magasin de certificats local de chaque serveur BizTalk Server, de sorte qu'il puisse être utilisé pour signer les messages. Vous devrez également envoyer la clé publique associée à votre certificat à tous les partenaires commerciaux auxquels vous allez envoyer des messages sécurisés, de sorte qu'ils puissent utiliser votre clé publique pour vérifier vos messages et pour crypter les messages qu'ils vous envoient.

Lors de l'enregistrement de votre certificat sur les serveurs BizTalk Server (à l'aide du composant logiciel enfichable Certificats de la console MMC), vous devez ajouter le certificat au magasin de certificats appartenant à la machine locale plutôt qu'à un utilisateur spécifique, afin de permettre à BizTalk Server d'utiliser le certificat indépendamment de l'utilisateur actuellement connecté. Le certificat doit être enregistré dans le dossier Personal du magasin de certificats de l'ordinateur local.

Enregistrement des certificats de vos partenaires commerciaux

Chacun de vos partenaires commerciaux doit vous envoyer son certificat de clé publique de manière à ce que vous puissiez décrypter ses messages et vérifier ses signatures numériques. Les certificats de vos partenaires commerciaux doivent être ajoutés au magasin BizTalk Server sous Certificat (Ordinateur local) de la console Certificats.

Configuration de canaux et de ports de messagerie pour la messagerie sécurisée

Lors de l'utilisation du Gestionnaire de messagerie de BizTalk Server pour définir les échanges de messages que vous souhaitez effectuer avec vos partenaires commerciaux, vous pouvez spécifier des informations de sécurité pour les canaux et les ports de messagerie.

Un canal représente le traitement qui sera effectué sur un message entrant et est utilisé pour acheminer le message vers le port de messagerie (ou groupe de ports) sortant approprié. Lors de l'édition des propriétés d'un canal, vous pouvez spécifier les options de sécurité suivantes :

• un certificat de clé privée pouvant être utilisé pour décrypter le message entrant ;

• un certificat de clé publique pouvant être utilisé pour vérifier la signature du message entrant ;

• un certificat de clé privée pouvant être utilisé pour signer le message sortant.

Un port de messagerie est utilisé pour envoyer un document sortant vers sa destination à l'aide d'un protocole de transport spécifique. Vous pouvez configurer les propriétés du port de messagerie pour crypter ou signer le document, ou les deux, avant le transport. Lors de la configuration des propriétés d'un port de messagerie, vous pouvez spécifier les options de sécurité suivantes :

• un certificat de clé publique pouvant être utilisé pour crypter le document sortant ;

• si oui ou non le document sortant doit être signé à l'aide du certificat de clé privée configuré dans le canal.

Remarque : plusieurs canaux peuvent transférer des documents à un même port de messagerie et chaque canal peut spécifier un certificat différent avec lequel signer le document. Cela signifie que si le port de messagerie est configuré pour signer les documents sortants, il signe chaque document avec le certificat spécifié dans le canal qui a été utilisé pour traiter le document. Tout document passant par un canal sans certificat spécifié ne sera pas signé. Si le port de messagerie est configuré pour ne pas signer les documents, aucun document n'est signé, indépendamment des certificats spécifiés dans un canal.

Autorités de certification et serveurs de certificats

Les certificats numériques sont émis, gérés et conservés par des autorités de certification. En général, il existe deux approches pour la gestion des certificats client. Vous pouvez choisir d'utiliser une autorité de certification publique, telle que Verisign. Dans ce cas, Verisign prend en charge les fonctions administratives de vérification de l'identité de l'organisation, puis d'émission des certificats. Ce type d'arrangement est le plus simple pour démarrer et nécessite moins de surcharge administrative.

Vous pouvez également choisir de gérer votre propre autorité de certification et d'émettre vous-même les certificats. Dans ce cas, vous devez gérer tous les aspects de la vérification de l'identité, ainsi que de l'émission et de la gestion des certificats. Cette méthode offre le contrôle de l'environnement le plus poussé, mais au prix d'une surcharge administrative non négligeable.

Détermination des exigences en termes de sécurité

Lors de l'établissement de vos exigences en termes de sécurité, vous devez tenir compte des aspects du transport qui sera utilisé et du type d'information contenu dans le document.

Transport Authentification Confidentialité Intégrité des données http Certificats du client Authentification de base* Signatures numériques Cryptage PKI Cryptage PKI Signatures numériques HTTPS Certificats du client Authentification de base** Signatures numériques Cryptage des canaux Cryptage des canaux Signatures numériques FTP Mots de passe en texte clair Signatures numériques Cryptage PKI Signatures numériques SMTP (S/MIME) Signatures numériques Cryptage PKI Signatures numériques

* L'authentification de base sur HTTP envoie les mots de passe au format codé BASE 64. Ces mots de passe risquent d'être compromis et doivent être considérés comme non sécurisés.

** L'authentification de base sur HTTPS envoie également les mots de passe au format codé BASE 64. Ces mots de passe sont transmis via un canal crypté et sont considérés comme sécurisés.

Les documents transmis à l'aide de BizTalk Server doivent également être classés dans l'une des catégories suivantes :

• Non classifié. Ce type d'information est librement disponible et considéré comme public. Il peut être facilement mis à disposition sur votre site Web (par exemple, le catalogue de vos produits). Vous devez toujours envisager l'application d'une signature numérique à ces informations afin de garantir qu'elles proviennent bien de vous et qu'elles n'ont pas été modifiées.

• Confidentiel. La divulgation de ce type d'information causerait des dommages à l'organisation. Ce type d'information est lié à des offres ou des devis pouvant occasionner des pertes pour l'organisation si des concurrents se procurent ces informations, ou encore un désagrément pour le client, dû à la divulgation. Lorsque ce type d'information transite sur Internet, les informations ne doivent être transmises que sous forme cryptée.

• Secret. La divulgation de ce type d'information causerait des dommages sérieux à l'ensemble de l'organisation. Ce type d'information concerne les informations de règlement, telles que les numéros de carte bancaire, ou toute autre information pouvant être utilisée à des fins malveillantes, et ne doit jamais être divulgué. Seules les personnes autorisées peuvent accéder à ces informations, lesquelles sont presque toujours stockées et transmises sous forme cryptée.

Le tableau suivant récapitule comment divers protocoles prennent en charge différents niveaux de sécurité.

Transport Non classifié Confidentiel Secret http Pas de cryptage. Signature numérique facultative. Cryptage PKI de bout en bout. Signature numérique facultative. Stocké au format crypté à l'aide du cryptage PKI avec signature numérique. HTTPS Signature numérique facultative. Cryptage de bout en bout à l'aide du cryptage de canal (SSL, TLS, etc.). Signature numérique facultative. Stocké au format crypté à l'aide du cryptage PKI avec signature numérique. FTP Pas de cryptage. Signature numérique facultative. Cryptage PKI de bout en bout. Signature numérique facultative. Stocké au format crypté à l'aide du cryptage PKI avec signature numérique. SMTP (S/MIME) Pas de cryptage. Envoi à l'aide de MIME. Cryptage de bout en bout à l'aide de S/MIME. Signature numérique facultative. Cryptage de bout en bout à l'aide de S/MIME et signature numérique. Stocké au format crypté par accès programmé à PKI depuis l'application.

Planification de la fonctionnalité Message Queuing

Dans de nombreux scénarios, Message Queuing est le moyen le plus efficace de communiquer avec BizTalk Server, en raison de sa fonctionnalité de distribution fiable et peu couplée. Celles-ci comprennent :

• Messages entrants postés via HTTP ou HTTPS vers une application ASP (Active Server Page).

  Lorsqu'un document est publié vers une application ASP, Message Queuing peut l'envoyer à BizTalk Server.

• Documents sortants à destination d'applications professionnelles.

  Une fois un message reçu et traité par BizTalk Server, il peut être placé dans une file d'attente de messages et envoyé à une application professionnelle. L'application peut lire le message à partir de la file d'attente de messages, ou le message peut être routé par l'intermédiaire du pont MSMQ/MQ Series vers un environnement de grands systèmes en vue du traitement par une application MQ Series.

• Documents entrants en provenance d'applications professionnelles.

  De la même façon, lorsqu'une application professionnelle doit envoyer un document à BizTalk Server, elle peut placer ce document dans une file d'attente.

• Orchestration XLANG.

  L'orchestration repose en grande partie sur l'utilisation de Message Queuing, car il s'agit d'une des technologies d'intégration utilisées pour lier des applications, notamment BizTalk Messaging.

Remarque : la limite physique de la quantité de données pouvant être contenues dans une file d'attente est de 2 gigaoctets. Chaque message peut contenir jusqu'à 2 Mo de données non Unicode (car BizTalk Server convertit les données au format Unicode) ou 4 Mo de données Unicode.

Planification de l'installation de Message Queuing

Message Queuing est livré avec Windows 2000 Server. Cependant, ce service n'est pas installé par défaut et doit être ajouté à chaque serveur qui prendra part à des communications basées sur Message Queuing.

Les serveurs qui doivent être équipés du service Message Queuing sont les suivants :

• tous les serveurs IIS qui envoient des messages à BizTalk Server ;

• les serveurs BizTalk Server du réseau VLAN de l'infrastructure ;

• le serveur de cluster Message Queuing du réseau VLAN de l'infrastructure.

Message Queuing est utilisé pour envoyer les messages du groupe de serveurs Web vers les serveurs BizTalk Server du réseau VLAN de l'infrastructure. Il faut alors autoriser le trafic Message Queuing à passer par le pare-feu, ce qui est possible en permettant le passage du trafic par le port 1801.

Lors de l'installation de Message Queuing, il est important d'installer Message Queuing Server plutôt qu'un client dépendant. Cela permet à Message Queuing de stocker les messages localement, ainsi que d'envoyer et de recevoir des messages, et donc de fournir un service d'annuaire de file d'attente, même en l'absence de connexion à un annuaire Active Directory™ offrant un service d'annuaire de file d'attente.

Planification de la disponibilité élevée de Message Queuing

En cas de défaillance d'un serveur de réception qui héberge une file d'attente de messages, un point de défaillance est introduit. Bien entendu, Message Queuing étant peu couplé, aucun message n'est perdu en cas d'échec du serveur de réception pour une raison quelconque, car les serveurs d'envoi conservent les messages dans une file d'attente locale, jusqu'à ce que le serveur de réception soit de nouveau disponible. Cependant, si votre entreprise ne peut pas tolérer d'interruption ou de perte potentielle de messages en raison d'une panne de disque dur dans les serveurs BizTalk Server qui hébergent les files d'attente de messages de destination, vous pouvez garantir une disponibilité très élevée de Message Queuing en procédant de la façon suivante :

• Installez Message Queuing sur un cluster de serveur à des fins de basculement. Le cluster de serveur héberge les files d'attente locales auxquelles les serveurs du groupe Web envoient des messages par transaction.

• Mettez en place un "service de déploiement" dans le même serveur de cluster afin de procéder à des lectures transactionnelles à partir de files d'attente locales pour les messages entrants, puis d'envoyer les messages dans une transaction vers les files d'attente locales désignées dans les serveurs BizTalk Server. Le service de déploiement doit être configuré pour assurer l'équilibrage de charge des messages entrants sur les multiples files d'attente locales de ces serveurs. En général, l'équilibrage de charge est réalisé grâce à une méthode de répétition alternée.

• Configurez des fonctions de réception redondantes dans les serveurs BizTalk Server d'un groupe. Les fonctions de réception de chaque serveur BizTalk Server doivent être configurées pour lire les files d'attente locales par l'intermédiaire de transactions et pour envoyer le message au serveur BizTalk Server en vue du traitement.

Remarque : le principal motif pour disposer d'un service de déploiement est d'assurer l'équilibrage de charge des messages sur les files d'attente locales de chacun des serveurs BizTalk Server de réception. La seule alternative pour assurer cet équilibrage de charge des messages consisterait à faire en sorte que tous les serveurs BizTalk Server contrôlent une même file d'attente distante. Cependant, Message Queuing ne prend pas en charge les lectures transactionnelles à partir d'un ordinateur distant. Vous pouvez donc perdre des données, lorsque les fonctions de réception entre les serveurs BizTalk Server sont configurés pour lire les messages à partir de files d'attente distantes si, par exemple, le serveur ou le transport présentent des défaillances. La lecture non transactionnelle n'est donc pas recommandée.

Le cluster Message Queuing peut être le même que celui sur lequel l'orchestration BizTalk Server est hébergée. Le cluster de serveur se trouve dans le réseau VLAN de l'infrastructure, l'isolant ainsi de la zone DMZ. Cette conception fait que le serveur de cluster est également directement accessible à partir du réseau VLAN de l'infrastructure.

Remarque : ce cluster de serveur peut également être utilisé pour héberger les ressources du partage de fichiers pour les répertoires virtuels vers lesquels pointent les serveurs FTP de la zone DMZ. La solution de mise en cluster offre donc également une disponibilité élevée des services FTP.

Pour en savoir plus sur l'installation de Message Queuing sur un cluster de serveur, consultez la documentation de Windows 2000.

Planification de files d'attente pour une évolutivité élevée

Dans de nombreux cas, un seul serveur de réception doté du matériel approprié pourra parfaitement prendre en charge la fonction de lecture des messages de la file d'attente, tout en étant capable de participer au traitement des éléments de la file d'attente. Dans certains cas impliquant la réception de très gros volumes de messages ou mettant en œuvre une procédure complexe de traitement des messages, vous pouvez optimiser les performances en configurant un serveur BizTalk Server en tant que serveur dédié de lecture des files d'attente de messages ; cela permet d'éviter qu'il ne participe au traitement et donc d'avoir à ajouter des serveurs au groupe BizTalk Server pour traiter la charge de travail.

Dans certains cas rares, lorsque l'unique serveur de réception a du mal à traiter rapidement les messages des files d'attente, vous pouvez envisager de répartir la tâche de lecture des messages entre plusieurs serveurs BizTalk Server. Dans ce cas, le service de déploiement hébergé sur le cluster de serveur Message Queuing doit être configuré pour l'équilibrage de charge des messages entrants entre les serveurs BizTalk Server.

Planification de la sécurité

Vous pouvez sécuriser les files d'attente en mettant en place des listes de contrôle d'accès, afin de limiter le nombre d'utilisateurs autorisés à lire ou à écrire dans une file d'attente, et en cryptant les données des files d'attente. Pour en savoir plus sur la sécurisation des files d'attente, consultez la section "Message Queuing" de la documentation Windows 2000.

Planification de vos files d'attente

Les files d'attente que vous créez pour transmettre des documents vers et depuis BizTalk Server doivent être des files d'attente locales, de manière à ce qu'elles puissent lire les messages de manière transactionnelle. Les lectures transactionnelles à partir de files d'attente de messages distantes ne sont pas prises en charge dans Message Queuing version 2.0 ou antérieure.

BizTalk Server peut recevoir des messages à l'aide d'une fonction de réception, laquelle doit être configurée pour contrôler les files d'attente locales.

Planification de l'envoi de messages

Vous devez utiliser le mode d'adressage au format direct lors de l'adressage d'une file d'attente de messages. Cela permet d'indiquer à Message Queuing qu'il ne doit pas utiliser le service d'annuaire pour obtenir des informations de routage. Lorsqu'un nom au format direct est utilisé, toutes les informations de routage sont extraites du nom de format et Message Queuing envoie les messages à la file d'attente en une seule fois, sans interroger la base de données Message Queuing centrale dans Active Directory, ce qui améliore considérablement les performances.

La syntaxe suivante est utilisée lors de l'adressage d'une file d'attente locale privée à l'aide du mode d'adressage au format direct :

QueueInfoObject.formatname = "Direct=OS:NomOrdinateur\private$\NomFiled'attente"

Configuration de la messagerie BizTalk Server pour l'utilisation de files d'attente

BizTalk Server peut à la fois envoyer et recevoir des messages à l'aide de Message Queuing. Les documents entrants peuvent être lus à partir d'une file d'attente à l'aide d'une fonction de réception ou d'un planning XLANG, et les documents sortants peuvent être envoyés à une file d'attente en configurant un port de messagerie pour qu'il utilise le protocole Message Queuing ou le planning XLANG pour la liaison avec la file d'attente de messages.

Réception de documents à l'aide d'une file d'attente

Pour configurer BizTalk Server pour la réception de documents à partir d'une file d'attente de messages, vous devez utiliser l'outil d'administration de BizTalk Server pour créer une fonction de réception qui contrôle une file d'attente spécifique. Comme cela a été indiqué précédemment, il doit s'agir d'une file d'attente locale, de sorte que les lectures transactionnelles puissent être prises en charge.

Tous les messages placés dans la file d'attente contrôlée sont automatiquement lus par BizTalk Server et placés dans la file d'attente des éléments de travail en vue de leur traitement.

Envoi de documents à l'aide d'une file d'attente

Pour envoyer un document à l'aide d'une file d'attente de messages, vous devez configurer le port de messagerie utilisé pour transmettre le document sortant ou le planning XLANG afin qu'il utilise le protocole Message Queuing, et vous devez spécifier le nom de la file d'attente à laquelle les messages doivent être envoyés.

Interfonctionnement avec les environnements IBM

Message Queuing peut être utilisé pour l'intégration avec d'autres solutions IBM fonctionnant dans un environnement IBM AS400, OS/390 ou AIX. Pour envoyer des messages vers ces environnements, vous devez installer Microsoft Host Integration Server 2000 et utiliser le pont MSMQ/MQ Series pour router les messages d'une file d'attente Microsoft Message Queuing vers une file d'attente IBM MQ Series. Pour en savoir plus sur le pont MSMQ/MQ Series, consultez la documentation de Host Integration Server 2000.

Planification de communications HTTP/HTTPS

Les protocoles les plus couramment utilisés sur Internet sont HTTP et sa version sécurisée, HTTPS. Votre solution BizTalk Server peut utiliser des fichiers ASP dans un site Web pour recevoir des documents entrants via HTTP ou HTTPS. Ces documents peuvent ensuite être passés à BizTalk Server à l'aide de l'interface COM IInterchange ou d'une file d'attente de messages. Les ports sortants peuvent être configurés pour l'envoi de messages à l'aide du protocole HTTP ou HTTPS vers une URL spécifiée.

Réception de documents à l'aide de HTTP ou HTTPS

Pour recevoir des documents à l'aide de HTTP ou HTTPS, vous devez publier un site Web à l'aide de IIS, vers lequel des documents peuvent être envoyés. Dans la plupart des cas, votre site Web contiendra une page ASP utilisée pour recevoir le document entrant et l'acheminer vers BizTalk Server.

Dans un site à volume élevé, il est recommandé de créer une extension de filtre ISAPI plutôt que d'utiliser une page ASP pour placer les documents dans une file d'attente de messages. Cela augmente considérablement le débit lorsque le site Web traite un volume élevé de documents entrants. 

Pour optimiser l'évolutivité, il est recommandé de créer un groupe de serveurs Web utilisant l'équilibrage de charge réseau Windows ou une technologie d'équilibrage de charge similaire.

Prise en charge de connexions SSL

Pour prendre en charge les communications HTTPS, vous devez installer un certificat numérique sur vos serveurs Web et configurer le site pour autoriser les connexions SSL (Secure Sockets Layer). Vous devez considérer cela comme l'exigence minimale de sécurité dans un scénario de type entreprise à entreprise, car elle permet l'authentification du serveur et offre des services de cryptage pour les échanges de documents via la connexion.

En outre, vous souhaiterez peut-être désactiver l'accès anonyme au site et imposer l'authentification de vos partenaires commerciaux.

Envoi de documents à BizTalk Server

Lorsqu'un script ASP ou une extension de filtre ISAPI reçoit un document, il/elle doit contenir du code spécifique pour envoyer ce document à BizTalk Server. Bien qu'il existe différentes approches pour l'exécution de cette tâche, votre code placera en général le document dans une file d'attente de messages contrôlée par BizTalk Server, ou enverra le document à BizTalk Server à l'aide de la méthode Submit ou SubmitSync de l'interface COM IInterchange.

Dans la plupart des cas, votre application doit inclure du code qui lit le message entrant et le place dans une file d'attente de messages. Le message peut ensuite être passé à BizTalk Server de façon peu couplée, comme cela est décrit dans la section précédente. Gardez à l'esprit que la taille limite des documents dans la file d'attente de messages est de 2 Mo.

Vous pouvez également utiliser l'interface IInterchange pour envoyer des messages. Cependant, cette approche soulève plusieurs problèmes :

• L'envoi programmable n'utilise pas la mise en cache ; les performances ne seront donc peut-être pas aussi bonnes qu'avec l'utilisation d'une fonction de réception, laquelle peut mettre en cache plusieurs messages. L'envoi par programmation donne lieu à des performances deux à trois fois inférieures.

• L'envoi de documents est étroitement couplé. Si le serveur BizTalk Server n'est pas disponible, l'envoi ne peut pas avoir lieu.

Remarque : comme nous l'avons vu dans la section "Planification de la fonctionnalité Message Queuing" plus tôt dans ce chapitre, la taille des messages est limitée à 2 Mo lors de l'utilisation de Message Queuing pour envoyer les documents entrants aux serveurs BizTalk Server via une file d'attente de messages. Un autre moyen de traiter cette situation consiste à faire en sorte que le serveur Web de la zone DMZ publie le document entrant vers les serveurs BizTalk Server du réseau VLAN de l'infrastructure via une page ASP sur les serveurs IIS. La page ASP peut implémenter les différentes méthodes, comme par exemple l'objet XMLHTTP dans MSXML 3.0, le protocole basé sur SOAP ou les services Web, lors de l'envoi du document. Cette approche supprime la restriction relative à la taille des messages. Pour obtenir évolutivité et disponibilité, les serveurs BizTalk Server et hébergeant les serveurs IIS doivent utiliser l'équilibrage de la charge réseau. La page ASP appelée par les serveurs Web dans la zone DMZ envoie ensuite le document entrant à BizTalk Server via IInterchange.

Envoi de documents à l'aide de HTTP ou HTTPS

Pour envoyer des documents à l'aide de HTTP ou HTTPS, vous devez utiliser le Gestionnaire de messagerie de BizTalk Server pour configurer les propriétés du port de messagerie utilisé pour transmettre votre document. Vous pouvez définir le protocole de transport sortant sur HTTP ou HTTPS et spécifier l'URL vers laquelle envoyer le document.

Pour que BizTalk Server puisse envoyer avec succès des documents à l'aide de HTTP ou HTTPS, il doit pouvoir envoyer des données vers Internet. Si BizTalk Server est installé derrière un pare-feu, les ports du pare-feu doivent être configurés pour autoriser le trafic sortant sur le port 80 pour les données HTTP et sur le port 443 pour les données HTTPS. Dans le centre IDC, BizTalk Server peut être installé dans le réseau VLAN de l'infrastructure derrière deux pare-feu (utilisés pour créer une zone DMZ pour le groupe de serveurs Web). Dans ce cas, la configuration du pare-feu peut s'avérer plus complexe, nécessitant le chaînage des pare-feu et l'autorisation du seul trafic sortant.

Planification des communications via FTP et via le système de fichiers

Vous pouvez prendre en charge l'envoi de documents à BizTalk Server à l'aide de FTP en créant une fonction de réception de fichiers qui contrôle le répertoire virtuel pointé par le site FTP.

Création d'un site FTP

Pour permettre l'envoi de documents par FTP, vous devez créer un site FTP à l'aide de IIS. En fonction du volume des envois FTP que vous prévoyez de recevoir, vous pouvez choisir de mettre en cluster le site FTP sur plusieurs serveurs IIS et de configurer le répertoire virtuel FTP pour faire référence à un dossier physique unique sur un serveur distant dans le réseau VLAN de l'infrastructure. Ce scénario est illustré à la figure 8.

Lors de la conception d'une solution pour un niveau très élevé de disponibilité, vous pouvez configurer les ressources de partage de fichiers dans le cluster de serveur pour qu'elles pointent vers des dossiers physiques du réseau local de stockage (SAN, Storage Area Network) ou des batteries de disques SCSI. Une fois cela effectué, vous pouvez configurer les répertoires virtuels dans le serveur FTP afin d'utiliser les notations UNC pour référencer les répertoires physiques en cluster, comme par exemple \\serveur\partage.

Figure 8. Racines virtuelles FTP faisant référence à un dossier distant

Remarque : l'accès à ces répertoires virtuels dans le réseau VLAN de l'infrastructure à partir des serveurs FTP de la zone DMZ doit être autorisé à travers le deuxième pare-feu. Cette configuration peut être implémentée de façon sécurisée à l'aide d'une stratégie IPSEC et en autorisant le port 445 à accéder au partage de fichiers.

Le site FTP doit nécessiter l'authentification intégrée de Windows afin de garantir un niveau minimum de sécurité. En outre, vos partenaires commerciaux doivent être affectés à des dossiers spécifiques pour le dépôt des documents entrants et pour la lecture des documents sortants traités par les serveurs BizTalk Server.

Remarque : des outils de contrôle réseau peuvent être utilisés pour "détecter" les mots de passe envoyés à un site FTP. Pour cette raison, vous devez utiliser le cryptage PKI et la signature numérique dans les applications pour lesquelles la sécurité est une priorité essentielle.

Envoi de documents FTP à BizTalk Server

Une fois un document placé dans un dossier FTP du serveur Message Queuing en cluster, les fonctions de réception des serveurs BizTalk Server peuvent être configurées pour contrôler le dépôt de fichiers dans le dossier FTP. Une fois un fichier déposé dans le dossier, la fonction de réception l'envoie à BizTalk Server en vue du traitement.

Configuration d'une fonction de réception de fichier pour le dossier FTP

La méthode la plus simple de transmettre les documents soumis à l'aide de FTP à BizTalk Server est d'utiliser le partage de fichiers de Windows 2000 pour partager le dossier FTP. Créez une fonction de réception sur un serveur BizTalk Server ou plus qui surveille l'ajout de nouveaux fichiers au dossier partagé. La fonction de réception peut être configurée pour contrôler un partage distant.

Utilisation du système de fichiers pour communiquer avec les applications

Des documents peuvent être échangés avec les applications internes via le système de fichiers. BizTalk Server peut lire les documents des dossiers du système de fichiers à l'aide d'une fonction de réception, comme cela a été décrit plus haut. En outre, BizTalk Server peut envoyer des documents à des emplacements du système de fichiers en configurant un port de messagerie pour qu'il utilise le protocole de fichier et en spécifiant le dossier de destination.

Pour garantir la sécurité appropriée, vous devez utiliser les autorisations NTFS de Windows pour limiter l'accès aux dossiers contenant des documents sensibles. Vous pouvez également envisager l'utilisation de l'audit NTFS pour enregistrer l'accès du système de fichiers au dossier. D'autres fonctions de sécurité peuvent être mises en place grâce au cryptage et à la signature des documents à l'aide de certificats PKI, comme cela a été décrit plus haut.

Planification de communications SMTP

Le courrier électronique SMTP est utilisé pour une large part des communications sur Internet. Dans certains cas, vous souhaiterez peut-être autoriser des applications à échanger des documents professionnels par courrier électronique.

Planification de la sécurité

Lors de l'échange de documents professionnels par courrier électronique, vous devez garantir la sécurité des documents à l'aide des instructions détaillées dans la section "Planification de la sécurité Internet", plus haut dans ce chapitre. Tout message électronique qui achemine des documents professionnels doit être signé et crypté à l'aide de certificats numériques.

Lors de l'envoi de documents professionnels signés et cryptés à l'aide de SMTP, BizTalk Server utilise la clé publique d'un partenaire commercial pour les crypter. Si la signature numérique du document est également requise, BizTalk Server utilise également sa propre clé privée pour les signer.

Remarque : aucun serveur ne doit héberger des magasins de certificats dans la zone DMZ, laquelle peut contenir des clés publiques/privées. Cela présenterait un grave risque en termes de sécurité.

Lorsque la solution BizTalk Server reçoit par courrier électronique des documents cryptés et signés en provenance d'un partenaire commercial, ces documents arrivent dans une zone de relais SMTP de la zone DMZ. Ce serveur fonctionne uniquement comme routeur de courrier électronique SMTP vers un serveur Exchange Server 2000 derrière le deuxième pare-feu du réseau VLAN de l'infrastructure.

Avec cette architecture, vous devez installer une zone de relais SMTP et un serveur Microsoft Exchange Server 2000.

Zone de relais SMTP dans la zone DMZ

La zone de relais SMTP est hébergée sur le même serveur Windows 2000 que celui sur lequel sont installés les serveurs FTP et DNS ; elle sert uniquement de routeur pour les messages électroniques échangés avec Microsoft Exchange Server 2000 dans le réseau VLAN de l'infrastructure. La zone de relais SMTP fonctionne comme hôte intelligent dans le centre IDC. Aucune vérification de sécurité n'est effectuée sur le courrier électronique entrant ou sortant.

Exchange Server dans le réseau VLAN de l'infrastructure

Ce serveur Microsoft Exchange Server 2000 reçoit les messages électroniques des partenaires commerciaux par le biais du serveur SMTP Exchange Server 2000 de la zone DMZ. Lorsque BizTalk Server envoie du courrier électronique, celui-ci doit être configuré pour être envoyé au serveur Exchange Server 2000 du réseau VLAN de l'infrastructure, lequel doit ensuite transférer le courrier sortant vers le serveur Exchange Server 2000 de la zone DMZ.

Planification de la réception de courrier électronique SMTP

BizTalk Server ne prend pas directement en charge la réception de courrier électronique. Pour permettre aux partenaires commerciaux d'envoyer des documents professionnels via le protocole SMTP, vous devez utiliser un système de courrier électronique prenant en charge les événements de programmation et la personnalisation, comme par exemple Microsoft Exchange Server 2000 dans le réseau VLAN de l'infrastructure. Vous devez ensuite créer une boîte de réception pour votre application BizTalk Server et écrire du code personnalisé à exécuter lors de la distribution d'un nouveau message. Votre code personnalisé doit placer le message dans une file d'attente de messages contrôlée par la fonction de réception d'un serveur BizTalk Server, ou utiliser l'interface IInterchange pour envoyer le message reçu à BizTalk Server (même si, comme cela a été dit plus haut, cette approche n'est pas recommandée pour des raisons liées aux performances).

Remarque : la méthode utilisée pour envoyer le document par courrier électronique à BizTalk Server être très similaire à celle utilisée avec les protocoles HTTP ou HTTPS, comme cela a été expliqué dans la section "Réception de documents à l'aide de HTTP ou HTTPS", plus haut dans ce chapitre.

Exchange Server 2000 offre un modèle de programmation piloté par les événements, par l'intermédiaire de VBA (Visual Basic for Applications), lequel peut être utilisé pour traiter les messages entrants en plaçant le message dans une file d'attente ou en appelant la méthode Submit de l'interface IInterchange.

Le document envoyé reste crypté et signé. BizTalk Server doit être configuré pour effectuer le décryptage des documents professionnels signés et cryptés reçus par courrier électronique, en vue de leur authentification.

Planification de l'envoi de courrier électronique SMTP

Pour que votre solution BizTalk Server puisse envoyer du courrier électronique aux partenaires commerciaux, vous devez utiliser l'outil d'administration de BizTalk Server afin de configurer votre groupe BizTalk Server pour qu'il utilise le serveur Exchange Server 2000 du réseau VLAN de l'infrastructure pour le courrier sortant.

Pour envoyer du courrier électronique SMTP, vous devez configurer le port de messagerie sortant pour que votre message utilise le protocole de transport SMTP et vous devez spécifier l'adresse de destination (par exemple, individu@microsoft.com). Les ports de messagerie configurés pour utiliser le cryptage effectueront ce cryptage à l'aide du codage S/MIME.

Planification de l'orchestration

BizTalk Server Orchestration est utilisé pour automatiser les processus professionnels nouveaux et longs. Chaque processus professionnel est conçu à l'aide de l'outil de conception BizTalk Orchestration et est compilé en un planning XLANG, lequel est exécuté à l'aide d'un composant COM+ XLANG Scheduler.

Planification d'une architecture BizTalk Orchestration

Pour obtenir une disponibilité élevée et des fonctions de basculement, vous devez avoir dédié des serveurs BizTalk Server à BizTalk Orchestration dans un environnement en cluster avec basculement à instance unique. Pour une évolutivité maximale, ces serveurs ne doivent pas être configurés pour participer à la réception ou au traitement de documents par l'intermédiaire de BizTalk Messaging.

Remarque : vous pouvez empêcher le serveur de participer au service de réception en ne créant aucune fonction de réception pour ce serveur. Vous pouvez également configurer le serveur de manière à ne pas participer au traitement des éléments de travail en désactivant l'option Participate in Work-Item Processing (Participer au traitement des éléments de travail) dans les propriétés du serveur d'orchestration dans l'outil d'administration de BizTalk Server. La désactivation du traitement des éléments de travail ne signifie pas que BizTalk Messaging est désactivé. Cela signifie simplement qu'il n'interroge pas le serveur SQL Server pour la participation au traitement des éléments de la file d'attente. Cette configuration permet au serveur d'orchestration d'exécuter BizTalk Messaging si un planning XLANG le lui demande. BizTalk Messaging est un des objets disponibles dans le planning XLANG.

Dans la mesure où tous les serveurs de traitement délèguent au serveur d'orchestration le travail associé à un planning XLANG, ces serveurs de traitement ne doivent pas être configurés pour faire appel directement à des plannings XLANG dans le port de messagerie. En revanche, vous devez leur imposer de faire appel au service d'orchestration à l'aide d'un message d'une file d'attente de messages, lequel est contrôlé par un composant personnalisé de traitement des messages que vous avez créé. Le composant personnalisé doit être conçu pour lire les messages d'une file d'attente et pour faire appel à un planning XLANG pour traiter le message.

Pour configurer un serveur BizTalk Server pour l'orchestration et un composant de service personnalisé :

1. Installez le service de cluster pour les serveurs BizTalk Server et Message Queuing pour l'orchestration dans un groupe BizTalk Server.

2. Configurez le serveur BizTalk Server pour l'orchestration, de sorte qu'il ne participe pas au traitement des éléments de travail. Vous pouvez utiliser l'outil BizTalk Server Administration pour configurer ce paramètre.

3. Assurez-vous qu'aucune fonction de réception du groupe BizTalk Server ne s'exécute sur ce serveur BizTalk Server. Vous pouvez utiliser l'outil BizTalk Server Administration pour vérifier les paramètres.

4. Créez un composant de service personnalisé qui contrôle les files d'attente de messages afin de détecter tout nouveau message placé par les serveurs de traitement. Une fois le message supprimé de la file d'attente, le composant de service instancie un planning XLANG désigné. Une fois l'objet planning XLANG instancié, l'ensemble des documents professionnels du message peut être envoyé à l'objet d'instance du planning XLANG en vue du traitement.

Remarque : des problèmes de stabilité peuvent se produire lorsque trop de plannings sont activés dans un environnement multithread, contribuant alors à une situation d'intense sollicitation. Cependant, si le composant personnalisé est créé à l'aide de Visual Basic, il risque "d'accélérer" l'activation des plannings, car le composant de Visual Basic fonctionne dans l'environnement compartimenté et supprime un par un les messages d'une file d'attente. Au cours de la phase de test de l'application, les développeurs peuvent augmenter la charge d'activation des plannings en augmentant le nombre de messages de la file d'attente contrôlée par le composant personnalisé. Si le traitement des plannings XLANG ne peut pas maintenir le rythme de suppression des messages de la file d'attente et les opérations correspondantes d'activation des plannings, cela peut indiquer que l'opération de suppression des messages de la file d'attente doit encore être "accélérée". En général, un délai dans le composant personnalisé procédera à cette "accélération". Lorsque XLANG est surchargé en raison d'une situation d'intense sollicitation, il commence à enregistrer des erreurs dans le journal de l'application.

Optimisation de la base de données XLANG

Le planificateur XLANG nécessite des lectures et écritures fréquentes dans la base de données XLANG, en particulier lorsque des transactions sont implémentées et que des intervalles d'expiration sont utilisés. Le faible débit des instances de planning XLANG peut être provoqué par des goulets d'étranglement dans la base de données (XLANG) de persistance.

BizTalk Server utilise la base de données XLANG pour la persistance des plannings d'orchestration. Lors de la conception d'une application en vue d'une forte sollicitation, la base de données de persistance doit se trouver sur un canal de disque distinct des autres bases de données du serveur SQL Server. Une autre conception recommandée consiste à placer la base de données sur un agrégat de disques et les journaux de transactions sur un autre agrégat de disques.

Optimisation des plannings XLANG

Pour optimiser les plannings XLANG, les développeurs doivent comprendre les problèmes de thread d'exécution liés à la création de composants qui sera implémentée dans les plannings XLANG.

Le moteur de planification est configuré pour s'exécuter dans un compartiment multithread et le moteur peut utiliser un groupe limité de threads pour appeler les composants qui doivent s'exécuter dans des compartiments à thread unique, tels que les composants Visual Basic.

Lorsqu'un planning inclut des composants Visual Basic (avant Visual Basic .NET), cela risque de réduire les performances, car les composants Visual Basic s'exécutent dans des compartiments à thread unique. Ces composants peuvent en bloquer d'autres s'il y a de nombreux appels simultanés en attente. Cette situation peut conduire à des verrous et provoquer l'interruption d'instances de planning.

Une alternative à ce scénario consiste à développer une solution hautement évolutive en créant des composants C++ dans un compartiment multithread, plutôt que d'utiliser Visual Basic.

Planification de la gestion et de l'exploitation

Une fois une solution BizTalk Server 2000 créée, celle-ci nécessite généralement peu de maintenance. Cependant, certains problèmes de gestion doivent être prévus et pris en considération.

Outils de gestion

BizTalk Server est livré avec un certain nombre d'outils qui peuvent être utilisés pour gérer une solution BizTalk Server à la fois d'un point de vue administration du système et d'un point de vue gestion commerciale. Ces outils sont BizTalk Messaging Manager, l'outil BizTalk Administration, BizTalk Editor, BizTalk Mapper, BizTalk Orchestration Designer et le site Web IIS BizTalk Tracking. Vous devez installer des applications de gestion sur un ordinateur qui peut accéder aux serveurs BizTalk Server, à leurs bases de données de configuration et aux sites IIS WebDAV et BizTalkTracking. Dans le centre IDC, où BizTalk Server est installé sur le réseau VLAN de l'infrastructure, vous pouvez installer les outils de gestion de BizTalk Server sur la station de travail de gestion. Cela vous permet d'administrer BizTalk Server lorsque vous êtes connecté localement à la station de travail de gestion, ou à l'aide d'une session des services Terminal Server via une connexion de réseau privé virtuel (VPN, Virtual Private Network).

Remarque : BizTalk Orchestration Designer nécessite l'installation de Visio 2000 ou d'une version ultérieure sur la station de travail de gestion.

Sauvegarde des bases de données BizTalk Server

Dans la mesure où BizTalk Server se base sur les informations de ses bases de données, vous devez planifier une routine de sauvegarde à partir des instructions suivantes :

• La base de données InterchangeBTM contient les informations de configuration de votre solution BizTalk Server. Vous devez procéder à une sauvegarde complète de cette base de données une fois la solution déployée, puis de nouveau après toute modification apportée à la configuration (comme par exemple l'ajout d'un nouveau canal ou d'un nouveau port). Dans la mesure où les données de cette base de données restent statiques au cours du fonctionnement normal, il n'est pas nécessaire de procéder à des sauvegardes régulières de la base de données ou des journaux de transactions.

• La base de données InterchangeSQ contient les éléments de travail envoyés au groupe de serveurs BizTalk Server. Dans la plupart des cas, cette base de données contient des données uniquement de façon temporaire et vous pouvez donc décider de ne pas la sauvegarder. Cependant, si vous ne pouvez pas vous permettre de perdre les messages des files d'attente de nouvelle tentative ou de suspension, vous devez sauvegarder cette base de données.

• La base de données InterchangeDTA contient les données de suivi de vos échanges. Cette base de données doit être sauvegardée régulièrement pour des raisons d'audit légal et de récupération en cas d'incident.

• La base de données XLANG est utilisée pour gérer l'état des processus professionnels longs. Cette base de données doit être sauvegardée régulièrement pour des raisons de récupération en cas d'incident.

Vidage de la base de données InterchangeDTA

Lorsque la fonctionnalité de suivi des documents est utilisée, la taille de la base de données Tracking peut rapidement augmenter. Il est nécessaire d'implémenter la réplication SQL Server ainsi que des procédures de vidage afin de déplacer périodiquement les données de la base de données Tracking vers un data warehouse, ou de les supprimer.

Remarque : pour gérer la base de données Tracking, vous pouvez utiliser un script SQL Server pour supprimer ou déplacer des enregistrements de la base de données Tracking. Vous pouvez trouver un exemple de script dans le dossier \\Program Files\Microsoft BizTalk Server\SDK\Messaging Samples\SQLServerAgentJobs.

Contrôle d'une solution BizTalk Server

De nombreux aspects doivent être contrôlés pour garantir le fonctionnement efficace d'une solution BizTalk Server. Comme dans tout contrôle des performances, vous devez passer un certain temps à recueillir des données de performances lors du premier déploiement de votre solution, afin de disposer d'une base de comparaison. Cela rend plus significatifs les chiffres obtenus lors des contrôles suivants.

Surveillance des serveurs BizTalk Server

Vous devez utiliser le Moniteur système pour examiner l'utilisation du processeur et de la mémoire par les serveurs BizTalk Server configurés pour le traitement des éléments de travail. Si le volume des documents entrants a augmenté et que l'utilisation du processeur n'est pas particulièrement élevée, vous pouvez augmenter le nombre de threads actives et diminuer l'intervalle entre les appels de la file d'attente, afin d'améliorer le débit.

Pour les serveurs de réception, vous devez contrôler le nombre de messages des files d'attente de messages et des emplacements de fichiers qui sont interrogés par les fonctions de réception. Si un retard évident se produit dans le traitement des documents, vous pouvez envisager l'augmentation du nombre de threads de réception. Si cela conduit à une utilisation du processeur nettement supérieure à 80 % pendant une période relativement longue, envisagez l'ajout de processeurs ou l'utilisation de processeurs plus rapides.

Un aspect à contrôler particulièrement est l'utilisation des disques. SQL Server, les files d'attente de messages, les fonctions de réception de fichiers et les fichiers d'échange génèrent tous une activité sur les disques. Vous devez contrôler le compteur % Temps du disque ; si sa valeur dépasse en permanence 100 % (elle peut atteindre jusqu'à 1 000 %), vous devez ajouter des disques durs. La pagination excessive est généralement provoquée par une mémoire insuffisante, mais elle peut être interprétée de façon erronée comme un goulet d'étranglement d'E/S de disque. Lors du contrôle de l'utilisation des E/S, vous devez examiner les compteurs Mémoire / Octets disponibles et Mémoire / Lectures de pages, en parallèle avec les compteurs Disque physique / % Temps du disque et Disque logique / Long. moy. de file d'attente du disque. Si une augmentation de la longueur de la file d'attente s'accompagne d'une diminution du taux de lectures de pages, cela dénote un manque de mémoire.

Fournisseur WMI

BizTalk Server offre des interfaces WMI (Windows Management Instrumentation) pour la gestion et le contrôle. Ces interfaces individuelles se trouvent dans le fichier \Program Files\Microsoft BizTalk Server\Setup\InterchangeProvSchema.mof.

Les objets de gestion WMI de BizTalk Server sont les suivants :

• MicrosoftBizTalkServer_MgmtDB contient des paramètres de chaîne de connexion pour la base de données de gestion de messagerie de BizTalk Server.

• MicrosoftBizTalkServer_Group représente les propriétés et les méthodes BizTalk Server, à l'échelle du groupe, permettant le vidage des éléments des files d'attente de suspension ainsi que l'actualisation des analyseurs.

• MicrosoftBizTalkServer_Server contient les propriétés des serveurs BizTalk Server individuels du groupe BizTalk Server. En outre, il offre des méthodes pour l'arrêt et le démarrage de BizTalk Services.

• MicrosoftBizTalkServer_ReceiveFunction contient les propriétés des fonctions de réception.

• MicrosoftBizTalkServer_Queue contient les propriétés globales des files d'attente.

• MicrosoftBizTalkServer_RetryQueue représente les échanges qui sont en attente de corrélation de réception, ou les échanges qui doivent être envoyés à plusieurs destinations. Cet objet inclut également une méthode de déplacement d'un document vers la file d'attente de suspension.

• MicrosoftBizTalkServer_ScheduledQueue représente les échanges qui sont planifiés pour une distribution ultérieure en fonction d'un intervalle de service. Cet objet inclut également une méthode de déplacement d'un document vers la file d'attente de suspension.

• MicrosoftBizTalkServer_SuspendedQueue représente les échanges qui n'ont pas pu être traités avec succès. Des méthodes permettent également la consultation des documents, des échanges et des descriptions d'erreurs, ainsi que le renvoi de documents.

• MicrosoftBizTalkServer_WorkQueue représente les échanges en cours dans la base de données de file d'attente partagée.

Contrôle des performances des plannings XLANG

Lorsque le moteur de planification XLANG exécute des plannings XLANG, il génère plusieurs types d'événements, montrant ainsi la progression des instances de planification. Vous pouvez utiliser le Moniteur d'événements XLANG pour contrôler les événements de planification XLANG et pour consulter la progression des instances de planification. Vous pouvez contrôler l'application de planification XLANG par défaut ou les applications COM+ personnalisées que vous créez pour héberger des plannings XLANG. Le Moniteur d'événements XLANG peut s'abonner à tous les événements publiés par les applications hôte sur un nombre quelconque d'ordinateurs locaux distribués. Il peut également stocker ces événements dans un fichier en vue de leur analyse ultérieure.

Remarque : pour plus d'informations sur l'utilisation du Moniteur d'événements XLANG, consultez le fichier Lisezmoi.htm associé à cet outil. À la fois le Moniteur d'événements XLANG (XLANGMon.exe) et le fichier Lisezmoi installé par l'Assistant Installation de Microsoft BizTalk Server 2000 se trouvent dans le répertoire d'installation suivant : \\Program Files\Microsoft BizTalk Server\SDK\ XLANG.

Les bases de données qui hébergent la base de données de persistance XLANG doivent être contrôlées à l'aide du Moniteur système de Windows 2000. Si l'utilisation du processeur dépasse 80 %, vous devez ajouter des processeurs ; si la longueur de file d'attente dépasse en permanence 1 ou que les E/S de disque dépassent en permanence 100 %, vous devez ajouter des disques.

Optimisation des performances par l'intermédiaire du Registre

Dans certains cas, les performances peuvent être optimisées par la modification des paramètres du Registre relatifs à BizTalk Server. Comme pour toute intervention sur le Registre, vous devez procéder avec une extrême prudence et uniquement lorsque vos exigences en termes de performances ne peuvent pas être satisfaites à l'aide des outils de gestion classiques.

Vous pouvez ajouter les clés de Registre DWORD suivantes à la clé HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\BTSSVC afin d'optimiser les performances de BizTalk Server :

• NoValidation. L'ajout de cette clé impose à BizTalk Server de ne pas valider les spécifications de documents. Cela peut améliorer les performances, mais cette possibilité ne doit être utilisée que dans les environnements dans lesquels vous disposez d'un contrôle total sur la structure des documents.

• ParserRefreshInterval. L'ajout de cette clé vous permet de spécifier (en millièmes de seconde) la fréquence à laquelle BizTalk Server doit vérifier la présence de nouveaux analyseurs. S'il n'est pas prévu d'ajouter des analyseurs, vous pouvez affecter la valeur 0 à cette clé afin d'éviter des accès inutiles à la base de données.

• CacheSize. Cette clé peut être utilisée pour configurer le nombre maximal d'objets de configuration (canaux, documents, etc.) que BizTalk Server peut conserver en mémoire cache.

• BatchSize. Cette valeur indique le nombre de documents lus par une fonction de réception au cours d'une même transaction.

Pour en savoir plus sur ces clés de Registre, consultez la section Optimisation des paramètres du Registre de la documentation de BizTalk Server 2000.

Résumé

Ce chapitre décrit les principaux aspects à prendre en considération lors de la conception d'une infrastructure pour une solution BizTalk Server.

Les principales décisions que vous devrez prendre concernent l'emplacement du groupe BizTalk Server dans la topologie de votre réseau, les protocoles qui seront pris en charge pour les messages entrants et sortants, l'emplacement et la configuration de vos serveurs de bases de données, ainsi que les processus de gestion et de contrôle que vous utiliserez pour garantir en permanence des performances optimales pour BizTalk Server.

<< 1 2 3 4 5 6 7 8 9 >>

Dernière mise à jour le vendredi 1 mars 2002

Pour en savoir plus

• Lire la version US de cet article

• Ressources techniques sur BizTalk Server