Ce document a pour but d’analyser et d’apporter une réponse à une problématique concrète, la gestion du processus de publication d’informations et de contenu, à l’aide d’un outil de Business Process Management (BPM), Microsoft BizTalk Server 2004.

Il est en effet très fréquent d’avoir à gérer une problématique comme celle-ci, et dans un monde où, de plus en plus, les informations affluent de sources disparates, il peut être intéressant de se pencher sur la manière de gérer le processus de publication d’informations.

Ce processus s’étend de la récupération et de l’agrégation des informations jusqu’à sa publication finale sur un portail ou un site web, en passant par les différentes étapes intermédiaires de confirmation et de validation.

Les solutions mises en œuvres pour gérer ce processus consistent généralement en un applicatif métier, permettant la saisie des articles qui, pour pouvoir être publiés, sont soumis à un contrôle et validation d’un tiers. Si ce type d’application permet d’apporter une réponse et une solution à un besoin bien précis, on se retrouve rapidement limité par leurs capacités à gérer des informations issues d’autres référentiels que ceux prévus par l’application.

En effet, est-ce que ces applications permettent de récupérer et d’agréger des informations sur Internet (via Web Services ou flux RSS – Real Simple Syndication), telles que les derniers articles Reuters ou les dernières cotations boursières ? Ces applications permettent elles de gérer des articles postés par email ou par Web Services ?

C’est cette multitude de référentiels d’informations qui fait apparaître le besoin d’externalisation du processus de gestion de contenu (agrégation, validation, publication) au sein d’un BPM tel que BizTalk Server 2004.

1.1. Description du scénario

La société Contoso dispose d’un site intranet réalisé avec SharePoint, sur lequel est publié du contenu provenant des rédacteurs de Contoso, mais aussi de sources d’informations publiques, comme les flux RSS du New York Times.

Pour pouvoir saisir et publier de nouveaux articles sur leur intranet, les employés de Contoso ont plusieurs possibilités :

Une application web de saisie spécifique, alimentant une base de données
Un formulaire de saisie InfoPath qui soumet les articles via Web Service
L’envoi d’articles par email à submitpost@contoso.com

Une fois saisis et envoyés, les articles sont soumis au contrôle et à la validation du responsable éditorial de Contoso (par email), qui décide alors d’approuver ou non la publication de l’article sur le site intranet. Le responsable éditorial se verra également soumettre l’ensemble des articles nouvellement publiés sur le flux RSS du New York Times.

C’est pour pouvoir gérer l’ensemble des canaux d’informations et de contenu alimentant le site intranet, que le besoin d’externalisation de ce processus se fait ressentir. En effet, l’intérêt de décrire et d’implémenter les règles métiers composant le processus au sein de BizTalk Server 2004, est de pouvoir être capable d’exposer un service unique et générique de validation et de publication, totalement découplé et indépendant des applications de saisies et de récupération de contenu.

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 d’invocation d’une orchestration
Invocation de Web Services en back-end
Invocation via InfoPath des Web Services publiés par BizTalk Server 2004
Définition de règles métiers au sein du « Business Rules Engine »
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 métier du processus :

Les employés de Contoso rédigent leurs articles sur l’application web dédiée à leur saisie, puis soumettent leurs articles (1). Ces derniers sont alors soumis à l’orchestration BizTalk par Web Service (2).

D’autres possibilités sont offertes aux rédacteurs de Contoso pour soumettre leurs articles. Ils peuvent en effet utiliser et remplir un formulaire InfoPath (3), qui une fois soumis, transmet l’article à BizTalk Server 2004 via Web Service (4).

On peut également imaginer qu’il leur soit accordé la possibilité de rédiger leurs articles dans un email et de l’envoyer à submitpost@contoso.com (5). Ces emails seront automatiquement interceptés et traités par BizTalk Server 2004 (6).

Les flux RSS du New York Times seront également interrogés automatiquement par BizTalk Server 2004 (7) et les différents articles ainsi récupérés sauront soumis au même traitement et processus de validation que les articles des rédacteurs de Contoso.

En fonction de la catégorie de l’article (« Business », « Politics », « Science », « Sports », « Technology », etc.), une règle métier définie au sein du « BizTalk Rules Engine » permet de choisir la personne à qui il faut transmettre l’article. Ainsi, les articles « Business » seront envoyés à business@contoso.com, alors que les articles « Technology » seront transmis à tech@contoso.com (8).

Chaque article traité par BizTalk Server 2004 est donc soumis par email à l’approbateur correspondant à la catégorie de l’article (9), qui peut alors choisir d’approuver ou non la publication finale de l’article (10).

Si l’article est approuvé, alors il est publié sur l’intranet de Contoso (11).

Enfin, un email est envoyé à l’auteur de l’article pour lui notifier que son article a été publié ou refusé, accompagné d’un commentaire de l’approbateur (12).

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 « ContosoCM.Schemas » qui sera référencée et exploitée par d’autres projets BizTalk de notre solution « ContosoCM ». Voici les schémas définis dans notre projet :

1. SubmissionRequest :

Ce schéma définit les différents éléments à envoyer pour soumettre un article par Web Service.

2. SubmissionResponse :

Une fois soumis, est associé à l’article un identifiant « ArticleId » qui est retourné dans la réponse du Web Service.

3. ArticleApprobator :

Ce schéma permet de définir le message qui sera exploité par le moteur de « Business Rule » de BizTalk, afin de déterminer la personne à qui il faut envoyer l’article pour approbation.

2.2. Orchestration

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 « ContosoCM.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 « SubmissionRequest » est soumis à BizTalk Server 2004 par l’intermédiaire du port « ArticleSubmissionPort ». Ce port permet de recevoir les requêtes SOAP envoyées par nos utilisateurs (à l’application Web Services « ContosoCMWS ») et de les soumettre au traitement de notre orchestration.

2.2.2. Insertion de l’article dans la base

Une fois la requête reçue, la première étape de son traitement consiste à insérer l’article dans la base de données de l’intranet. L’article n’est pas publié, il est uniquement stocké. Pour cela, nous invoquons le Web Service « ArticleService.InsertArticle », grâce au port de communication « InsertArticlePort ».

Un assistant nous a permis de générer automatiquement ce port « InsertArticlePort » à partir du WSDL du Web Service. Nous avons juste eu à créer les messages à envoyer (InsertArticleRequestMsg) et à réceptionner (InsertArticleResponseMsg) 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. Envoi de la réponse

Une fois l’article inséré dans la base de données de l’intranet, la valeur « ArticleId » de l’article nouvellement créé est retournée à l’utilisateur, par Web Service, en réponse à sa requête initiale de traitement de son article. 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 « ArticleSubmissionPort ».

2.2.3. Création d’une règle métier avec le « Business Rule Composer »

Il faut ensuite déterminer la personne responsable de l’approbation de l’article, et ce, en fonction de sa catégorie. Pour cela, nous devons créer une « Business Rule » (règle métier) à l’aide du « Business Rule Composer », qui va permettre de définir les personnes à qui il faut envoyer les articles, en fonction des catégories.

L’intérêt de définir et d’externaliser cette logique métier au sein du « Business Rule Engine », en dehors de l’orchestration, est de pouvoir être capable d’effectuer des modifications beaucoup plus facilement, sans avoir à éditer, recompiler et redéployer notre orchestration.

2.2.3.1. Définition du « Vocabulary »

Pour créer une règle métier, il faut tout d’abord définir ce que l’on appelle un « Vocabulary ». Il s’agit d’un groupe de « Definitions », qui correspondent en quelque sorte aux entités et variables que l’on utilisera dans notre « Policy » (règle métier).

Dans notre cas, nous avons créé une définition « Category », de type XML Element (en mode GET), qui permettra d’aller récupérer la valeur de l’élément « Category » du message XML soumis.

Nous avons également une définition « Approbator Email », de type XML Element (en mode SET) qui va nous permettre de définir l’adresse email de l’approbateur et de la retourner au sein de l’orchestration. Cette définition pointe sur l’élément « ApprobatorEmail » du message XML soumis.

Enfin, nous avons une troisième définition « Category Values », de type « Set of values » qui permet d’énumérer les différentes catégories possibles.

2.2.3.2. Définition de la « Policy »

Maintenant que notre « Vocabulary » a été définit, nous pouvons créer notre « Policy ». Pour chacune des catégories possibles, nous définissions une « Rule » (règle), qui va évaluer la valeur de la définition « Category », et mettre à jour la définition « Approbator Email » en conséquences.

Par exemple, la règle « Business » définit que si la catégorie est égale à « Business », alors, il faudra envoyer la notification et la demande d’approbation à business@contoso.com :

Le principe est le même pour les autres règles « Politics », « Science », « Sports » et « Technology ».

2.2.4. Appel de la règle métier

Notre règle métier déployée, nous pouvons désormais l’invoquer au sein de notre orchestration. Pour cela, il faut préparer le message XML « ArticleApprobator », puis invoquer la règle métier « ApprobationConfig » en passant le message « ArticleApprobator » en tant que paramètre.

C’est grâce à l’appel de cette règle métier, que nous allons pouvoir récupérer l’adresse email de la personne à qui il faut transmettre l’article.

L’appel à la règle métier est effectuée au sein d’un « Scope », configuré en mode de transation « Atomic », afin de s’assurer que les changements d’état, comme la modification de variables ou de messages, ne soient visibles en dehors du scope que lorsque la transaction atomique est correctement validée et terminée.

2.2.5. Envoi de la notification et demande d’approbation

Maintenant que nous avons récupéré l’email de la personne responsable de l’approbation de l’article en cours de traitement, il suffit de créer l’email de notification à envoyer, qui contiendra :

Le titre de l’article
Le corps de l’article
L’auteur de l’article et son email
Un lien vers la fiche d’approbation / déclinaison de l’article

L’email est transmis à l’approbateur via le port « NotificationEmailPort ». La propriété « Port Binding » de ce port a pour valeur « Dynamic ». Cela signifie que c’est un port dynamique, c'est-à-dire qu’il n’est pas configuré au design-time mais au run-time. En effet, la destination pour envoyer les emails de notifications varie en fonction de la catégorie de l’article en cours de traitement, et de ce fait, le port sera dynamiquement configuré.

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 publication de contenu.

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

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>

<Category xmlns="">string</Category>

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

<Body xmlns="">string</Body>

<Author xmlns="">string</Author>

<AuthorEmail xmlns="">string</AuthorEmail>

</SubmissionRequest>

</ReceiveArticle>

</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>

<ArticleId xmlns="">integer</ArticleId>

</SubmissionResponse>

</ReceiveArticleResponse>

</soap:Body>

</soap:Envelope>

3. Formulaire d’approbation des articles

Une notification est envoyée par email aux approbateurs, à chaque fois qu’un nouvel article est soumis. Dans cet email, figure un lien pointant vers un formulaire de l’intranet, leur permettant d’approuver ou de refuser la publication en ligne de l’article. Il leur est également possible de saisir quelques lignes de commentaires à envoyer à l’auteur de l’article pour justifier sa décision :

Que l’article soit approuvé ou non, une notification est envoyée par email à son auteur, lui précisant que son article a été publié ou refusé, avec les commentaires de l’approbateur.

Si l’approbateur approuve l’article, ce dernier est alors publié en ligne sur le portal intranet de Contoso :

4. 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 à soumettre des articles. Pour cela, il nous faut une interface permettant la saisie et l’envoi des articles par Web Service. 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. Une fois le formulaire rempli et validé, InfoPath soumet les données du formulaire à notre Web Service d’invocation de l’orchestration du processus de validation de contenu. L’utilisateur n’a plus qu’à attendre une réponse de la part de l’approbateur.

5. Formulaire Intranet

Les rédacteurs de Contoso peuvent également utiliser l’écran de soumission d’un nouvel article de leur intranet. A l’instar du formulaire InfoPath, ce formulaire soumet les données via Web Service à notre orchestration :

6. Extensions

Une fois implémenté, ce processus de validation / publication de contenu est devenu un véritable service, auquel on va pouvoir interfacer de nouveaux modules. En effet, il est tout à fait possible d’envisager ce genre d’extensions :

6.1. Envoi des articles par email

Il peut être intéressant d’offrir la possibilité aux rédacteurs de Contoso de saisir et de composer leurs articles dans un email, et de l’envoyer à « submitpost@contoso.com ».

Pour implémenter cette fonctionnalité, l’idée serait d’avoir un service qui récupère tout email envoyé à « submitpost@contoso.com », de parser son contenu et de le transformer en un fichier XML sauvé dans un répertoire « Mail_Inbox ». Ensuite, une orchestration BizTalk se chargerait de monitorer et de traiter les fichiers déposés dans ce répertoire, afin de les soumettre au processus de validation en invoquant notre orchestration « ProcessArticle ».

6.2. Agrégation de contenu en ligne

Une autre idée intéressante con