Dans cet article vous trouverez une première compréhension générale de l'architecture de BizTalk.
Cette compréhension est nécessaire avant de nous plonger dans le développement.
BizTalk permet de mettre en place des flux de données à partir d’une origine A vers un destination B. Mais que ce passe-t-il entre ces deux points ? Tel est la question à laquelle nous allons répondre.
Voici une vue très simplifiée de l’architecture de BizTalk :
1. Les données sont reçues par un Receive Port. Les receive ports ne font que transmettre les données en format binaire, sans se soucier du contenu de ce qu’ils transportent.
2. Elles sont acheminées vers une base de données centrale par une Receive Pipeline. C’est lors de cette phase du transport que le mapping sera appliqué aux données binaires pour fournir un format XML comprenant des promoted properties.
3. Ensuite, si des orchestrations sont configurées pour agir sur le type de message reçu, elles seront instanciées. Une orchestration est une étape du processus métier qui est prise en charge par BizTalk.
4. Les Send Pipelines sont l’exact opposé des Receive Pipelines. Ces pipelines vont prendre les données sous format XML et les convertir dans le format destination désiré. Encore une foi grâce à un mapping.
5. Les données sont enfin envoyées au destinataire par un Send Port qui ne se charge que de transmettre les informations binaires au bon endroit.
Pour savoir quelle est l’étape à appliquer à un message à un moment donné, BizTalk garde un fichier supplémentaire, le fichier de contexte.
Ce fichier de contexte possède de nombreuses information tel que :
· Le type du fichier message
· L’historique complet du fichier à travers le processus BizTalk
· Les erreurs éventuelles survenues
· Les différentes promoted properties
C’est sur les valeurs contenues dans ce fichier de contexte que les différentes parties du flux BizTalk, les artefacts, peuvent souscrire.
Ainsi nous allons pouvoir créer, par exemple, une Send Pipeline et la souscrire aux messages ayant un schéma correspondant au XSD « monSchema.xsd » et provenant de l’orchestration « monOrchestration ».
Le moteur interne de BizTalk créera alors toutes les suscriptions T-SQL nécessaire pour instancier cette Send Pipeline à chaque foi que des données correspondante seront insérée dans la MessageBox.
La MessageBox est le cœur de BizTalk. Elle repose sous SQL-Server ce qui nous offre beaucoup de possibilité quand à la fragmentation de cette base de donnée.
Lorsque qu’un fichier est reçu par BizTalk on parle de message. Les messages peuvent-être dupliqué, ainsi si plusieurs artefacts ont une suscription qui correspond à un même message, chacun de ces artefacts recevra une copie autonome du message.
Maintenant que nous avons une vue globale de l’architecture de BizTalk, nous allons pouvoir nous intéresser en détail à chaque artéfact.
Port
Un port est la représentation logique d’une communication physique par laquelle BizTalk reçoit et envoi des messages.
Chaque port est un conteneur qui possède toutes les informations nécessaires à l’établissement d’un canal de communication.
L’élément principal d’un port est l’adaptateurs qu’il utilise. Chaque type de communication possède son adaptateur.
Par exemple, un Send Port utilisant le protocole FTP possèdera un adaptateur FTP ainsi que les configurations suivantes :
· Ip de contact
· Login
· Password
Pour ne citer que les plus évidentes.
Receive Port
Les receive ports ont pour particularité d’être des conteneurs de Port. Ainsi un unique reveive port peut en faite être associé à plusieurs configurations différentes, nommée Receive Location.
Ainsi un receive port attendant des ordres d’achat pourra être composé de plusieurs receive locations :
· La première attendant des fichiers sur un FTP
· La seconde sur le système de fichier d’un serveur
· La troisième par mail
Quelque soit l’origine du fichier reçu, il sera traité de la même manière dans la suite du flux de donnée.
Send Port
En contradiction avec les receive port, les send ports eux ne peuvent contenir qu’un unique port de destination.
Pour palier à ce désavantage, BizTalk offre la possibilité de crée des SendPortGroup, contenant plusieurs Send Port.
Logical Port
Lors de la création d’une orchestration, le programmeur ne sait pas forcément d’où lui viendra les données, ni où il devra les envoyer ensuite.
C’est dans ces cas précis qu’interviennent les ports logiques.
Les ports logiques ne doivent être liés à des ports physiques qu’au moment du déploiement de l’application.
Dynamic Send Port
Ces send ports particulier permettent de définir la destination des messages au moment de l’exécution au lieu de le faire lors déploiement de l’application.
Cette destination doit être définie par déduction sur des promoted properties.
Adaptateur
Les adaptateurs sont les interfaces de communication de BizTalk autant en entrée qu’en sortie.
La plupart du temps, les adaptateurs ne sont que des interfaces de communication basée sur un protocole de transport donné. Ils n’ont donc aucune compréhension interne des données qu’ils transportent.
Leur unique utilité est de nourrir et de délester la machinerie de BizTalk.
Dans le cas d’adaptateur de réception, deux modes principaux existent :
· Le pooling : de temps à autre l’adaptateur vérifie le contenu d’un répertoire (ou autre) pour vérifier si des messages attendu par BizTalk ne s’y trouve pas. C’est le cas du « File System Adaptater ».
· L’écoute : l’adaptateur est en attente d’un événement en provenance su monde extérieur pour se réveiller.
Lorsqu’un message est reçu par un adaptateur, contrairement à ce que l’on dessine habituellement, il n’est pas envoyé directement à une receive pipeline mais passe d’abord par la MessageBox.
C’est le « Message Engine » de BizTalk qui à la charge de transmettre ce message de la MessageBox a la receive pipeline appropriée.
Un adaptateur des plus important est le « SQL Adaptater », en effet, la MessageBox reposant sur une base de données SQL Server, chaque communication interne à BizTalk repose sur cet adaptateur.
Pipeline
Les pipelines ont pour fonction d’effectuer des traitements de données sur les messages entrants ou les messages sortants. Cet aussi cet artéfact qui à comme responsabilité la validation de ces messages.
Par traitements de données ont entent principalement tout ce qui est sécurité (cryptage/décryptage, signature).
BizTalk fournit 4 pipelines basiques qui permettent de remplir toutes les fonctions les plus couramment utilisées :
· Receive Pipeline
o XmlReceive : permet de recevoir des messages XML et de les valider
o PassThruReceive : permet de recevoir des messages sous format flat file
· SendPipeline
o XmdTransmit : permet d’envoyer des messages XML et de les valider
o PassThruTransmit : permet d’envoyer des messages sous format flat file
Comme son nom l’indique, un pipeline est un suivit d’opérations les unes aux suites des autres. Dans un pipeline l’ordre des opérations est très important, en effet, a quoi bon par exemple essayer de valider un fichier XML qui n’a pas été décrypté.
Pour simplifier la mise en place de pipeline, BizTalk à séparé en grands groupes les type d’opérations pouvant être effectuée sur un message.
Receive Pipeline Operation Group :
1. Décode : cette étape sert à décoder les messages d’un format externe à un format lisible par les autres composants. Le plus commun des cas de décode est sans nul doute le décryptage.
2. Désassemble : en fonction du type de message, cette étape va soit traduire le message d’origine en un message XML, soit découper le message en plusieurs sous-messages plus conforme à l’implémentation du flux.
3. Validation : valide un message à partir d’un schéma.
4. Résoudre les partenaires : cette étape est principalement utilisée pour certifier la provenance des messages reçus.
Send Pipeline Operation Group :
1. Pré-assemble : cette étape et le dernier point de modifications des données par le flux BizTalk, généralement utilisée pour faire des transformations de dernière minute sur le XML interne de BizTalk avant qu’il ne soit transformé en flat file.
2. Assemble : utilisation d’un schéma pour transformer un ou plusieurs messages en un message respectant le format convenant au destinataire.
3. Encore : à l’inverse de décode, cette phase est utilisée pour crypter les données. (Un autre exemple est la compression des données)
De nombreux composant de pipelines effectuant ce genre d’opération sont inclus dans BizTalk mais il est toujours possible d’écrire nos propres composants ou d’en acheter de nouveau, comme d’habitude.
Orchestration
Les orchestrations permettent au développeur BizTalk d’implémenter un processus métier à travers un outil de dessin : l’Orchestration Designer.
Cet outil permet d’exprimer le processus métier via une série de forme glissée sur la surface de dessin à partir de la boîte à outil de Visual Studio.
A travers ces dessins, tout le framework .Net ainsi que le framework BizTalk sont accessible.
Il est ainsi possible de laisser libre cours à son implémentation du processus métier sans pour autant devoir écrire plusieurs programmes fastidieux pour gérer chaque étape de ce processus.
Les orchestrations, tout comme les autres artéfacts de BizTalk, souscrivent à certain messages arrivant dans la MessageBox et sont instanciée par celle-ci lorsque l’un deux arrive.
Ces orchestrations sont alors capable, par exemple de gérer des exception tel que : « A la réception d’un ordre d’achat j’envoie une facture, mais si je n’ai pas d’accusé de réception avant 2 jours, j’annule l’ordre »
Encore une foi, les « shape d’orchestration », ces fameuses formes servant à dessiner sont nombreuses mais il est toujours possible de créer les nôtre.