Mulesoft Tutorial

  • (4.0)
  • | 16132 Ratings
Mulesoft Tutorial

One of the most popular enterprise service bus (ESB), Mule has the features of being Java-based, light-weight, and it functions as the runtime engine of a complete hybrid enterprise integration platform for SOA, SaaS and APIs called the Anypoint platform

Mulesoft ESB

Mulesoft is a popular integration platform which facilitates developers in connecting applications together thereby enabling the exchange of data and moreover, the advantage offered to be swiftness and easiness. Regardless of the different kinds of technologies that various applications make use of, including HTTP, JMS, Web Services, JDBC and others, Mulesoft is very useful in easy integration of existing systems, Another prominent advantage that ESB provides is the real-time integration and orchestration of events or also in batch, whose deployment can be done from anywhere and has worldwide connectivity.

Mule ESB

You might have a question in your mind regarding what an ESB is and in which way this bus-like infrastructure is useful in the organizing of your applications and systems.

The idea of ESB was conceived due to the downsides appearing in the point-to-point integration. The main ones being brittleness and hard manageability after a period of time. Point-to-point integration also has another drawback: as a consequence of using this method custom integration code will spread among applications with no central way to facilitate monitoring or troubleshooting. This is usually referred to as "spaghetti code" and it also doesn’t scale as tight dependencies between applications are created.

An Enterprise Service Bus (ESB) is an architecture.

It can be considered as a fusion of rules and principles with the purpose of integrating many applications together, irrespective of the number over a bus-like infrastructure. The essence behind the ESB architecture is that one will be able to integrate different applications by providing a communication bus between them. By doing this, each application will be able to talk to the bus. As a consequence, systems are decoupled from each other, facilitating them to conduct communication without dependency on or knowledge of other systems which are on the bus.

ESB provides the following advantages:

  • It fastens up the process of marketing your new initiatives
  • Productivity is vastly improved, which converts to more apps developed within your business
  • Facilitates leveraging your already existing systems during the development of applications all thanks to the transformation capabilities and pre-built communication.

One should be using an ESB if the answer to the following questions is ‘YES’!

  • Is there a need to integrate three or more applications or services?
  • Is there a requirement of plugging in more applications with the passage of time?
  • Is there a requirement of using more than one type of communication protocol?
  • Would a need arise for message routing capabilities like content-based routing, forking and aggregating message flows?
  • Is there a scenario where the services you publish are consumed by other applications?

Returning to our main topic of discussion, Mule ESB comprises of the following capabilities:

  • Service mediation - Helps in the creation of message protocol and format independence among applications.
  • Service creation and hosting - it serves as a lightweight container in order to expose and host reusable services.
  • Data transformation - facilitates the exchange of data regardless of the format or transport protocol.
  • Message routing - facilitates the rerouted, filtered, aggregated or re-sequenced of messages based on rules and content.

Mule ESB is considered the best in the market. Wondering why? Let us now try to understand the competitive advantage Mule ESB offers.

Effective Scaling, both Up and Down: 

This would ensure limitless freedom for your teams. As a result, they can bridge together as many apps and systems as needed.

Ideally Embeddable: 

  • Can be directly embedded into a single app
  • Can be plugged it into your app server
  • Can also be embedded into a JUnit test case
Integration of All Components:

Irrespective of the Technology used. Not only integrating them under its umbrella it also enhances the communication across the infrastructure of various apps and multiple systems.

Highly Accessible:

A wide variety of code languages are supported and also, it comes with a large variety of widely used tools that your team might already be familiar with. As a direct consequence, the development team would face very fewer problems in writing custom code.

Reusability of Components:

The team is motivated and encouraged to reuse the infrastructure components.


By eliminating all the unused modules with its modular design, you make it lighter

  • Reusability of Components:
  1. The team is encouraged to reuse your infrastructure's components.
  2. Lightweight:
  3. its modular design helps you make it lighter by removing all the unused modules.

Mule Application Building Blocks

The Mule Palette is the place where the Mule application building blocks are separated into categories. Let us take a quick glance through each one of them. 

Message Sources:

In a building block Message Source is the first one. It is a receiver that facilitates the receiving of new messages and their placement in the queue for processing.

Message sources are Anypoint Connectors. Connectors are useful in providing connectivity to external resources, such as:

  • Protocols, Databases, or APIs.
  • Standard protocols ( HTTP, SMTP, AMQP, FTP).
  • Twitter, Salesforce, or MongoDB (Third-party APIs ).

Connectors of Anypoint:

The second building block is the Anypoint connectors. Anypoint Platform is equipped with more than 120 pre-built connectors - out of which 30 are packaged with Anypoint Studio and the remaining ones are available in the Anypoint Exchange.

Connectors can be accessed in two ways: either directly from Anypoint Studio or at

Here we have mainly two types of Anypoint Connectors:

  • Connectors of Endpoint-based
  • Connectors of Operation-based 

Connectors of Endpoint-based:

  • There are two endpoints in a flow which can be either inbound or outbound.
  • Inbound endpoints function as a message source for a flow.
  • Outbound endpoints facilitate the transfer of information to the external system.

Connectors of Operation-based:

  • In order to structure the building blocks, these connectors would need the specification of an operation. This category includes most connectors which are not based on a standard communication protocol.
  • You might be a little unclear with the concept of Endpoints and Connectors. A connector is nothing but a Mule-specific connection to an external resource of any kind. But an endpoint can be considered as a flow-level element that has been configured to facilitate the receiving and/or sending messages from and/or to external resources.
  • An endpoint is created, whenever you drag a connector from the Mule Palette. Connectors and endpoints, both of them are global elements.

Operation-based connectors

  • In order to structure the building blocks, these connectors require the specification of an operation. This category includes most connectors not based on a standard communication protocol.
  • You might be a little confused with Endpoints and Connectors. A Mule-specific connection to an external resource of any kind is called a Connector. But an endpoint is a flow-level element that is configured to receive and/or send messages from and/or to external resources.
  • An endpoint is created, when you drag a connector from the Mule Palette. Connectors and endpoints, both are global elements.

Frequently asked MuleSoft Interview Questions


Now let us move on to Mulesoft Anypoint Studio. Anypoint Studio is an integrated development environment (IDE) which is Eclipse-based that provides:

  • Two-way editing choice between graphical and XML views.
  • A framework for data transformation and language (EE - Enterprise Edition).
  • Templates for frequent integration patterns (EE - Enterprise Edition).
  • Visual debugging (EE - Enterprise Edition)
  • Integration with Maven for continuous build processes
  • One-click deployment of applications.


Running an Application in Anypoint Studio:

In order to test applications without leaving it, an embedded Mule runtime is provided in the Anypoint Studio This console will provide us with the application logs and information.

Testing Applications to Make Requests to an Endpoint:

Some options include

  • Using a browser.
  • Making use of a CURL command-line utility.
  • A browser extension like Postman (for Google Chrome).

Mule Flow and Messages:

Let us now talk about Mule Flow and Messages.

Mule Flow

With help from a series of message processors which are plugged together in the flow, the acceptance and processing of messages is done by the Mule applications. 

A typical flow has the following components:

Message Source - takes in a message which is from an external source, and then the execution of the flow is triggered. 

Message Processors - Transforms, filters, enriches, and processes messages.

An application can comprise of:

  • A single flow.
  • Multiple flows which are connected together helping in the creation of more complex applications.

Mule Message

A Mule Message comprises of

  • Inbound Properties which have been set from the message source
  • Outbound Properties which will be added by the message processor
  • Payload which is the crux of the message
  • Attachments which can be considered as the ancillary info to the message

The message structure is separated into two parts:

  • The header of Message  – It comprises of the message metadata
  • The payload of Message – It comprises of the business-specific data

Every message object contains the embedded message within it. The message object can be retrieved from the context. We also have the option of changing its properties and payload by making use of the custom Java components and transformers inside a Mule flow.

Properties, Variables and Transport Barriers


The message metadata includes properties. The variables help in speaking to the information about a message. The extent of properties and variables characterizes their application over the message's life-cycle. 

Contingent upon their degree, properties can be of two sorts: inbound and outbound. 

Inbound Properties 

A few properties contain metadata which helps In keeping the messages from getting to be mixed while crossing crosswise over streams. These properties are changeless and can't be modified by the client. They're accessible just for the degree of the stream – when the message leaves the stream, inbound properties will never again be available there. 

Outbound Properties 

Outbound properties can be consequently set by Mule or by taking the assistance of stream arrangements of a client. In contrast to inbound properties, outbound properties are changeable. They change into inbound properties at whatever point a message enters another stream subsequent to making a cross through transport-barriers. 

One can set and get outbound and inbound properties individually by making a call to the related setter and getter techniques in their particular scope:

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


In Applications, there are two types of variables which are available to declare.

Flow Variable

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

Session Variable

Session Variable becomes available over the entire application once it has been declared.

Transport Barriers

Transport barriers incorporate HTTP-connectors, VMs, JMS or comparable connectors. These need ways or endpoints for a message so as to be steered. 

In the event that we see cautiously, one key refinement between flow variables and sessions variables as for transport barriers is that flow variable isn't accessible crosswise over transport barriers, however, session variables are accessible over the task in all flows. 


Amid the formation of sub-flow or private flow, we can either allude to the flow from a parent or another flow utilizing the flow-ref segment. Both the flow variables and session variables are accessible in sub-flows and private flows which can be alluded utilizing flow-ref.

Mulesoft Sample Application

Give us a chance to get our hands grimy by making an application in Anypoint Studio which contains different flows, and impart between themselves utilizing inbound and outbound connectors.

We can configure an HTTP listener as

host="localhost" port="8081" doc:name="HTTP Listener Configuration"/>

Flow components must always be contained within a tag. Let us see an example flow which has multiple components: 

<flow name="Flow">
path="/" doc:name="HTTP"
<logger message="Original
paylaod: #[payload]"
level="INFO" doc:name="Logger"/>
<logger message="Payload After Initialization: #[payload]"
level="INFO" doc:name="Logger"/>
<set-variable variableName="f1"
value="#['Flow Variable 1']" doc:name="F1"/>
<set-session-variable variableName="s1"
value="#['Session variable 1']" doc:name="S1"/>
<vm:outbound-endpoint exchange-pattern="request-response"
path="test" doc:name="VM"/>

STEP 2. A reference is being provided to a configured HTTP listener inside the flow. Post that we’re maintaining a logger which is useful to log the payload that HTTP listener is receiving through POST method.

Then, in order to transform the payload after receiving the message, a custom Java transformer class is put: 

public Object transformMessage(
MuleMessage message,
  String outputEncoding) throws TransformerException {

message.setPayload("Payload is transferred here.");
      "outboundKey", "outboundpropertyvalue", PropertyScope.OUTBOUND);
return message;

STEP 3. The transformer class must be extending AbstractMessageTransformer. An outbound property is also being set inside the class. Now that the payload has been converted inside the message object, and have logged that in the console with the help of the logger, we'll now set two variables - a flow variable and a session variable. 

Finally, we will now be sending our payload by making use of the outbound VM connector. The receiving endpoint is determined by the path in VM connector.

STEP 4. After being carried and transformed by initial flow, a message now reaches Flow1 with the help of inbound VM endpoints. The outbound properties which have been set by the first flow are retrieved by the Java components and it returns the object, which now is the message payload.

The transfer message() method for this task:

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

After this, the session and flow variables are set to the second flow. Now we have obtained a reference to Flow2 using flow-ref component.

In Flow2, the message has been changed with help from the Java component class and logged it in the console. The F3 flow variable has also been set.

After calling Flow2 with the help of flow-ref, Flow1 will wait for the message to be processed in Flow2. Any flow variable which has been set in Flow1 and Flow2 will be accessible in both flows.

The reason for this is that these flows aren’t separated by any transport barriers. Finally, with the help of VMs, the message will be sent back to the HTTP requester. All the VMs have been configured as request-response. This application can be invoked from any REST client by posting any JSON data in the body. As configured in the HTTP listener, the URL will be localhost:8081. 

STEP 5. Building Projects Using Maven in Command Line

We need to include pluginGroup in the settings.xml file which is located in Maven’s conf directory, 


We also need to communicate to Maven where it will be able to find Mule repositories and this should to be included in profile tag:

< profile >
< id >Mule Org< /id  >
< activation >
< activeByDefault >true< /activeByDefault >
< /activation >
< repositories>
< repository >
< id >mulesoft-releases< /id >
< name >MuleSoft Repository< /name>
< url >< /url >
< layout >default< /layout >
< /repository >
< repository >
< id >mulesoft-snapshots< /id >
< name >MuleSoft Snapshot Repository< /name >
< url >< /url >
< layout >default< /layout>
< /repository >
< /repositories >
< /profile >

Now, it is easy to initiate a Maven project by using the command:

mvnmule-project-archetype:create -DartifactId=muleesb -DmuleVersion=3.8.1

After configuration of this project has been done, a deployable archive using mvn package command can be created. The deployment of this archive can be done in the apps folder of any standalone Mule server.

That covers our sample application in MulesoftAnypoint Studio. Do reach out to us in case of any issues with the understanding. 

Explore Mulesoft Sample Resumes! Download & Edit, Get Noticed by Top Employers! Download Now!


Being both lightweight and also highly scalable, Mulesoft allows one to start small and connect more applications as time progresses. The competitive advantage it offers is also unmatched We can’t wait to see you get started and get going.

Subscribe For Free Demo

Free Demo for Corporate & Online Trainings.

Anji Velagana
About The Author

Anji Velagana is working as a Digital Marketing Analyst and Content Contributor for Mindmajix. He writes about various platforms like Servicenow, Business analysis,  Performance testing, Mulesoft, Oracle Exadata, Azure, and few other courses. Contact him via and LinkedIn. Protection Status