Contact Free trial Login

Anypoint MQ Terminology

Anypoint MQ is an enterprise, multi-tenant, cloud messaging service that performs advanced asynchronous messaging scenarios between applications. Anypoint MQ is fully integrated with Anypoint Platform, offering role-based access control, client app management, and connectors.

The Anypoint MQ messaging broker enables applications to communicate by publishing a Mule message to a queue so that another app can consume the message.

Anypoint MQ supports hybrid use cases, IoT in which you collect data from different devices, and a REST API you can use with device applications. You can also use Anypoint MQ with other app frameworks such as node.js to communicate to queues.

Anypoint MQ:

  • Provides fully hosted and managed queues and message exchanges in the cloud. A queue is a temporary storage area. A message exchange binds one or more queues so that a message sent to a message exchange appears in all its bound queues simultaneously.

  • Is built on Anypoint Platform, which means that queues and message exchanges offer the same management capabilities as the platform itself, from environments and business groups for multi-tenant role-based access control to client access management.

  • Supports large payloads, encryption, queuing, and publish/subscribe (pub/sub) paradigms.

  • Enables you to easily connect to non-Mule applications using the REST API.

  • Provides Anypoint Studio access, which makes the process of leveraging your queues and message exchanges as simple as drag, drop, and configure.

  • Displays usage statistics on the number of messages and API requests so you can manage peak usage and subscription parameters.

  • Provides dead-letter queue capability for undeliverable messages.

  • Enables you to delay message delivery at the queue and message level.

Features

Anypoint MQ includes these features:

  • Queues and Message Exchanges

    Send messages to queues, pull messages from queues, create a message exchange to perform pub/sub scenarios to send a message to multiple queues.

  • Management console

    Monitor queue statistics, purge queues, and see how many messages are in flight using the management console.

  • Anypoint MQ connector

    Send and receive messages from any Mule app, whether it’s deployed in CloudHub or used in a hybrid scenario and deployed on-premises.

  • Usage information

    Organization administrators or owners can view the current and past months' usage, including the total number of messages and API requests. You access this information from the Access Management page. For more information, see Anypoint MQ Usage Information.

  • REST API

    Use the REST API to easily communicate with non-Mule applications.

  • Environments and role-based access control

    Anypoint MQ is fully integrated with Anypoint Access Management, allowing you to specify different environments for your queues, who can access each environment, and what they can do within each environment.

  • Client management

    Create client applications tokens.

  • Large payloads

    Anypoint MQ supports payloads up to 10 MB.

  • Disaster recovery

    Within each region, Anypoint MQ services deploy to multiple availability zones (AZs) to provide high availability (HA). If service in one availability zone goes down, the Anypoint MQ service operates normally in that region. If all availability zones go down in a region, the Anypoint MQ service is unavailable in that region until at least one of the availability zones comes back up. Because the storage solution for Anypoint MQ is durable, messages that were already in the Anypoint MQ system before service was interrupted are retained.

  • Delay queues

    With delay queues, you can postpone the delivery of new messages to a queue for a specified period. Consumers can’t see messages sent to a delay queue for the duration of the delay period. The minimum delay for a queue is 0 milliseconds. The maximum is 15 minutes.

    If you change the queue delay for:

    • Standard queues, the setting change doesn’t affect messages in the queue.

    • FIFO queues, the setting change is retroactive to all messages in the queue.

    You can override the default queue delay for a particular message in a standard queue only.

  • Delayed delivery for messages

    For messages in a standard queue, you can the postpone delivery of a particular message to the queue for a specified period. Consumers can’t see messages sent with delivery delay for the duration of the delay period. The minimum delivery delay for a message is 0 milliseconds. The maximum is 15 minutes.

    Delayed delivery is not supported for individual messages in a FIFO queue.

  • Encrypted queues

    Messages in queues data can optionally be encrypted, enabling companies to be compliant with their data at rest policies. If enabled, Anypoint MQ encrypts messages using PBE with MD5 and Triple DES, and with a 168-bit key. Anypoint MQ messages are encrypted server-side.

Queues

Message queues provide temporary storage that enables applications to communicate in a scalable and reliable way. Publishers can publish messages into queues, and subscribers can receive messages from queues. You can create a dead-letter queue to store undeliverable messages.

Anypoint MQ Publisher-Queue-Subscriber

Queues provide these benefits:

  • Horizontal scalability

    By putting a message on a queue, the work to process that message can be distributed over multiple subscribers.

  • Reliability

    Queues ensure that messages are always processed, even in the case of failure.

    In Anypoint MQ, reliability is provided with queues using a lock and acknowledge mechanism. This ensures that a message is always processed, even in the case of failure.

  • Decoupling

    A queue can be used as a communication mechanism between different applications and devices, allowing them to have different development life cycles or maintenance windows, without affecting other applications.

  • Aggregation

    Multiple message producers can publish to a single queue, which enables easy consumption by consumers.

    1. A consumer retrieves messages from a queue. This locks the messages and makes the messages invisible to all other consumers.

    2. When retrieving, the consumer specifies a lock timeout. If the message is not processed within that time window, the message is made visible to other consumers to be processed. This ensures that if there was a failure of some sort, such as the consumer node crashed, a message can be processed by another node. A locked message does not block other messages to be read. The lock makes a message unavailable to other applications while locked.

      If a consumer processes a message successfully, the client acknowledges the message, and Anypoint MQ removes the message from the queue. For more information on how Anypoint MQ processes acknowledged messages, see Acknowledge a Message.

      If a consumer is not able to process a message, the message proceeds with a negative acknowledgment and becomes visible in the queue again.

  • Message TTL

    Each queue has a message time-to-live (TTL). TTL specifies how long the message is in the queue before Anypoint MQ expires the message and removes it from the queue.

  • Unlimited messages in a queue

    There is no limit on the number of messages in a queue. Each message in a queue is limited to 10 MB.

  • Long polling

    Messages are read through long polling. The server holds a request open until new data is available, and then Anypoint MQ delivers a batch of messages with a single read.

  • Billing and charging

    Billing is based on the number of messages delivered to subscribers from queues, not the number of queues or message exchanges you create.

Clients

In Anypoint MQ, each consumer must be registered as a client app with a name, ID, and a secret. The client app uses the ID and secret to authenticate and get access to queues and message exchanges within a single environment. Client apps cannot be used across multiple environments or business groups.

Message Exchanges

With message exchanges you can to distribute a single message to multiple consumers.

mq pub ex sub

For example, if a publisher publishes changes in the weather, and you have multiple apps that want to receive that data, you can use a message exchange to publish a single message to multiple queues for each app. A binding is a relationship between the queue and message exchange, which tells the message exchange where to send messages. A queue can be bound to multiple message exchanges.

Example

In this example, an app running Salesforce customer relationship manager (CRM) wants to communicate with two applications that handle different databases.

CRM sends msg to Anypoint MQ that apps receive

Using Anypoint MQ, the Salesforce app sends a pub/sub message to a message exchange, and the two applications receive the message from the message exchange and convey the message to their respective databases.

Glossary

  • ACK/NACK

    • ACK

      An app receives a message and Anypoint MQ deletes the message. For more information, see Acknowledge a Message.

    • NACK

      An app does not receive a message and Anypoint MQ does not delete the message.

  • Binding

    Enables pub/sub apps to bridge the simple pub/sub structure and use point-to-point features, such as sending a message to specific applications. Bindings identify which queues comprise a message exchange. In Anypoint Platform, by specifying which message queues are bound to a message exchange, Anypoint MQ creates and manages the bindings for you.

  • Dead letter queue (DLQ)

    A queue that stores undeliverable messages from other queues.

  • Destination

    A message exchange or queue. Applications register to a destination and publish messages to the destination. Applications subscribe to a destination to receive a message. Anypoint MQ lets you configure Destinations by creating or maintaining queues or message exchanges. Anypoint Studio lets you configure destinations using the Anypoint MQ connector.

  • Durable message

    A message that persists until its indicated client receives it.

  • In Flight

    Messages awaiting ACK or NACK, or with an expired lock time-to-live setting. In-flight messages are not visible to other consumers. Anypoint MQ supports up to 120,000 in-flight messages per queue for standard (non-FIFO) queues. FIFO queues can have up to 10 in-flight messages per queue.

  • Duration

    Messages can persist in flight for up to 2 weeks after which messages older than 2 weeks are deleted.

  • In Queue Messages that have been sent.

  • Lock ID

    A lock that lets an app read a queue exclusively. Anypoint MQ provides the lock when an app acknowledges a message from a queue. A locked message does not block other messages to be read. The lock makes a message unavailable to other applications while locked.

  • Message

    Serializable Mule Message content that applications send and receive so that the applications can communicate with each other.

  • Message Exchange

    A pub/sub message source with multiple outputs. Applications register to subscribe to messages that the message exchange publishes.

  • On-premises

    Mule runtime that runs on a computer in your organization.

  • Payload

    The message content, which can be text, JSON, or CSV (comma-separated values).

  • Point-to-point

    A pattern that allows an app to send a message that only a single app can receive.

  • Pub/sub (publish/subscribe)

    A pattern that enables messages to be distributed to multiple consumers.

  • Publisher

    An app that sends messages to Anypoint MQ.

  • Queue

    A point-to-point message storage area that holds a message that a client receives.

  • Subscriber

    An app that receives messages from Anypoint MQ.

  • Usage

    A chart that illustrates how much data and API requests have been consumed.

We use cookies to make interactions with our websites and services easy and meaningful, to better understand how they are used and to tailor advertising. You can read more and make your cookie choices here. By continuing to use this site you are giving us your consent to do this.