Mulesoft Basics

Mule Application Building Blocks

In this article we will find the basic concepts before start building Mule application using Anypoint studio. Here we will see things about

• Mule Palette
• Project explorer
• Pom basic configuration
• Shortcuts
• Selecting runtimes
• Munits coverage view
• Test your application and many more.

Mule application building blocks are separated into categories in the Mule 3 Palette:

In Mule 4 build concept is almost same but in Mule 4 runtime decoupled the extra libraries from core runtime libraries and providing only the core libraries to build basic app flows, which makes it lightweight runtime. However we can add modules or import from exchange as per requirement.

      

Add modules in Mule 4

Search from Exchange and Add in Mule 4

Now lets discuss about components

Message Sources :

The first building block of most flows is a receiver that receives new messages and places them in the queue for processing.

• Message sources are usually Anypoint Connectors.
• Connectors provide connectivity to external resources, such as:
• Databases, protocols, or APIs.
• Standard protocols like HTTP, FTP, SMTP, AMQP.
• Third-party APIs like Salesforce, Twitter, or MongoDB.

Anypoint Connectors :

• There are 2 main types:
• Endpoint-based connectors
• Operation-based connectors

Endpoint-Based Connectors :

• Are either inbound or outbound endpoints in a flow.
• Inbound endpoints serve as a message source for a flow.
• Outbound endpoints send information to external systems.

Operation-Based Connectors :

• These connectors require the specification of an operation in order to perform.
• This category includes most connectors not based on a standard communication protocol

Connector vs Endpoint :

• A connector is a Mule-specific connection to an external resource of any kind.
• An endpoint is a flow-level element that is configured to receive and/or send messages from and/or to external resources.
• When you drag a connector from the Mule Palette, an endpoint is created.
• Connectors and endpoints are global elements.

Creating Mule Applications With Anypoint Studio

Anypoint Studio is an Eclipse-based integration development environment that provides:

• Two-way editing between graphical and XML views.
• Visual debugging (EE).
• A data transformation framework and language (EE).
• One-click deployment of applications.
• Templates for common integration patterns (EE).
• Integration with Maven for continuous build processes.

Sample Flow: Visual

Anypoint Studio View: 

Running an Application:

Anypoint Studio comes with an embedded Mule runtime to test applications without leaving it.
The console outputs application logs and information:

Introducing Mule Flows and Message

Mule Flows

Mule applications accept and process messages through a series of message processors plugged together in the flow.

A typical flow has:

Message Source  - Accepts a message from an external source, triggering the execution of the flow.
Message Processors - Transforms, filters, enrichs, and processes messages.
An application can consist of:

• A single flow.
• Multiple flows/subflows connected together to create more complex applications.

Mule Message Structure

You can find more about Mule message structures and events

Anatomy of  a Flow : 

artifacts-json: In Mule 4

Pom.xml: 

Pom file is now required for Mule 4 app build. All mule app in mule4 is packaging as mule-application 

Project Explorer: 

Below Project explorer shows how the structure of Mule 4 App will look like:

Runtime Selection: 

You can select your required runtime by selecting through Run/Debug as configuration

Menu Bar & Shortcuts

Quick Access: 

You can quickly search from Quick Access, it is placed at top right of your anypoint studio.

Munit Coverage View: 

For munit coverage and reports you can run and also view in anypoint studio.

Testing Applications: For testing Mule Application

Some options:
• A browser.
• A cURL command-line utility.
• A browser extension like Postman (for Google Chrome). 

Read More »

Mule 4 components - InDepth

A Mule4 message is composed of a payload and its attributes. Mule event is immutable, so every change to an instance of a Mule event results in the creation of a new instance.

A Mule 4 Event is composed of these objects:

While we have already seen in Mule 3, Mule message is, itself, embedded within a Mule message object and it may contain variables, attachments, and exception payloads.

In Mule 3, When the request is received by Mule message source. It is then converted into a Mule message or flow and starts processing it when it receives an inbound endpoint in a flow.

In Mule 4, flows triggered by an event are generated when a trigger reaches the event source of flow. This trigger could be an external event triggered by a resource that might be external to the Mule app.

You can create, or update, variables in these ways:

• Using the Set Variable component.
• Using a Target Variable from within an operation, such as the Read operation to the File connector or the Store operation to the Database connector.
• Using the Datwave Transform Component (EE-Only).
• Using Scripting Component (in scripting module)

You can also delete/remove:

• Using the Remove Variable component.
  
  After creating a variable, you can access and use it within the scope of a Mule flow where you created it, which includes any flows that are joined with it through a Flow Ref component.
   vars : Keyword for accessing a variable, for example, if the name of your variable is myVar, you can access it like this: vars.myVar

Note that a variable in the Mule event is different from variables defined in a DataWeave script, which are local to the script and not accessible outside of it.

Message Collections:

One of the major changes to the new Mule Message structure is when dealing with collections. In Mule 3, components that returned multiple payloads, used a special structure called the MuleMessageCollection. But in Mule 4, any component that needs to deal with multiple messages can simply set the payload of the message to a List of Mule Messages. We can then iterate over these messages using DataWeave, For Each, or other components based on requirement.

Comparison between Mule 3 Structure and Mule 4 Structure

Mule 3	Syntax	Mule 4	Syntax	Description
Mule Message	#[message]	Simplified	#[message]	Consists of payload and attributes
Inbound properties	#[message.inboundProperties.'http.version']	Replaced by Attributes	#[attributes.header]	Replaced with attributes and have advantage that we can store it in variables to access throughout your flow.
Outbound properties	#[message.outboundProperties.'MULE_ENCODING']	Removed		We can achieve it by using dataweave expression.
Flow Variables	#[flowVars.varName]	Replaced	#[vars.varName]	Replaced with variables but acts same as Mule 3
Session Variables	#[sessionVars.varName]	removed	​	Removed as transport barriers are no more exists. We can store values in variables itselves.
Record Variables	#[recordVars.varName]	removed	​	Removed as batch jobs is a scope which lives inside flow, we can store in variables.
Attachements	#[message.inboundAttachements]	removed	​	Inbound and outbound attachments have been removed. The affected connectors now handles the attachment using Dataweave.

List of predefined keyword used in 

• vars
• app
• attributes
• authentication
• correlationId
• dataType
• error
• message
• mule
• payload
• server

Happy Learning :)

Read More »