Mule Overview

For a Mule app to run, it must be deployed into an environment where the Mule runtime engine is installed.

Mule is packaged within the Studio IDE and with Design Center on Anypoint Platform so that you can run a Mule app as you design it.

For production and pre-production deployments of Mule apps, you can use Runtime Manager to deploy Mule apps to runtimes within CloudHub and other supported platform as a service (PaaS) solutions.

In addition to using Runtime Manager, you can perform deployments and manage Mule apps with Anypoint CLI 3.x, which includes commands for deployments and a number of Anypoint Platform use cases.

For more on deployment options, see Deployment Strategies.

Mule works by responding to events that are initiated by external or internal resources. Mule works with a variety of sources, including listeners for external events, and schedulers for internally triggered events.

Mule processes events as messages through Event processors. Mule can also handle a high volume of messages in batches through Batch processors.

This behavior reflects Mule’s event-driven architecture (EDA). For more on this topic, see Mule Events.

Within a Mule app, event processing components are arranged into one or more container-like components, called flows.

Understanding basic flow architecture is key to understanding Mule. Essentially, every Mule flow contains a series of components that receive or process messages.

At the simplest level, flows are sequences of Event processors. A message that enters a flow can pass through a variety of processors. In a typical flow, a Mule app receives a message through an Event source (such as an HTTP listener), transforms that message into a new format, and processes any business logic before writing the processed message to an external system in a format that the system can read.

To break up processing into more manageable units, Mule apps often contain multiple, interrelated flows, instead of just a single flow. A flow can call another flow as a direct reference.

For more on this topic, see Flows and Subflows and Mule Applications.

An Event source (or trigger) is the first component in a flow. It receives a triggering event, creates a corresponding Mule event object, and forwards that event on for processing by the next component in the flow.

External clients can trigger processing in a Mule flow through a number of communication protocols and methods, such as JMS, HTTP, FTP, JDBC, or File. Mule translates these communication protocols and methods into a standard message format, which passes through the flow’s Event processors.

Event sources in Mule can connect to specific external sources, either through a standard protocol or a third-party API. It is also possible to set a Scheduler component. Some schedulers can poll for specific changes to external resources, such as new files or table rows in an external resource. Examples of listeners and connector operations that can trigger a flow include:

Note that you can also create your own Event source using the Mule SDK.

Once a flow is triggered through an Event source, subsequent components process the Mule event as it travels through the flow. By default, each Event processor that receives a Mule event returns a new Mule message, typically with a set of attributes and the message payload that the processor returns. The processor passes on the new message as output to the next processor in the flow.

Event processors available to Mule apps include:

Note that you can also create your own Event processors using the Mule SDK.

For more on this topic, see Core Components and Connectors and Modules.

DataWeave is the primary language used for formulating expressions in Mule. Within fields of many message processing components, in addition to the Transform Message component, you can use DataWeave to access, manipulate, transform, and extract data from the Mule event.

At runtime, Mule evaluates expressions while executing a flow to:

For more on this topic, see DataWeave Language.

Mule supports batch jobs, which split messages into individual records, act on each record, then report the results and, if necessary, push 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.

Studio and Design Center provide various batch components that you can use to configure batch processes. For more on this topic, see Batch Processors.

Mule Runtime includes an embedded API Gateway, which enables you to apply security policies to an API, enrich incoming or outgoing messages, and add capabilities to an API without having to write any code. See API Gateway for information on the Mule runtime engine in the API Manager documentation.

The Mule execution engine is based on a non-blocking runtime. This is a task-oriented execution model that allows you to take advantage of non-blocking IO calls and to make tuning configurations in a simple way.

Flows always function synchronously. If you need to achieve asynchronous patterns, such as Fire-and-Forget, you can use the Async (<async>) component.

Mule Event processors indicate to the runtime whether they are CPU intensive, CPU light, or IO intensive operations. These workload types help the runtime tune for different workloads, removing the need for you to manage thread pools manually to achieve optimum performance. Instead, the runtime introspects the available resources (such as memory and CPU cores) in the system to tune thread pools automatically.

For more detailed documentation on the execution engine, threading model, and tuning options, see Execution Engine.

The Mule version you use determines what your Mule app can do and what features and products are compatible with Mule. Core components, which process the Mule event as it travels through flows in a Mule app, are part of a Core module that is bundled with and shares the same version as Mule. Modules, connectors, the DataWeave language, and a number of MuleSoft products have their own versioning system but are compatible with specific versions of Mule. For example, DataWeave 2.0 and Studio 7.x are compatible Mule 4.x runtimes, while DataWeave 1.0 and Studio 6.x are compatible with Mule 3.x runtimes. You need to make sure the connector or module you use in a Mule app is compatible with your Mule version.