Mulesoft ESB Interview Questions And Answers

41. 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.

42. Explain Flow in Mule ESB?
Answer: A flow is a construct within which you link together several individual elements to handle the receipt, processing, and eventual routing of a message.

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.

43. 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.

44. What are Message Sources is Mule ESB?
Answer: Message sources in Mule are usually Anypoint Connectors, elements which provide connectivity to a specific external source, either via a standard protocol (such as HTTP, FTP, SMTP) or a third-party API (such as Salesforce.com, Twitter, or MongoDB.)

45. 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.

46. 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.

47. What is REST?
Answer: REST stands for Representational State Transfer or RESTful web service. REST is a client-server architecture which means each unique URL is a representation of some object or resource. Any REST API developed uses HTTP methods explicitly and in a way that’s consistent with the protocol definition. This basic REST design principle establishes a one-to-one mapping between creating, read, update, and delete (CRUD) operations and HTTP methods. According to this mapping:

To create a resource on the server, use POST.
To retrieve a resource, use GET.
To change the state of a resource or to update it, use PUT.
To remove or delete a resource, use DELETE.
Example:
If we want to create a REST service that fetches the record of a customer then our URI will be:
– GET
where the HTTP method is GET,
Resource is customer
And URI parameter is customer which depicts
for which resource we want to fetch the records

48. What are the different types of variables in mule?
Answer:

• Flow Variable
• Session Variable
• Record Variable

49. What are Shared Resources in Mule and how are they 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.

50. What are all the Primitives used in Mediation?
Answer:
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

51. Different between SDO and SMO?
Answer:
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

52. A 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.

53. What’s a typical day like for you?
Answer: I help MuleSoft customers connect applications using CloudHub. I would say that on average I spend maybe 60% of my time in Mule Studio and the rest of the time with meetings, project planning, documentation and that sort of thing