Mule Application Building Blocks

  Mule Application Building Blocks

Basically Mule application building blocks comprises of number of sections like 

1) Connectors

2) Scopes

3) Components

4) Transformers

5) Filters

6) Flow Control

7) Error Handling

8) Security

you can see in the palette below is the snapshot of mule palette.

Connectors  : Connectors are used to connect external systems.They are message source.
ex : HTTP connector,Database connector,FTP connector,etc.
if you need to connect to any HTTP API then you need to use HTTP connector similarly if you need to connect with any database you need database connector.

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

Connectors in Mule are either endpoint-based or operation-based:

Endpoint-based connectors follow either a one-way or request-response exchange pattern and are often (but not always) named and based around a standard data communication protocol, such as FTP and SMTP.


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.

Scopes : A scope is a block contains message processors for some particular operation.
ex : batch scope,transactional scope,etc.

Sometimes referred to as "wrappers", the message processors known as Scopes appear as processing blocks when you first place them on the Message Flow canvas. Certain scopes such as, Poll, Message Enricher, and Until Successful require you to embed only one message processor within the processing block. Variously, these scopes add functionality to the embedded message processor by:

Triggering the message processor periodically

Enhancing the message processor’s payload

Triggering the message processor until an associated event succeeds

Typically, the other sub-group of scopes (which includes Composite, Async, and Sub Flow) accepts more than one message processor.



Components : Components are also used to do operations.
ex : Invoke component,transform message,etc.

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 they allow 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.

Web Service Components :

Web Service components, as the name implies, enable Mule to use SOAP and RESTful protocols to communicate with external Web services. The SOAP and RESTful components use CXF and Jersey services to convert messages from Java to XML. Web Service components also allow the developer to select or define the logic to be invoked by component.

+ If using the RESTful component you only need to select a Java class and add a script to the component. On the other hand, SOAP configuration requires you to define attributes and select the operation method used to publish a SOAP Web service. As an example of how the CXF component can be used, a SOAP message could be sent to a Web-service-enabled website such as a used car price database, with the parameters needed for a search.

+ The site would then return an XML-formatted document with the resulting data, for example, prices, model, and features. The data returned is then integrated directly into a third-party website or application.

Configuring Components :

You can locate components in the Mule Palette.

To configure a component, double-click on the component to open the Properties Editor in the console. Every component in the Studio palette includes three common fields: Display name, Notes, and Metadata, all of which are optional.

Beyond the two common fields, most Components do not require extensive configuration. The five script components available within Studio support almost identical property pane fields.


For details, see the individual component reference pages on how to use and configure each type of component.

Transformers :  They are used to convert format form one form to another.
ex : xml to json,Object to String,etc.

A Transformer prepares a message to be processed through a Mule flow by enhancing or altering the message header or message payload. For example, if the message source that triggers your flow receives data in XML format, but a downstream message processor requires JSON-formatted data, one or more transformers positioned between the message source and the message processor can achieve the necessary translation. (Since no XML-to-JSON transformer exists, this particular example calls for a XML-to-Object transformer chained to an Object-to-JSON transformer.)


Mule Studio provides a set of standard transformers to handle the most common data transformation scenarios. Typically, these pre-packaged processors require minimal configuration. However, if your particular use case requires special settings, you can open the Properties pane for the particular transformer have selected, then modify the default configuration using the drop-down lists or text-entry fields.

Filters : Filters perform filtering operations.If a particular condition is not met then they don't allow payload(body) to pass.
ex: And filter,Regex filter,schema validation filter,etc

Filters :

Mule bundles more than a dozen Filters that determine whether a message can proceed through an application flow based on some condition or test.

There are filters to test the payload and properties of a message, an exception, or if a message is a duplicate of a previous message. Other filters let you quickly define more flexible tests, using MEL, schema validation, wildcard, regex expressions. Additional boolean logic filters such as and, or, and not help you link filters together to create more complex logical tests.

When to Use Filters :

Most filters silently eliminate the tested message with no logging or reporting. This may not be desirable, especially for messages that have already progressed through several steps of a flow. Because of this behavior, filters are usually used immediately after a message source to filter out unwanted message types. For example, you might use filters immediately after an HTTP Listener to automatically reject request messages that don’t have a required payload type or some other required Metadata, or to otherwise automatically silently filter spurious requests that are definitely not intended for that Mule application flow.

Alternatives to using filters include using typical defensive coding techniques, such as using Choice routers to test a message for conditions, then routing the message to different flows based on certain logical conditions. If a condition indicates an error state, you can either handle the error and log the condition, or you could throw an exception from the flow for processing in a parent flow, or with a global exception handling strategy. Another option to test for exceptional conditions in a flow is to use a Validation component. Validation components are similar to filters, except they throw exceptions when the logical test fails.


Some filters include options to throw exceptions, and the Message filter wraps any other type of Filter so that you can call a compensating flow or throw an exception if the wrapped filter’s condition fails. While this is technically OK, you should always consider if Filters are the correct message processor for your use case, or if your flows will be more understandable by just using Choice routers, and then throwing exceptions with Validation components or directly with Java inside a Groovy component or other MEL expression.

Flow Control : They are used to route payload to as per condition.
ex : choice, scatter gather,splitter,etc.

It Sends the same message to multiple target message processors.

Use the All Flow Control to route or broadcast the same message to more than one processor component.

In many cases, All sends messages to connectors. If the connector has a filter associated to it, then the message must pass through the filtering criteria in order for the connector to receive it.


If the targets receiving messages from the All Flow Control also return messages, then these return messages, if any, are aggregated together and collectively form the response.

Error Handling : There are different error handling mechanism are used in mule 3 for handling exception.
ex : catch exception strategy, choice exception strategy,etc.

Mule provides numerous options for handling errors. Faults that occur within Mule are referred to as exceptions; when an activity in your Mule instance fails, Mule throws an exception. To manage these exceptions, Mule allows you to configure exception strategies.

Mule’s default exception strategy — which implicitly applies to all Mule applications — manages errors (that is. thrown exceptions) in Mule flows. When your flows require more sophisticated error management, you can implement one or more exception strategies to construct precise, efficient protocols for handling errors.


From a high level perspective, errors that occur in Mule fall into one of two categories: System Exceptions, and Messaging Exceptions.

Security : This section is used for security measures in our mule flows.
ex : encryption,oauth provider module,etc.

Out of the box, Mule provides several tools to ensure the security of applications:

Mule Security Manager, client authentication and authorization on inbound requests as well as credential mapping for outbound calls

LDAP and third party identity management system integration

Validation of inbound requests through the SAML 2.0 federated identity standard


Secure FTP (SFTP) Transport that enables Mule flows to read and write to remote directories over the SSH protocol.

Beyond the out-of-the-box features, Anypoint Enterprise Security, a separate, downloadable module, is a collection of security features that enforces secure access to information in Mule applications. Available as a module to download on your existing instance of Mule Enterprise, this suite of security features provides various methods for applying security to integration applications and Web services. The following security features bridge gaps between trust boundaries in applications:

Mule Secure Token Service (STS) Oauth 2.0 Provider

Mule Credentials Vault

Mule Message Encryption Processor

Mule Digital Signature Processor

Mule Filter Processor

Mule CRC32 Processor.