Nav
You are viewing an older version of this section. Click here to navigate to the latest version.

Understanding the Mule Message

This example introduces the Mule Message and shows you how to use the Mule expression language to inspect it. It demonstrates how to view the composition of a typical Mule Message, including its scope, properties, and payload data.

We introduce a several new concepts:

  • The Mule Message - the Mule Message is the key piece of data that passes through a mule application

  • Message Property Scopes -Message Property Scopes help organize message properties (meta-data attached to business-specific payloads) across the message life-cycle as it passes through the Mule system

  • Mule Expression Language - Mule has a powerful expression language built-in for querying request and response payloads and headers. We’ll use an expression to log something useful with the logger component.

What You Will Learn

  • How to build on an existing Mule Flow in MuleStudio

  • How to use expressions to access Mule Messages properties

  • How to work with Mule message scopes

Watch the video

See this example built and run in Mule Studio

Build it Now!

5 minutes

Prerequisites

Building the Example

  1. We’re going to continue editing the previous example and add a Logger component to the flow. Drag the Logger component from the palette to the canvas between the HTTP endpoint and Hello component:

    studioAddLogger-1

  2. Double click on the Logger component to edit its properties.

  3. In the Name field enter: "ExtractNameProperty" and in the Message field enter the following text: "Hello #[header:INBOUND:name]!"

    studioConfigureLogger-1

The #[header:INBOUND:name] is a mule expression that extracts the value of the messages property "name" from the INBOUND scope of the message header. We’ll discuss scopes in greater detail in another example. Think of a scope as a way of partitioning items of interest over different parts of the message’s life-time. For example, you keep an entirely different set of items in the briefcase you take to work from those in your gym bag (one hopes!).

A Mule message consists of three parts

  • the header, which contains sets of named properties partitioned into scopes

  • the payload, which consists of business-specific data (such as a purchase order)

  • an optional attachment

A message is like a suitcase you take on a trip. While in transit, you don’t care what’s in the suitcase, but you do use the handle to carry it, the wheels to roll it, and the lock to secure it. The properties of a Mule messages are much like the handle, wheels, and lock of the suitcase - they help get the message where it needs to go. The message payload is like the contents of the suitcase. Most of the time you don’t need to know about it until you arrive at your destination.
Conceptually a Mule Message travels along the lines from block to block in your Mule Configuration. Each block takes a crack at the message and takes some action based on a value of one of its properties.
Think of the message as your suitcase passing through the baggage handling system (Mule). In this example we have added a logger to inspect and display a message property, much as a baggage handling system might read a bar code on the routing ticket attached to the suitcase to decide the best way to lose your luggage.

Running the Example

  1. Right click on the flow in the project tree and select Run As… → Mule Application

    Hot Deployment

    If you didn’t stop running the Mule application from the last example, the changes you made here will automatically get hot deployed when you hit Save in the File menu or press CTRL+S.

    studioRunFlow

  2. Next open up a browser and go to http://localhost:8082/?name=Helen. You should see the following in your browser:

    studioBrowserOutput-1

  3. Now go back to Mule Studio and check the logs, you’ll see that the Logger wrote out to the console printing the value of the "name" message property.

    studioConsoleOutput-1

    The console will also print out an exception due to the fact that the web browser makes a second request (for a favicon.ico) which does not contain the proper header.

    studioConsoleExceptionOutput

What Just Happened?

  • You just added a Logger message processor to your flow, which demonstrated how to access Mule Message properties

  • You used the #[header:INBOUND:name] expression to inspect one of the properties in the Mule message header

Next Steps