Mule works by responding to events (such as the receipt of a message) that are initiated by external resources. This follows the concept of Event Driven Architecture (EDA).
At the simplest level, Mule applications accept and process events as messages through several message processors.
Message processors are arranged into a flow (or several of them).
|Large or streaming messages can instead be processed as broken down into records in a batch job rather than 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 and process messages. Mule applications usually contain multiple linked flows, which, in combination, perform the integration required for your use case.
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.
The units that make up flows may be referred to as building blocks (in Studio’s graphical representation of a flow) or elements (in an XML flow representation). In general, a building block corresponds to an icon in the Anypoint 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 XML configuration file.
The example below is a simple flow created in Anypoint Studio’s visual editor; click the XML Editor tab to view the XML of a Mule project that holds the same flow.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 <?xml version="1.0" encoding="UTF-8"?> <mule 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" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="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/http http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd"> <http:listener-config name="HTTP_Listener_Configuration" host="localhost" port="8081" doc:name="HTTP Listener Configuration"/> <flow name="basic_tutorialFlow"> <http:listener config-ref="HTTP_Listener_Configuration" path="/" doc:name="HTTP"/> <set-payload value="Hello World!" doc:name="Set Payload"/> <logger message="#[payload]" level="INFO" doc:name="Logger"/> </flow> </mule>
Mule processes messages, also known as events, which may be transmitted from resources external to Mule. 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. This message source – in the example above, an inbound HTTP endpoint – 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.)
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.
Flows can also include filters, scopes, 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.
Within many of the fields of the message processors of 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.
Mule Expression Language (MEL) is the primary language used for formulating expressions in Mule, allowing you to access, manipulate, and use information from the message and its environment.
At runtime, Mule evaluates expressions while executing a flow to:
Extract information that it can use to process the current message.
Set or manipulate a value in the message header or payload.
Perform an operation on information in the message, application, Mule instance, or server.
For more information on MEL, see:
Anypoint Studio also supports batch jobs as an alternative to standard flows. A batch job is a block of code that splits messages into individual records, performs actions upon each record, then reports on the results and potentially pushes the processed output to other systems or queues. This functionality is particularly useful when working with streaming input or when engineering "near real-time" data integration between SaaS applications.
A batch job is a top-level element in Mule that exists outside all Mule flows and provides record I/O for Mule message processing. 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 as they move through the batch job.
A batch job executes when triggered by 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. Once every record has 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.
For more information on batch processing, see: