BizTalk Server 2004 est une solution serveur facilitant la gestion des processus métiers de l’entreprise afin de permettre à des applications et des systèmes hétérogènes de communiquer entre eux.

Nous verrons dans ce document, quelles sont les possibilités réellement offertes par BizTalk Server 2004, tant au niveau technique qu’au niveau de son intégrabilité au sein d’un système d’informations.

1.1. Description du scénario

Dans un site réalisé avec Sharepoint, il est offert aux utilisateurs la possibilité d’effectuer des commandes de livres. Pour cela, un formulaire InfoPath leur permet de saisir les informations nécessaires à la commande (l’identifiant du livre et la quantité désirée). Une fois la commande soumise, le formulaire InfoPath se charge d’invoquer et de lancer, via Web Services, le processus de gestion des commandes défini dans BizTalk Server 2004.

La commande sera acceptée ou non, en fonction de son montant. Si le montant total de la commande s’élève à plus de 100€ alors la commande sera rejetée, sinon elle sera validée. La liste des livres exploitée sera celle fournie dans la table « Titles » de la base de données « Pubs » fournie en exemple avec SQL Server. Les prix des livres commandés seront récupérés par invocation de Web Service.

Si le montant de la commande est trop élevé, une réponse est retournée à l’utilisateur lui précisant que sa commande n’a pas pu être traitée. Dans le cas contraire, la commande est sauvegardée sur disque, sous forme de fichier XML, et le Web Service de confirmation est alors invoqué pour procéder à la réalisation de la commande. Enfin, une réponse est retournée à l’utilisateur afin de lui annoncer que sa commande a été correctement traitée.

1.2. Fonctionnalités mises en oeuvre

Voici la liste des principales fonctionnalités de BizTalk Server 2004 qui seront mises en oeuvre :

Orchestrations
Schémas & Maps
Publication de Web Services
Invocation de Web Services en back-end
Invocation via InfoPath des Web Services publiés par BizTalk Server 2004
Publication et intégration d’un formulaire InfoPath dans Sharepoint

1.3. Architecture de la solution

Le schéma ci-dessous représente l’architecture globale de la solution et permet de visualiser la cinématique complète du processus de gestion d’une commande :

L’utilisateur saisit sa commande grâce à un formulaire InfoPath, puis soumet sa commande (1). La commande est alors transmise via Web Services (2) à l’application « PubsOrdersWS » permettant d’activer le processus et l’orchestration de la gestion de la commande, « PubsOrders.Orchestration » définit dans BizTalk Server 2004 (3).

L’orchestration s’occupe alors d’aller récupérer le prix du livre commandé, à l’aide du Web Service « TitleShopWS.GetTitlePrice » (4). Ce dernier effectue une simple extraction au sein de la base de données « Pubs » (5) et renvoie une réponse contenant le prix du livre concerné.

Ensuite, le montant total de la commande est calculé et s’il est en dessous de 100€, l’orchestration transfère la commande au Web Service « TitleShopWS.ProcessOrder » (6) afin de procéder à sa réalisation et stocke la commande sur disque sous forme de fichier XML (7). Une réponse est alors retournée à l’utilisateur (8) lui indiquant que sa commande a été correctement traitée.

Si le montant de la commande excède la limite autorisée des 100€, une réponse est immédiatement retournée à l’utilisateur, lui précisant que sa commande n’a pas pu être traitée.

2. Implémentation de la solution

2.1. Schémas

La première des choses à faire lors de la configuration d’un nouveau processus métier, est de créer les schémas XSD décrivant la structure et la grammaire des messages échangés tout au long de l’orchestration. En effet, BizTalk Server 2004 fonctionne essentiellement à base de messages XML afin de communiquer et transmettre les données entre les différents acteurs intervenants dans l’orchestration.

Dans notre cas, les schémas permettent de définir la structure du message SOAP reçu pour activer une instance de l’orchestration, mais aussi la structure du message de la réponse à retourner.

Nos schémas sont définis et regroupés dans une assembly « PubsOrders.Schemas » qui sera référencée et exploitée par d’autres projets BizTalk de notre solution « PubsOrders ». Voici les schémas définis dans notre projet :

2.2. Orchestration de la commande

Passons maintenant à la description même de notre processus métier, c'est-à-dire à la création de notre schéma d’orchestration. Pour cela, nous avons un second projet BizTalk intégré à notre solution, qui se nomme « PubsOrders.Orchestration ».

Voici les étapes clés de la cinématique de notre processus métier :

2.2.1. Réception de la requête

Une instance de notre orchestration est activée dés qu’un nouveau message de type « TitleOrderSchema » est soumis à BizTalk Server 2004 par l’intermédiaire du port « TitleOrdersWSPort ». Ce port permet de recevoir les requêtes SOAP envoyées par nos utilisateurs (à l’application Web Services « PubsOrdersWS ») et de les soumettre au traitement de notre orchestration.

2.2.2. Récupération du prix

Une fois la requête reçue, la première étape de son traitement consiste à récupérer le prix du livre commandé. Pour cela, nous invoquons le Web Service « TitleShopWS.GetTitlePrice », grâce au port de communication « TitleShopPort ».

Un assistant nous a permis de générer automatiquement ce port « TitleShopPort » à partir du WSDL du Web Service. Nous avons juste eu à créer les messages à envoyer (GetTitlePriceMsg) et à réceptionner (GetTitlePriceReplyMsg) de la part du Web Service.

Consommer un Web Service avec BizTalk Server 2004 est donc d’une extrême simplicité, car aucune ligne de code n’est nécessaire ; tout le côté technique d’invocation d’un Web Service est entièrement pris en charge par BizTalk Server 2004 et totalement transparent à ses utilisateurs.

2.2.3. Confirmation de la commande

Le montant total de la commande est alors calculé en fonction du prix unitaire du livre commandé et de la quantité demandée par l’utilisateur.

Dans le cas où le montant total de la commande n’excède pas les 100€ autorisés, la commande est alors confirmée, en invoquant cette fois-ci l’opération « ProcessOrder » de notre Web Service « TitleShopWS », toujours grâce au port de communication « TitleShopPort ».

L’appel à ce Web Service nous retourne un message « PROCESSED » nous indiquant que la commande a été correctement traitée.

Si le montant excède la limite autorisée des 100€, un message « DENIED » sera retourné à l’utilisateur.

2.2.4. Stockage de la commande sur disque

La commande est alors sauvegardée sur disque, dans un répertoire « Orders », et ce, grâce au port « TitleOrderFilePort ».

La propriété « Port Binding » de ce port a pour valeur « Specify Later ». Cela signifie que le port est un port logique, c'est-à-dire qu’il n’est pas encore configuré et que la destination pour écrire les fichiers de commande sur disque n’est pas définie.

C’est donc lors du lancement de l’orchestration, qu’il faudra avoir défini un port physique, que l’on associera au port logique, afin de spécifier la destination physique du port.

L’intérêt de ce découplage est de pouvoir être en mesure de changer la destination physique dynamiquement, sans avoir à recompiler et redéployer l’orchestration. En effet, si la destination avait été spécifiée directement au sein même de notre assembly, il faudrait rouvrir le projet, changer la destination, recompiler notre assembly, la redéployer, etc.

2.2.5. Envoi de la réponse

Enfin, une réponse contenant le statut de la commande est renvoyée à l’utilisateur, lui précisant si sa commande a pu être correctement traitée ou non.

Le statut de la commande (« Processed » ou « Denied ») est retourné à l’utilisateur, par Web Service, en réponse à sa requête initiale de traitement de sa commande. Le port utilisé pour renvoyer la réponse est donc le même que celui pour recevoir les requêtes des utilisateurs ; il s’agit du port « TitleOrderWSPort ».

2.2.6. Schéma d’orchestration

2.3. Publication des Web Services d’invocation de l’orchestration

Grâce à l’utilitaire « BizTalk Web Services Publishing Wizard », il est possible de publier les Web Services d’invocation d’une orchestration. Cet assistant permet de créer une application ASP.NET Web Service, dont le rôle est de servir de façade d’invocation à notre processus métier de gestion de commande de livres.

C’est cette application ASP.NET Web Service « PubsOrdersWS » publiée par l’assistant, qui sera exploitée par notre formulaire InfoPath de saisie des commandes.

2.3.1. Message d’invocation du Web Service

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<TitleId xmlns="">string</TitleId>

<Quantity xmlns="">string</Title>

</TitleOrder>

</ProcessTitleOrder>

</soap:Body>

</soap:Envelope>

2.3.2. Message de réponse du Web Service

<?xml version="1.0" encoding="utf-8"?>

<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">

<soap:Body>

<OrderId xmlns="">string</OrderId>

<Price xmlns="">string</Price>

<Status xmlns="">string</Status>

</Reply>

</ProcessTitleOrderResponse>

</soap:Body>

</soap:Envelope>

3. Formulaire InfoPath d’invocation

Une fois le Web Service de notre orchestration publié, il nous est désormais possible de l’invoquer et de commencer à effectuer des commandes. Pour cela, il nous faut une interface permettant la saisie et l’envoi par Web Service, des commandes de livres. InfoPath, le nouveau né de la suite Office System, offre une réponse correspondant tout à fait à ce type de besoin.

En effet, on peut dire qu’InfoPath est à BizTalk Server 2004 ce qu’Outlook est à Exchange. Ensembles, InfoPath et BizTalk Server 2004 permettent d’apporter une réponse aux différents problèmes et besoins qu’ont les entreprises concernant la récolte des données, comme par exemple :

Récupération et récolte des données inefficace, impliquant généralement des re-saisies et des risques d’entrée d’erreur.
Des formulaires généralement trop complexes d’utilisation engendrant une capacité limitée à fournir les informations requises.
Des solutions de récolte de données sur mesure sont trop coûteuses
Difficulté à réutiliser les données au sein des différents processus métiers de l’entreprise

InfoPath permet de créer rapidement et très facilement des formulaires de saisies, offrant une interface de saisie des données très simple d’accès et d’utilisation (environnement « user friendly »). Bâti entièrement sur XML, InfoPath récolte les données saisies qui peuvent alors être écrites dans un fichier XML, transmises à des Web Services ou à une base de données, à un collaborateur, etc.

Grâce aux assistants, la création des formulaires avec InfoPath est d’une extrême simplicité, et en plus de cela, ces derniers bénéficient d’une interface simple, soignée et élégante :

Quelques minutes seulement auront été nécessaires à la génération de ce formulaire, sans qu’aucune ligne de code ne soit tapée. Dés son chargement, le formulaire invoque un premier Web Service afin de récupérer la liste des livres disponibles. Ensuite, une fois validé, InfoPath soumet les données du formulaire à notre Web Service d’invocation de l’orchestration du processus de commande, et récupère alors le prix total et le statut de la commande.

4. Intégration du formulaire InfoPath dans Sharepoint

Si vous utilisez Sharepoint, vous avez la possibilité de publier le formulaire InfoPath afin qu’il apparaisse directement au sein de la liste des documents de votre site Sharepoint. Pour cela, il suffit simplement d’exploiter la fonctionnalité « Publish… » d’InfoPath, et de préciser l’adresse du site Sharepoint.

5. BizTalk Health and Activity Tracking (HAT)

Afin de superviser l’ensemble des activités d’orchestration, BizTalk Server 2004 met à disposition le « Health and Activity Tracking » (HAT). Le HAT est l’outil idéal pour détecter et identifier les anomalies durant les différents processus d’orchestration, puisqu’il permet de surveiller, de tracer, mais aussi de débugger en temps réel les processus d’orchestration.

Il est également possible d’effectuer des requêtes et des analyses sur l’historique des orchestrations, faisant de HAT un outil efficace de reporting d’activité.

Le HAT permet donc d’apporter les réponses à des questions du type :

Pourquoi une orchestration ne fonctionne pas correctement ?
Quel est le statut de ma commande et où en est-elle dans le processus de gestion des commandes ?
Quel est le client qui a effectué le plus de commande ce mois ci ?
Le Web Service de notre fournisseur était inaccessible hier soir, comment suis-je capable de soumettre à nouveau les commandes ?

6. Conclusion

BizTalk Server 2004 se présente donc comme un moyen idéal d’orchestration des processus métiers. Sa simplicité de mise en œuvre, son intégration transparente avec des outils comme InfoPath ou SharePoint, et la gamme d’outils mis à disposition (Health and Activity Tracking, Business Rules Engines, Single Sign-On, Business Activity Monitoring, etc.), satisferont non seulement les développeurs, mais aussi les administrateurs et décideurs de l’entreprise.