Mulesoft Training Interview Questions and Answers

1. What is a Mule?

Mule ESB (a.k.a. Mule) is a lightweight Java-based enterprise service bus (ESB) and integration platform that allows developers to connect applications together quickly and easily, enabling them to exchange data. Mule ESB enables easy integration of existing systems, regardless of the different technologies that the applications use, including JMSWeb Services, JDBC, HTTP, and more.

2. Why Mule ESB?

Mule ESB is a lightweight open-source framework but highly scalable, allowing you to start small applications and connect multiple applications. Mule manages all the interactions between applications and components transparently, ESB will take care of the multiple applications, and we can easily integrate third-party applications using Mule.

3. Difference between Callout and Service Invoke?

Service Invoke: The Service Invoke primitive is used to make a service request in either a request or response mediation flow. The service may be Request/Response or One-Way. Multiple instances of the Service Invoke primitive are permitted in a flow, allowing a series of service invocations to be performed.

Callout: The Callout receives the message and calls the requested service and operation. There is a Callout node for each connected target operation in the mediation flow.

4. What are all the Primitives used in Mediation?

We have different types of primitives in mediation.

  • Message Filter
  • Type Filter
  • Endpoint Lookup
  • Service Invoke
  • Fan-out
  • Fan-in
  • XSLT
  • BO Map
  • Message Element Setter
  • DB lookup
  • Data Handler
  • Custom Mediation
  • Header Setters
  • Message Logger
  • Even Emitter
  • Stop
  • Fail
  • Sub Flow

5. What are all the configurations required for JDBC Adapter implementation?

Data Sources need to be created and need to be configured with DB. If we have security, then we need to create security authentication.

6. Difference between SDO and SMO?

SDO: Service Data Object is the representation of the variable or Object.

SMO: The SMO model is a pattern for using SDO Data Objects to represent messages

7. What is the functionality of Fan-in and Fan-out?

Fan-out: We can use the Fan Out primitive to fire the output terminal once (with the input message) or fire the output terminal multiple times. You can use Fan Out in isolation or as part of a Fan-Out and Fan In combination.

Fan-In: Fan In is always partnered with a Fan-Out in the same flow and acts as a decision point for when to continue flow execution. It receives a number of messages until a decision point is reached, at which point the last message to be received is propagated to the output terminal. The Fan In primitive may only be used in combination with Fan-Out.

8. Difference between Stop and fail?

Stop: Stops a particular path in the flow, without generating an exception.

Fail: Generates a failure in the flow.

9. What is Correlation Context?

Correlation Context: Used when Mediation primitives want to pass values from the request flow to the response flow. Used to pass values from the request message onto the response.

10. What is Shared Context?

Shared Context is a temporary area that is created along with Service Message Object (SMO) in the Mediation Flows. Shared Context is a type of context which is present in the SMO. Shared Context is mainly used when we are using an Aggregation process where we need to iterate the BO for Certain times. Shared Context maintains Aggregation data between Aggregation (Fanout and Fan-in) primitives. The Content (data) which is present in the shared context BO does not persist across Request and Response flows i.e. The Data in the Shared Context which is used in Request flow cannot be used again in Response flow.

11. What is Transient Context?

Transient Context is used for passing values between Mediation primitives within the current flow either the request flow or the responses flow. The transient context cannot link requests and responses and hence cannot be used across. Used when you want to save an input message before a service invokes a call. After the services invoke call, the next primitive can create another message by combining the service invoke response and the original message stored in the transient context.

12. What is a Mule UMO?

A Mule UMO is a Universal Message Object

UMO is now a legacy term. What was once referred to as UMO Components are now referred to as Service Components.

13. How to add classes/jars to the Mule class path?

Use the MULE_LIB variable (generally set in the run script)

To include JAR file(s) in a mule classpath, declare each dependent jar file in the MULE_LIB entry.

For spring resource, if the XML bean declaration is placed within a project, include the project JAR file in the classpath too (i.e. if not included, Mule will throw a **.xml not found on the classpath)

14. Why is it important to be able to categorize exceptions?

It is important to be able to categorize exceptions because not all exceptions are the same. At a very high level, we can classify exceptions into “Business” or “Non-Business” exceptions. Within these two classes, there can be any number of types of Business and Non-Business exceptions.

Business exceptions are typically due to incorrect data or incorrect process flow. Due to the nature of a business exception, it is typically non-retriable and therefore would not make sense to configure a rollback and retry. Instead, processing should stop immediately, and the exception sent back as a response or message routed to a dead letter queue and a notification sent to operations.


15. How Mule Selects a Flow Processing Strategy

Each flow varies in the degree to which it can benefit from the transactional reliability of synchronous processing, as opposed to the high throughput of the queued-asynchronous alternative. 

Mule selects a processing strategy for a flow based on two criteria:

  1. The flow’s exchange pattern
  2. Whether or not the flow is transactional

A flow employs one of two exchange patterns, determined by the exchange pattern of the flow’s inbound endpoint:

A request-response exchange pattern is used when the sender of the messages (i.e. the flow’s inbound endpoint) expects a response or some kind of result to return to the caller.

A one-way exchange pattern is used when no response is expected, or when the result is sent to some other flow or system and not back to the caller.

16. How can you implement a loop in mediation?

By using Fan-in and Fan-out primitive.

17. How do I start Mule server within my web app?

  • Define your mule configuration file and ensure that it is included in the web app class path.
  • Add the following lines in the web.xml















        <load-on-startup />






NOTE: The mule version used was 1.3.3

18. How do I use Mule to call JIRA Web Services?

The following sample shows how to use Mule to call JIRA web services in JIRA. It will do simple things such as,

1. Login to JIRA (external JIRA instance)
2. Get JIRA server information

In order to use the sample make sure you have the com.Atlassian.Jira.RPC.soap.beans.RemoteServerInfo class file in your classpath. The .class file is inside the Atlassian-Jira-RPC-plugin-3.7.3-1.jar file in your JIRA directory. It’s located (in Windows) under <jira_installation_dir>\atlassian-jira\WEB-INF\lib directory

19. How to invoke an HTTPS page

You need to set up your key store. Do this by retrieving the certificate from the server. A command like the below will do:

$: OpenSSL s_client -connect server port

20. What is Mule Data Integrator?

Mule has released a data integrator tool, it is a visual mapping tool that supports flat-file, java objects, XML mappings, etc. Coding complex mappings can be very tedious and additionally difficult to maintain, the mule data integrator with drag and drop facilities makes building and maintaining mappings very simple.

The mapping is done in eclipse (plugins required) and executed on a data integrator runtime that sits onto Mule ESB – this requires a license.