Getting started with Mule

I intend to write a few blogs about Mule, probably the most-used open source Enterprise Service Bus out there. This blog will cover the basics to get Mule up and running.

Installing Mule

Installation of Mule is pretty straightforward:

  • Download the latest Mule ESB Community Edition here;
  • Extract the downloaded archive to a directory of your choice;
  • If you plan to use Maven, set the MULE_HOME environment variable, eg. in your .bashrc file for Ubuntu:
    export MULE_HOME=~/Applications/mule-standalone-3.1.2
    
  • You can now run the server via the following command (on Ubuntu):
    $MULE_HOME/bin/mule
    

Hello World!

To build a simple Hello World example directly in Eclipse follow this tutorial on the Mule website. It also shows you how to install and use the mule plugin for eclipse.

Using Maven

If you’re like me and like to use Maven, there’s a maven plugin available to quickly create a basic mule standalone project.
The basic command for creating a mule project with the plugin is

mvn mule-project-archetype:create -DartifactId=HelloMule -DmuleVersion=3.1.2

To quickly setup a basic project check out this site. If you follow the example a simple maven project is created.
You can “eclipsify” this project via the following maven command:

mvn eclipse:eclipse

Now, you can import the project in Eclipse.

The generated project

The generated project contains a simple mule configuration:

  <flow name="main">
        <vm:inbound-endpoint path="in" exchange-pattern="request-response"/>
        <echo-component/>
        <vm:outbound-endpoint path="out"/>
    </flow>

As you can see, the example is very simple. It contains two in-memory queues. You can send some text in the vm://in queue and it gets echoed out into the vm://out queue.

Fixing the testcase

Before you can run the example, there’s an error in the generated test case, that needs to be solved first (or you can skip the test when running maven of course).
The configuration for the test case, called artifactId-functional-test-config.xml is similar to the main configuration:

    <flow name="main">
        <vm:inbound-endpoint path="in" exchange-pattern="request-response"/>
        <test:component appendString=" Received"/>
        <vm:outbound-endpoint path="out"/>
    </flow>

As an extra bonus it appends ” Received” to the input string before it is sent to the vm://out queue.
The unit test contains the following code:

    public void testHelloMule() throws Exception
    {
        MuleClient client = new MuleClient(muleContext);
        MuleMessage result = client.send("vm://in", "some data", null);
        assertNotNull(result);
        assertNull(result.getExceptionPayload());
        assertFalse(result.getPayload() instanceof NullPayload);
        assertEquals("some data Received", result.getPayloadAsString());
    }

If you run the test goal, this test case will fail on line 7. The problem is that the input string is sent to the vm://out queue, hence the synchronous result is an empty mule message. To fix this, you can either change the configuration, so that the input is not passed to the vm://out queue, like this:

    <flow name="main">
        <vm:inbound-endpoint path="in" exchange-pattern="request-response"/>
        <test:component appendString=" Received"/>
    </flow>

The other option is to adjust the test case, so that the result is read from the vm://out queue:

    public void testHelloMule() throws Exception
    {
        MuleClient client = new MuleClient(muleContext);
        client.send("vm://in", "some data", null);
        MuleMessage result = client.request("vm://out", 5000);
        assertNotNull(result);
        assertNull(result.getExceptionPayload());
        assertFalse(result.getPayload() instanceof NullPayload);
        assertEquals("some data Received", result.getPayloadAsString());
    }

Installing the mule project

After you fixed the bug in the testcase, you can install the application.

mvn clean install

This will package the project into a zip file and copy this file to the $MULE_HOME/apps directory. Here Mule will pick it up and deploy the file.

For now it doesn’t do much besides creating the 2 in-memory queues. In the next blog, I’ll dive a little deeper into Mule and show some basic configurations.

References

As a small reference, there’s a DZone refcard available containing an overview of Mule 3 commands.