Get Started With Mule ESB

What Is Mule ESB?

It's an Enterprise Service bus which can easily integrate existing systems, regardless of technology, service creation, or host reusable service. Mule ESB can be used to exchange data in various formats like REST, SOAP, etc.

Mule Building Blocks

Mule message processor: After Mule receives a message from a Message Source, it uses one or more message processors to process the message through a flow. 

Components: Components are highly flexible tools to perform any business logic using Java or any of a number of scripting languages.

MEL: MEL is a lightweight, Mule-specific expression language that you can use to access and evaluate the data in the payload, properties and variables of a Mule message. Accessible and usable from within virtually every message processor in Mule, MEL enables you to quickly and elegantly filter, route, or otherwise act upon the different parts of the Mule message object.

For example:

<logger message="The value in my first variable is #[flowVars.myVar1]" level="INFO"/>

Mule Message  

The Mule message is the data that passes through an application via one or more flows. It consists of two main parts:

• The message header, which contains metadata about the message.

• The message payload, which contains your business-specific data. 

Connectors 

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 fall at the end of a flow and act as the recipient of the final payload data. 

Example: ActiveMQ connectors, Salesforce Connectors, JDBC connectors

Endpoints

Endpoints are used to connect flows. An endpoint is a specific channel on which a flow can send messages and from which another flow or external service can receive messages. For example, a purchasing component may receive an order request over HTTP. Once the order has been processed by the component, a JMS message may be sent over a topic to notify an auditing system, and a response can be sent back over HTTP.

Example : HTTP Endpoint, JMS Endpoint

Filters 

Filters determine whether or not a message processor should process an incoming event or message. You can use the On Unaccepted property to optionally specify the name of the message processor that should handle any unaccepted events. Check the Throw On Unaccepted box to throw an exception if a message or event is not handled. The default when not checked is to not throw an exception.

Example: Logic filters apply the And/Or/Not logic to one or more nested filters that they enclose. When you use these logic filters, you add nested filters to them from within the And/Or/Not-filter nested pane.

Routers

Routers (Flow Controls in Anypoint Studio) route messages to various destinations in a Mule flow. Some routers incorporate logic to analyze and possibly transform messages before routing takes place. For example, various flow controls can:

• Split a message into several segments, then route each segment to a different building block.
• Combine several messages into a single message before sending it to the next building block in the flow.
• Reorder a list of messages before sending it to the next building block.
• Evaluate a message to determine which of several possible building blocks it should be routed to next.
• Broadcast the same message to multiple building blocks

Example: Choice Routers

<choice>
  <when expression="payload=='foo'" evaluator="groovy">
    <append-string-transformer message=" Hello foo" />
  </when>
  <when expression="payload=='bar'" evaluator="groovy">
    <append-string-transformer message=" Hello bar" />
  </when>
  <otherwise>
    <append-string-transformer message=" Hello ?" />
  </otherwise>
</choice>

Error Handling

Mule ESB 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 (i.e. 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.

Example: Default Exception Strategy - Defined and implicitly applied by default to handle all messaging exceptions that are thrown in Mule applications.