Your SlideShare is downloading. ×
  • Like
  • Save
Introduction à mule esb
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Introduction à mule esb

  • 3,347 views
Published

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

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

Published in Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads

Views

Total Views
3,347
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
3
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 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