Mule ESB is a lightweight Java-based integration platform that allows applications to connect and exchange data. It acts as a transit system carrying data between applications within or across organizations. Mule enables integration regardless of technology and provides capabilities like service creation, mediation, routing, and transformation. When integrating 3 or more applications that may need to connect more in the future or use different protocols, an ESB like Mule can help with its scalability and reusable components. Mule Studio provides a graphical interface to design integration flows by connecting message sources, processors, and connectors.

1. Mule ESB

2. What is Mule ESB?
• 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 and allows different applications to
communicate with each other by acting as a transit system for carrying data
between applications within your enterprise or across the Internet.
• It enables easy integration of existing systems, regardless of the different
technologies that the applications use.
Example: JMS, Web Services, JDBC, HTTP, and more

3. Capabilities of Mule
• Service creation and hosting — expose and host reusable services, using the ESB
as a lightweight service container
• Service mediation — shield services from message formats and protocols,
separate business logic from messaging, and enable location-independent service
calls
• Message routing — route, filter, aggregate, and re-sequence messages based on
content and rules
• Data transformation — exchange data across varying formats and transport
protocols

4. Do I need an ESB and when to select an ESB?
It is form the article written by MuleSoft founder and VP of Product Strategy Ross Mason: To ESB or not to ESB.
1. Are you integrating 3 or more applications/services?
2. Will you need to plug in more applications in the future?
3. Do you need to use more than one type of communication protocol?
4. Do you need message routing capabilities such as forking and aggregating
message flows, or content-based routing?
5. Do you need to publish services for consumption by other applications?

5. Advantages of Mule provides over other
competitors
• Mule's stage event-driven architecture (SEDA) makes it highly scalable.
• Mule components can be any type you want. You can easily integrate anything from
a "plain old Java object" (POJO) to a component from another framework.
• Mule and the ESB model enable significant component reuse.
• Unlike other frameworks, Mule allows you to use your existing components without
any changes. Components do not require any Mule-specific code to run in Mule,
and there is no programmatic API required. The business logic is kept completely
separate from the messaging logic.

6. Mule Enterprise
• There are two editions of Mule. Community and Enterprise.
• Enterprise is the enterprise-class version of the ESB, with additional features
and capabilities that are ideal for production deployments of Mule that have
requirements for performance, HA, resiliency, or technical support.
https://www.mulesoft.com/platform/soa/mule-esb-enterprise

7. Installation

8. Anypoint Studio
• Canvas /Message Flow
• Global Elements
• Configuration XML
• Palette ( where mule building blocks/elements are available )
1. Connector 4. Transformers
2. Scope 5. Filters
3. Components 6. Flow Control elements (or "Routers")

9. Message Sources
• Mule processes messages, also known as events.
• which may be transmitted from resources external to Mule.
Example: A message can be initiated by an event
• Such as a consumer request from a mobile device.
• A change to data in a database.
• The creation of a new customer ID in a Software as a service(Saas) application.
• The first building block of most flows is a receiver which receives new messages and places them in the queue for processing. This
message source – receives messages from one or more external sources, thus triggering the execution of a flow.
• 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.)

10. Message Processors
• In Mule, message processors are grouped together by category.
• Mule transformers are the key to exchanging data between nodes.
• Mule to convert message payload data to a format that another application can
understand.
• Mule uses Staged Event-Driven Architecture (SEDA) for core asynchronous
message processing in flows.
• Importantly, components don’t have to have any Mule-specific code.
• It can be simply be POJOs, Spring beans, Java beans, Groovy scripts, Python, JavaScript,
Ruby, and PHP or web services containing the business logic for processing data.

11. Mule Flow
• A flow is the most versatile and powerful
integration mechanism available in Mule.
• A flow is the construct within which you link
together several individual elements to handle the
receipt, processing, and eventual routing of a
message.
• You can connect many flows together to build a
complete application and each names should be
unique.
Private Flows, Sub Flows, Flow-Ref

12. Mule Message Structure
The Mule message is the data that passes through an application
via one or more flows. It consists of two main parts:
• The message header, which contains metadata about the
message.
• The message payload, which contains your business-specific
data.
• A Mule message is, itself, embedded within a Mule message
object.
• Some Mule message objects may contain variables,
attachments, and exception payloads

13. Mule Expression Language
Mule Expression Language (MEL) is the primary language used for formulating
expressions in Mule, allows us to access, manipulate, and use information from
the message and its environment.
• MEL is a lightweight and 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.
#[message.inboundProperties.propertyName]

14. Properties & Variables
• The metadata contained in the message header consists of properties which
provide useful information about the message.
• Properties and Variables share a common format: each individual property or
variable has a name and a value.
• A message’s properties and variables have specific scopes that define and
organize how they apply across that message’s lifecycle.

15. • Properties have two main scopes: inbound and outbound.
• Inbound properties are immutable, are automatically generated by the message source and
cannot be set or manipulated by the user.
• Outbound properties are mutable; they are set during the course of a flow and can become
inbound properties when the message passes from the outbound endpoint of one flow to the
inbound endpoint of a different flow via a transport.

16. • Variables are user-defined metadata about a message. Variables have three scopes:
• Flow variables apply only to the flow in which they exist.
• Session variables apply across all flows within the same application.
• Record variables apply to only to records processed as part of a batch.

17. Anypoint Studio
• Palette (Message Processors)
1. Connector
2. Scope
3. Components
4. Transformers
5. Filters
6. Flow Control elements (or "Routers")
7. Error Handling
8. Security

18. Anypoint Connectors
• Anypoint Connectors receive or send messages between Mule and one or
more external sources.
• Connectors can act as message sources by working as inbound endpoints.
• Connectors can act as a message processor that performs an operation in the
middle of a flow.
• Connectors can be at the end of a flow and act as the recipient of the final
payload data.

19. Connectors in Mule are either endpoint-based or operation-based
Endpoint-Based Connectors
• Endpoint-based connectors follow either a one-way or request-response exchange pattern.
• Endpoint-based connectors are configured as either inbound or outbound endpoints in a flow.
• Inbound endpoints serve as a message source for a flow.
• Outbound endpoints can occur mid-flow or at the end of flows and send information to external
systems.
• Connectors often (but not always) named and based around a standard data communication
protocol
such as FTP and SMTP.
Operation-Based Connectors
• Operation-based connectors follow an information exchange pattern based on the operation that
you select and are often (but not always) named and based around one or more specific third-party
APIs.
• When you add an operation-based connector to your flow, you immediately define a specific
operation for that connector to perform.
Global Connector Configurations

20. Components
• Components are the message processors which is embedded with business
logic and it is executes on message.
• Components fall into three categories
1. General Components
2. Script Components
3. Web service Components.

21. • General Components
• General components execute whenever a message is received.
• The logic embedded into General components cannot be modified.
• Components such as the Logger and Flow Reference fall into this category.
• Script Components
Script components do not contain pre-packaged logic. Instead it allows the developer to specify the logic
(in the form of a custom script or a Java class) to add into the component.
• Script components also allow you to:
• Configure interceptors
• Add Spring beans
• Change the value or reference of a specific property within the associated class
• The Java Component allows you to reference a Java class.
• The other Script components support the Groovy, JavaScript, Python and Ruby scripting engines.

22. • Web Service Components
Web Service components provide or facilitate the developer in exposing, consuming, and
proxying web services with the framework to reference classes and API’s needed by RESTful and
SOAP Web services. These components let you add interceptors, bundled logic which executes
before the service is published, that run tasks such as scheduling or logging a specific event.
• The CXF component leverages the CXF framework, mule uses to support SOAP web services.
• The REST component work with Jersey to support REST Web services.

23. Scopes
• Scopes are also known as wrappers. mule scopes work to encapsulate other
message processors so that they function as a single unit.

24. Scopes Available in any point studio

25. Scopes explanation:
• Async scope:Creates a block of message processors that execute
asynchronously while the rest of the flow continues to execute in parallel.
For instance, you can populate an Async scope with a sequence of building
blocks that perform logging so that logging does not slow down the rest of
the application flow.
• Cache scope:Caches data produced by part of a flow. Wrap a cache scope
around message processors in your flow so that it caches the response events
produced within the scope

26. Scopes explanation
Composite Source:To accept incoming messages from multiple input
channels, place two or more message sources (also known as receivers) into a
Composite Source. A message entering the Composite Source on any
supported channel triggers the processing flow.
Foreach:Splits any type of message collection apart into individual messages
for processing, and then aggregate them again at the end of the scope.

27. Scopes explanation
Message Enricher:Appends information to a message, often using an
expression to determine what part of the payload to evaluate so as to return an
appropriate value to append to that payload. For example,the expression can
evaluate a ZIP code and then append the associated City and State to the
payload. The message processor is executed and the enricher scope uses the
result of that execution to enrich the message coming into the scope.
Until Successful:Attempts, at a specified interval, to route a message to an
embedded message processor until one of the following occurs:

28. Scopes explanation
• The message processor succeeds
• The maximum number of retries is reached
• An exception is thrown
Thus, Until Successful can prove useful in sending messages to resources, such
as shared printers, which might not always be immediately available.

29. Scopes explanation
Request-Reply Scope:The Request-Reply scope enables you to embed a
"pocket" of asynchronous processing within a Mule flow. This functionality
enables you to receive a response from an asynchronous flow without
hardcoding the destination of the response. For example, you can use request-
reply to convert a one-way VM or JMS flow to a request-response flow
without having to change it’s configuration. In other words, the request-reply
converts part of a synchronous process into an asynchronous one.

30. Scopes explanation
Request-reply consists of two parts:
•The request portion wraps the connector or outbound connector which submits an asynchronous request to another flow or an external resource
•The response portion wraps the connector or inbound connector which receives an asynchronous response from another flow or an external resource

31. Scopes explanation
• Poll scope:By default, Poll Scopes in Mule are set to poll a resource every
1000 milliseconds for new data. At times, you may wish to adjust the default
polling interval, or configure the polling schedule to follow a more
complex logic.
• The below details are on how to configure a polling schedule via two
methods made available in Anypoint Studio:
• Fixed Frequency Scheduler
• Cron Scheduler

32. Scopes explanation
Message Enricher:One common scenario involves the need to enrich an incoming
message with information that isn’t provided by the source system. You can use a
content enricher if the target system needs more information than the source system
can provide.
• Consider a message from a source system contains a zip code but the target system
needs the two letter state. A message enricher can be used to lookup the state using
the zip code from an enrichment resource. The enricher calls out to the enrichment
resource with the current message (containing the zip code) then enriches the
current message with the result.

33. Routers
Routers (Flow Controls ) route messages to various destinations in a Mule flow. Some routers
incorporate logic to analyze and possibly transform messages before routing takes place. For
example, various flow controls can:
• Split a message into several segments, then route each segment to a different building block
• Combine several messages into a single message before sending it to the next building block
in the flow
• Reorder a list of messages before sending it to the next building block
• Evaluate a message to determine which of several possible building blocks it should be
routed to next
• Broadcast the same message to multiple building blocks

34. Flow Controls in Anypoint Studio

35. Routers
APIkit Router :
Based on an API RAML file, it routes arriving calls to the corresponding flow
depending on the resource and method
Choice:
Evaluates a message against specified criteria, then sends it to the first message
processor that matches those criteria

36. Routers
Splitter :
Evaluates an expression which determines how it sections a message into two
or more parts. The Splitter then sends each of these message parts, in
sequence, to the next message processor in an application flow.
Collection Aggregator :
Checks the group tag (known as a Correlation ID) attached to each message in
a group to create a collection of messages which share the same Correlation
ID.

37. Routers
Collection Splitter :
Accepts a collection of messages (or parts of messages), splits them into
individual messages, then sends each new message, in sequence, to the next
message processor in a flow
Scatter Gather :
Sends a request message to multiple targets concurrently. It collects the
responses from all routes, and aggregates them into a single message

38. Routers
Message Chunk Splitter :
Sections a message into segments of a specified length, then sends each
segment, in sequence, to the next message processor in a flow. This is
particularly useful when the message recipient cannot accept messages longer
than a specified length

39. Routers
Message Chunk Aggregator :
Checks the group tag (Correlation ID) of each message in a collection, selects
all the messages whose group tag matches the specified value, then combines
those messages into a single message which is then sent to the next message
processor in an application flow. This is particularly useful for re-assembling
the segments of a long message that has been received as multiple messages,
each one consisting of a segment of fixed length created and sent by the
Message Chunk Splitter

40. Routers
Resequencer :
Accepts a collection of messages, then uses the Sequence ID of each message
to reorder those messages. It then sends the messages (in order of their new
sequence), to the next message processor in an application flow.
SOAP Router :
Based on a WSDL file, it routes arriving calls to the corresponding flow
depending on the resource and method