Présentation générale de l'ESB Open Source Mule et des notions SOA & ESB

1. Introduction à Mule ESB
Mehdi EL KRARI
@elkrari

2. Table des matières
Introduction....................................................................................................5
1Architecture orientée service ..........................................................................6
1.1Introduction............................................................................................6
1.2Principes généraux d'une architecture orientée service :.............................6
1.3Avantages d'une architecture orientée service :..........................................7
2Entreprise Service Bus ..................................................................................8
2.1Introduction............................................................................................8
2.2Les principes ..........................................................................................8
2.3L’architecture .........................................................................................9
3Outil de travail : MuleSoft.............................................................................11
3.1Comment fonctionne Mule......................................................................11
3.1.1Architecture de base des flux de messages...........................................11
3.1.2Configuration de Mule ESB...............................................................12
3.2Ce que peut faire Mule............................................................................12
3.3L'essentiel de Mule Studio.......................................................................13
3.3.1Quelle est la relation entre Mule ESB et Mule Studio?.........................13
3.3.2Comment utiliser Mule Studio ?........................................................14
3.3.3Comment utiliser l'éditeur visuel de Mule Studio?...............................15
3.4Les blocs de construction de Mule Studio..................................................17
3.4.1Présentation....................................................................................17
3.4.2Les points de terminaison.................................................................20
3.4.3Les transformateurs..........................................................................23
3.5Les éléments globaux...............................................................................25
3.6Débogage et déploiement des applications..................................................26
3.6.1Débogage d'une application...............................................................27
3.6.2Déploiement d'une application...........................................................27
2

3. Index des illustrations
L'architecture d'un bus ESB.............................................................................9
Un simple flux Mule sur Studio........................................................................11
Simple flux Mule à travers l'architecture Mule ESB...........................................11
Les deux environnements de développements de Mule........................................13
Mule Studio intègre Mule ESB.........................................................................14
Les quatre grandes étapes pour développer sous Mule Studio..............................14
Les quatre quadrants de l'éditeur visuel de Mule Studio.....................................16
Les trois onglets qui composent le canevas........................................................16
Un élément d'un flux est un bloc de construction...............................................17
Représentation du flux sur l'éditeur visuel et en XML........................................18
Exemple de flux, aussi bien sur l'éditeur visuel que XML....................................18
Configuration d'attributs d'un élément dans l'éditeur visuel et XML....................19
Modèles d'échange de messages........................................................................20
Exemple de point de terminaison entrant (Inbound Endpoint)............................20
Exemple de point de terminaison sortant (Outbound Endpoint)..........................21
Réutilisation d'un élément global dans plusieurs flux..........................................26
3

4. Introduction
Le système d'information de l'entreprise est généralement constitué
d'applications et de données constituant son héritage (en anglais legacy).
Avec les fusions de groupe, l'évolution des technologies, cet héritage a
tendance à devenir hétérogène et à se spécialiser par métier (entité, service,
etc.), ce qui provoque un fonctionnement en silo, c'est-à-dire un
cloisonnement des différents métiers empêchant certaines formes de
transversalité et masquant au décideur une vision globale du système
d'information de son entreprise. L'intégration des applications de
l'entreprise (EAI) est une solution à ce problème. Elle consiste à développer
des connecteurs spécifiques permettant de faire communiquer entre eux les
différents silos de l'entreprise.
4

5. 1 Architecture orientée service
1.1Introduction
Une architecture orientée services (notée SOA pour Services Oriented
Architecture) est une architecture logicielle s'appuyant sur un ensemble de services
simples.
L'objectif d'une architecture orientée services est donc de décomposer une
fonctionnalité en un ensemble de fonctions basiques, appelées services, fournies par
des composants et de décrire finement le schéma d'interaction entre ces services.
L'idée sous-jacente est de cesser de construire la vie de l'entreprise autour
d'applications pour faire en sorte de construire une architecture logicielle globale
décomposées en services correspondant aux processus métiers de l'entreprise.
Lorsque l'architecture SOA s'appuie sur des web services, on parle alors de
WSOA, pour Web Services Oriented Architecture).
1.2 Principes généraux d'une architecture orientée service :
Il n'existe pas à proprement parler de spécifications officielles d'une
architecture SOA, néanmoins les principales notions fédératrices que l'on retrouve
dans une telle architecture sont les suivantes :
• La notion de service, c'est-à-dire une fonction encapsulée dans un
composant que l'on peut interroger à l'aide d'une requête composée d'un ou
plusieurs paramètres et fournissant une ou plusieurs réponses. Idéalement
chaque service doit être indépendant des autres afin de garantir sa
réutilisabilité et son interopérabilité.
• La description du service, consistant à décrire les paramètres d'entrée
du service et le format et le type des données retournées. Le principal format
de description de services est WSDL (Web Services Description Language),
normalisé par le W3C.
• La publication (en anglais advertising) et la découverte (discovery) des
services. La publication consiste à publier dans un registre (en anglais
registry ou repository) les services disponibles aux utilisateurs, tandis que la
notion de découverte recouvre la possibilité de rechercher un service parmi
ceux qui ont été publiés. Le principal standard utilisé est UDDI (Universal
5

6. Description Discovery and Integration), normalisé par l'OASIS.
• L'invocation, représentant la connexion et l'interaction du client avec le
service. Le principal protocole utilisé pour l'invocation de services est SOAP
(Simple Object Access Protocol).
1.3Avantages d'une architecture orientée service :
Une architecture orientée services permet d'obtenir tous les avantages d'une
architecture client-serveur et notamment :
• Une modularité permettant de remplacer facilement un composant (service)
par un autre.
• Une réutilisabilité possible des composants (par opposition à un système
tout-en- un fait sur mesure pour une organisation).
• De meilleures possibilités d'évolution (il suffit de faire évoluer un service ou
d'ajouter un nouveau service).
• Une plus grande tolérance aux pannes.
• Une maintenance facilitée.
6

7. 2 Entreprise Service Bus
2.1Introduction
L'Enterprise Service Bus ou ESB est une technique informatique inter-
logicielle. Son but est avant tout de permettre la communication des applications
qui à la base ne sont pas pensées pour fonctionner ensemble (deux ERP
-Enterprise Resource Planning ou Progiciel de gestion intégré - provenant de deux
éditeurs différents par exemple).
Roy Schulte de la société Gartner inc, en fait la description suivante : «
L'ESB est une nouvelle architecture qui exploite les services web, les systèmes
orientés messages, le routage intelligent et la transformation. L'ESB agit comme
une colonne vertébrale légère et omniprésente de l'intégration à travers laquelle les
services logiciels et les composants applicatifs circulent ».
On peut considérer l'ESB comme une nouvelle génération d'EAI (en
français, Intégration d'applications d'entreprise) construite sur des standards
comme XML, JMS ou encore les services web. Aussi, la différence majeure avec
l'EAI réside dans le fait que l'ESB propose une intégration complètement distribuée
grâce à l'utilisation des conteneurs de services. Ces "mini-serveurs" contiennent la
logique d'intégration et peuvent être déposés n'importe où sur le réseau.
2.2Les principes
L'ESB en tant que médiateur entre les clients et les fournisseurs de services
s'appuie sur les principes suivants :
• La découverte dynamique : les services ainsi que la sémantique associée sont
enregistrés dans un annuaire partagé.
• La chorégraphie des processus métiers et l'orchestration des services
associés: un outil permet d’orchestrer automatiquement les services
nécessaires à l’implémentation des processus collaboratifs représentés
graphiquement.
• La distribution forte : les services sont distribués sur le réseau de l'entreprise
ou sur Internet.
• La communication par messages : les services s’échangent des messages
représentés par des documents textuels.
• Le terme ESB a été utilisé la première fois par l'éditeur Sonic Software
7

8. (filiale Progress Software Corporation). D'une certaine façon les ESB
constituent une évolution de l'EAI, notamment pour des raisons de
performance en cas de grosses volumétries (les traitements sont
potentiellement distribués) et de sécurité (éviter le 'Single Point of failure
potentiel d'une plate-forme centrale), bien que les EAI/ESB les plus récents
se soient améliorés sur ces deux problématiques.
2.3L’architecture
L'Enterprise Service Bus possède comme son nom l'indique une architecture
en bus qui l'oppose à l'architecture hub and spoke des premiers EAI. Ceci fait de
l'ESB une solution hautement distribuée. Les composantes de cette architecture
sont illustrées sur l'illustration ci-dessous
L'ESB possède quatre fondements :
• Le Middleware Orienté Message (MOM) qui permet l'échange de
messages de manière asynchrone. Ainsi chaque message est déposé sur une
file d'attente avant d'être consommé par le destinataire.
• Les services Web qui permettent d'interfacer les applications avec le bus.
Chaque service contient une logique d'intégration des messages
(transformation, routage, etc.).
• Les transformations qui concernent les messages circulant sur le bus, elles
sont essentielles dans un ESB car leur rôle est de permettre à des
applications de converser même si elles définissent différemment leurs
données.
• Le routage intelligent qui découple l'expéditeur du message de son
destinataire. C'est en fait l'ESB qui va déduire la destination du message.
8
Illustration 1: L'architecture d'un bus ESB

9. Pour cela il se fonde sur le contenu du message et les règles qui ont été
définies.
Peuvent venir se greffer à cette architecture:
• Le Business Activity Monitoring (BAM) qui permet de suivre l'activité
d'un processus métier.
• Le Business Process Management (BPM) qui a pour but de maîtriser
l'orchestration des processus métier, c'est-à-dire l'enchaînement des
échanges entre applications.
9

10. 3 Outil de travail : MuleSoft
3.1Comment fonctionne Mule
3.1.1 Architecture de base des flux de messages
Les schémas ci-dessous illustrent un simple flux Mule tel qu'il y paraît sur
Studio - un message entre à gauche du flux, les blocs traitent le message un par un,
puis le message quitte le flux à sa droite.
Nous pouvons examiner le même flux dans le contexte de l'architecture
couches de Mule ESB: application, intégration et transport. Comme l'illustre
le diagramme ci-dessous, les blocs de construction de Mule fonctionnent sur
différentes couches d'abstraction dans un seul flux.
10
Illustration 2: Un simple flux Mule sur Studio
Illustration 3: Simple flux Mule à travers l'architecture Mule ESB

11. 3.1.2 Configuration de Mule ESB
Il existe trois grands types de flux dans les applications Mule:
1. Composante axée sur la manipulation des messages - l'utilisation, ou
la personnalisation des POJO existants, Connecteurs Cloud, ou des beans
Spring qui contiennent la logique métier pour traiter ou enrichir des
messages.
2. Orchestration de services - configure des points de terminaison, des
routeurs, des transformateurs et des filtres pour orchestrer les appels entre
les flux de Mule, dont chacun effectue différentes tâches de traitement avec le
message.
3. Intégration - utilisent des transports pour «dissocier» les Web Services à
partir de leurs protocoles sous-jacents et envoyer/recevoir des messages sur
les connecteurs des différents protocoles. Mule ESB prend en charge de
nombreux transports existants et protocoles de communication populaires,
mais on peut également développer un transport personnalisé si on a besoin
d'étendre Mule pour soutenir un « legacy » particulier ou système
propriétaire.
3.2Ce que peut faire Mule
Mule ESB est une plate-forme d'intégration à travers laquelle les applications
peuvent communiquer les unes avec les autres.
Plutôt que de construire des solutions coûteuses, sur mesure, lourdes en
maintenance, pour relier les systèmes anciens à de nouveaux, de se connecter avec
les services Web, ou accéder aux bases de données, Mule ESB a les outils qu'il faut
afin de résoudre ces problèmes d'intégration, en connectant quoi que ce soit avec
quoi que ce soit.
Avec Mule ESB, on peut :
• Intégrer des applications ou des systèmes
• Construire des APIs
• Connecter une application à une API
• Créer des Web Services qui orchestrent des appels à d'autres Web Services
• Héberger des Web Services et des applications d'intégration sur place ou
dans le cloud
• Intégrer avec SAP ou encore Salesforce
11

12. 3.3L'essentiel de Mule Studio
Mule Studio est un basé sur Eclipse, un environnement de développement
d'intégration. Il propose deux environnements de développement que vous pouvez
utiliser pour créer des applications Mule:
1. Éditeur visuel « drag-and-drop »
2. Edteur XML
Tout ce qui est développé ou configuré dans un éditeur est reflété dans
l'autre.
3.3.1 Quelle est la relation entre Mule ESB et Mule Studio?
Mule ESB est le cœur d'une application ESB. On peut installer et utiliser
Mule ESB sans Mule Studio (connu aussi sous le nom de Mule ESB
standalone (autonome) ou Mule ESB runtime) et interagir avec lui - la
construction et l'exécution d'applications d'intégration et des services Web - via un
EDI externe indépendant, comme IntelliJ, Eclipse ou Jdeveloper.
Mule Studio est l'interface graphique utilisateur, elle sert pour accéder aux
fonctionnalités Mule ESB. Plutôt que d'écrire du code XML dans un IDE pour
créer des applications Mule, on utilise Studio, un environnement visuel de
développement d'intégration. Studio ( connu aussi sous le nom de Mule ESB
DesignTime) est utilisé pour faire glisser et déposer des éléments en place pour
modéliser rapidement, configurer et déployer des applications sur place ou dans le
cloud.
12
Illustration 4: Les deux environnements de développements de Mule

13. 3.3.2 Comment utiliser Mule Studio ?
A. Modèle
L'éditeur visuel permet à un développeur d'organiser des blocs de
construction sur un canevas pour créer des flux de Mule, qui forment la base
de l'une des applications Mule. Il suffit de glisser-déposer les blocs de
construction sur le canevas pour créer une séquence d'événements qui
facilitent le traitement des messages Mule.
B. Configuration
L'éditeur visuel fournit des boîtes de dialogue pour configurer les blocs de
construction. Les boites de dialogues acceptent de simples entrées écrites en
anglais, plutôt que formaté XML, les développeurs n'ont pas à se soucier de
la syntaxe XML lors de la configuration de chaque bloc de construction.
13
Illustration 5: Mule Studio intègre Mule ESB
Illustration 6: Les quatre grandes étapes pour développer sous Mule Studio

14. Les développeurs déjà à l'aise avec le langage XML préfèrent peut-être
utiliser l'éditeur XML pour définir les détails de configuration en écrivant
des instructions XML directement dans le fichier de configuration XML.
Mule Studio rend le code XML plus facile en fournissant des conseils de
syntaxe (suggestions d'auto-complétion) et fournit des menus déroulants qui
liste les options disponibles pour les attributs XML.
C. Débogage
Mule Studio inclut un débogueur pour exécuter une application Mule et
regarder le code source et examiner les variables pendant l'exécution. On a
qu'à Définir des points d'arrêt dans une application, puis laisser Mule faire
le travail.
D. Déploiement
On peut déployer une nouvelle application studio sur place pour la tester, ou
à l'extérieur et la faire tourner dans un environnement de production. Un
développeur peut également déployer une application Studio sur le référentiel
d'applications dans la console de gestion Mule ou la déployer sur CloudHub.
3.3.3 Comment utiliser l'éditeur visuel de Mule Studio?
L'éditeur visuel de Mule Studio est divisé en quatre quadrants :
1. L'explorateur des pacquages
2. Les canevas
3. Le schéma
4. La console
14

15. Le Package Explorer affiche les dossiers et les fichiers d'un projet sous
forme d'arborescence. Un Clique pour agrandir ou réduire les dossiers du projet
Mule et examiner les fichiers qui composent ce projet.
Le canevas offre un espace qui facilite l'agencement des composants en flux
Mule. La Palette, sur le côté droit du canevas, affiche une liste de blocs de
construction Mule qu'on peut cliquer et faire glisser sur le canevas pour construire
notre application. Au pied du canevas, Studio propose trois onglets qui offrent des
méthodes différentes pour interagir avec notre application:
• Flux de messages: l'interface drag-and-drop qui facilite l'agencement des
composants studio en flux Mule
• Éléments globaux: l'interface pour créer ou éditer des configurations
réutilisables pour les blocs de construction de Mule
• Configuration XML: l'interface de l'éditeur XML affiche les déclarations
XML qui correspondent aux blocs de construction disposés par les flux de
messages du canevas.
15
Illustration 7: Les quatre quadrants de l'éditeur visuel de Mule Studio
Illustration 8: Les trois onglets qui
composent le canevas

16. Le schéma affiche un aperçu miniature du canevas entier, avec un curseur
qui défile avec boîte de l'affichage dans le panneau de canevas. Cela fournit un haut
niveau, une vue à vol d'oiseau de notre application Mule.
La console affiche une liste des événements et des problèmes (dans le cas
échéant) que studio rapporte en créant ou exécutant votre application Mule. Les
onglets JavaDoc et les déclarations affichent les catégories d'informations
supplémentaires relatives à votre code.
3.4Les blocs de construction de Mule Studio
3.4.1 Présentation
Sur Mule Studio, un bloc de construction est une représentation visuelle d'un
élément.
Si construire une application Mule via XML dans un environnement de
développement intégré, un développeur configure une série d'éléments dans un
ordre précis pour créer un flux. Un élément, enfermé dans chevrons(<...>), définit
une activité que Mule doit effectuer lors du traitement d'un message. Par exemple,
un élément <http:inbound endpoint> reçoit de nouveaux messages, puis les
transmet à l'élément suivant de son flux.
L'éditeur visuel de Studio affiche chaque élément dans un flux comme un bloc
de construction.
Dans l'éditeur visuel, trois blocs de construction alignés horizontalement
dans un flux représentent les trois éléments verticalement énumérés dans l'éditeur
XML, comme l'illustre l'image ci-dessous. La ligne en pointillés qui entoure les
éléments de base représente la portée du flux, les flèches indiquent le sens du
message lors de son passage à travers le flux.
16
Illustration 9: Un élément d'un
flux est un bloc de construction

17. Par exemple, l'image suivante affiche le même flux sur ces deux formats,
l'éditeur visuel et l'éditeur XML.
Code couleur de l'éditeur XML
Vert = nom de l'élément et de ses délimiteurs
Violet = nom de l'attribut et de ses délimiteurs
Bleu = valeur de l'attribut et de ses délimiteurs
Les blocs de construction de l'éditeur visuel de Mule Studio appartiennent à
l'une des trois catégories suivantes:
1. Les sources de messages, acceptent les messages dans les flux et
déclenchent Mule pour commencer le traitement du message.
2. Les processeurs de messages, accomplissent un certain type d'action
avec un message tel que le filtrage, la transformation, l'acheminement
(routage) ou la validation.
3. Les composants, effectuent des fonctionnalités spécifiques pré-emballés ou
codées sur mesure.
17
Illustration 10: Représentation du flux sur l'éditeur visuel et en XML
Illustration 11: Exemple de flux, aussi bien sur l'éditeur visuel que XML

18. Les attributs :
Après avoir créé un flux de blocs de construction dans l'éditeur Visuel de
Studio, on doit configurer les attributs de chacun. Pour ce faire, on a deux options
dans le studio:
1. En double-cliquant sur un bloc de construction dans le canevas de l'éditeur
visuel pour ouvrir son panneau de propriétés, dans lequel on peut définir ses
attributs en entrant ses valeurs dans les champs correspondants.
OU
2. En accédant à l'éditeur XML, puis en définissant les attributs directement
dans le fichier de configuration XML
Quelle que soit la méthode que choisie, Studio reflète automatiquement et
immédiatement les modifications de configuration dans les deux éditeurs, ce qui
adhère à ses fonctionnalités d'édition dans les deux sens. L'exemple ci-dessous
illustre les configurations d'attributs d'un élément dans l'éditeur visuel et XML.
Modèles d'échange de messages :
L'un des attributs de la source du message est le modèle d'échange. Le
modèle d'échange détermine si la source du message reçoit simplement un message,
ou reçoit, puis répond à un message.
Modèle d'échange Comportement
Sens unique (one-way) Reçoit des messages puis lance le traitement
Double-sens (two-way) Reçoit des messages, lance le traitement, puis renvoie la
réponse
Avec l'éditeur Visuel de Mule Studio, le modèle d'échange d'une source de
messages est indiqué par la flèche perché sur le coin supérieur droit du bloc de
18
Illustration 12: Configuration d'attributs d'un élément dans l'éditeur visuel et XML

19. construction. Une icône double flèche indique un modèle à deux voies d'échange de
messages (ci-dessous, à gauche), une seule flèche indique à sens unique (ci-dessous,
à droite).
3.4.2 Les points de terminaison
Vue d'ensemble :
Les points de terminaison transmettent des messages entrants et sortants
d'un flux de Mule, généralement à des ressources externes telles que les bases de
données, les clients Web ou les serveurs de messagerie, mais ils peuvent échanger
des messages avec d'autres flux de Mule. Des points de terminaison spécifiques tels
que HTTP, JMS, et WMQ utilisent chacun un canal spécifique (i.e. un protocole
de transport) pour transférer des messages.
À propos des points de terminaison entrants :
Un point de terminaison entrant, qui se trouve au début d'un flux et agit
comme une source de message, déclenche une nouvelle instance de flux à chaque
fois qu'il reçoit un message.
Chaque message entrant doit arriver sur le canal de transport spécifique pris
en charge par le terminal qui reçoit. Par exemple, le courriel peut arriver sur un
point de terminaison entrant (compte) POP3 ou IMAP, mais les fichiers doivent
utiliser le points de terminaison FTP, « File », ou SFTP.
À propos des points de terminaison entrants :
Si un point de terminaison n'est pas le premier bloc de construction (i.e. la
source du message) dans un flux, il est désigné comme un point de terminaison
sortant, puisqu'il utilise un canal de transport spécifique qu'il prend en charge (tel
que SMTP, HTTP ou JDBC) pour distribuer des messages à des cibles en dehors
19
Illustration 13: Modèles d'échange de messages
Illustration 14: Exemple de point de terminaison entrant (Inbound Endpoint)

20. du flux qui peuvent aller à de systèmes de fichiers, à des serveurs d'email, aux
clients Web et peut également inclure d'autres flux de Mule.
Dans de nombreux cas, un point de terminaison sortant achève un flux en
envoyant un message entièrement traitée à sa dernière destination externe.
Toutefois, les points de terminaison sortants ne font pas toujours le traitement des
flux complet, car ils peuvent également exister au milieu d'un flux : Ils envoient les
données à une source externe, et les passent également (ou d'autres données) vers
le processeur de messages suivant du flux.
À propos des points de terminaison requête-réponse :
Certains points de terminaison, lorsqu'ils sont configurés sur un modèle
d'échange de requête-réponse, deviennent des points de terminaison «hybrides» qui
à la fois acceptent les messages entrants (agissant ainsi comme des sources de
messages entrants ou de terminaux), et envoi le résultats des messages traités à
leurs expéditeurs d'origine (agissant ainsi en tant que paramètres sortants ). En
outre, les points de terminaison requête-réponse peuvent, dans certaines
circonstances, apparaître au début, au milieu ou à la fin d'un flux.
Les point de terminaison disponibles dans Mule Studio :
Mule studio empaqute plus d'une vingtaine de points de terminaison et la
liste ne cesse de croître. Certains d'entre eux ne sont disponibles que pour Mule
Enterprise Edition, et par conséquent, les icônes sont rendus avec un bleu clair
(plutôt que foncé), comme illustré dans le tableau suivant:
Database (JDBC) FTP SAP
Les points de terminaison entrants et sortants :
Les points de terminaison de cette liste -non exhaustive- peuvent être ajoutés
à un flux soit comme un point de terminaison entrant ou sortant. Les points de
terminaison entrants peuvent être configurés pour recevoir des données de message
à partir de sources externes, telles qu'un navigateur Web, tandis que les points de
20
Illustration 15: Exemple de point de terminaison sortant (Outbound Endpoint)

21. terminaison sortants peuvent être configurés pour envoyer des données de message
à un correspondant externe ou à un autre bloc de construction dans un flux pour
un traitement ultérieur.
Point de
terminaison Description
AJAX Échange de façon asynchrone
des messages entre un serveur
ajax et un navigateur.
Base de données
(JDBC)
Se connecte à une base de
données en utilisant le
protocole de transport JDBC.
FTP Lit et écrit dans un serveur
FTP.
Fichier (File) Lit et écrit sur un fichier
système.
HTTP Envoie et reçoit des messages
via le protocole de transport
HTTP.
TCP Envoie ou reçoit des messages
via une socket TCP.
Les points de terminaison seulement entrants :
Comme leur nom l'indique, les points de terminaison entrants uniquement ne
peuvent que consommer des messages, ils ne peuvent pas envoyer des données vers
des destinations hors du flux. Par exemple, chacun des points de terminaison POP3
et IMAP recevoit des messages à partir d'un serveur de messagerie.
Point de
terminaison Description
IMAP transport d'email utilisé pour recevoir un
message via IMAP
POP3 Reçoit des messages via le protocole POP3
de transport d'email.
Servlet Permet à une application Mule d'écouter
des événements reçus via une servlet.
21

22. Les points de terminaison seulement sortants:
Les points de terminaison sortant uniquement peuvent envoyer des messages
aux autres blocs de construction ou vers de ressources externes, mais ils ne peuvent
pas recevoir des messages directement à partir de sources externes.
Point de
terminaison Description
SMTP Envoie un message électronique via le
protocole SMTP.
3.4.3 Les transformateurs
Vue d'ensemble :
Un transformateur prépare un message à traiter à travers un flux Mule en
augmentant ou en modifiant l'en-tête de message ou la partie utile du message. Par
exemple, si la source du message qui déclenche votre flux reçoit des données au
format XML, mais un processeur de messages aval nécessite des données au format
JSON, un ou plusieurs transformateurs placés entre la source du message et le
processeur de message peut parvenir à la traduction nécessaire. (Comme aucun
transformateur XML à JSON existe, cet exemple particulier, appelle à un XML-to-
Object transformateur enchaîné à un transformateur Object-to-JSON.)
Mule Studio fournit un ensemble de transformateurs standard pour gérer les
scénarios les plus courants de transformation de données. En règle générale, ces
blocs de construction pré-emballés nécessitent une configuration minimale.
Toutefois, si notre cas d'utilisation particulier nécessite des réglages particuliers,
on peut ouvrir la fenêtre des propriétés pour le transformateur qu'on a sélectionné,
puis modifier la configuration par défaut en utilisant la liste déroulante des listes
ou des champs de saisie de texte.
Chaînage des transformateurs :
On peut transformer une séquence de sorte que la sortie de la première
devient l'entrée pour l'autre. Par exemple, si on a besoin de mettre en œuvre une
transformation de A à D, mais aucun de ces transformateur pré-emballés existe, on
peut être en mesure de trouver tous les transformateurs préemballés nécessaires
pour mettre en œuvre la chaîne de A à B, B-à C et C à D, qui simule efficacement
la non-disponibilité de A à D du transformateur.
22

23. Les transformateurs personnalisée :
Studio fournit un transformateur personnalisé, qui nous permet de configurer
si aucun transformateur pré-emballés ou une séquence de transformateurs répond à
nos besoins. Cette option nécessite de coder une classe Java qui effectue la
transformation exacte dont on a besoin. On peut ensuite configurer le
transformateur personnalisé pour référencer cette classe personnalisée.
Mapping de données :
La composante DataMapper offre une alternative puissante et polyvalente
pour un grand nombre de transformateurs standard livré avec Studio. En plus de
traduire les données d'un format à un autre et la manipulation des valeurs,
DataMapper peut mapper un champ de saisie (comme prenom) à un champ de
sortie différent (comme nom). Plusieurs champs (tels que le titre, prenom, et nom
peuvent se combiner pour former un champ composite (comme nom_complet).
Les transformateurs d'objets Java :
Chaque transformateur dans ce groupe change un objet Java dans un autre
objet Java, un objet Java dans un autre type de données (par exemple, une requête
HTTP), ou un certain type de données non Java (comme une réponse HTTP) en
un objet Java.
Transformateurs
d'objets Java Description
Byte-Array-to-
Object
Convertit un tableau d'octets à un
objet, que ce soit en désérialisant
le tableau ou le convertissant en
une chaîne de caractères
Byte-Array-to-
String
Convertit un tableau d'octets en
chaîne
File-to-String Lit le contenu d'un java.io.File
dans un objet java.lang.String
HTTP-Response-
to-Object
Convertit une réponse HTTP (par
exemple, une chaîne, un flux ou
tableau d'octets du message net)
dans un message Mule
Object-to-Json Convertit un objet Java à un objet
JSON codée, consommable par
d'autres langues
23

24. Object-to-XML Convertit un objet Java en code
XML en utilisant XStream
Les transformateurs de contenu :
Ce groupe de transformateurs modifie des messages en ajoutant, supprimant,
ou en convertissant le message (ou une en-tête du message).
Transformateurs
de contenu Description
Append string Ajoute une chaîne de caractères
au message net
Body-to-
Parameter-map
Convertit le « bodu » d'une
requête HTTP dans un objet Map
HTTP-Response-
to-String
Convertit une réponse HTTP en
chaîne et conserve l'en-tête du
message
Message-to-HTTP-
Response
Crée une réponse HTTP valide à
l'aide du message en cours et de
ses en-têtes HTTP
XSLT Transforme XML en utilisant
XSLT
3.5Les éléments globaux
En Mule, un élément global est un bloc de construction réutilisable qu'on
configure une fois, puis référence plusieurs fois à partir de blocs de construction
dans de multiples flux. Plutôt que de répéter d'écrire le même code et d'appliquer la
même configuration à de blocs multiples, on peut créer un élément global qui
détaille nos configurations ou des détails de transport. Ensuite, on peut demander à
n'importe quel nombre de blocs de construction à travers les flux dans notre
application Mule pour référencer cet élément global.
24

25. 3.6Débogage et déploiement des applications
Après modélisation, puis configurer votre application Studio Mule, seuls deux
étapes restent pour mettre votre application au travail: le débogage, puis le
déploiement.
25
Illustration 16: Réutilisation d'un élément global
dans plusieurs flux

26. 3.6.1 Débogage d'une application
En tant que plugin Eclipse, Mule studio intègre toutes les fonctionnalités de
débogage que propose Eclipse. La perspective de débogage de Studio permet de
contrôler l'exécution de notre application en définissant des points d'arrêt, la
suspension d'applicaitons lancés, le pas à pas dans notre code, ou d'examiner le
contenu des variables.
3.6.2 Déploiement d'une application
On peut déployer une application développée sur Mule Studio de quatre
façons:
1. Déploiement sur le serveur de test intégré
2. Déploiement sur un serveur Mule Enterprise
3. Publier sur le « Mule Management Console Application Repository »
4. Déployer sur cloudhub
Déploiement sur le serveur de test intégré :
On exécute notre application en local, sur le serveur intégré de Mule Studio,
pour la tester. Le serveur Mule de test intégré est livré avec l'édition
communautaire et peut tourner pendant une période de 12 heures avant qu'il doit
être redémarré.
Lorsqu'on spécifie « Exécuter en tant qu'application Mule », Studio génère et
déploie automatiquement notre application sur le serveur Mule interne, qui démarre
automatiquement, si nécessaire.
1. Dans l'explorateur de package, un clique-droit sur le nom du projet, puis on
sélectionne Run As > Mule Application.
2. Studio exécute l'application sur le serveur de test intégré de Mule. (Sauf si
on l'arrête, Studio exécute l'application pendant une période de 12 heures.)
Les activités de l'application sont visibles dans la console Studio.
3. Pour arrêter l'exécution de l'application, on clique sur le bouton rouge, sur le
bord supérieur de la console.
26