Amazon Simple Queue Service (Amazon SQS) offers a reliable, highly scalable hosted queue for storing messages as they travel between computers. By using Amazon SQS, developers can simply move data between distributed application components performing different tasks, without losing messages or requiring each component to be always available. Amazon SQS makes it easy to build an automated workflow, working in close conjunction with the Amazon Elastic Compute Cloud (Amazon EC2) and the other AWS infrastructure web services.

Important

Although it is called Queue, Amazon SQS does not guarantee FIFO access to messages in Amazon SQS queues, mainly because of the distributed nature of the Amazon SQS. If you require specific message ordering, you should design your application to handle it.

Sending a message to the Queue

You can send a message by using send-message as follows:

<sqs:send-message>

That will send your payload as a STRING, so, if you want to send some other object, you will have to convert it to a string, and then when you are receiving it, you'll have to revert that conversion, to get your original object.

Example

<flow name="producer">
    <description>Puts a text message in the message queue.</description>
    <inbound-endpoint address="http://localhost:9090/add-status-to-mongo"/>
    <expression-transformer expression="#[header:inbound:status]" evaluator="string"/>
    <sqs:send-message/>
</flow>

In this example, we can view how to send to the queue a message created from the parameter status of the url http://localhost:9090/add-status-to-mongo As you can see, we have to make that status, the new payload, so it could be sent.

Receiving messages from the Queue

You can start receiving messages by using recieve-messages that acts like an inbound endpoint and it can be used as such.

<flow name="messagesConsumer">
    <!-- INBOUND ENDPOINT -->
    <sqs:recieve-messages visibilityTimeout="5" 
                          preserveMessages="false"/>
    <!-- REST OF YOUR FLOW -->
    <logger level="INFO" message="Received a message: #[payload]"/>
</flow>

A Mule flow is divided in two. The first portion of it is usually an inbound endpoint or a message source. It is an entity that will receive/generate events that will later be processed by the rest of the flow. The other portion is a collection of message processors which will processes the messages received/generated by the inbound endpoint.

Every time our messages Consumer receives a message it will execute the rest of the flow. In the case, it will log a message at INFO level.

Parameters

The preserveMessages parameter is a flag that indicates if you want to preserve the messages (true), or delete them (false) from the queue after you get them. By default, it will delete them.

The visibilityTimeout is an integer that represents the duration (in seconds) the retrieved message is hidden from subsequent calls to retrieve. For example, if you only have a message in the queue, and you retrieve it with a visibilityTimeout of 5 second, you will have an "empty" queue, until "appears" again in 5 seconds.

Example

<flow name="consumer">
    <sqs:receive-messages />
    <mongo:insert-object-from-map collection="status">
      <mongo:element-attributes>
        <mongo:element-attribute key="text">#[payload]</mongo:element-attribute>
      </mongo:element-attributes>
    </mongo:insert-object-from-map>
</flow>

This example gets a message from the queue, and add it to a Mongo DB. Because receive-messages is a Source, you don't have to run it, because it will be running from the beginning. Then every message received from the queue, will be inserted in the collection status from our Mongo DB. As you can see, every command that follows the receive-message will used each message that retrieves.