Adapter Biztalk for Twitter : ou comment utiliser la plateforme Twitter pour diffuser automatiquement des messages provenant de Biztalk

Par L'équipe Bewise, posté le 28/09/2009

Profil : Développeur | Niveau : Intermédiaire (200)

Cet article décrit comment réaliser une application Biztalk qui prend un message en entrée, simplement sous la forme d'un fichier xml dans un répertoire et poste le contenu sur Twitter.

L'intérêt dans un système d'information est certes très limité mais cet article se veut avant tout, une approche ludique pour présenter BizTalk et toucher du doigt le développement sur cette plate-forme.

Pour rappel, BizTalk Server est une plate-forme complète permettant de gérer efficacement les flux et processus business des systèmes d'information.
L'un des usages triviaux de BizTalk est l'ESB (Enterprise Service Bus) qui permet de faire communiquer simplement des applications (LOB, Oracle, SAP, SQL Server, etc.) et modéliser ainsi des processus d'entreprise.

Dans notre exemple, Twitter pourrait très bien être le système d'alerte de votre SI. Voyons comment communiquer avec.

Avant de commencer la réalisation de l'application en elle-même, un petit détour vers la documentation de l'API de Twitter s'impose.

L'API de Twitter

L'API de Twitter est documentée sur http://apiwiki.twitter.com/. L'accès se fait très facilement en REST. Ainsi, pour les besoins qui nous concernent (envoi d'un Tweet, c'est-à-dire mis à jour du status), l'uri utilisée sera http://twitter.com/statuses/update.xml . Sur cet appel en particulier, on note qu'il faut être identifié avec les informations d'authentification du compte sur lequel on va tweeter. L'appel se fait en POST, la réponse reçue est en XML. Une petite application de test s'écrie rapidement et permet de valider le fonctionnement :

Biztalk : création de l'application

L'implémentation de ce besoin passe donc, dans Biztalk, par la réception du message à envoyer, sa transformation dans le schéma nécessaire à Twitter et l'envoi sur le service. L'envoi, comme nous l'avons vu précédemment, est un simple post en http, donc il n'est pas nécessaire d'aller chercher plus loin que le type de transport http déjà présent dans Biztalk.

Pour notre cas d'exemple nous partirons simplement du dépôt d'un fichier xml dans un répertoire sous la forme suivante :

   1:  xml version="1.0" encoding="UTF-8"?>

   2:  <monMessage>

   3:     Ceci est le message à poster.

   4:  monMessage>

Son schéma est le suivant :

   1:  xml version="1.0" encoding="utf-16"?>

   2:  <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">

   3:     <xs:element name="monMessage" type="xs:string" />

   4:  xs:schema>

Il faut également définir le schéma du message de sortie, soit comprendre qu'un port d'envoi http est simplement l'équivalent d'un POST via une WebRequest comme nous l'avons fait plus haut. Ainsi, le contenu du message à envoyer sur ce port doit être de la forme «status=Ceci est le message à poster.». Pour obtenir ce type de message le plus simple est de construire le schéma à partir de l'assistant et d'un fichier plat d'exemple.

Notez l'attribut « tag_name » qui spécifie que le message est préfixé par « status= ».

La map permettant de créer la requête depuis le message d'entrée s'obtient rapidement entre les deux schémas ; on en profite pour rajouter une functoïd qui limite le nombre de caractères du tweet à 140, comme requis par Twitter (sinon Twitter tronque le message et l'opération de troncature est notifiée dans la réponse du post).

Une fois la requête prête à être envoyée, on passera par un Pipeline d'envoi utilisant un FlatFileAssembler utilisant le schéma de la requête. Ce pipeline permettra d'aplatir le message.

Reste enfin à préparer le schéma qui sera utilisé pour recevoir la réponse de l'appel. Pour simplifier, on utilise un fichier XML d'exemple (construit à partir du document XML donné dans la documentation par exemple) et on génère le schéma à partir de cette instance (deux fichiers sont créés, l'un étant utilisé pour la partie géolocalisation récente d'un tweet).

Ces opérations faites le projet est donc constitué de :

Un schéma de message d'entrée
Un schéma pour la requête Twitter
Un schéma pour la réponse Twitter
Une map entre message d'entrée et requête Twitter.
Un pipeline d'envoi

Une fois le projet déployé, il reste à configurer correctement chacun des ports .

Biztalk : configuration de l'application

Commençons par la réception : un port de type FILE pour lequel on aura pris soin de configurer correctement les droits d'accès NTFS sur le répertoire.

L'émission est un port de type solicit-response (on envoie une requête à Twitter mais on attend la réponse) :

Notez que l'on passe par le pipeline de sortie réalisé dans l'application.

Les paramètres du transport http sont les suivants :

On précise dans l'onglet Authentification un mode d'authentification basique avec les identifiants de connexion du compte Twitter.

Dans cette application, on n'utilisera pas d'orchestration, donc nous abonnons directement ce send port au port de réception fait précédemment :

Une particularité de ce send port est l'utilisation d'une map (Outbound Maps) pour la transformation du message d'entrée. En effet, comme ce port reçoit directement des messages de type « monMessage », il faut les transformer en requête Twitter.

Reste à recevoir la réponse, que l'on se contentera de déposer dans un répertoire. Ceci passe par la création d'un nouveau Send port qui est filtré sur la réponse de Twitter :