salesforce Dreamforce On-Demand
Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.4)
  3. Mule Fundamentals

  4. Mule Concepts

Mule Concepts

Based on the concept of Event Driven Architecture (EDA), Mule works by responding to messages initiated by external resources (i.e. events). At the simplest level, Mule applications accept and process events as messages through several message processors plugged together in a flow. Understanding the basic flow architecture is key to understanding Mule. Essentially every Mule flow contains a series of message processors that accept, then process messages.

Mule Flow

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 which you can then deploy on premise, on Mule or another application server, or in the cloud.

At the simplest level, flows are sequences 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.

Flow1-1

The units with which flows are constructed are known generically as building blocks (in Studio’s graphical representation of a flow) or elements (in XML configuration). In general, a building block corresponds to an icon in the Mule Studio GUI, which in turn represents a message source, processor, or component. A building block is a visual representation of an XML element within the Mule application’s configuration file.

The example below is a simple flow created in Mule Studio’s visual editor; click the XML Editor tab to view the XML version of the same flow.

Studio Visual Editor

Simple+Example+Flow+Studio

XML Editor

<?xml version="1.0" encoding="UTF-8"?>

<mule xmlns:tracking="http://www.mulesoft.org/schema/mule/ee/tracking" xmlns:http="http://www.mulesoft.org/schema/mule/http" xmlns="http://www.mulesoft.org/schema/mule/core" xmlns:doc="http://www.mulesoft.org/schema/mule/documentation" xmlns:spring="http://www.springframework.org/schema/beans" version="EE-3.5.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.mulesoft.org/schema/mule/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd

http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-current.xsd

http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd

http://www.mulesoft.org/schema/mule/ee/tracking http://www.mulesoft.org/schema/mule/ee/tracking/current/mule-tracking-ee.xsd">


<flow name="Simple_Example_Flow1" doc:name="Simple_Example_Flow1">
    <http:inbound-endpoint exchange-pattern="request-response" host="localhost" port="8081" doc:name="HTTP" path="kittens"/>
    <set-payload value="Kittens? Kittens!" doc:name="Set Payload"/>
    <echo-component doc:name="Echo"/>
</flow>

</mule>

Message Sources

Mule processes messages (i.e. events) initiated in external resources. For example, a message can be initiated by an event such as a consumer request from a mobile device, or a change to data in a database, or the creation of a new customer ID in a SaaS application.

The first building block of most flows is a receiver which receives new messages and places them in the queue for processing. Mule uses a message source element – in the example above, an inbound HTTP endpoint – to receive messages from one or more external sources, thus triggering the execution of a flow.

Message sources in Mule make use of transports to carry messages from application to application in the Mule framework. In the context of Enterprise Ingetration Patterns (EIP), transports implement message channels and provide consistent connectivity to an underlying data source or message channel. Whenever there is a message source in Mule, there is a corresponding transport working in the background to establish and maintain communication. For example, the HTTP transport handles messages sent to an HTTP endpoint in Mule via HTTP protocol. In Mule, you can also configure a transport to apply synchronous transformers to the response before returning it to the caller.

The heart of a transport is the connector which maintains the configuration and state for the transport. In other words, connectors contain nearly all the connectivity details that Mule needs to actually connect with another system or application.

In Mule, message sources manifest as either Endpoints or Anypoint Connectors. The two types of endpoints exist to distinguish the enterprise-specific endpoints from the non-enterprise specific. For example, an SMTP endpoint facilitates connection to any mail server, thus it exists in Mule as an endpoint; a Facebook Connector facilitates connection specifically to Facebook thus it exists as an Anypoint Connector. (Note: in Studio, Anypoint Connectors are referred to by their legacy name, Cloud Connectors.)

Message Processors

In Mule, message processors are grouped together by category.

Mule transformers are the key to exchanging data between nodes, as they allow Mule to convert message payload data to a format that another application can understand. Mule also enables content enrichment of messages which allows you to retrieve additional data during processing and attach it to the message.

Mule uses components to conduct backend processes for specific business logic such as checking customer and inventory databases. Components route messages to the correct application, such as an order fulfillment system. 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; they can simply be POJOs, Spring beans, Java beans, Groovy scripts, or web services containing the business logic for processing data. Components can even be developed in other languages such as Python, JavaScript, Ruby, and PHP. Mule’s catalog of building blocks includes the most commonly used Enterprise Integration Patterns.

Flows can also include filters, wrappers, and routers. For example, you can use a filter to whitelist IP addresses from which your application accepts messages; you can use a scope to "wrap" around several message processors and cache the result of the processing they perform; you can use a router to send messages down different paths in your application depending on the content of the message payload. Mule includes a variety of filters, scopes and routers to customize how a flow processes messages.

When you configure the individual elements that link together to make your flow, you can use Mule Expression Language to extract information about the message or its environment and instruct Mule to make processing decisions based on that information. Later in this series, you can examine how to use expressions in Mule.

See Also