Mulesoft interview questions

MuleSoft Interview Questions – Top 50

1. What is Mulesoft?

Answer:

MuleSoft provides the most widely used integration platform (Mule ESB

&CloudHub) for connecting SaaS& enterprise applications in the cloud and on-premise.

2. What is a REST web service?

Answer:

Representational State Transfer (REST) is an architectural style that specifies
constraints, such as the uniform interface, that if applied to a web service induce
desirable properties, such as performance, scalability, and modifiability, that enable
services to work best on the Web.

3. What are the Flow Processing Strategies?

Answer:

  • Synchronous Flow Processing Strategy, Queued Flow Processing
  • Strategy, Asynchronous Flow Processing Strategy, Thread Per Processing
  • Strategy, Queued Asynchronous Flow Processing Strategy, Non-blocking Flow
  • Processing Strategy, Custom Processing Strategy, Rollback Exception Handling.

4. What is caching and why to use it?

Answer:

Caching is a concept with is used to store frequently used data in the memory, file
system or database which saves processing time and load if it would have to be
accessed from original source location every time.

5. How can we create and consume SOAP service in Mule?

Answer:

Creating SOAP Service – We can create a SOAP service same as we create Mule
Project With RAML, the only change is instead of RAML we need to import Concert
WSDL. Consuming SOAP Service – We can use Web Service Consumer or CXF
component in our mule flow to access/consume SOAP service.

6. What are Shared Resources in Mule and how are they been used?

Answer:

We can make connectors as an reusable component by defining them as common
resources and expose them to all applications deployed under a same domain, these
resources are known as shared resources. These shared resource needs to be
defined inside Mule Domain Project and then referred to each of the projects that
are meant to use the elements in it. (eLearning Portal)

7. What are the different types of flow?

Answer:

Subflow – A subflow is always synchronous. It is similar to a synchronous flow,
subflow executes in the same thread of the calling process. Calling process triggers
the sub-flow and waits for it to complete and resumes once the sub-flow has
completed.
Synchronous Flow– Same as sub-flow, the only difference is that in synchronous
flows you need to separately define an exception strategy to it, it does not inherit the
exception strategy of its calling flow.
Asynchronous Flow – As in sub-flow and synchronous flow, calling process
triggers the sub-flow and waits for it to complete; for asynchronous flow the flow,
calling process triggers an asynchronous flow and moves ahead to its next activity.
An asynchronous flow executes in parallel to its calling/parent flow in a different
thread. An asynchronous flow does not return its output to its parent/calling flow.
Private Flow – flow that does not have an inbound connector in the source. Means
a private flow cannot start on its own on receiving the inbound message as it does not
have any inbound connector, A private flow can only be called using flow-ref same assub-flow.

8. What is Shared Resource in Mule and how they have been used?

Answer:

We can make connectors as a reusable component by defining them as common
resources and expose them to all applications deployed under the same domain,
these resources are known as shared resources. These shared resource needs to be
defined inside Mule Domain Project and then referred to each of the projects that are
meant to use the elements in it.

9. Why Mule Was Designed?

Answer:

Mule’s core was designed as an event-driven framework combined with a unified
representation of messages, expandable with pluggable modules. These modules
would provide support for a wide range of transports or add extra features, such as
distributed transactions, security, or management. Mule was also designed as a
programmatic framework offering programmers the means to graft additional
behavior such as specific message processing or custom data transformation.
(Mulesoft Interview Questions)

10. How can you change the runtime changes using mediation
primitive?

Answer:

We have future called Promotable properties in ESB. We can configure this future
while development. Then we can make it changed at runtime without restarting the
server it can be published.

mulesoft tutorial

11. What Is Router In Mule?

Answer:

Routers play a crucial role in controlling the trajectory a message will follow when it
transits in Mule. They are the gatekeepers of the endpoints of a service, taking care of
keeping messages on the right succession of tracks so they can reach their intended
destinations. Certain routers act like the big classification yards: they can split, sort,
or regroup messages based on certain conditions.

12. What are different types of Primitives used in Mediation?

Answer:

These are the different types of primitives in mediation:

1. Message Filter
2. Type Filter
3. Endpoint Lookup
4. Service Invoke
5. Fan-out
6. Fan-in
7. XSLT
8. BO Map
9. Message Element Setter
10. DB lookup
11. Data Handler
12. Custom Mediation
13. Header Setters
14. Message Logger
15. Even Emitter
16. Stop
17. Fail
18. Sub Flow

13. How Mule ESB works?

Answer:

Mule is based on the concept of Event Driven Architecture (EDA), works by
responding to messages initiated by external resources (that is, events). Mule
applications accept and process events as messages through several message
processors plugged together in a flow. Alternatively, large or streaming messages can
be processed as records in a batch job.
Every Mule flow contains a series of message processors that accept, then process
messages. Mule applications usually contain multiple linked flows and/or batch jobs,
which, in combination, perform the integration required for your use case.

14. What are the main Features of Mule ESB? What are the different ESBs in the market?

Answer:

1)The main Features of Mule ESB are:

• It is very simple and easy to use-Drag and drops Graphical design
• SLA monitoring and API management
• High scalability
• We can deploy in a One-click cloud or on-premise deployments

2)Different ESB’s in Market are:

• Talend
• Mule ESB
• JBoss Fuse ESB

15. What Is Global Endpoint In Mule?

Answer:

An endpoint destination that is shared by several routers, it is worth creating a global
endpoint. A global endpoint is not typified for inbound or outbound routing, making
it usable in many different places in a configuration file. It must be named so it can
actually be used in a service, which will reference the global endpoint by its name. A
global endpoint can also help clarify the usage of a particular destination.

16. What Is Model Layer In Mule?

Answer:

The first logical layer is the model layer. A Mule model represents the runtime
environment that hosts services. It defines the behavior of Mule when processing
requests handled by services. The model provides services with supporting features,
such as exception strategies. It also provides services with default values that simplify their configuration.

(Mulesoft Interview Questions)

17. What Is Bridge Component In Mule?

Answer:

A bridge component is used to pass the messages from the inbound router to the outbound one.

A bridge is a neutral component:

it does not perform any action or modify messages that it processes.
A bridge component is used to pass the messages from the inbound router to the outbound one.

A bridge is a neutral component:

it does not perform any action or modify messages that it processes.

18. What are the advantages of using an ESB?

Answer:

Provides a way for end points to connect to each other without having to directly talk to each other.
It simplifies the communications for the end points as they only have to conform to a standard communication interface, the bus.
An ESB provides a single place to get some key end point metrics: frequency,
availability, and performance.
An ESB tends to provide more than one communication interface. However, a developer only needs to choose the easiest one to get and receive the data from the bus. (what Is Mulesoft Used For)

19. Why Mule is preferred than other ESB implementations?

Answer:

Mule is lightweight but highly scalable, allowing you to start small and connect more
applications over time. The ESB manages all the interactions between applications
and components transparently, regardless of whether they exist in the same virtual
machine or over the Internet, and regardless of the underlying transport protocol
used.
Several commercial ESB implementation provide limited functionality or built on top
of an existing application server or messaging server, locking you into that specific

vendor. Mule is vendor-neutral, so different vendor implementations can plug in to
it. You are never locked in to a specific vendor when you use Mule.

20. Explain Batch Jobs in Mule ESB?

Answer:

A batch job is a top-level element in Mule ESB which exists outside all Mule flows.
Batch jobs split large messages into records which Mule processes asynchronously; just as flows process messages, batch jobs process records.
A batch job contains one or more batch steps which, in turn, contain any number of message processors that act upon records.

A batch job executes when triggered by either a batch executor in a Mule flow or a message source in a batch-accepting input. when triggered, Mule creates a new batch job instance.

When all records have passed through all batch steps, the batch job instance ends and the batch job result can be summarized in a report to indicate which records succeeded and which failed during processing.

21. What are various types of Exception Handling?

Answer:

1. Choice Exception Handling.
2. Catch Exception Handling.
3. Rollback Exception Handling.
4. Global Exception Handling.
5. Default Exception Handling.

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

Answer:

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. (Mulesoft Interview Questions)

mulesoft training videos

23. What Are Configuration Builders In Mule?

Answer:

Mule uses configuration builders that can translate a human-authored configuration
file into the complex graph of objects that constitutes a running node of this ESB.
The main builders are of two kinds: a Spring-driven builder, which works with XML
files, and a script builder, which can accept scripting language files.

24. Explain Mule Expression Language (MEL)?

Answer:

MEL is a lightweight, Mule-specific expression language that you can use to access and evaluate the data in the payload, properties and variables of a Mule message.
Accessible and usable from within virtually every message processor in Mule, MEL enables you to quickly and elegantly filter, route, or otherwise act upon the different parts of the Mule message object.

25. What are Batch Jobs in Mule ESB?

Answer:

A batch job is a top-level element in Mule which exists outside all Mule flows. Batch jobs split large messages into records which Mule processes asynchronously in a batch job; just as flows process messages, batch jobs process records.
A batch job contains one or more batch steps which, in turn, contain any number of
message processors that act upon records as they move through the batch job.
During batch processing, you can use record-level variables (recordVars) and MEL expressions to enrich, route or otherwise act upon records.

26. Explain Flow in Mule ESB?

Answer:

A flow is the construct within which you link together several individual elements to
handle the receipt, processing, and eventual routing of a message.
A Flow is a sequence of message-processing events. A message that enters a flow may pass through a wide variety of processors. In the example diagram below, Mule
receives the message through a request-response inbound endpoint, transforms the content into a new format, and processes the business logic in a component before returning a response via the message source. (MuleSoft Training Online)

27. What is Transient Context?

Answer:

Transient Context: 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 call (within a request or response flow). After the services invoke call, the next primitive can create
another message by combining the service invoke a response and the original message stored in the transient context.

28. Do you have any particular areas of interest or ability?

Answer:

Talk to the interviewer about your strengths and be sure to highlight any particular
skill that you excel in. It’s a great idea, if you can, to highlight specific skills that may
be listed on the company’s job posting / job description. If there is a related area of
interest where you’d like to expand your skills, you can mention those as well.

29. What is MuleSoft Anypoint platform used for?

Answer:

MuleSoft’s Anypoint Platform of integration products is designed to tie together software as a service (SaaS) and on-premises software. (Mulesoft Interview Questions)

30. What are the advantages of Soap Web Services?

Answer:

WS Security: SOAP defines its own security known as WS Security.
Language and Platform independent: SOAP web services can be written in any programming language and executed in any platform.
Disadvantages of Soap Web Services:
Slow: SOAP uses XML format that must be parsed to be read. It defines many standards that must be followed while developing the SOAP applications. So it is slow and consumes more bandwidth and resource.
WSDL dependent: SOAP uses WSDL and doesn’t have any other mechanism to discover the service.

31. What are the different types of Flow Processing Strategies

Answer:

There are six different types of Flow Processing Strategies. They are
1. Asynchronous Flow Processing Strategy.
2. Custom Processing Strategy.
3. Thread Per Processing Strategy.
4. Queued Asynchronous Flow Processing Strategy.
5. Synchronous Flow Processing Strategy.
6. Non-blocking Flow Processing Strategy.
7. Queued Flow Processing Strategy.

32. What is ESB?

Answer:

An enterprise service bus (ESB) is software architecture for middleware that provides
fundamental services for more complex architectures. For example, an ESB
incorporates the features required to implement a service-oriented architecture
(SOA). In a general sense, an ESB can be thought of as a mechanism that manages
access to applications and services (especially legacy versions) to present a single,
simple, and consistent interface to end-users via Web- or forms-based client-side front ends

Check Demo Sesstion:

Check More Tutorial Videos

33. When do we need ESB?

Answer:

Mule and other ESBs offer real value in scenarios where there are at least a few
integration points or at least 3 applications to integrate. They are also well suited to
scenarios where loose coupling, scalability and robustness are required.

34. How did you find MuleSoft?

Answer:

I found MuleSoft a little bit by coincidence. My wife got a job at UCSF so we moved
here from Stockholm and while waiting for the paperwork to process I found out that
MuleSoft’s HQ was located in San Francisco. Since I had tested Mule ESB at my previous job to build integrations and had liked the product, I thought I would apply.

35. How Message In Mule Is Composed?

Answer:

A Mule message is composed of different parts: The payload, which is the main data
content carried by the message.
The properties, which contain the meta information much like the header of a SOAP
envelope or the properties of a JMS message. Optionally, multiple named
attachments, to support the notion of multipart messages.

mulesoft-tutorial

 

36. What Is Transport Layer In Mule?

Answer:

The transport layer is in charge of receiving or sending messages. This is why it is
involved with both inbound and outbound communications. A transport manifests
itself in the configuration by the following elements: connectors, endpoints and
transformers.
A transport also defines one message adapter. A message adapter is responsible for
extracting all the information available in a particular request (data, meta
information, attachments, and so on) and storing them in transport-agnostic fashion
in a Mule message. (Mulesoft Interview Questions)

37. Explain ESB Integration core principles?

Answer:

Transformation: Data transformation between canonical data formats and specific
data formats required by each ESB connector.
Transportation: Transport protocol negotiation between multiple formats. Such as
HTTP, JMS, JDBC.
Mediation: Providing multiple interfaces for the purpose of a) supporting multiple
versions of a service for backwards compatibility or alternatively, b) to allow for
multiple channels to the same underlying component implementation. This second
requirement may involve providing multiple interfaces to the same component, one
legacy interface (flat file) and one standards compliant (SOAP/XML) interface.
Non-functional consistency: For a typical ESB initiative, this can include
consistency around the way security and monitoring policies are applied and implemented.

38. What Are Differences Between Mule And Other Commercial Esbs?

Answer:

Prescriptive deployment model, whereas Mule supports a wide variety of deployment
strategies. Prescriptive SOA methodology, whereas Mule can embrace the
architectural style and SOA practices in place where it is deployed. Mainly focused on
higher-level concerns, whereas Mule deals extensively with all the details of
integration. Strict full-stack web service orientation, whereas Mule’s capacities as an
integration framework open it to all sorts of other protocols. Comprehensive
documentation, a subject on which Mule Source has made huge progress recently.

39. Why Mule Was Designed?

Answer:

Mule’s core was designed as an event-driven framework combined with a unified
representation of messages, expandable with pluggable modules. These modules
would provide support for a wide range of transports or add extra features, such as
distributed transactions, security, or management. Mule was also designed as a
programmatic framework offering programmers the means to graft additional
behavior such as specific message processing or custom data transformation.

40. What Is Endpoint In Mule?

Answer:

An endpoint represents the specific usage of a protocol, whether it is for listening/polling, reading from, or writing to a particular target destination. Hence it controls what underlying entities will be used with the connector they depend on.
The target destination itself is defined as a URI. Depending on the connector, the URI will bear a different meaning; for example, it can represent a URL or a JMS destination.

41. What Is Connector In Mule?

Answer:

A connector is in charge of controlling the usage of a particular protocol. It is
configured with parameters that are specific to this protocol and holds any state that
can be shared with the underlying entities in charge of the actual communications.
For example: a JMS connector is configured with a Connection, which is shared by the different entities in charge of the actual communication.

42. What Difficulties Mule Does Encompass?

Answer:

Transport: applications can accept input from a variety of means, from the file
system to the network.
Data format: speaking the right protocol is only part of the solution, as applications
can use almost any form of representation for the data they exchange.
Invocation styles: synchronous, asynchronous, or batch call semantics entail very
different integration strategies.

Life cycles: applications of different origins that serve varied purposes tend to have
disparate development, maintenance, and operational life cycles.

43. When Does Mule Instantiates A Connector?

Answer:

If Mule figures out that one of our endpoints needs a particular connector, it will
automatically instantiate one for us, using all the default values for its different
configuration parameters. This is a perfectly viable approach if we are satisfied with
the behavior of the connector when it uses its default configuration. This is often the
case for the VM or HTTP transports. Note that Mule will name these default
connectors with monikers such as connector. (Mulesoft Interview Questions)

44. What Is Component In Mule?

Answer:

Components are the centerpiece of Mule’s services. Each service is organized with a
component at its core and inbound and outbound routers around it. Components are
used to implement a specific behavior in a service. This behavior can be as simple as
logging messages or can go as far as invoking other services. Components can also
have no behavior at all; in that case they are pass-through and make the service act
as a bridge between its inbound and outbound routers.

45. What Is Transport Service Descriptor In Mule?

Answer:

The connector has a technical configuration known as the Transport Service Descriptor (TSD). This hidden configuration is automatically used for each instance
of the connector. It defines technical parameters such as what classes to use for the message receivers, requesters, and dispatchers; or the default transformers to use in inbound, outbound, and response routers. Knowing these default values is essential to grasping the behavior of a transport.

46. Most embarrassing moment?

Answer:

I once got locked out of a sauna in the middle of winter (in Sweden), without any
clothes. My friend managed to get a hold of a briefcase-sized mobile phone (this was
a while ago) and called for someone with an additional key to let us in again.

47. Why we use RAML?

Answer:

RAML helps client know, what the service is and how all the operations can be invoked. RAML helps the developer in creating the initial structure of this API.
RAML can also be used for documentation purpose.

48. Why do we need ESB?

Answer:

ESB, a middleware technology, is a Bus-like architecture used to integrate
heterogeneous systems. In ESB, each application is independent and yet able to
communicate with other systems. It, thus, prevents scalability issues and ensures
that communication happens only through it.

49. What is Mulesoft used for?

Answer:

Mulesoft is an integration platform that allows developers to connect applications
together quickly and easily, enabling them to exchange data.

50. What is Shared Context?

Answer:

Shared Context: Context is a temporary area which 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 Aggregation process where we need to Iterate the BO for Certain times. Shared Context maintains Aggregation data between Aggregation (FanOut and FanIn) 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 can not be used again in Response flow.

Leave a Comment

Your email address will not be published. Required fields are marked *