Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                

Mulesoft Is An Integration Platform For Connecting Enterprise and Saas Applications in The Cloud and On-Premise. What Is Mule?

Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 8

MuleSoft is an integration platform for connecting enterprise and SaaS

applications in the cloud and on-premise.

What is Mule?

Mule is an open-source enterprise integration platform that helps tackle the problems in
developing integration applications. Some of the problems that are tackled by Mule include
Error handling, Monitoring, Lifecycle and management, Data format, etc. Thus, with these
problems gone, Mule helps focus on the application’s core requirements like scalability and
efficiency.

What are the different tools and services offered by Mulesoft?

MuleSoft helps in the task of data integration diligently and efficiently. The tools and
services offered by MuleSoft include:

 API Designer: API Designer is a web-based tool that contains a console and a
scripting notebook for JavaScript.
 API Manager: API Manager is a management tool that allows organizations in
managing users, traffic, and service level agreements.
 Anypoint Studio: Anypoint Studio is a graphical design environment to build and edit
APIs and integrations.
 API Portal: This is a portal that offers developers different kinds of documents,
tutorials, and code snippets related to APIs.
 API Analytics: API Analytics is an analytics tool that allows a user to track the
specifications of an API. This also includes its performance, usage, and reliability.
Additionally, it offers a dashboard and charts.

3. What is Mule ESB?

Mule ESB stands for Mule Enterprise Service Bus. Mule ESB makes it easy for the
development teams to flexibly connect, access, and exchange data easily. This means that
even though the application is running into different VMs, the interactions between them
are easy. 

What are Connectors in Mule?

Connectors in Mule are Mule’s abstraction for sending and receiving data and interacting
with various APIs. There are generally 2 forms of connectors in Mule: 
 Transport: This is the most common form of connector used in Mule. Like HTTP,
transports provide an adaptation layer for a protocol. These are the sources and
sinks for data - to get data into and out of flows.
 Cloud connectors: These are typically used to interact with an API. Usually, cloud
connectors don’t give endpoints. Instead, they have message processors that map to
the operations provided in the API. The operations of an API are combined by these
cloud connectors. The effect of this is that the initial friction for a developer is greatly
reduced.

What is a runtime manager in Mule?

In Mule, a runtime manager is used for deploying and managing Mule applications

We can deploy or pause the mule application by using runtime manager.

What is Mule Runtime?

A runtime engine that is used to host and run Mule applications, is called a Mule runtime.
This is similar to an application server.

What do you mean by Flow in Mule?

‘Flow’ is when we combine together multiple individual processors in order to handle a


receipt, its processing and eventual routing of a message. We can connect several flows
together to build one whole application.

Sub Flows

We use subflows to group common logic. Subflows are processed synchronously; that is,
execution of the calling flow halts until the subflow is complete.

Additionally, subflows inherit the processing strategies and exception handling strategies
of the calling flow. We can call a subflow from multiple different flows. Should we not wish
to inherit these strategies, we could call a synchronous flow.

Synchronous Flows

Like a subflow, a synchronous flow is also processed synchronously. This means that when
we call a synchronous flow, it must complete before the parent flow resumes its execution.

Unlike a subflow, it doesn't inherit the processing and exception handling strategies of the
calling flow. Consequently, the processing and exception handling strategies of the calling
flow do not affect the behavior of this type of flow.

For these reasons, this type of flow is ideal for transactional processing since messages
processed using synchronous flows execute on a single thread.
Asynchronous Flows

Asynchronous flows execute in parallel to the calling flow; i.e., they are processed
asynchronously.

Private Flow

Private flow is basically a normal flow which doesn't have a endpoint. This flow can only
be invoke by a different another flows using flow ref component.

What are the parameters to configure a scheduler?

The Scheduler component in Mule helps us to trigger a flow when a time-based condition is
met. 

The parameters related to configuring a scheduler are as follows:

 Frequency: The Scheduler uses frequency to trigger flows.


 Start Delay: This signifies the time to wait before triggering a flow.
 Time Unit: This is the time unit for frequency and for Start Delay.

For example in some use cases where you need to do a specific task at a particular period of
time or repeatedly at a fixed interval, your integration flow can be scheduled via Scheduler.

List types of variables in MuleSoft

Types of variables in MuleSoft are:

 Flow Variable: It is used to either set or removes variables tied to a particular


message in the current flow.
 Record Variable: It is used for batch processing flows.
 Session Variable: This variable is used to either set or remove variables tied to a
particular message for the complete lifecycle.

What is the payload in MuleSoft?

The payload is a mule runtime variable that stores objects or arrays. It helps developers to
access payload under different forms.

On Error-Continue and On Error-Propagate


If error is handled using On-error Propagate, it will raise an error back to the calling
flow.

 If error is handled using the On-error Continue then it will not raise an error back to the
calling flow and continue to the next process as it is.

But it will not continue to other processors in the flow where error is handled(on error
continue case)

 Suppose if we have a single flow, then on error propagate and on error continue
behaves same way, instead the on error gives 200 status and on error propagate gives 500
status code.

Even if its on error continue, it will not go to the next processor within the same flow
where the error is handled.

Differences between For Each and Parallel For Each Scopes


The For Each scope splits a payload into elements and processes them one by one through the
components that you place in the scope. It is similar to a for-each/for loop code block in most
programming languages and can process any collection, including lists and arrays. The collection
can be any supported content type, such as application/json, application/java, or application/xml.

Both For Each and Parallel For Each split the defined collection, and the components within
the scope process each element in the collection. Also, in both cases, each route runs with
the same initial context. The difference between these two scopes are:

 For Each works sequentially, while the Parallel For Each processes in parallel. This
difference affects error handling:

Because of the processing differences, the execution of For Each execution is


interrupted when an error is raised (and the Error Handler is invoked), while Parallel
For Each processes every route before invoking the Error Handler with a
MULE:COMPOSITE_ROUTE error type.

 For Each does not modify the payload, while the Parallel For Each outputs a
collection of the output messages from each iteration.

Batch job
Within a Mule application, batch processing provides a construct for asynchronously
processing larger-than-memory data sets that are split into individual records. Batch jobs
allow for the description of a reliable process that automatically splits up source data and
stores it into persistent queues, which makes it possible to process large data sets while
providing reliability. In the event that the application is redeployed or Mule crashes, the job
execution is able to resume at the point it stopped.

-------------------------------------------------------------------------------------------

Mule 4 includes a simplified Mule message model in which each Mule event has a message
and associated variables. A Mule message is composed of a payload and its attributes
(metadata, such as file size). Variables ( vars ) which hold arbitrary user information such as
operation results, auxiliary values, and so on.

A Mule event contains the core information processed by the runtime. It travels through
components inside your Mule app following the configured application logic. ... A Mule
Message contains a message payload and its associated attributes. Variables are Mule event
metadata that you use in your flow.
JMS

JMS (Java Message Service) is an API that provides the facility to create, send and read
messages. It provides loosely coupled, reliable and asynchronous communication.

MUnit is a Mule application testing framework that allows you to easily build
automated tests for your integrations and APIs.

Mule throws a messaging error (a Mule error) whenever a problem


occurs within a flow of a Mule app, where Mule events and the
messages they contain are processed.

URI AND QUERY Parameters


If we want to identify the employee on the basis of empID, we will be using the URI param.
GET /employee/{empID}
 
If we want to filter the book on the basis of empName, we will be using Query Parameter.
GET /employee?empName=Raghav.

RAML AND YAML

YAML originally stood for Yet Another Markup Language

RAML is the RESTful API Modeling Language and is built on top of YAML.
 400 – Bad Request
 401 – Unauthorised
 402 – Payment Required
 403 – Forbidden
 404 – Not Found
 405 – Method Not Allowed
 406 – Not Acceptable
 407 – Proxy Authentication Required
 408 – Request Timeout
 409 – Conflict
 410 – Gone
 411 – Length Required
 412 – Precondition Failed
 413 – Payload Too Large
 414 – URI Too Long
 415 – Unsupported Media Type
 416 – Range Not Satisfiable
 417 – Expectation Failed
 418 – I’m a teapot
 421 – Misdirected Request
 422 – Unprocessable Entity
 423 – Locked
 424 – Failed Dependency
 426 – Upgrade Required
 428 – Precondition Required
 429 – Too Many Requests
 431 – Request Header Fields Too Large

 451 – Unavailable For Legal Reasons

 200 – OK
 201 – Created
 202 – Accepted
 203 – Non-Authoritative Information
 204 – No Content
 205 – Reset Content
 206 – Partial Content
 207 – Multi-Status
 208 – Already Reported
 226 – IM Used

You might also like