Bewise

Nous développons... votre avance

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

DGD
28/09/2009 - L'équipe DGD de Bewise

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 de tout ceci 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 :

public static string UpdateStatus(string message) 
{ 
   if (message.Length > 140) 
      message = message.Substring(0, 140); 
   HttpWebRequest request = (HttpWebRequest)WebRequest.Create("http://twitter.com/statuses/update.xml"); 
   request.Method = "POST"; 
   request.ContentType = "application/x-www-form-urlencoded"; 
   request.Credentials = new NetworkCredential(TwitterAccountLogin,TwitterAccountPassword); 
   
   byte[] bytes = System.Text.Encoding.ASCII.GetBytes("status=" + message); 
   request.ContentLength = bytes.Length; 
   
   using (Stream reqStream = request.GetRequestStream()) 
   { 
      reqStream.Write(bytes, 0, bytes.Length); 
      reqStream.Close(); 
   } 
   
   WebResponse response = request.GetResponse(); 
   string textResponse; 

   using (StreamReader reader = new StreamReader(response.GetResponseStream())) 
   { 
      textResponse = reader.ReadToEnd(); 
      reader.Close(); 
   } 

   response.Close(); 

   return textResponse; 
}

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 :

<?xml version="1.0" encoding="UTF-8"?> 
<monMessage> 
   Ceci est le message à poster. 
</monMessage> 

Son schéma est le suivant :

<?xml version="1.0" encoding="utf-16"?> 
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
   <xs:element name="monMessage" type="xs:string" /> 
</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.

clip_image002

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).

clip_image004

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.

clip_image006

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.

clip_image008

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

clip_image010

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

Les paramètres du transport http sont les suivants :

clip_image012

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 :

clip_image014

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.

clip_image016

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 :

clip_image018

clip_image020

Voilà, l’application est correctement déployée et configurée, il reste à tester…

Tests

1-Je crée mon fichier XML que je dépose dans mon répertoire d’entrée…

clip_image022

2- … la réponse de Twitter est reçue dans le répertoire de sortie …

clip_image024

clip_image026

3- … et sur Twitter le tweet est bien présent.

clip_image028

> Tous les articles

Commentaires

aucun commentaire
Page 1/1
   
Connexion
  • Accueil
  • Plan du site
  • Contact
Bewise TV, Blog technique, Webcasts...

Votre carrière et nous

  • Nos offres
  • Votre candidature
Ignorer les liens de navigation > Accueil > Nos Métiers > Administration, Système et Communication > Détail Article
Ignorer les liens de navigation
Nous
Nos Métiers
Vous Former
Nos Evénements
Nos Références
Nos Activités
Nos Certifications
Nos Chiffres
Le Groupe
Nos Partenaires
On Parle de Nous
Votre Carrière et Nous
Nous Contacter
Défiler vers le haut
Défiler vers le bas
Administration, Système et Communication
Architecture, Méthodes, Industrialisation
Décisionnel et Gestion des Données
Nouvelles Interfaces Utilisateurs
Portail et Travail Collaboratif
Solutions Langages et Framework
Solutions Web Avancées
Défiler vers le haut
Défiler vers le bas
Nos cours
Le Planning
Offres promotionnelles
Défiler vers le haut
Défiler vers le bas
TechDays'12
TechLunch
Windows 8 Camp
Défiler vers le haut
Défiler vers le bas
  • Infos légales
  • Lettre du Regional Director
  • Revue de presse