Home

Overview - MessageQueue

Glossary

• MessageQueue and MultiQueue are used interchangeably and are both referring to the application.
• queueType and subQueue are used interchangeably and are both referring to one of the individual queues within the multi queue.

Application Overview

The MessageQueue application provides a REST API to interact with multiple message queues via a single application. Each of these are "sub-queues" are separate from one another and within the code and REST API this is referred to as the "queue type" or "type".

The application is comprised of two main settings, the Storage Mechanism and the Restriction Mode both are used together to control where messages are stored and how the MessageQueue can be interacted with.

Interacting with the MessageQueue

You need to always specify the "type" when interacting with the application so that it understands what "sub-queue" you wish to interact with. There are some exceptions such as the UUID search which will search the whole MultiQueue. The MultiQueue also allows messages to be "assigned" but not consumed (incase the processing application fails so that the message is not lost). The best way to explain this is probably with an example of the common payload used when interacting with the REST endpoints.

Payload Overview

QueueMessage Response Payload

An example response payload returned when a QueueMessage is created:

{
    "queueType": "test",
    "correlationId": "47716ebb-e609-45c9-8d9e-30e6ba7732bd",
    "message": {
        "payload": {
            "property": "a test2",
            "id": 123,
            "is_ok": true
        },
        "type": "test",
        "assignedTo": null,
        "uuid": "2e24b00b-328f-4972-82e6-a0480ad823f8"
    }
}

$.queueType and $.message.type are the same value which indicates the "sub-queue" identifier that this message was created in.

$.message.uuid can either be provided or generated, if provided in the creation payload it will be retained, otherwise the generated UUID will be generated and returned in the response.

$.message.payload is a custom object that can be provided with whatever structure you wish. In this example its an object with String, Int and Boolean values.

$.message.assignedTo is indicating whether this message is "marked or being used" by an entity. This can be used to determine the state of the message and to resolve any special cases. For example, if the instance which has been assigned this message is no longer available, you may want to find all messages that are assigned to the arbitrary value and release the messages, or remove them if applicable. Otherwise the messages cannot be directly claimed by other instances via the /next endpoint.

Error Response Payload

When any error response is thrown a response body like the following will be provided to the caller:

{
    "correlationId": "88b59a45-b88a-49c6-9e89-3ed71b3104a9",
    "message": "Failed to add entry with UUID [86b62477-f70d-4501-a9fb-e4271cce22a8], an entry with the same UUID already exists in queue with type [notification-sms]."
}

---

Correlation ID

By default the application will generate and log a UUID specific for each new request. This same UUID will also be returned in success and failure response messages. However if you wish you can provide a custom Correlation ID in any request by providing it in as the following header value X-Correlation-Id.