Mule Tutorial Series: HTTP Endpoint, Java Component & Expression Filter

A typical Mule application is built around one or more flows. The flow receives a message; the message progresses thru one or multiple steps/activities which perform specific tasks/actions. The flow consists of message sources (endpoints) and then message processors(endpoints, scopes, components, transformers, filters, flow controls, error handlers).

Message endpoints are components provided by Mule to allow Mule’s interaction with external world/applications. Message processors accept messages from endpoints process(modify, enrich, transform), route (filter, flow control, aggregate) to potential destination(endpoint). Please note that an endpoint can be inbound or outbound. An endpoint can function as a receiver as well as a transmitter.

In our first tutorial let’s focus on the HTTP endpoint. The HTTP endpoint essentially exposes a HTTP URL which can be accessed by external applications to upload message. In this case the message will be a HTTP request.

For our demonstration purposes, we have created the following Mule flow. Its graphical illustration of the flow as provided by Mule Studio visualizer is as shown below:


The flow contains the following components:

HTTP Endpoint
Logger Component
Expression Filter
Java Component

The configuration/setting details of each of the component is provided below. Note the configuration settings are explained assuming the use of Mule Studio IDE, in case you do not have the luxury of Mule Studio, refer to the Mule Flow XML source code for understanding and implementation. Please remember to retain default settings for properties not mentioned in the instructions below.

In the HTTP Endpoint component’s ‘General’ tab configure the properties with specified values.

Exchange-patterns – one-way
Host – localhost
Port – 8081
Path – (blank)

HTTP endpoint can be configured to accept request and produce a response. Alternatively it can only accept requests and will not produce responses. By specifying one-way we force the component to only accept HTTP requests. The other properties and their values are self-explanatory.

Mule provides a useful utility component, the Logger component to gain insights into the information flowing thru the Mule subsystem. We have added the Logger component in the flow to understand the structure of the message received by the HTTP component.

In the Logger component’s ‘General’ tab configure the following property with specified value.

Message – #[string: Response: #[payload]]

The message property value of the logger component defines the logging statement. In this case the message payload is dynamically referred to via the #[] notation, in the string. The notation uses MEL (Mule Expression Language) to gain access to the message. The variable ‘payload’ denotes the message received by the end point and it is accessed via MEL notation #[payload].

The HTTP endpoint is configured to receive requests at http://localhost:8081. A request sent to this endpoint will inevitabilty cause browsers to send requests for favicon (http://localhost:8081/favicon.ico). Our flow does not need to respond to these requests. To prevent the request with /favicon.ico passing thru we use another Mule processor called filter.

Mule provides a number of filters for our demonstration, we use the expression filter.In the ‘General’ tab of the filter we set the expression property with the following.

Expression – #[!payload.contains(‘favicon.ico’)]

The MEL specifies that if the payload contains the favicon.ico string, the request will not be allowed to proceed to the next processor.

The final component in the flow is the Java component. The following property is set in the ‘General’ tab of the Java component.

Class name: com.vinraj.integration.http.DataEcho

The class name property of the java component defines the Java class to be invoked while processing the message. The source code of the DataEcho class is shown below

package com.vinraj.integration.http;

import java.util.Map;

public class DataEcho {

	public DataEcho() {

	public void echo() {
		System.out.println("Reached echo method");

	public void echoInput(String input) {
		System.out.println("Reached echoInput method");
		System.out.println("Input: " + input);

	public void echoMap(Map map) {
		System.out.println("Reached echoMap method");
		System.out.println("Map: " + map);


The method name is not relevant, but the signature of the method primarily the argument types are important. The HTTP endpoint output payload is of the type string. Hence Mule needs a method within the target Java class file to accept a single string argument. The echoInput provides the method which is invoked at runtime by Mule server.

The XML source code of the Mule flow is shown below

<?xml version="1.0" encoding="UTF-8"?>

    <flow name="HTTP_FlowFlow1" doc:name="HTTP_FlowFlow1">
        <http:inbound-endpoint exchange-pattern="one-way" host="localhost" port="8081"
        <logger message="#[string: Response: #[payload]]" level="INFO" doc:name="Logger"/>
        <expression-filter expression="#[!payload.contains('favicon.ico')]" doc:name="Expression"/>
        <component class="com.vinraj.integration.http.DataEcho" doc:name="Java"/>

Note: the XML namespaces added within the mule element tag has been removed for code legibility.

To start the application, start the Mule server by right clicking on the flow in the package explorer view and selecting Run As –> Mule Application in the context menu. The console view will display server start-up and initialization messages. Once the server is in running mode, a message similar to the screen shot below will be displayed. Note my Mule application name is ‘integration’, hence the logger message ‘Started app ‘integration’’.


To invoke the application, open any browser window and type the following:


Refer the following output is observed in the console view:

INFO  2013-12-24 17:21:09,885 [[integration].HTTP_FlowFlow1.stage1.02] org.mule.api.processor.LoggerMessageProcessor:  Response: /
Reached echoInput method

Input: /
INFO  2013-12-24 17:21:19,361 [[integration].HTTP_FlowFlow1.stage1.02] org.mule.api.processor.LoggerMessageProcessor:  Response: /favicon.ico

The browser sends two HTTP requests to Mule server. One for the / and second for /favicon.ico. The first request is allowed by the expression filter and the logger code within the echoInput method of the DataEcho class is displayed. The expression filter skips the second request and prevents its passage to the Java component.

That’s it for the first tutorial.


11 thoughts on “Mule Tutorial Series: HTTP Endpoint, Java Component & Expression Filter

  1. Hi I have one doubt . My scenario is have to pass the database result as parameter dynamically to the soap web service. I am passing the Parameter via SetPayload component.

    I am passing the parameter in this below format

    I am getting argument mismatch error. I tested this argument using logger payload[0][‘RATE’],payload[0][‘APPLICANT_NAME’], it retrieves the value perfectly. When I used this in set-payload I am getting argument mismatch error.

    I am looking to resolve this problem.

    Thanks in advance.

  2. Hey I Have many doubt in mule.
    1) I want to make a html page which come when mule started aftere that I should work same like my web server and I should have different web pages in mule and also different configuration.
    Can any one help me with this issue.

  3. The single quote from the sample Expression – #[!payload.contains(‘favicon.ico’)] is for html
    It gives an error and not very obviously to realize at beginning

    Following is the expression for coding

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s