Reading Time: 6 minutes

Today I am going to introduce a recently created module: Mule Requester.

As its name may hint, its goal is to allow the request of a resource at any point in a flow. This resource can be a file, a message (from VM, JMS, AMQP, etc.), an e-mail, etc. It’s intended for resources that originally could only be requested by message sources.

latest report
Learn why we are the Leaders in API management and iPaaS
Read reports

Let’s try to explain it better with an example. Say we want to consume messages from a queue on demand, i.e. not consuming the message as soon as it’s put on the queue but at a later stage, when a user calls an HTTP inbound endpoint, for example. We cannot achieve this by using a JMS inbound endpoint, since it will consume the message as soon as it’s put on the queue. Thinking about a way of doing this, we could have a stopped flow and activate it on demand but this would cause the consumption of more than one message or a clumsy implementation that would pick a message and stop the flow again. Another option would be to use a component but this would have to deal with the specifics of the transport, leading to either one implementation per transport type or a big component handling all the transports.

The above mentioned case can be easily achieved using the Mule Requester module, simply by placing the starting point of the flow (the HTTP inbound endpoint in our example) followed by the requester:

Some of its more common use cases are:

  • Load a file in the middle of a flow for processing.
  • Consume messages (one, N, all) from a queue in the middle of a flow.
  • Pull messages from a mail server on demand, to use its data in an enricher for example.

Why releasing it as a Mule module?

  • It’s reusable
  • It’s simple
  • It can be easily installed in MuleStudio
  • It can be used with Maven

Following the first example, let’s show a more complex one: consuming all the messages from a queue on demand. Let’s assume that the use case is to get all those messages after a user called an inbound HTTP endpoint (it could be any other kind of Mule endpoint, e.g. Quartz).

First we have the flow with the starting entry point:

This flow simply receives a request at http://localhost:8081/emptyqueue and delegates to another flow called QueueRequester:

This flow does all the magic:

  1. First it requests a message from the queue ‘input’.
  2. If there is a message, it processes it (just logs the payload in the example) and calls the same flow again, to allow the processing of the next messages in queue.
  3. Otherwise, if there is no pending message in the queue, it just logs the queue has been emptied and finishes.

That configuration also contains another example that shows how to consume a file based on an expression after calling an HTTP inbound endpoint.

Key feature of the module:

  • Expressions support
  • Possibility of throwing an exception if the requested resource is null
  • Automatic transformer: the return type of the requester resource can be set to any type and Mule will automatically try to transform it