Contact Us 1-800-596-4880
  1. Homepage
  2. Mule Runtime (3.8)

  3. Key Concepts

Key Concepts

Mule runtime engine version 3.8 reached its End of Life on November 16, 2021. For more information, contact your Customer Success Manager to determine how to migrate to the latest Mule version.

Messages and Events

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 and message sources that accept and process messages. External clients trigger various message sources through various communication protocols and methods, such as JMS, HTTP, FTP, JDBC, or File. Every message source translates a particular communication protocol or method into a standard message format, which is then passed down to the flow’s message processors. Flows can also use connectors to make outbound client requests to other external resources and services, or to other Mule applications.

Mule applications often contain multiple flows, which are linked and combined together in various ways to perform the integration required for your use case. A flow can call another flow as a direct reference, or may call a flow through a common communication protocol or method, such as JMS, HTTP, FTP, or File. The called flows might be part of the same Mule application, or might be running in a separate application deployment running on another Mule runtime across the network.

Flows

A flow is the construct within which you link together several individual processors 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 processors. 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

In general, each processor corresponds to an icon in the Anypoint Studio GUI, which in turn represents a message source, processor, or component, which is written into the application’s XML file as an XML element. Each XML element inside a flow within the Mule application’s XML configuration file usually has a corresponding icon that is displayed in the flow, indicating the processor’s position in the XML file’s flow element.

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.

Studio Visual Editor

simple+flow2

XML Editor

<?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>

Message Sources

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 processor of most flows 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.)

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 flow elements support the most commonly used Enterprise Integration Patterns.

Flows can also include filters, scopes, and routers. For example, you can use a filter to allow 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

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.

#[message.inboundProperties.propertyName]

For more information on MEL, see:

Batch Processing

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.

batch_main1

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:

See Also