Premiers pas avec Mule ESB

1. Vue d'ensemble

Mule ESB est un bus de service d'entreprise léger basé sur Java. Il permet aux développeurs de connecter plusieurs applications ensemble en échangeant des données dans différents formats. Il transporte des données sous la forme d'un message.

Les ESB offrent des capacités puissantes en fournissant un certain nombre de services, tels que:

  • Création et hébergement de services
  • Médiation de service
  • Routage des messages
  • Transformation des données

Nous trouverons les ESB utiles si nous avons besoin d'intégrer plusieurs applications ensemble, ou si nous avons l'idée d'ajouter plus d'applications à l'avenir.

ESB est également utilisé pour traiter plus d'un type de protocole de communication et lorsque des capacités de routage de messages sont requises.

Créons un exemple de projet dans la section 5 à l'aide d' AnyPoint Studio qui est disponible en téléchargement ici.

2. Structure des messages Mule

En termes simples, l'objectif principal d'un ESB est de servir d'intermédiaire entre les services et d'acheminer les messages vers divers points de terminaison. Il doit donc gérer différents types de contenu ou de charge utile.

La structure du message est divisée en deux parties:

  • L'en-tête, quicontient des métadonnées de message
  • La charge utile, qui contient des données spécifiques à l'entreprise

Le message est incorporé dans un objet de message. Nous pouvons récupérer l'objet message à partir du contexte. Nous pouvons modifier ses propriétés et sa charge utile à l'aide de composants Java personnalisés et de transformateurs dans un flux Mule.

Chaque application se compose d'un ou plusieurs flux.

Dans un flux, nous pouvons utiliser des composants pour accéder, filtrer ou modifier un message et ses différentes propriétés.

Par exemple, nous pouvons obtenir une instance d'un message en utilisant le composant Java. Cette classe implémente composant un appelable d'interface de org.mule.api.lifecycle package:

public Object onCall(MuleEventContext eventContext) throws Exception { MuleMessage message = eventContext.getMessage(); message.setPayload("Message payload is changed here."); return message; }

3. Propriétés et variables

Les métadonnées du message se composent de propriétés. Les variables représentent des données sur un message. La manière dont les propriétés et les variables sont appliquées tout au long du cycle de vie du message est définie par leurs portées. Les propriétés peuvent être de deux types, en fonction de leur étendue: entrante et sortante.

Les propriétés entrantes contiennent des métadonnées qui empêchent le brouillage des messages lors de la traversée des flux. Les propriétés entrantes sont immuables et ne peuvent pas être modifiées par l'utilisateur. Ils ne sont présents que pendant la durée du flux - une fois que le message quitte le flux, les propriétés entrantes ne sont plus présentes.

Les propriétés sortantes peuvent être définies automatiquement par Mule, ou un utilisateur peut les définir via la configuration de flux. Ces propriétés sont modifiables. Ils deviennent des propriétés entrantes lorsqu'un message entre dans un autre flux après avoir franchi les barrières de transport.

Nous pouvons définir et obtenir des propriétés sortantes et entrantes respectivement en appelant les méthodes setter et getter associées dans leurs portées respectives:

message.setProperty( "outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); String inboundProp = (String) message.getInboundProperty("outboundKey");

Il existe deux types de variables disponibles à déclarer dans les applications.

La première est la variable de débit qui est locale à un flux Mule et disponible dans le flux, les sous-flux et les flux privés.

Les variables de session une fois déclarées deviennent disponibles dans l'ensemble de l'application.

4. Barrières de transport et ref.

Les barrières de transport sont des connecteurs HTTP, des VM, des JMS ou des connecteurs similaires qui nécessitent des chemins ou des points de terminaison pour que les messages soient routés. Les variables de flux ne sont pas disponibles à travers les barrières de transport, mais les variables de session sont disponibles dans le projet dans tous les flux.

Lorsque nous devons créer un sous-flux ou un flux privé, nous pouvons faire référence au flux d'un parent ou d'un autre flux à l'aide du composant flow-ref . Les variables de flux et les variables de session sont disponibles dans les sous-flux et les flux privés référencés à l'aide de flow-ref .

5. Exemple de projet

Créons une application dans Anypoint Studio qui contient plusieurs flux, qui communiquent entre eux via des connecteurs entrants et sortants.

Regardons le premier flux:

Nous pouvons configurer un écouteur HTTP comme:

Les composants de flux doivent être à l'intérieur d'un marque. Ainsi, un exemple de flux avec plusieurs composants est:

Dans le flux, nous fournissons une référence à un écouteur HTTP configuré. Ensuite, nous gardons un enregistreur pour enregistrer la charge utile que l'écouteur HTTP reçoit via la méthode POST.

Après cela, une classe de transformateur Java personnalisée est placée, qui transforme la charge utile après réception du message:

public Object transformMessage( MuleMessage message, String outputEncoding) throws TransformerException { message.setPayload("Payload is transferred here."); message.setProperty( "outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); return message; }

La classe transformer doit étendre AbstractMessageTransformer . Nous définissons également une propriété sortante à l'intérieur de la classe.

Maintenant, nous avons déjà converti la charge utile à l'intérieur de l'objet de message et l'avons consigné dans la console à l'aide du logger. Nous définissons une variable de flux et une variable de session.

Finally, we are sending our payload through outbound VM connector. The path in VM connector determines the receiving endpoint:

The message carried and transformed by the initial flow reaches Flow1 through an inbound VM endpoint.

The Java component retrieves outbound properties set by the first flow and returns the object which becomes the message payload.

The transformMessage() method for this task:

public Object transformMessage( MuleMessage message, String outputEncoding) throws TransformerException { return (String) message.getInboundProperty("outboundKey"); }

Then, flow and session variables are set to the second flow. After that, we've got a reference to Flow2 using flow-ref component.

In Flow2, we've transformed the message using Java component class and logged it in the console. We've also set a flow variable F3.

After calling Flow2 using flow-ref, Flow1 will wait for the message to be processed in Flow2.

Any flow variable set in Flow1 and Flow2 will be available in both flows since these flows aren't separated by any transport barriers.

Finally, the message is sent back to the HTTP requester through VMs. We configured all VMs as request-response.

We can invoke this application from any REST client by posting any JSON data in the body. The URL will be localhost:8081 as configured in HTTP listener.

6. Maven Archetype

We can build a Mule ESB project using Mulesoft's Maven archetype.

In Maven's settings.xml file, we first need to add the org.mule.tools plugin group:

 org.mule.tools 

Then, we need to add a profile tag that says where Maven should look for Mulesoft artifacts:

 Mule Org  true    mulesoft-releases MuleSoft Repository //repository-master.mulesoft.org/releases/ default   

Finally, we can create the project using mule-project-archetype:create:

mvn mule-project-archetype:create -DartifactId=muleesb -DmuleVersion=3.9.0

After configuring our project, we can create a deployable archive using mvn package.

After that, we'd deploy the archive into the apps folder of any standalone Mule server.

7. A Standalone Mule Server via MuleSoft's Maven Repository

As just noted, the project we just created requires a standalone Mule server.

If we don't already have one, we can edit our pom.xml to pull one from MuleSoft's Maven repository:

 org.mule.tools.maven mule-maven-plugin 2.2.1  standalone 3.9.0    deploy deploy  deploy    

8. Conclusion

In this article, we've gone through different necessary concepts of building as ESB application in Mule. We've created a sample project illustrating all the described concepts.

We can now start creating ESB application using Anypoint Studio to meet our various needs.

As usual, the complete project can be found over on GitHub.

1. Overview

Mule ESB is a lightweight Java-based Enterprise Service Bus. It allows developers to connect multiple applications together by exchanging data in different formats. It carries data in the form of a message.

ESBs offer powerful capabilities by providing a number of services, such as:

  • Service creation and hosting
  • Service mediation
  • Message routing
  • Data transformation

We'll find ESBs useful if we need to integrate multiple applications together, or if we have the notion of adding more applications in the future.

ESB is also used for dealing with more than one type of communication protocol and when message routing capabilities are required.

Let's create a sample project in Section 5 using AnyPoint Studio which is available for download here.

2. Mule Message Structure

Simply put, the primary purpose of an ESB is to mediate between services and route messages to various endpoints. So it needs to deal with different types of content or payload.

The message structure is divided into two parts:

  • The header, whichcontains message metadata
  • The payload, which contains business-specific data

The message is embedded within a message object. We can retrieve the message object from the context. We can change its properties and payload using custom Java components and transformers inside a Mule flow.

Each application consists of one or more flows.

In a flow, we can use components to access, filter or alter a message and its different properties.

For example, we can obtain an instance of a message using Java component. This component class implements a Callable interface from org.mule.api.lifecycle package:

public Object onCall(MuleEventContext eventContext) throws Exception { MuleMessage message = eventContext.getMessage(); message.setPayload("Message payload is changed here."); return message; }

3. Properties and Variables

Message metadata consists of properties. Variables represent data about a message. How properties and variables are applied across the message's life-cycle is defined by their scopes. Properties can be of two types, based on their scope: inbound and outbound.

Inbound properties contain metadata that prevents messages to become scrambled while traversing across flows. Inbound properties are immutable and cannot be altered by the user. They're present only for the duration of the flow – once the message exits the flow, inbound properties are no longer there.

Outbound properties can be set automatically by Mule, or a user can set them through flow configuration. These properties are mutable. They become inbound properties when a message enters another flow after crossing transport-barriers.

We can set and get outbound and inbound properties respectively by calling associated setter and getter methods in their respective scopes:

message.setProperty( "outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); String inboundProp = (String) message.getInboundProperty("outboundKey");

There are two types of variables available to declare in applications.

One is flow variable which is local to a Mule flow and available across the flow, sub-flows and private flows.

Session variables once declared become available across the entire application.

4. Transport Barriers and flow-ref

Transport barriers are HTTP-connectors, VMs, JMS or similar connectors that require paths or endpoints for messages to be routed. Flow variables aren't available across transport barriers, but session variables are available across the project in all flows.

When we need to create sub-flow or private flow, we can refer to the flow from a parent or another flow using flow-ref component. Both flow variables and session variables are available in sub-flows and private flows referred to using flow-ref.

5. Example Project

Let's create an application in Anypoint Studio that contains multiple flows, which communicate between themselves through inbound and outbound connectors.

Let's look at the first flow:

We can configure an HTTP listener as:

Flow components must be inside a tag. So, an example flow with multiple components is:

Inside the flow, we're providing a reference to a configured HTTP listener. Then we're keeping a logger to log the payload that HTTP listener is receiving through POST method.

After that, a custom Java transformer class is placed, that transforms the payload after receiving the message:

public Object transformMessage( MuleMessage message, String outputEncoding) throws TransformerException { message.setPayload("Payload is transferred here."); message.setProperty( "outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND); return message; }

The transformer class must extend AbstractMessageTransformer. We're also setting an outbound property inside the class.

Now, we have already converted payload inside the message object, and have logged that in the console using logger. We're setting a flow variable and a session variable.

Finally, we are sending our payload through outbound VM connector. The path in VM connector determines the receiving endpoint:

The message carried and transformed by the initial flow reaches Flow1 through an inbound VM endpoint.

The Java component retrieves outbound properties set by the first flow and returns the object which becomes the message payload.

The transformMessage() method for this task:

public Object transformMessage( MuleMessage message, String outputEncoding) throws TransformerException { return (String) message.getInboundProperty("outboundKey"); }

Then, flow and session variables are set to the second flow. After that, we've got a reference to Flow2 using flow-ref component.

In Flow2, we've transformed the message using Java component class and logged it in the console. We've also set a flow variable F3.

After calling Flow2 using flow-ref, Flow1 will wait for the message to be processed in Flow2.

Any flow variable set in Flow1 and Flow2 will be available in both flows since these flows aren't separated by any transport barriers.

Finally, the message is sent back to the HTTP requester through VMs. We configured all VMs as request-response.

We can invoke this application from any REST client by posting any JSON data in the body. The URL will be localhost:8081 as configured in HTTP listener.

6. Maven Archetype

We can build a Mule ESB project using Mulesoft's Maven archetype.

In Maven's settings.xml file, we first need to add the org.mule.tools plugin group:

 org.mule.tools 

Then, we need to add a profile tag that says where Maven should look for Mulesoft artifacts:

 Mule Org  true    mulesoft-releases MuleSoft Repository //repository-master.mulesoft.org/releases/ default   

Finally, we can create the project using mule-project-archetype:create:

mvn mule-project-archetype:create -DartifactId=muleesb -DmuleVersion=3.9.0

After configuring our project, we can create a deployable archive using mvn package.

After that, we'd deploy the archive into the apps folder of any standalone Mule server.

7. A Standalone Mule Server via MuleSoft's Maven Repository

As just noted, the project we just created requires a standalone Mule server.

Si nous n'en avons pas déjà un, nous pouvons éditer notre pom.xml pour en extraire un du référentiel Maven de MuleSoft:

 org.mule.tools.maven mule-maven-plugin 2.2.1  standalone 3.9.0    deploy deploy  deploy    

8. Conclusion

Dans cet article, nous avons passé en revue différents concepts nécessaires pour créer une application ESB dans Mule. Nous avons créé un exemple de projet illustrant tous les concepts décrits.

Nous pouvons maintenant commencer à créer une application ESB en utilisant Anypoint Studio pour répondre à nos différents besoins.

Comme d'habitude, le projet complet peut être trouvé sur GitHub.