# mulesoft Anypoint MQ Connector - Full Documentation

<!-- document id=c8f4b8a79401d7af2afb30c4cf4e8b4e5fc01f65e52e7206447f05589cd951e0 url=/mulesoft/current/en-us/anypoint-mq-connector/2.x/anypoint-mq-ack.md -->

---
product: Anypoint MQ Connector
version: 2.x
---

# Anypoint MQ ACK and NACK Operations

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Acknowledging a message (ACK) informs the broker that the message has been processed and must be
removed from the queue to prevent redelivery. Not acknowledging a message (NACK) tells the broker to
not process the message and to return the message to the queue for redelivery to any available
consumer.

The Anypoint MQ connector provides three acknowledgment configurations: Immediate, Automatic, and
Manual.

## Immediate Acknowledgment

Use the `IMMEDIATE` acknowledgment mode to acknowledge messages as your app consumes them and before
processing them.

When Anypoint MQ acknowledges a message, it removes the message from the queue and doesn’t redeliver
it if an error occurs during processing.

If the app restarts between being acknowledged and dispatched, the message might not be available
again because it was deleted from the queue. To prevent message deletion until after processing, use
the `AUTO` or `MANUAL` acknowledgment mode instead.

If an error occurs during message processing using `IMMEDIATE` mode, Anypoint MQ throws an
`ANYPOINT-MQ:ACKING` error. To manage errors without losing messages, use a dead letter queue.

## Automatic Acknowledgment

Use the `AUTO` acknowledgment mode to acknowledge a received message automatically only if the flow
execution finishes successfully.

If an error occurs during flow execution, execution terminates, and the message is returned to the
queue for redelivery.

## Manual Acknowledgment

Use the `MANUAL` acknowledgment mode to delegate all responsibility to the app logic to decide when
to acknowledge the message.

With this configuration, every message received has an `AnypointMQMessageContext` object in the Mule
message `attributes` that identifies this message uniquely for a given connection.

### Acknowledgment Timeout

When using either `AUTO` or `MANUAL` acknowledgment modes, you can use the `acknowledgementTimeout`
parameter to control how long the message remains in-flight waiting to be acknowledged, before
automatically returning to the queue.

The app must execute either an ACK or NACK operation on the message before the timeout expires.

When using `acknowledgementTimeout`, consider expected app-time processing, including time for
unexpected delays, such as external systems delay and app back-pressure due to high load. For
example, if you expect the consumed message to be processed in 10 seconds, set the
`acknowledgementTimeout` to a minimum of 15 seconds.

### Execute an ACK Operation

Acknowledging a message informs the broker that the message has been processed and must be removed
from the queue to prevent redelivery.

The\`AnypointMQMessageContext\` object identifies the message to pass on to the `anypoint-mq:ack`
operation:

```xml
<flow name="consumerWithManualAck">
    <anypoint-mq:consume
       destination="${destination}"
       acknowledgementMode="MANUAL"
       config-ref="AMQ_Config"/>

    <!-- Process messages without modifying the payload-->
    <jms:publish config="JMS_config" destination="${bridgedDestination}">

    <anypoint-mq:ack messageContext="#[attributes]" config-ref="AMQ_Config"/>
</flow>
```

If a non-void operation is invoked during message processing, the payload and attributes of the Mule
message are modified. To perform an ACK operation after processing, you must save the original
attributes in a variable.

To save attributes to use later, use the `target` and `targetValue` parameters to store the whole
message in a variable:

```xml
<flow name="consumerWithManualAck">
    <anypoint-mq:consume destination="${destination}"
                 acknowledgementMode="MANUAL"
                 config-ref="AMQ_Config"
                 target="mqMessage"
                 targetValue="#[message]"/>

    <!--Do message processing changing the payload-->
    <http:request method="POST" path="/invoicesProcessing" config-ref="httpRequestConfig">
            <http:body>#[vars.mqMessage.payload]</http:body>
    </http:request>

    <anypoint-mq:ack messageContext="#[vars.mqMessage.attributes]" config-ref="AMQ_Config"/>
</flow>
```

### Execute a NACK Operation

Not acknowledging a message informs the broker that the message was not processed successfully and
commands the broker to return the message to the queue for redelivery to any available consumer.

The `AnypointMQMessageContext` object that identifies the message is passed to the
`anypoint-mq:nack` operation:

```xml
<flow name="consumerWithManualAck">
    <anypoint-mq:consume
                 destination="${destination}"
                 acknowledgementMode="MANUAL"
                 config-ref="AMQ_Config"/>

    <!--Do message processing-->
    <logger message="#[payload]">

    <anypoint-mq:nack messageContext="#[attributes]" config-ref="AMQ_Config"/>
</flow>
```

## See Also

- [Anypoint MQ Consume Operation](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-consume)

- [Anypoint MQ Subscriber Source](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-listener)

<!-- document id=f0aff14f188787a5a1c3dedcdd0572b61e4428ddc5789e791b2e087a298ca22a url=/mulesoft/current/en-us/anypoint-mq-connector/3.x/anypoint-mq-ack.md -->

---
product: Anypoint MQ Connector
version: 3.x
---

# Anypoint MQ ACK and NACK Operations

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Acknowledging a message (ACK) informs the Anypoint MQ broker that the message has been processed and
must be removed from the queue to prevent redelivery. Not acknowledging a message (NACK) tells the
broker to not process the message and to return the message to the queue for redelivery to any
available consumer.

## Acknowledgment Modes

The Anypoint MQ connector provides three acknowledgment modes:

- Immediate

  Use Immediate when you want to acknowledge messages as your app consumes them, before processing
  them.

- Automatic

  Use Automatic to acknowledge a received message automatically only if the flow execution finishes
  successfully.

- Manual

  Use Manual if you want the app logic to control message acknowledgment.

### Immediate Acknowledgment

Use the `IMMEDIATE` acknowledgment mode to acknowledge messages as your app consumes them and before
processing them.

When Anypoint MQ acknowledges a message, it removes the message from the queue and doesn’t redeliver
it if an error occurs during processing.

If the app restarts between being acknowledged and dispatched, the message might not be available
again because it was deleted from the queue. To prevent message deletion until after processing, use
the `AUTO` or `MANUAL` acknowledgment mode instead.

If an error occurs during message processing using `IMMEDIATE` mode, Anypoint MQ throws an
`ANYPOINT-MQ:ACKING` error. To manage errors without losing messages, use a dead letter queue.

### Automatic Acknowledgment

Use the `AUTO` acknowledgment mode to acknowledge a received message automatically only if the flow
execution finishes successfully.

If an error occurs during flow execution, the message is not acknowledged ('NACK') and the message
is returned to the queue for redelivery.

### Manual Acknowledgment

Use the `MANUAL` acknowledgment mode to delegate all responsibility for message acknowledgment to
the app logic.

With this configuration, every message received has an `ackToken` value that identifies this message
uniquely for a given connection.

Save this `ackToken` value to use later as input to the ACK or NACK operations.

## Acknowledgment Timeout

When using either `AUTO` or `MANUAL` acknowledgment modes, you can use the `acknowledgementTimeout`
parameter to control how long the message remains in-flight waiting to be acknowledged, before
automatically returning to the queue. The `acknowledgementTimeout` timer begins when the message is
consumed.

If `acknowledgementTimeout` is not set, Anypoint MQ Connector uses two minutes. If you need a
different TTL, you must define it explicitly in the `acknowledgementTimeout` parameter of the
subscriber.

When using `acknowledgementTimeout`, consider expected app-time processing, including time for
unexpected delays, such as external systems delay and app back-pressure due to high load. For
example, if you expect the consumed message to be processed in 10 seconds, set
`acknowledgementTimeout` to a minimum of 15 seconds.

> [!IMPORTANT] When using the `prefetch` mode in the Subscriber source, Anypoint MQ attempts to
> honor the expiration time specified by `acknowledgementTimeout`. However, Anypoint MQ extends the
> expiration timeout if the time that the message remains in the buffer reaches 80% of the timeout
> value.
>
> For this reason, don’t use `prefetch` mode if the `acknowledgementTimeout` must be honored.

### Acknowledgment Timeout — AUTO Acknowledgement Mode

After a subscriber consumes a message, a timer starts, indicating how long the message has been
in-flight for the broker waiting for acknowledgment. If the flow processing does not end with a
success or failure before the `acknowledgementTimeout` limit is reached, the message automatically
returns to the queue for redelivery.

### Acknowledgment Timeout — MANUAL Acknowledgement Mode

When consuming a message using `MANUAL` acknowledgment mode by either the Subscriber or Consume
operations, the app must execute either an ACK or NACK operation using the message `ackToken` before
the `acknowledgementTimeout` limit is reached. If neither operation executes with the given token
before the timeout, the message automatically returns to the queue for redelivery. Any attempt to
acknowledge the message after the timeout limit fails due to an expired token.

## ACK Operation — MANUAL Acknowledgement Mode

Acknowledging a message (ACK) informs the broker that the message has been processed and must be
removed from the queue to prevent redelivery.

When performing the ACK operation using Manual mode, you must use the acknowledgment token
(`ackToken`) to identify the message. It is available in the `ackToken` field of the message
attributes:

```xml
<flow name="consumerWithManualAck">
    <scheduler>
        <scheduling-strategy >
          <fixed-frequency />
        </scheduling-strategy>
    </scheduler>

    <!-- Consume a message -->
    <anypoint-mq:consume destination="${destination}"
         acknowledgementMode="MANUAL"
            config-ref="Anypoint_MQ_Config"/>

    <!-- Save the ackToken for future acknowledgment -->
    <set-variable variableName="currentAckToken"
       value="#[attributes.ackToken]"/>

    <!-- Do the required processing of the message -->
    <flow-ref name="process-message"/>

    <!-- Use the ackToken to ACK the message -->
    <anypoint-mq:ack ackToken="#[vars.currentAckToken]"
         config-ref="Anypoint_MQ_Config" />
</flow>
```

If a non-void operation is invoked during message processing, the payload and attributes of the Mule
message are modified. To perform an ACK operation after processing, you must save `ackToken` in a
variable.

To save attributes to use later, use the `target` and `targetValue` parameters to store the whole
message in a variable:

```xml
<flow name="consumerWithManualAck">
      <scheduler>
        <scheduling-strategy >
          <fixed-frequency />
        </scheduling-strategy>
      </scheduler>

    <!-- Consume a message -->
    <anypoint-mq:consume destination="${destination}"
        acknowledgementMode="MANUAL"
        config-ref="Anypoint_MQ_Config"
        target="mqMessage"
        targetValue="#[message]"/>


    <!--Do any message processing-->
    <jms:publish-consume destination="#[vars.mqMessage.attributes.targetDestination]"
        config-ref="JMS_Config">
        <jms:message>
            <jms:body>#[vars.mqMessage.payload]</jms:body>
        </jms:message>
    </jms:publish-consume>

    <!-- Use the ackToken to ACK the message -->
    <anypoint-mq:ack ackToken="#[vars.mqMessage.attributes.ackToken]"
        config-ref="Anypoint_MQ_Config" />
</flow>
```

## NACK Operation

Not acknowledging (NACK) a message informs the broker that the message was not processed
successfully and commands the broker to return the message to the queue for redelivery to any
available consumer.

The acknowledgment token `ackToken` is a unique identifier for the message that you must use when
executing the NACK operation. It is available in the `ackToken` field of the message attributes:

```xml
<flow name="consumerWithManualAck">
    <scheduler>
      <scheduling-strategy >
        <fixed-frequency />
      </scheduling-strategy>
    </scheduler>

    <!-- Consume a message -->
    <anypoint-mq:consume destination="${destination}"
           acknowledgementMode="MANUAL"
           config-ref="Anypoint_MQ_Config"
           target="mqMessage"
          targetValue="#[message]"/>

    <!--Do message processing -->
    <logger message="#[payload]"/>

    <!-- Use the ackToken to NACK the message -->
    <anypoint-mq:nack ackToken="#[vars.mqMessage.attributes.ackToken]"
    config-ref="Anypoint_MQ_Config" />
</flow>
```

## See Also

- [Anypoint MQ Consume Operation](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-consume)

- [Anypoint MQ Subscriber Source](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-listener)

<!-- document id=6fbc2bed1fee46c3e839caeea0ca6cb8f131a4c1ea006158c715ca2be726cdd0 url=/mulesoft/current/en-us/anypoint-mq-connector/latest/anypoint-mq-ack.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Anypoint MQ ACK and NACK Operations

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Acknowledging a message (ACK) informs the Anypoint MQ broker that the message has been processed and
must be removed from the queue to prevent redelivery. Not acknowledging a message (NACK) tells the
broker to not process the message and to return the message to the queue for redelivery to any
available consumer.

## Acknowledgment Modes

The Anypoint MQ connector provides three acknowledgment modes:

- Immediate

  Use Immediate when you want to acknowledge messages as your app consumes them, before processing
  them.

- Automatic

  Use Automatic to acknowledge a received message automatically only if the flow execution finishes
  successfully.

- Manual

  Use Manual if you want the app logic to control message acknowledgment.

### Immediate Acknowledgment

Use the `IMMEDIATE` acknowledgment mode to acknowledge messages as your app consumes them and before
processing them.

When Anypoint MQ acknowledges a message, it removes the message from the queue and doesn’t redeliver
it if an error occurs during processing.

If the app restarts between being acknowledged and dispatched, the message might not be available
again because it was deleted from the queue. To prevent message deletion until after processing, use
the `AUTO` or `MANUAL` acknowledgment mode instead.

If an error occurs during message processing using `IMMEDIATE` mode, Anypoint MQ throws an
`ANYPOINT-MQ:ACKING` error. To manage errors without losing messages, use a dead letter queue.

### Automatic Acknowledgment

Use the `AUTO` acknowledgment mode to acknowledge a received message automatically only if the flow
execution finishes successfully.

If an error occurs during flow execution, the message is not acknowledged (NACK) and the message is
returned to the queue for redelivery.

### Manual Acknowledgment

Use the `MANUAL` acknowledgment mode to delegate all responsibility for message acknowledgment to
the app logic.

With this configuration, every message received has an `ackToken` value that identifies this message
uniquely for a given connection.

Save this `ackToken` value to use later as input to the ACK or NACK operations.

## Acknowledgment Timeout

When using either `AUTO` or `MANUAL` acknowledgment modes, you can use the `acknowledgementTimeout`
parameter to control how long the message remains in-flight waiting to be acknowledged, before
automatically returning to the queue. The `acknowledgementTimeout` timer begins when the message is
consumed.

If `acknowledgementTimeout` is not set, Anypoint MQ Connector uses two minutes. If you need a
different TTL, you must define it explicitly in the `acknowledgementTimeout` parameter of the
subscriber.

When using `acknowledgementTimeout`, consider expected app-time processing, including time for
unexpected delays, such as external systems delay and app back-pressure due to high load. For
example, if you expect the consumed message to be processed in 10 seconds, set
`acknowledgementTimeout` to a minimum of 15 seconds.

> [!IMPORTANT] When using the `prefetch` mode in the Subscriber source, Anypoint MQ attempts to
> honor the expiration time specified by `acknowledgementTimeout`. However, Anypoint MQ extends the
> expiration timeout if the time that the message remains in the buffer reaches 80% of the timeout
> value.
>
> For this reason, don’t use `prefetch` mode if the `acknowledgementTimeout` must be honored.

### Acknowledgment Timeout — AUTO Acknowledgement Mode

After a subscriber consumes a message, a timer starts, indicating how long the message has been
in-flight for the broker waiting for acknowledgment. If the flow processing does not end with a
success or failure before the `acknowledgementTimeout` limit is reached, the message automatically
returns to the queue for redelivery.

### Acknowledgment Timeout — MANUAL Acknowledgement Mode

When consuming a message using `MANUAL` acknowledgment mode by either the Subscriber or Consume
operations, the app must execute either an ACK or NACK operation using the message `ackToken` before
the `acknowledgementTimeout` limit is reached. If neither operation executes with the given token
before the timeout, the message automatically returns to the queue for redelivery. Any attempt to
acknowledge the message after the timeout limit fails due to an expired token.

## ACK Operation — MANUAL Acknowledgement Mode

Acknowledging a message (ACK) informs the broker that the message has been processed and must be
removed from the queue to prevent redelivery.

When performing the ACK operation using Manual mode, you must use the acknowledgment token
(`ackToken`) to identify the message. It is available in the `ackToken` field of the message
attributes:

```xml
<flow name="consumerWithManualAck">
    <scheduler>
        <scheduling-strategy >
          <fixed-frequency />
        </scheduling-strategy>
    </scheduler>

    <!-- Consume a message -->
    <anypoint-mq:consume destination="${destination}"
         acknowledgementMode="MANUAL"
            config-ref="Anypoint_MQ_Config"/>

    <!-- Save the ackToken for future acknowledgment -->
    <set-variable variableName="currentAckToken"
       value="#[attributes.ackToken]"/>

    <!-- Do the required processing of the message -->
    <flow-ref name="process-message"/>

    <!-- Use the ackToken to ACK the message -->
    <anypoint-mq:ack ackToken="#[vars.currentAckToken]"
         config-ref="Anypoint_MQ_Config" />
</flow>
```

If a non-void operation is invoked during message processing, the payload and attributes of the Mule
message are modified. To perform an ACK operation after processing, you must save `ackToken` in a
variable.

To save attributes to use later, use the `target` and `targetValue` parameters to store the whole
message in a variable:

```xml
<flow name="consumerWithManualAck">
      <scheduler>
        <scheduling-strategy >
          <fixed-frequency />
        </scheduling-strategy>
      </scheduler>

    <!-- Consume a message -->
    <anypoint-mq:consume destination="${destination}"
        acknowledgementMode="MANUAL"
        config-ref="Anypoint_MQ_Config"
        target="mqMessage"
        targetValue="#[message]"/>


    <!--Do any message processing-->
    <jms:publish-consume destination="#[vars.mqMessage.attributes.targetDestination]"
        config-ref="JMS_Config">
        <jms:message>
            <jms:body>#[vars.mqMessage.payload]</jms:body>
        </jms:message>
    </jms:publish-consume>

    <!-- Use the ackToken to ACK the message -->
    <anypoint-mq:ack ackToken="#[vars.mqMessage.attributes.ackToken]"
        config-ref="Anypoint_MQ_Config" />
</flow>
```

## NACK Operation

Not acknowledging (NACK) a message informs the broker that the message was not processed
successfully and commands the broker to return the message to the queue for redelivery to any
available consumer.

The acknowledgment token `ackToken` is a unique identifier for the message that you must use when
executing the NACK operation. It is available in the `ackToken` field of the message attributes:

```xml
<flow name="consumerWithManualAck">
    <scheduler>
      <scheduling-strategy >
        <fixed-frequency />
      </scheduling-strategy>
    </scheduler>

    <!-- Consume a message -->
    <anypoint-mq:consume destination="${destination}"
           acknowledgementMode="MANUAL"
           config-ref="Anypoint_MQ_Config"
           target="mqMessage"
          targetValue="#[message]"/>

    <!--Do message processing -->
    <logger message="#[payload]"/>

    <!-- Use the ackToken to NACK the message -->
    <anypoint-mq:nack ackToken="#[vars.mqMessage.attributes.ackToken]"
    config-ref="Anypoint_MQ_Config" />
</flow>
```

## See Also

- [Anypoint MQ Consume Operation](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-consume)

- [Anypoint MQ Subscriber Source](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-listener)

<!-- document id=c11e0fff4b4d700067bac368d4b2e56e84b79c7decb08026fc471675830cade1 url=/mulesoft/current/en-us/anypoint-mq-connector/2.x/index.md -->

---
product: Anypoint MQ Connector
version: 2.x
---

# Anypoint MQ Connector 2.x

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Support Category: Select

The Anypoint MQ connector provides publish-subscribe messaging to Mule apps using the Anypoint MQ
cloud service.

Anypoint MQ supports a wide range of messaging use cases: enterprise messaging patterns,
asynchronous communications between microservices, IoT, and more. Anypoint MQ also has a REST API
for publishing or consuming messages using any framework such as node.js, Java, Go, and devops bash
scripts.

For more information, see the [Anypoint MQ Overview](https://docs.mulesoft.com/mq/).

## Before You Begin

To use this connector, you should be familiar with Anypoint Studio, Anypoint connectors, and Mule
flows. The Anypoint MQ connector is free, but connecting to the service in Anypoint Platform
requires a license. Free trial software is available.

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule Runtime Engine</p></td><td><p>4.0.0 and later</p></td></tr><tr><td><p>Anypoint Studio</p></td><td><p>7 and later</p></td></tr></tbody></table>

This documentation applies to Anypoint MQ connector 2.x only. To migrate from version 2.x to the
version 3.x, see the [Anypoint MQ 3.x Connector Migration Guide](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-new-3x-major).

## Install Anypoint MQ Connector

In Anypoint Studio:

1.  Create or open a Mule project.

2.  Click the Exchange **(X)** icon in the Studio task bar.

3.  Enter your Anypoint Platform username and password and click **Sign in**.

4.  Select **All assets** and search for "MQ"

5.  Select "Anypoint MQ Connector — Mule 4", and click **Add to project**.

6.  Follow the prompts to install the connector.

For standalone apps or apps written in XML:

1.  Open your Mule project in Anypoint Studio.

2.  Add the connector as a dependency in the pom.xml file:

    ```xml
    <dependency>
      <groupId>com.mulesoft.connectors</groupId>
      <artifactId>anypoint-mq-connector</artifactId>
      <version>x.x.x</version>
      <classifier>mule-plugin</classifier>
    </dependency>
    ```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Configure Anypoint MQ in a Mule Project

In Anypoint Studio:

1.  Install the connector, if it’s not already installed. See
    [Install Anypoint MQ Connector](#install-anypoint-mq-connector).

2.  Create or open a Mule project.

3.  Search for "mq" in the **Mule Palette** to see all the available operations for the **Anypoint
    MQ** connector.

### Create a New Configuration for the Anypoint MQ Connector

1.  Drag the operation from the palette to the canvas, then select it.

2.  Click the green plus sign to the right of **Connector configuration**.

3.  Specify the broker URL for the region you want your MQ queues and exchanges to reside.

    To obtain and configure this URL, in Anypoint Platform, select **MQ > Destinations**. See
    [Anypoint MQ Regions](https://docs.mulesoft.com/mq/mq-faq#regions) for the list of regions.

4.  In Anypoint Platform, click **MQ > Client Apps**.

    If needed, create a client app.

5.  Copy the **Client App ID** value to the **Client App ID** field in Studio.

6.  Copy the **Client Secret** value to the **Client Secret** field in Studio.

    You can ignore the other settings to test your connector.

7.  Click **Test Connection** to verify the Anypoint MQ Default subscriber.

8.  Click **OK**.

### Select an Operation

In the **Mule Palette** in Studio, click **Anypoint MQ** to display a list of available operations:

<table><colgroup><col> <col></colgroup><thead><tr><th>Operation</th><th>Description</th></tr></thead><tbody><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-publish">Publish</a></p></td><td><p>Publishes messages to a queue or message exchange.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-consume">Consume</a></p></td><td><p>Consumes messages from a queue.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-listener">Subscribe</a></p></td><td><p>Waits for messages from a queue.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-ack">ACK</a></p></td><td><p>Indicates that the message has been consumed correctly and deletes the message from in-flight status.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-ack">NACK</a></p></td><td><p>Changes the status of the message from in-flight to in-queue to be consumed again by an available consumer.</p></td></tr></tbody></table>

1.  Drag the operation from the palette to the canvas, then select it.

2.  Configure the operation accordingly.

    For a list of configuration fields for each operation and information about XML elements, see
    the [Anypoint MQ Connector Reference - 2.x](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-connector-reference).

## Example: Anypoint MQ Bridge with DataWeave

The following example illustrates the use of the Anypoint MQ connector with DataWeave to transform a
message to JSON:

```xml
<anypoint-mq:default-subscriber-config name="MQ_Configuration">
    <anypoint-mq:connection url="https://mq-us-east-1.anypoint.mulesoft.com/api/v1"
    clientId="${env.clientId}" clientSecret="${env.clientSecrete}"/>
</anypoint-mq:default-subscriber-config>

<flow name="producerFlow">
  <anypoint-mq:subscriber config="MQ_Configuration" destination="${inbound}"/>

  <http:request config-ref="Invoice_API" method="POST" path="/invoicesProcessing" >
    <http:body>#[output application/json ---
    {
        body : payload,
        origin : attributes.message.properties.orgId,
        trackingNumber : attributes.message.id
    }]</http:body>
  </http:request>
</flow>
```

## See Also

- [Anypoint MQ Overview](https://docs.mulesoft.com/mq/)

- [FAQ: Anypoint MQ](https://docs.mulesoft.com/mq/mq-faq)

- [Anypoint MQ REST APIs](https://docs.mulesoft.com/mq/mq-apis)

- [Anypoint MQ Connector on Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.connectors/anypoint-mq-connector/)

<!-- document id=5193e080678bf3dbdc23660cac6e869ffbbf49f67c636c01cbb998989fd8ecfd url=/mulesoft/current/en-us/anypoint-mq-connector/3.x/index.md -->

---
product: Anypoint MQ Connector
version: 3.x
---

# Anypoint MQ Connector 3.x — Mule 4

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Support Category: Select

The Anypoint MQ connector provides publish-subscribe messaging to Mule apps using the Anypoint MQ
cloud service.

Anypoint MQ supports a wide range of messaging use cases, such as enterprise messaging patterns,
asynchronous communications between microservices, and IoT. Anypoint MQ also has a REST API for
publishing or consuming messages using frameworks such as node.js, Java, Go, and DevOps bash
scripts.

## Requirements

To use this connector, you should be familiar with Anypoint Studio, Anypoint Connectors, and
application flows. The Anypoint MQ connector is free, but connecting to the service in Anypoint
Platform requires a license.

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.1.1 and later</p></td></tr><tr><td><p>Anypoint Studio</p></td><td><p>7 and later</p></td></tr></tbody></table>

This documentation applies to Anypoint MQ connector 3.x only. To migrate from version 2.x to the
version 3.x, see the [Anypoint MQ Connector 3.x Migration Guide](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-new-3x-major).

## Install Anypoint MQ Connector

You can use this connector with apps written in Anypoint Studio, standalone apps, or apps written in
XML.

In Anypoint Studio:

1.  Create or open a Mule project.

2.  Click the **Exchange** icon in the Studio task bar.

3.  Enter your Anypoint Platform username and password and click **Sign in**.

4.  Select **All assets** and search for "MQ".

5.  Select "Anypoint MQ Connector - Mule 4", and click **Add to project**.

6.  Follow the prompts to install the connector.

For standalone apps or apps written in XML:

1.  Open your Mule project in Anypoint Studio.

2.  Add the connector as a dependency in the pom.xml file:

    ```xml
    <dependency>
      <groupId>com.mulesoft.connectors</groupId>
      <artifactId>anypoint-mq-connector</artifactId>
      <version>x.x.x</version>
      <classifier>mule-plugin</classifier>
    </dependency>
    ```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Configure an Operation in a Mule Project

In Anypoint Studio:

1.  Install the connector, if it’s not already installed. See
    [Install Anypoint MQ Connector](#install-anypoint-mq-connector).

2.  Create or open a Mule project.

3.  Search for "mq" in the **Mule Palette**.

4.  Click **Anypoint MQ** to see the available operations for the connector.

    ![Anypoint MQ Mule Palette](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-connector-palette.png)

5.  Configure the operation accordingly.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Operation</th><th>Description</th></tr></thead><tbody><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack">ACK</a></p></td><td><p>Indicates that the message has been consumed correctly and deletes the message from In Flight status.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-consume">Consume</a></p></td><td><p>Consumes messages from a queue.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack">NACK</a></p></td><td><p>Changes the status of the message from In Flight to In Queue to be consumed again by an available consumer.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-publish">Publish</a></p></td><td><p>Publishes messages to a destination.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-listener">Subscriber</a></p></td><td><p>Listens for messages from a queue.</p></td></tr></tbody></table>

### Configure the Connection to the Default Subscriber

For each operation, you must configure a connection to a subscriber.

In Anypoint Studio:

1.  Drag the name of the operation from the **Mule Palette** to the canvas, and then select it.

2.  Click the green plus sign to the right of **Connector configuration**.

3.  In Anypoint Platform, click **MQ > Destinations**.

4.  Copy the URL for your region to the **URL** field in Studio.

5.  In Anypoint Platform, click **MQ > Client Apps**.

6.  If needed, create a client app.

7.  Copy the **Client App ID** value from Anypoint Platform to the **Client App ID** field in
    Studio.

8.  Copy the **Client Secret** value from Anypoint Platform to the **Client Secret** field in
    Studio.

9.  Click **Test Connection** to verify the Anypoint MQ Default subscriber.

10. Click **OK**.

## See Also

- [Tutorial: Create a Queue and Send Messages to It](https://docs.mulesoft.com/mq/mq-tutorial)

- [Anypoint MQ Connector Reference](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-connector-reference)

- [Anypoint MQ Overview](https://docs.mulesoft.com/mq/)

- [FAQ: Anypoint MQ](https://docs.mulesoft.com/mq/mq-faq)

- [Anypoint MQ REST APIs](https://docs.mulesoft.com/mq/mq-apis)

- [Anypoint MQ Connector in Anypoint Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.connectors/anypoint-mq-connector/)

- [Anypoint MQ Connector Release Notes for Mule 4](https://docs.mulesoft.com/release-notes/connector/anypoint-mq-connector-release-notes-mule-4)

<!-- document id=0269cb09467b8dec1e5f3cdd957b2f858865bdb550cab9864f2611b280ced807 url=/mulesoft/current/en-us/anypoint-mq-connector/3.x/anypoint-mq-new-3x-major.md -->

---
product: Anypoint MQ Connector
version: 3.x
---

# Anypoint MQ Connector 3.x Migration Guide

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint MQ Connector version 3.0 includes new features, such as simplified configuration,
standardized endpoints, and non-blocking functionality.

## Global Configuration

In version 2.x of this connector, `default-subscriber-config` includes these parameters:

```xml
<anypoint-mq:default-subscriber-config
    name="Anypoint_MQ_Default_subscriber"
    acknowledgementMode="IMMEDIATE"
    acknowledgementTimeout="10000" <!-- (1) -->
    maxRedelivery="2"              <!-- (2) -->
    pollingTime="2000"
    fetchSize="5"                  <!-- (3) -->
    fetchTimeout="5000"            <!-- (3) -->
    frequency="2000">              <!-- (3) -->
  <anypoint-mq:connection          <!-- (4) -->
    clientId="${client.id}"
    clientSecret="${client.secret}"/>
  <anypoint-mq:circuit-breaker     <!-- (5) -->
    circuitName="InvoiceSettings"
    onErrorTypes="JMS:TIMEOUT"
    errorsThreshold="10" tripTimeout="1"
    tripTimeoutUnit="MINUTES" />
</anypoint-mq:default-subscriber-config>
```

In version 3.x of this connector, the `config` element contains only the connection settings:

```xml
<anypoint-mq:config name="Anypoint_MQ_Config">
    <anypoint-mq:connection
        clientId="${client.id}"
        clientSecret="${client.secret}" />
</anypoint-mq:config>
```

This table lists the 2.x `config` elements and their 3.x equivalents.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Element</th><th>Version 2.x Behavior</th><th>Version 3.x Equivalent</th></tr></thead><tbody><tr><td><div><div><p><strong>(1)</strong> - Acknowledgment</p></div></div></td><td><div><div><p>Global acknowledgment settings for the Anypoint MQ Subscriber sources.</p></div></div></td><td><div><div><p>Configure for each Subscriber instance.</p></div></div></td></tr><tr><td><div><div><p><strong>(2)</strong> - Max Redelivery</p></div></div></td><td><div><div><p>Redelivery filter for Anypoint MQ messages located in the <code>redeliveryCount</code> header.</p></div></div></td><td><div><div><p>Deprecated and no longer available as a standalone filter. Use <code>"DLQ + Idempotent Filter"</code> pattern instead.</p></div></div></td></tr><tr><td><div><div><p><strong>(3)</strong> - Message Fetch</p></div></div></td><td><div><div><p>All parameters related to how messages are retrieved from the Anypoint MQ service, including <code>prefetch</code> configuration.</p></div></div></td><td><div><div><p>Configure all the fetching strategy parameters on each Subscriber under the <code>Subscriber Type</code> parameter.</p></div></div></td></tr><tr><td><div><div><p><strong>(4)</strong> - Connection</p></div></div></td><td><div><div><p>Connection parameters.</p></div></div></td><td><div><div><p>Idem configuration for all the connection settings.</p></div></div></td></tr><tr><td><div><div><p><strong>(5)</strong> - Circuit Breaker</p></div></div></td><td><div><div><p>Circuit Breaker configuration for the Anypoint MQ Subscriber source.</p></div></div></td><td><div><div><p>Handle each Circuit Breaker instance either as a standalone element referenced by each Anypoint MQ Subscriber or as a private Circuit Breaker for the Subscriber source that declares it.</p></div></div></td></tr></tbody></table>

## Subscriber Listener

In version 3.x of this connector, the `Subscriber` message source configuration for message
listening has changed.

For information about the new subscriber, see [Anypoint MQ Subscriber Source](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-listener).

### Message Acknowledgment

In version 2.x of this connector, the acknowledgement mode of the Subscriber source is defined at
the configuration level:

```xml
<anypoint-mq:default-subscriber-config name="Anypoint_MQ_Default_subscriber"
       acknowledgementMode="MANUAL" acknowledgementTimeout="120000">
    <anypoint-mq:connection clientId="${client.id}" clientSecret="${client.secret}"/>
</anypoint-mq:default-subscriber-config>
```

In version 3.x, these parameters are part of the Subscriber source itself and affect only that
single Subscriber instance. The semantics of the acknowledgment parameters has not changed. Here’s
the equivalent configuration of the Subscriber source:

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config"
    destination="queue"
    acknowledgementMode="MANUAL"
    acknowledgementTimeout="2"
    acknowledgementTimeoutUnit="MINUTES"/>
```

### Prefetch Mode

In version 2.x of this connector, `prefetch` mode is enabled by default and you specified all
related parameters at the configuration level:

```xml
<anypoint-mq:default-subscriber-config
      name="Anypoint_MQ_Default_subscriber"
      pollingTime="2000" fetchSize="5"
      fetchTimeout="5000" frequency="2000">
    <anypoint-mq:connection clientId="${client.id}"
      clientSecret="${client.secret}"/>
</anypoint-mq:default-subscriber-config>
```

Version 3.x includes a new concept called `Subscriber Type`, in which you control the `prefetch`
configuration.

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config"
    destination="queue">
   <anypoint-mq:subscriber-type>
     <anypoint-mq:prefetch maxLocalMessages="20"/>
   </anypoint-mq:subscriber-type>
</anypoint-mq:subscriber>
```

This table lists the 2.x `prefetch` parameters and their 3.x equivalents.

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Version 2.x Parameter</th><th>Description</th><th>Version 3.x Equivalent</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>fetchSize</code></p></div></div></td><td><div><div><p>Declared at the <code>config</code> level, controls the size of the local message buffer, which is calculated as three times the <code>fetchSize</code> value.</p></div></div></td><td><div><div><p><code>maxLocalMessages</code></p></div></div></td><td><div><div><p>Declared at the <code>Subscriber</code> level, explicitly controls the maximum size that the local message buffer can have. This parameter serves as a target number, attempting to fetch as many messages as needed to fill the buffer completely.</p></div><div><p>When using <code>prefetch</code> mode, set <code>maxLocalMessages</code> to a value greater than <code>1</code> to avoid message-processing latency issues. When <code>maxLocalMessages</code> is set to <code>1</code>, latency can occur when the connector prefetches the message but the app doesn’t consume it, and the message returns to the queue for reprocessing.</p></div></div></td></tr><tr><td><div><div><p><code>fetchTimeout</code></p></div></div></td><td><div><div><p>Controls the time waiting for a response from the service.</p></div></div></td><td><div><div><p>Deprecated</p></div></div></td><td><div><div><p>This parameter is no longer available. The connector always uses the maximum long-polling value.</p></div></div></td></tr><tr><td><div><div><p><code>frequency</code></p></div></div></td><td><div><div><p>Controls when to recheck for messages after the queue is empty.</p></div></div></td><td><div><div><p>Deprecated</p></div></div></td><td><div><div><p>This parameter is no longer available. The connector handles the frequency internally, fixed at 1 second.</p></div></div></td></tr><tr><td><div><div><p><code>pollingTime</code></p></div></div></td><td><div><div><p>Used only when <code>fetchSize</code> is <code>0</code>, effectively disabling the <code>prefetch</code> mode and enabling <code>polling</code> mode.</p></div></div></td><td><div><div><p>Deprecated</p></div></div></td><td><div><div><p>This parameter is replaced by the more powerful <code>polling</code> subscriber type.</p></div></div></td></tr></tbody></table>

### Polling Mode

Version 2.x of the Anypoint MQ Connector allowed you to disable the `prefetch` mode by setting the
`fetchSize` parameter to `0` and then using `pollingTime` as a fixed-frequency polling scheduler.

In version 3.x of this connector, the polling mode of the Subscriber source is simplified and
normalized. You can use the schedulers provided by Mule runtime engine out of the box, either as
`fixed-frequency` or `cron`:

- `fixed-frequency`

  ```xml
  <anypoint-mq:subscriber config-ref="Anypoint_MQ_Config"
    destination="queue">
     <anypoint-mq:subscriber-type >
        <anypoint-mq:polling fetchSize="9">
           <scheduling-strategy >
              <fixed-frequency frequency="1" timeUnit="SECONDS" />
           </scheduling-strategy>
        </anypoint-mq:polling>
     </anypoint-mq:subscriber-type>
  </anypoint-mq:subscriber>
  ```

- `cron`

  ```xml
  <anypoint-mq:subscriber destination="queue"
      config-ref="Anypoint_MQ_Config">
      <anypoint-mq:subscriber-type>
          <anypoint-mq:polling fetchSize="9">
              <scheduling-strategy>
                  <cron expression="0 * 14 * * ?"
                  timeZone="America/Los_Angeles"/>
              </scheduling-strategy>
          </anypoint-mq:polling>
      </anypoint-mq:subscriber-type>
  </anypoint-mq:subscriber>
  ```

This table lists the 2.x `polling` parameters and their 3.x equivalents.

<table><colgroup><col> <col> <col> <col></colgroup><thead><tr><th>Version 2.x Parameter</th><th>Description</th><th>Version 3.x Equivalent</th><th>Description</th></tr></thead><tbody><tr><td><div><div><p><code>fetchSize</code></p></div></div></td><td><div><div><p>Declared at the <code>config</code> level, controls the size of the local message buffer, which is calculated as three times the <code>fetchSize</code> value.</p></div></div></td><td><div><div><p><code>fetchSize</code></p></div></div></td><td><div><div><p>Declared at the <code>Subscriber</code> level, sets the maximum number (1-10) of messages to fetch on each polling execution. The default is 10.</p></div></div></td></tr><tr><td><div><div><p><code>fetchTimeout</code></p></div></div></td><td><div><div><p>Limits the wait time for a response from the service.</p></div></div></td><td><div><div><p>Deprecated</p></div></div></td><td><div><div><p>This parameter is no longer available. The connector always uses the maximum long-polling value.</p></div></div></td></tr><tr><td><div><div><p><code>frequency</code></p></div></div></td><td><div><div><p>Controls when to recheck for messages after the queue is empty.</p></div></div></td><td><div><div><p>Deprecated</p></div></div></td><td><div><div><p>This parameter is no longer available. The connector uses a fixed frequency of 1 second.</p></div></div></td></tr><tr><td><div><div><p><code>pollingTime</code></p></div></div></td><td><div><div><p>Used only when <code>fetchSize</code> is <code>0</code>, effectively disabling the <code>prefetch</code> mode and enabling <code>polling</code> mode.</p></div></div></td><td><div><div><p>Deprecated</p></div></div></td><td><div><div><p>This parameter is replaced by the more powerful <code>polling</code> subscriber type.</p></div></div></td></tr></tbody></table>

### Circuit Breaker

The circuit breaker declaration is no longer in `default-subscriber-config` and is either a global
element or an inline declaration.

In version 2.x of this connector, you declared the circuit breaker as part of the Subscriber
configuration and then referenced it across multiple Subscriber sources.

```xml
<anypoint-mq:default-subscriber-config name="ConfigWithCircuit" >
     <anypoint-mq:connection url="${providerUrl}"
       clientId="${clientId}"
      clientSecret="${clientSecret}"/>
   <anypoint-mq:circuit-breaker
       circuitName="InvoiceProcess"
       onErrorTypes="FTP:RETRY_EXHAUSTED, HTTP:SERVICE_UNAVAILABLE"
       errorsThreshold="10"
       tripTimeout="5"
       tripTimeoutUnit="MINUTES"/>
</anypoint-mq:default-subscriber-config>

<flow name="subscribe">
    <anypoint-mq:subscriber
        config-ref="ConfigWithCircuit"
        destination="${reservationsQueue}"/>
    <flow-ref name="invoiceProcess">
</flow>

<flow name="otherSubscribe">
    <anypoint-mq:subscriber
        config-ref="ConfigWithCircuit"
        destination="${paymentsQueue}"/>
    <flow-ref name="invoiceProcess">
</flow>

<sub-flow name="invoiceProcess">
  <ftp:write path="${auditFolder}" config-ref="ftp-config"/>
  <http:request config-ref="requestConfig" path="/external"/>
</sub-flow>
```

In version 3.x of this connector, you declare one standalone global element, and reference that
global element from each subscriber, no longer binding a connection to the app logic circuit:

```xml
<anypoint-mq:config name="Anypoint_MQ_Config">
    <anypoint-mq:connection url="${providerUrl}"
       clientId="${clientId}"
       clientSecret="${clientSecret}"/>
</anypoint-mq:config>

<anypoint-mq:circuit-breaker
    name="InvoiceProcess"
    onErrorTypes="FTP:RETRY_EXHAUSTED, HTTP:SERVICE_UNAVAILABLE"
    errorsThreshold="10"
    tripTimeout="5"
    tripTimeoutUnit="MINUTES"/>

<flow name="subscribe">
    <anypoint-mq:subscriber
        destination="${reservationsQueue}"
        config-ref="Anypoint_MQ_Config"
        circuitBreaker="GlobalCircuit"/>
    <flow-ref name="invoiceProcess">
</flow>

<flow name="otherSubscribe">
    <anypoint-mq:subscriber
        destination="${paymentsQueue}"
        config-ref="Anypoint_MQ_Config"
        circuitBreaker="GlobalCircuit"/>
    <flow-ref name="invoiceProcess">
</flow>

<sub-flow name="invoiceProcess">
  <ftp:write path="${auditFolder}" config-ref="ftp-config"/>
  <http:request config-ref="requestConfig" path="/external"/>
</sub-flow>
```

## Publish Operation

In version 2.x of this connector, Publish operation properties are declared like this:

```xml
<anypoint-mq:publish config-ref="Anypoint_MQ_Default_subscriber"
       destination="queue"
       messageId="#[vars.messageId]" sendContentType="false">
   <anypoint-mq:body >#[vars.messageBody]</anypoint-mq:body>
   <anypoint-mq:properties >
      <anypoint-mq:property key="MSG_TYPE" value="My Value"/>
   </anypoint-mq:properties>
</anypoint-mq:publish>
```

In version 3.x, you declare the same properties as a dynamic map, subject to transformations and a
dynamic number of keys, instead of having fixed keys for each message:

```xml
<anypoint-mq:publish config-ref="Anypoint_MQ_Config"
     destination="queue"
     messageId="#[vars.currentId]" sendContentType="false">
   <anypoint-mq:body >#[vars.messageBody]</anypoint-mq:body>
   <anypoint-mq:properties ><![CDATA[#[output application/java -----
{
   "MSG_TYPE" : vars.msgType
}]]]></anypoint-mq:properties>
</anypoint-mq:publish>
```

This table lists the 2.x Publish operation and its 3.x equivalents.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Changes</th><th>Version 2.x</th><th>Version 3.x</th></tr></thead><tbody><tr><td><p>Execution Type</p></td><td><p>Blocking</p></td><td><p>Non-Blocking</p></td></tr><tr><td><p>Properties Parameter</p></td><td><p>Fixed key-value map</p></td><td><p>Dynamic "content" parameter map</p></td></tr></tbody></table>

For more information, see [Anypoint MQ Publish Operation](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-publish)

## Consume Operation

This table lists the 2.x Consume operation and its 3.x equivalents.

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Changes</th><th>Version 2.x</th><th>Version 3.x</th></tr></thead><tbody><tr><td><p>Execution Type</p></td><td><p>Blocking</p></td><td><p>Non-Blocking</p></td></tr><tr><td><p>Default Acknowledgment Mode</p></td><td><p>MANUAL</p></td><td><p>IMMEDIATE</p></td></tr></tbody></table>

For more information, see [Anypoint MQ Consume Operation](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-consume).

## ACK and NACK Operations

The ACK and NACK operations use the `ackToken` string.

You can obtain `ackToken` from the `attributes` element. The `ackToken` value is available only for
messages that have a `MANUAL` acknowledgment mode.

This table lists the 2.x ACK and NACK operations and their 3.x equivalents.

<table><colgroup><col> <col></colgroup><thead><tr><th>Version 2.x</th><th>Version 3.x</th></tr></thead><tbody><tr><td><p>Operations received a <code>messageContext</code> parameter, whose value had to be the <code>attributes</code> element from a given message.</p></td><td><p>The <code>ackToken</code> string of the message for performing ACK or NACK of a message.</p></td></tr></tbody></table>

For more information, see [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack).

## Platform Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule Runtime Engine</p></td><td><p>4.1.1 and later</p></td></tr><tr><td><p>Anypoint Studio</p></td><td><p>v7 and later</p></td></tr></tbody></table>

<!-- document id=09d0a9feeec0086cedd4b61bdc4126b79b15dcd9f0505afc29592f286bd01c93 url=/mulesoft/current/en-us/anypoint-mq-connector/latest/index.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Anypoint MQ Connector Overview

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint Connector for Anypoint MQ (Anypoint MQ Connector) provides publish-subscribe messaging to
Mule apps using the Anypoint MQ cloud service.

Anypoint MQ supports a wide range of messaging use cases, such as enterprise messaging patterns,
asynchronous communications between microservices, and IoT. Anypoint MQ also has a REST API for
publishing or consuming messages using frameworks such as node.js, Java, Go, and DevOps bash
scripts.

## Requirements

To use this connector, you must be familiar with Anypoint Studio, Anypoint Connectors, and
application flows. Anypoint MQ Connector is free, but connecting to the service in Anypoint Platform
requires a license.

### Compatibility

<table><colgroup><col> <col></colgroup><thead><tr><th>Software</th><th>Version</th></tr></thead><tbody><tr><td><p>Mule runtime engine</p></td><td><p>4.1.1 and later</p></td></tr><tr><td><p>Anypoint Studio</p></td><td><p>7 and later</p></td></tr></tbody></table>

This documentation applies to Anypoint MQ Connector 4.x only. To migrate from version 3.x to the
version 4.x, see
[Upgrading and Migrating Anypoint MQ Connector](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-connector-upgrade-migrate).

## Install Anypoint MQ Connector

You can use this connector with apps written in Anypoint Studio, standalone apps, or apps written in
XML.

In Anypoint Studio:

1.  Create or open a Mule project.

2.  Click the **Exchange** icon in the Studio task bar.

3.  Enter your Anypoint Platform username and password and click **Sign in**.

4.  Select **All assets** and search for `MQ`.

5.  Select **Anypoint MQ Connector - Mule 4**, and click **Add to project**.

6.  Follow the prompts to install the connector.

For standalone apps or apps written in XML:

1.  Open your Mule project in Anypoint Studio.

2.  Add the connector as a dependency in the `pom.xml` file:

    ```xml
    <dependency>
      <groupId>com.mulesoft.connectors</groupId>
      <artifactId>anypoint-mq-connector</artifactId>
      <version>x.x.x</version>
      <classifier>mule-plugin</classifier>
    </dependency>
    ```

Replace `x.x.x` with the version that corresponds to the connector you are using.

To obtain the most up-to-date `pom.xml` file information, access the connector in
[Anypoint Exchange](https://www.mulesoft.com/exchange/) and click **Dependency Snippets**.

## Configure an Operation in a Mule Project

In Anypoint Studio:

1.  Install the connector, if it’s not already installed.

    See [Install Anypoint MQ Connector](#install-mq-connector).

2.  Create or open a Mule project.

3.  Search for `mq` in the **Mule Palette**.

4.  Click **Anypoint MQ** to see the available operations for the connector.

    ![The Mule Palette with Anypoint MQ Connector selected,  displaying the available operations](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-connector-palette.png)

5.  Configure the operation accordingly.

    <table><colgroup><col> <col></colgroup><thead><tr><th>Operation</th><th>Description</th></tr></thead><tbody><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack">ACK</a></p></td><td><p>Indicates that the message was consumed correctly and deletes the message from <code>In Flight</code> status.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-consume">Consume</a></p></td><td><p>Consumes messages from a queue.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack">NACK</a></p></td><td><p>Changes the status of the message from <code>In Flight</code> to <code>In Queue</code> to be consumed again by an available consumer.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-publish">Publish</a></p></td><td><p>Publishes messages to a destination.</p></td></tr><tr><td><p><a href="https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-listener">Subscriber</a></p></td><td><p>Listens for messages from a queue.</p></td></tr></tbody></table>

### Configure the Connection to the Default Subscriber

For each operation, you must configure a connection to a subscriber.

1.  In Anypoint Studio, drag the name of the operation from the **Mule Palette** to the canvas, and
    then select it.

2.  Click the green plus sign for **Connector configuration**.

3.  In Anypoint Platform, click **MQ > Destinations**.

4.  Click **Copy** and select **Connector version 4.x and later** from the menu:

    ![Copy button and menu with connector version options](/mulesoft/current/en-us/mq/_images/mq-tutorial-url.png)

5.  In Anypoint Studio, in the **Anypoint MQ Config** window, paste the URL in the **URL** field.

6.  In Anypoint MQ, click **MQ > Client Apps**.

    If needed, create a client app.

7.  Click the client app name to display the details pane.

8.  Copy the client app ID and client secret values from the details pane to the **Anypoint MQ
    Config** window in Studio:

    ![Global Element properties, including URL, client app ID, and client secret](/mulesoft/current/en-us/mq/_images/mq-tutorial-studio7-mq-config.png)

9.  Click **Test Connection** to verify the Anypoint MQ Default subscriber.

10. Click **OK**.

For more information, see
[Create and Connect a Mule 4 App to Anypoint MQ in Anypoint Studio 7](https://docs.mulesoft.com/mq/mq-tutorial#configure-mule-4-studio)
in the [Anypoint MQ Tutorial](https://docs.mulesoft.com/mq/mq-tutorial).

## See Also

- [Tutorial: Create a Queue and Send Messages to It](https://docs.mulesoft.com/mq/mq-tutorial)

- [FAQ: Anypoint MQ](https://docs.mulesoft.com/mq/mq-faq)

- [Anypoint MQ REST APIs](https://docs.mulesoft.com/mq/mq-apis)

- [Anypoint MQ Connector in Anypoint Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.connectors/anypoint-mq-connector/)

- [Anypoint MQ Connector Release Notes for Mule 4](https://docs.mulesoft.com/release-notes/connector/anypoint-mq-connector-release-notes-mule-4)

<!-- document id=f974c7956d0fe261a3d2f34cb8ff585760aef51e9b4e42e7d2b4025f0cb08d72 url=/mulesoft/current/en-us/anypoint-mq-connector/3.x/anypoint-mq-connector-reference.md -->

---
product: Anypoint MQ Connector
version: 3.x
---

# Anypoint MQ Connector Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Support Version: Select

Anypoint MQ Connector Version 3.x

Anypoint MQ is a multi-tenant, cloud messaging service that enables customers to perform advanced
asynchronous messaging among their applications.

## Configurations

---

### Config

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Name</p></td><td><p>String</p></td><td><p>Specifies the name for this configuration. Connectors refer to the configuration by using this name.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Connection</p></td><td><div><div><p><a href="#config_connection">Connection</a></p></div></div></td><td><p>Specifies the connection types to provide to this configuration.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Expiration Policy</p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before the runtime considers it eligible for purging. The platform purges expired instances as needed to free resources.</p></td><td></td><td></td></tr></tbody></table>

#### Connection Types

##### Connection

###### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>URL</p></td><td><div><div><p>String</p></div></div></td><td><p>The region URL for the queue from the <strong>Anypoint Platform &gt; MQ</strong> console</p></td><td><p>https://mq-us-east-1.anypoint.mulesoft.com/api/v1</p></td><td></td></tr><tr><td><p>Client App ID</p></td><td><div><div><p>String</p></div></div></td><td><p>The Client App ID from <strong>Anypoint Platform &gt; MQ &gt; Client Apps</strong></p></td><td></td><td><p>x</p></td></tr><tr><td><p>Client Secret</p></td><td><div><div><p>String</p></div></div></td><td><p>The Client Secret field from <strong>Anypoint Platform &gt; MQ &gt; Client Apps</strong></p></td><td></td><td><p>x</p></td></tr><tr><td><p>TLS Context</p></td><td><div><div><p><a href="#Tls">Tls</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Host</p></td><td><div><div><p>String</p></div></div></td><td><p>Destination host for proxy requests</p></td><td></td><td></td></tr><tr><td><p>Port</p></td><td><div><div><p>Number</p></div></div></td><td><p>Destination port for proxy requests</p></td><td></td><td></td></tr><tr><td><p>Username</p></td><td><div><div><p>String</p></div></div></td><td><p>Username to authenticate against the proxy</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password to authenticate against the proxy</p></td><td></td><td></td></tr><tr><td><p>Send Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Size of the buffer (in bytes) used when sending data, set on the socket itself</p></td><td></td><td></td></tr><tr><td><p>Receive Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Size of the buffer (in bytes) used when receiving data</p></td><td></td><td></td></tr><tr><td><p>Client Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>SO_TIMEOUT value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) indicates an indefinite wait.</p></td><td></td><td></td></tr><tr><td><p>Send TCP With No Delay</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>If set, transmitted data is not grouped but sent immediately. Defaults to true.</p></td><td><p>true</p></td><td></td></tr><tr><td><p>Linger</p></td><td><div><div><p>Number</p></div></div></td><td><p>SO_LINGER value, which determines how long (in milliseconds) the socket takes to close so that any remaining data is transmitted correctly</p></td><td></td><td></td></tr><tr><td><p>Keep Alive</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>SO_KEEPALIVE behavior on open sockets, which automatically checks open socket connections that are unused for long periods, and closes them if the connection becomes unavailable. This is a property on the socket itself and is used by a server socket to control whether connections to the server are kept alive before they are recycled.</p></td><td><p>false</p></td><td></td></tr><tr><td><p>Connection Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Number of milliseconds to wait until an outbound connection to a remote server is successfully created, before failing with a timeout. Defaults to 30 seconds.</p></td><td><p>30000</p></td><td></td></tr><tr><td><p>Reconnection</p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the deployment connectivity test to each connector fails.</p></td><td></td><td></td></tr></tbody></table>

## Operations

- [Ack](#ack)

- [Consume](#consume)

- [Nack](#nack)

- [Publish](#publish)

### Associated Sources

- [Subscriber](#subscriber)

### Ack

`<anypoint-mq:ack>`

Executes an acknowledgment indicating that the message is consumed correctly and deletes the message
from In Flight status.

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Ack Token</p></td><td><div><div><p>String</p></div></div></td><td><p>Acknowledgment token used to perform manual ACK and NACK operations, in MANUAL mode only</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:ACKING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

### Consume

`<anypoint-mq:consume>`

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Queue</p></td><td><div><div><p>String</p></div></div></td><td><p>Queue or Exchange name from which to fetch a message</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Acknowledgment Mode</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>IMMEDIATE</p></li><li><p>MANUAL</p></li></ul></div></div></td><td><p>Acknowledgment mode to use for the messages retrieved</p></td><td><p>IMMEDIATE</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Duration that a message is held by a consumer waiting for an acknowledgment or not acknowledgment. After that duration elapses, the message is again available to any consumer.</p></td><td><p>0</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>Time unit to use in the acknowledgmentTimeout configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Polling Time</p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for a message to be ready for consumption (0-20000).</p></div><div><ul><li><p>If this value is greater than 0 and no message arrives, the connector throws a <code>ANYPOINT-MQ:TIMEOUT</code> exception.</p></li><li><p>If this value is 0 and no message arrives, the connector returns <code>NULL</code> and doesn’t throw the <code>ANYPOINT-MQ:TIMEOUT</code> exception.</p></li></ul></div></div></td><td><p>10000</p></td><td></td></tr><tr><td><p>Polling Time Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>Time unit to use in the pollingTime configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of the operation output</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>Encoding of the operation output</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Use repeatable streams</p></td><td></td><td></td></tr><tr><td><p>Target Variable</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of a variable to store the operation’s output</p></td><td></td><td></td></tr><tr><td><p>Target Value</p></td><td><div><div><p>String</p></div></div></td><td><p>Expression to evaluate against the operation’s output and store the expression outcome in the target variable</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMQMessageAttributes">Anypoint MQ Message Attributes</a></p></div></div></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:ACKING

- ANYPOINT-MQ:CONSUMING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:TIMEOUT

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

### Nack

`<anypoint-mq:nack>`

Executes a not acknowledgment and changes the status of the message from In Flight to In Queue for
subscriber consumption

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Ack Token</p></td><td><div><div><p>String</p></div></div></td><td><p>Acknowledgment token used to perform manual ACK and NACK operations, in MANUAL mode only</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:NACKING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

### Publish

`<anypoint-mq:publish>`

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Destination</p></td><td><div><div><p>String</p></div></div></td><td><p>Queue or Exchange name from which to fetch a message</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of the operation output</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>The encoding of the operation output</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Use repeatable streams</p></td><td></td><td></td></tr><tr><td><p>Body</p></td><td><div><div><p>Binary</p></div></div></td><td><p>Body of the outgoing message, sent as a string as part of a JSON message. Any content that is published must be capable of being serialized to and deserialized from string format. Sending Objects that don’t have a proper string serialization causes the message to be unreadable on the receiving end.</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>User Properties</p></td><td><div><div><p>Object</p></div></div></td><td><p>Custom user properties set to the message</p></td><td></td><td></td></tr><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>Valid custom user ID for the outgoing message. If not specified, the broker creates one.</p></td><td></td><td></td></tr><tr><td><p>Message Group Id</p></td><td><div><div><p>String</p></div></div></td><td><p>ID of the message group to which the published message belongs. Specify only for FIFO queues.</p><p>Message group IDs can contain up to 128 alphanumeric characters (a-z, A-Z, 0-9) and punctuation (! " # $ % &amp; ' ( ) * + , - . / : ; &lt; = &gt; ? @ [ ] \ ^ _ ` { } | ~).</p></td><td></td><td></td></tr><tr><td><p>Delivery Delay</p></td><td><div><div><p>Number</p></div></div></td><td><p>Time to postpone delivery of the message before consumption: between 0 and 15 minutes.</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Delivery Delay Unit</p></td><td><div><div><p>Enumeration</p></div></div></td><td><div><div><p>Time unit to use in the <code>Delivery Delay</code> parameter:</p></div><div><ul><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li></ul></div></div></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Send Content-Type</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Set to true if the body type should be sent as an Anypoint MQ Message property</p></td><td><p>true</p></td><td></td></tr><tr><td><p>Target Variable</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of a variable to store the operation output</p></td><td></td><td></td></tr><tr><td><p>Target Value</p></td><td><div><div><p>String</p></div></div></td><td><p>Expression to evaluate against the operation output. The expression outcome is stored in the target variable</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMQMessagePublishAttributes">Anypoint MQ Message Publish Attributes</a></p></div></div></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:PUBLISHING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:ILLEGAL\_BODY

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

## Sources

### Subscriber

`<anypoint-mq:subscriber>`

Anypoint MQ Subscriber Message Source retrieves messages from the given destination name.

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Queue</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of the queue from which messages are retrieved</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Subscriber Type</p></td><td><div><div><p>One of:</p></div><div><ul><li><p><a href="#polling">Polling</a></p></li><li><p><a href="#prefetch">Prefetch</a></p></li></ul></div></div></td><td><p>Strategy to use when subscribing to messages from the service</p></td><td></td><td></td></tr><tr><td><p>Acknowledgment Mode</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>IMMEDIATE</p></li><li><p>AUTO</p></li><li><p>MANUAL</p></li></ul></div></div></td><td><p>Acknowledgment mode to use for the messages retrieved</p></td><td><p>AUTO</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Duration that a message is held by a broker waiting for an acknowledgment or not acknowledgment before being made available to any subscriber. Specifies the default <code>acknowledgmentTimeout</code> value for all Subscriber sources, unless it is overridden. The maximum value of this parameter is 12 hours.</p></td><td><p>If <code>acknowledgementTimeout</code> is not set (the default), the connector uses the TTL value of at least two minutes.</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>Time unit to use in the acknowledgmentTimeout configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Circuit Breaker</p></td><td><div><div><p><a href="#circuitBreaker">Circuit Breaker</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of the operation output</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>Encoding of the operation output</p></td><td></td><td></td></tr><tr><td><p>Primary Node Only</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Whether this source should only be executed on the primary node when running in a cluster</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Use repeatable streams</p></td><td></td><td></td></tr><tr><td><p>Redelivery Policy</p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><p>Message redelivery policy</p></td><td></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMQMessageAttributes">Anypoint MQ Message Attributes</a></p></div></div></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

## Types

### Tls

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Enabled Protocols</p></td><td><div><div><p>String</p></div></div></td><td><p>Comma-separated list of protocols enabled for this context</p></td><td></td><td></td></tr><tr><td><p>Enabled Cipher Suites</p></td><td><div><div><p>String</p></div></div></td><td><p>Comma-separated list of cipher suites enabled for this context</p></td><td></td><td></td></tr><tr><td><p>Trust Store</p></td><td><div><div><p><a href="#TrustStore">Trust Store</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Key Store</p></td><td><div><div><p><a href="#KeyStore">Key Store</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Revocation Check</p></td><td><div><div><ul><li><p><a href="#standard-revocation-check">Standard Revocation Check</a></p></li><li><p><a href="#custom-ocsp-responder">Custom OCSP Responder</a></p></li><li><p><a href="#crl-file">CRL File</a></p></li></ul></div></div></td><td></td><td></td><td></td></tr></tbody></table>

### Trust Store

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>Location of the trust store, resolved relative to the current classpath and file system, if possible</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password used to protect the trust store</p></td><td></td><td></td></tr><tr><td><p>Type</p></td><td><div><div><p>String</p></div></div></td><td><p>Type of store used</p></td><td></td><td></td></tr><tr><td><p>Algorithm</p></td><td><div><div><p>String</p></div></div></td><td><p>Algorithm used by the trust store</p></td><td></td><td></td></tr><tr><td><p>Insecure</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>If true, no certificate validations are performed, rendering connections vulnerable to attacks. Use at your own risk.</p></td><td></td><td></td></tr></tbody></table>

### Key Store

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>Location of the key store, resolved relative to the current classpath and file system, if possible</p></td><td></td><td></td></tr><tr><td><p>Type</p></td><td><div><div><p>String</p></div></div></td><td><p>Type of store used</p></td><td></td><td></td></tr><tr><td><p>Alias</p></td><td><div><div><p>String</p></div></div></td><td><p>When the key store contains many private keys, indicates the alias of the key that is used. If not defined, the first key in the file is used by default.</p></td><td></td><td></td></tr><tr><td><p>Key Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password used to protect the private key</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password used to protect the key store</p></td><td></td><td></td></tr><tr><td><p>Algorithm</p></td><td><div><div><p>String</p></div></div></td><td><p>Algorithm used by the key store</p></td><td></td><td></td></tr></tbody></table>

### Standard Revocation Check

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Only End Entities</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Verifies only the last element in the certificate chain</p></td><td></td><td></td></tr><tr><td><p>Prefer Crls</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Uses CRL-signing certificates before using OCSP-signing certificate</p></td><td></td><td></td></tr><tr><td><p>No Fallback</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Doesn’t use the secondary checking method (the one not selected for Prefer Crls)</p></td><td></td><td></td></tr><tr><td><p>Soft Fail</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Avoids verification failure when the revocation server cannot be reached or is busy</p></td><td></td><td></td></tr></tbody></table>

### Custom OCSP Responder

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Url</p></td><td><div><div><p>String</p></div></div></td><td><p>URL of the OCSP responder</p></td><td></td><td></td></tr><tr><td><p>Cert Alias</p></td><td><div><div><p>String</p></div></div></td><td><p>Alias of the signing certificate for the OCSP response, if present. The signing certificate must be in the trust store.</p></td><td></td><td></td></tr></tbody></table>

### CRL File

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>Path to the CRL file</p></td><td></td><td></td></tr></tbody></table>

### Reconnection

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Fails Deployment</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the deployment connectivity test to each connector fails.</p></td><td></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Reconnection strategy to use</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

### Reconnect

> [!NOTE] Anypoint MQ Connector doesn’t support this parameter. For more information, see
> [Can I use a retry strategy with the Anypoint MQ connector?](https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector)

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>How often to reconnect, in milliseconds</p></td><td></td><td></td></tr><tr><td><p>Count</p></td><td><div><div><p>Number</p></div></div></td><td><p>How many reconnection attempts to make</p></td><td></td><td></td></tr><tr><td><p>blocking</p></td><td><p>Boolean</p></td><td><p>If false, the reconnection strategy runs in a separate, non-blocking thread</p></td><td><p>true</p></td><td></td></tr></tbody></table>

### Reconnect Forever

> [!NOTE] Anypoint MQ Connector doesn’t support this parameter. For more information, see
> [Can I use a retry strategy with the Anypoint MQ connector?](https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector)

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>How often to reconnect, in milliseconds</p></td><td></td><td></td></tr><tr><td><p>blocking</p></td><td><p>Boolean</p></td><td><p>If false, the reconnection strategy runs in a separate, non-blocking thread</p></td><td><p>true</p></td><td></td></tr></tbody></table>

### Expiration Policy

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max Idle Time</p></td><td><div><div><p>Number</p></div></div></td><td><p>A scalar time value for the maximum amount of time a dynamic configuration instance should be allowed to be idle before it’s considered eligible for expiration</p></td><td></td><td></td></tr><tr><td><p>Time Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>A time unit that qualifies the maxIdleTime attribute</p></td><td></td><td></td></tr></tbody></table>

### Anypoint MQ Message Attributes

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Destination</p></td><td><div><div><p>String</p></div></div></td><td><p>Message destination</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Headers</p></td><td><div><div><p>Object</p></div></div></td><td><p>Message headers</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Properties</p></td><td><div><div><p>Object</p></div></div></td><td><p>Message properties</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>ID of the message</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Delivery Count</p></td><td><div><div><p>Number</p></div></div></td><td><p>Number of times the message was delivered</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Content Type</p></td><td><div><div><p>String</p></div></div></td><td><p>Content type of the message body</p></td><td></td><td></td></tr><tr><td><p>Ack Token</p></td><td><div><div><p>String</p></div></div></td><td><p>Acknowledgment token used to perform manual ACK and NACK operations, in MANUAL mode only</p></td><td></td><td></td></tr></tbody></table>

### Circuit Breaker

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>On Error Types</p></td><td><div><div><p>String</p></div></div></td><td><p>Error types that equal failure of the circuit when they occur during flow execution. By default, all errors result in failure.</p></td><td></td><td></td></tr><tr><td><p>Errors Threshold</p></td><td><div><div><p>Number</p></div></div></td><td><p>Of the errors considered by the circuit, how many must occur for the circuit to be opened.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Trip Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>How long the circuit remains open after <code>errorsThreshold</code> is reached</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Trip Timeout Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>The time unit bound to the tripTimeout value</p></td><td><p>MILLISECONDS</p></td><td></td></tr></tbody></table>

### Repeatable In Memory Stream

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Initial Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>The amount of memory allocated to consume the stream and provide random access to it. If the stream contains more data than can fit into this buffer, then the buffer expands according to the bufferSizeIncrement attribute, with an upper limit of maxInMemorySize.</p></td><td></td><td></td></tr><tr><td><p>Buffer Size Increment</p></td><td><div><div><p>Number</p></div></div></td><td><p>How much buffer size can expand. If set to 0 (zero) or less, STREAM_MAXIMUM_SIZE_EXCEEDED is raised when the buffer is full.</p></td><td></td><td></td></tr><tr><td><p>Max Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum amount of memory to use before STREAM_MAXIMUM_SIZE_EXCEEDED is raised. If set to 0 (zero) or less, memory is unlimited.</p></td><td></td><td></td></tr><tr><td><p>Buffer Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><p>Unit in which all these attributes are expressed</p></td><td></td><td></td></tr></tbody></table>

### Repeatable File Store Stream

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max In Memory Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum amount of memory that the stream can hold locally before content is buffered to disk</p></td><td></td><td></td></tr><tr><td><p>Buffer Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><p>Unit in which maxInMemorySize is expressed</p></td><td></td><td></td></tr></tbody></table>

### Redelivery Policy

For information on the redelivery policy, see
[Configure a Redelivery Policy](https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy).

### Anypoint MQ Message Publish Attributes

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>ID of the message that was published</p></td><td></td><td><p>x</p></td></tr></tbody></table>

### Prefetch

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max Local Messages</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum number of messages to prefetch from the service and keep locally before dispatching to the flow</p><p>NOTE: Due to a known issue, using <code>prefetch</code> mode with <code>maxConcurrency="1"</code> set on the <code>flow</code> element might result in message-processing latency.</p><p>When using <code>prefetch</code> mode, set <code>maxLocalMessages</code> to a value greater than <code>1</code> to avoid message-processing latency issues. When <code>maxLocalMessages</code> is set to <code>1</code>, latency can occur when the connector prefetches the message but the app doesn’t consume it, and the message returns to the queue for reprocessing.</p></td><td><p>30</p></td><td></td></tr></tbody></table>

### Polling

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Fetch size</p></td><td><div><div><p>Number</p></div></div></td><td><p>The maximum number of messages (1-10) to fetch on each polling execution</p><p>An error occurs if you configure a value greater than 10.</p></td><td><p>10</p></td><td></td></tr><tr><td><p>Scheduling Strategy</p></td><td><div><div><p>scheduling-strategy</p></div></div></td><td><div><div><p>Scheduling strategy for triggering the message fetch from the service</p></div><div><ul><li><p><a href="#fixed-frequency">Fixed Frequency</a></p></li><li><p><a href="#cron">Cron</a></p></li></ul></div></div></td><td></td><td><p>x</p></td></tr></tbody></table>

### Fixed Frequency

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>Polling frequency</p></td><td><div><div><p>1000ms</p></div><div><p>(1 second)</p></div></div></td><td></td></tr><tr><td><p>Start delay</p></td><td><div><div><p>Number</p></div></div></td><td><p>The amount of time for the scheduler to wait before starting</p></td><td><p>10</p></td><td></td></tr><tr><td><p>Time unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DAYS</p></li><li><p>HOURS</p></li><li><p>MINUTES</p></li><li><p>SECONDS</p></li><li><p>MILLISECONDS</p></li></ul></div></div></td><td><p>Time unit to use in the <code>startDelay</code> configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr></tbody></table>

### Cron

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Expression</p></td><td><div><div><p>Cron expression</p></div></div></td><td></td><td></td><td><p>x</p></td></tr><tr><td><p>Time Zone</p></td><td><div><div><p>String</p></div></div></td><td><p>The ID of the time zone in which the expression is based</p></td><td></td><td></td></tr></tbody></table>

## See Also

- [Fixed Frequency](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#fixed-frequency)

- [Cron Expressions](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#cron-expressions)

<!-- document id=8b629b241f2ceda10e2181d9daace5ebffc00a43bb9e13866b8e7220f8f6d9e7 url=/mulesoft/current/en-us/anypoint-mq-connector/latest/anypoint-mq-connector-reference.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Anypoint MQ Connector Reference

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Support Version: Select

Anypoint MQ Connector Version 4.x

Anypoint MQ is a multi-tenant, cloud messaging service that enables customers to perform advanced
asynchronous messaging among their applications.

## Configurations

---

### Config

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Name</p></td><td><p>String</p></td><td><p>Specifies the name for this configuration. Connectors refer to the configuration by using this name.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Connection</p></td><td><div><div><p><a href="#config_connection">Connection</a></p></div></div></td><td><p>Specifies the connection types to provide to this configuration.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Expiration Policy</p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before the runtime considers it eligible for purging. The platform purges expired instances as needed to free resources.</p></td><td></td><td></td></tr></tbody></table>

#### Connection Types

##### Connection

###### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>URL</p></td><td><div><div><p>String</p></div></div></td><td><p>The region URL for the queue from the <strong>Anypoint Platform &gt; MQ</strong> console</p></td><td><p>https://mq-us-east-1.anypoint.mulesoft.com/api/v1</p></td><td></td></tr><tr><td><p>Client App ID</p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Value from either:</p></div><div><ul><li><p><strong>ID</strong> from <strong>Anypoint Platform</strong> &gt; <strong>Access Management</strong> &gt; <strong>Connected Apps</strong></p></li><li><p><strong>Client App ID</strong> from <strong>Anypoint Platform &gt; MQ &gt; Client Apps</strong></p></li></ul></div></div></td><td></td><td><p>x</p></td></tr><tr><td><p>Client Secret</p></td><td><div><div><p>String</p></div></div></td><td><div><div><p>Value from either:</p></div><div><ul><li><p><strong>Secret</strong> from <strong>Anypoint Platform</strong> &gt; <strong>Access Management</strong> &gt; <strong>Connected Apps</strong></p></li><li><p><strong>Client Secret</strong> from <strong>Anypoint Platform &gt; MQ &gt; Client Apps</strong></p></li></ul></div></div></td><td></td><td><p>x</p></td></tr><tr><td><p>TLS Context</p></td><td><div><div><p><a href="#Tls">Tls</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Host</p></td><td><div><div><p>String</p></div></div></td><td><p>Destination host for proxy requests</p></td><td></td><td></td></tr><tr><td><p>Port</p></td><td><div><div><p>Number</p></div></div></td><td><p>Destination port for proxy requests</p></td><td></td><td></td></tr><tr><td><p>Username</p></td><td><div><div><p>String</p></div></div></td><td><p>Username to authenticate against the proxy</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password to authenticate against the proxy</p></td><td></td><td></td></tr><tr><td><p>Send Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Size of the buffer (in bytes) used when sending data, set on the socket itself</p></td><td></td><td></td></tr><tr><td><p>Receive Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Size of the buffer (in bytes) used when receiving data</p></td><td></td><td></td></tr><tr><td><p>Client Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>SO_TIMEOUT value on sockets. Indicates the amount of time (in milliseconds) that the socket waits in a blocking operation before failing. A value of 0 (the default) indicates an indefinite wait.</p></td><td></td><td></td></tr><tr><td><p>Send TCP With No Delay</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>If set, transmitted data is not grouped but sent immediately. Defaults to true.</p></td><td><p>true</p></td><td></td></tr><tr><td><p>Linger</p></td><td><div><div><p>Number</p></div></div></td><td><p>SO_LINGER value, which determines how long (in milliseconds) the socket takes to close so that any remaining data is transmitted correctly</p></td><td></td><td></td></tr><tr><td><p>Keep Alive</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>SO_KEEPALIVE behavior on open sockets, which automatically checks open socket connections that are unused for long periods, and closes them if the connection becomes unavailable. This is a property on the socket itself and is used by a server socket to control whether connections to the server are kept alive before they are recycled.</p></td><td><p>false</p></td><td></td></tr><tr><td><p>Connection Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Number of milliseconds to wait until an outbound connection to a remote server is successfully created, before failing with a timeout. Defaults to 30 seconds.</p></td><td><p>30000</p></td><td></td></tr><tr><td><p>Reconnection</p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the deployment connectivity test to each connector fails.</p></td><td></td><td></td></tr></tbody></table>

## Operations

- [Ack](#ack)

- [Consume](#consume)

- [Nack](#nack)

- [Publish](#publish)

### Associated Sources

- [Subscriber](#subscriber)

### Ack

`<anypoint-mq:ack>`

Executes an acknowledgment indicating that the message is consumed correctly and deletes the message
from In Flight status.

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Ack Token</p></td><td><div><div><p>String</p></div></div></td><td><p>Acknowledgment token used to perform manual ACK and NACK operations, in MANUAL mode only</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p></td><td></td><td></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:ACKING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

### Consume

`<anypoint-mq:consume>`

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Queue</p></td><td><div><div><p>String</p></div></div></td><td><p>Queue or Exchange name from which to fetch a message</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Acknowledgment Mode</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>IMMEDIATE</p></li><li><p>MANUAL</p></li></ul></div></div></td><td><p>Acknowledgment mode to use for the messages retrieved</p></td><td><p>IMMEDIATE</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Duration that a message is held by a consumer waiting for an acknowledgment or not acknowledgment. After that duration elapses, the message is again available to any consumer.</p></td><td><p>0</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>Time unit to use in the acknowledgmentTimeout configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Polling Time</p></td><td><div><div><p>Number</p></div></div></td><td><div><div><p>Time to wait for a message to be ready for consumption (0-20000).</p></div><div><ul><li><p>If this value is greater than 0 and no message arrives, the connector throws a <code>ANYPOINT-MQ:TIMEOUT</code> exception.</p></li><li><p>If this value is 0 and no message arrives, the connector returns <code>NULL</code> and doesn’t throw the <code>ANYPOINT-MQ:TIMEOUT</code> exception.</p></li></ul></div></div></td><td><p>10000</p></td><td></td></tr><tr><td><p>Polling Time Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>Time unit to use in the pollingTime configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of the operation output</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>Encoding of the operation output</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Use repeatable streams</p></td><td></td><td></td></tr><tr><td><p>Target Variable</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of a variable to store the operation’s output</p></td><td></td><td></td></tr><tr><td><p>Target Value</p></td><td><div><div><p>String</p></div></div></td><td><p>Expression to evaluate against the operation’s output and store the expression outcome in the target variable</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p></td><td></td><td></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMQMessageAttributes">Anypoint MQ Message Attributes</a></p></div></div></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:ACKING

- ANYPOINT-MQ:CONSUMING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:TIMEOUT

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

### Nack

`<anypoint-mq:nack>`

Executes a not acknowledgment and changes the status of the message from In Flight to In Queue for
subscriber consumption

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Ack Token</p></td><td><div><div><p>String</p></div></div></td><td><p>Acknowledgment token used to perform manual ACK and NACK operations, in MANUAL mode only</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p></td><td></td><td></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:NACKING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

### Publish

`<anypoint-mq:publish>`

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Destination</p></td><td><div><div><p>String</p></div></div></td><td><p>Queue or Exchange name from which to fetch a message</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of the operation output</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>The encoding of the operation output</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Use repeatable streams</p></td><td></td><td></td></tr><tr><td><p>Body</p></td><td><div><div><p>Binary</p></div></div></td><td><p>Body of the outgoing message, sent as a string as part of a JSON message. Any content that is published must be capable of being serialized to and deserialized from string format. Sending Objects that don’t have a proper string serialization causes the message to be unreadable on the receiving end.</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>User Properties</p></td><td><div><div><p>Object</p></div></div></td><td><p>Custom user properties set to the message</p></td><td></td><td></td></tr><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>Valid custom user ID for the outgoing message. If not specified, the broker creates one.</p></td><td></td><td></td></tr><tr><td><p>Message Group Id</p></td><td><div><div><p>String</p></div></div></td><td><p>ID of the message group to which the published message belongs. Specify only for FIFO queues.</p><p>Message group IDs can contain up to 128 alphanumeric characters (a-z, A-Z, 0-9) and punctuation (! " # $ % &amp; ' ( ) * + , - . / : ; &lt; = &gt; ? @ [ ] \ ^ _ ` { } | ~).</p></td><td></td><td></td></tr><tr><td><p>Delivery Delay</p></td><td><div><div><p>Number</p></div></div></td><td><p>Time to postpone delivery of the message before consumption: between 0 and 15 minutes.</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Delivery Delay Unit</p></td><td><div><div><p>Enumeration</p></div></div></td><td><div><div><p>Time unit to use in the <code>Delivery Delay</code> parameter:</p></div><div><ul><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li></ul></div></div></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Send Content-Type</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Set to true if the body type should be sent as an Anypoint MQ Message property</p></td><td><p>true</p></td><td></td></tr><tr><td><p>Target Variable</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of a variable to store the operation output</p></td><td></td><td></td></tr><tr><td><p>Target Value</p></td><td><div><div><p>String</p></div></div></td><td><p>Expression to evaluate against the operation output. The expression outcome is stored in the target variable</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p></td><td></td><td></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMQMessagePublishAttributes">Anypoint MQ Message Publish Attributes</a></p></div></div></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

#### Throws

- ANYPOINT-MQ:PUBLISHING

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:ILLEGAL\_BODY

- ANYPOINT-MQ:DESTINATION\_NOT\_FOUND

- ANYPOINT-MQ:RETRY\_EXHAUSTED

## Sources

### Subscriber

`<anypoint-mq:subscriber>`

Anypoint MQ Subscriber Message Source retrieves messages from the given destination name.

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Queue</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of the queue from which messages are retrieved</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Subscriber Type</p></td><td><div><div><p>One of:</p></div><div><ul><li><p><a href="#polling">Polling</a></p></li><li><p><a href="#prefetch">Prefetch</a></p></li></ul></div></div></td><td><p>Strategy to use when subscribing to messages from the service</p></td><td></td><td></td></tr><tr><td><p>Acknowledgment Mode</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>IMMEDIATE</p></li><li><p>AUTO</p></li><li><p>MANUAL</p></li></ul></div></div></td><td><p>Acknowledgment mode to use for the messages retrieved</p></td><td><p>AUTO</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Duration that a message is held by a broker waiting for an acknowledgment or not acknowledgment before being made available to any subscriber. Specifies the default <code>acknowledgmentTimeout</code> value for all Subscriber sources, unless it is overridden. The maximum value of this parameter is 12 hours.</p></td><td><p>If <code>acknowledgementTimeout</code> is not set (the default), the connector uses the TTL value of at least two minutes.</p></td><td></td></tr><tr><td><p>Acknowledgment Timeout Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>Time unit to use in the acknowledgmentTimeout configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr><tr><td><p>Circuit Breaker</p></td><td><div><div><p><a href="#circuitBreaker">Circuit Breaker</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of the operation output</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>Encoding of the operation output</p></td><td></td><td></td></tr><tr><td><p>Primary Node Only</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Whether this source should only be executed on the primary node when running in a cluster</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Use repeatable streams</p></td><td></td><td></td></tr><tr><td><p>Redelivery Policy</p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><p>Message redelivery policy</p></td><td></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Retry strategy in case of connectivity errors</p></td><td></td><td></td></tr></tbody></table>

#### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMQMessageAttributes">Anypoint MQ Message Attributes</a></p></div></div></td></tr></tbody></table>

#### For Configurations

- [Config](#config)

## Types

### Tls

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Enabled Protocols</p></td><td><div><div><p>String</p></div></div></td><td><p>Comma-separated list of protocols enabled for this context</p></td><td></td><td></td></tr><tr><td><p>Enabled Cipher Suites</p></td><td><div><div><p>String</p></div></div></td><td><p>Comma-separated list of cipher suites enabled for this context</p></td><td></td><td></td></tr><tr><td><p>Trust Store</p></td><td><div><div><p><a href="#TrustStore">Trust Store</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Key Store</p></td><td><div><div><p><a href="#KeyStore">Key Store</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Revocation Check</p></td><td><div><div><ul><li><p><a href="#standard-revocation-check">Standard Revocation Check</a></p></li><li><p><a href="#custom-ocsp-responder">Custom OCSP Responder</a></p></li><li><p><a href="#crl-file">CRL File</a></p></li></ul></div></div></td><td></td><td></td><td></td></tr></tbody></table>

### Trust Store

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>Location of the trust store, resolved relative to the current classpath and file system, if possible</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password used to protect the trust store</p></td><td></td><td></td></tr><tr><td><p>Type</p></td><td><div><div><p>String</p></div></div></td><td><p>Type of store used</p></td><td></td><td></td></tr><tr><td><p>Algorithm</p></td><td><div><div><p>String</p></div></div></td><td><p>Algorithm used by the trust store</p></td><td></td><td></td></tr><tr><td><p>Insecure</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>If true, no certificate validations are performed, rendering connections vulnerable to attacks. Use at your own risk.</p></td><td></td><td></td></tr></tbody></table>

### Key Store

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>Location of the key store, resolved relative to the current classpath and file system, if possible</p></td><td></td><td></td></tr><tr><td><p>Type</p></td><td><div><div><p>String</p></div></div></td><td><p>Type of store used</p></td><td></td><td></td></tr><tr><td><p>Alias</p></td><td><div><div><p>String</p></div></div></td><td><p>When the key store contains many private keys, indicates the alias of the key that is used. If not defined, the first key in the file is used by default.</p></td><td></td><td></td></tr><tr><td><p>Key Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password used to protect the private key</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>Password used to protect the key store</p></td><td></td><td></td></tr><tr><td><p>Algorithm</p></td><td><div><div><p>String</p></div></div></td><td><p>Algorithm used by the key store</p></td><td></td><td></td></tr></tbody></table>

### Standard Revocation Check

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Only End Entities</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Verifies only the last element in the certificate chain</p></td><td></td><td></td></tr><tr><td><p>Prefer Crls</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Uses CRL-signing certificates before using OCSP-signing certificate</p></td><td></td><td></td></tr><tr><td><p>No Fallback</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Doesn’t use the secondary checking method (the one not selected for Prefer Crls)</p></td><td></td><td></td></tr><tr><td><p>Soft Fail</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Avoids verification failure when the revocation server cannot be reached or is busy</p></td><td></td><td></td></tr></tbody></table>

### Custom OCSP Responder

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Url</p></td><td><div><div><p>String</p></div></div></td><td><p>URL of the OCSP responder</p></td><td></td><td></td></tr><tr><td><p>Cert Alias</p></td><td><div><div><p>String</p></div></div></td><td><p>Alias of the signing certificate for the OCSP response, if present. The signing certificate must be in the trust store.</p></td><td></td><td></td></tr></tbody></table>

### CRL File

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>Path to the CRL file</p></td><td></td><td></td></tr></tbody></table>

### Reconnection

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Fails Deployment</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the deployment connectivity test to each connector fails.</p></td><td></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>Reconnection strategy to use</p></td><td></td><td></td></tr></tbody></table>

### Reconnect

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>How often to reconnect, in milliseconds</p></td><td></td><td></td></tr><tr><td><p>Count</p></td><td><div><div><p>Number</p></div></div></td><td><p>How many reconnection attempts to make</p></td><td></td><td></td></tr><tr><td><p>blocking</p></td><td><p>Boolean</p></td><td><p>If false, the reconnection strategy runs in a separate, non-blocking thread</p></td><td><p>true</p></td><td></td></tr></tbody></table>

### Reconnect Forever

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>How often to reconnect, in milliseconds</p></td><td></td><td></td></tr><tr><td><p>blocking</p></td><td><p>Boolean</p></td><td><p>If false, the reconnection strategy runs in a separate, non-blocking thread</p></td><td><p>true</p></td><td></td></tr></tbody></table>

### Expiration Policy

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max Idle Time</p></td><td><div><div><p>Number</p></div></div></td><td><p>A scalar time value for the maximum amount of time a dynamic configuration instance should be allowed to be idle before it’s considered eligible for expiration</p></td><td></td><td></td></tr><tr><td><p>Time Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>A time unit that qualifies the maxIdleTime attribute</p></td><td></td><td></td></tr></tbody></table>

### Anypoint MQ Message Attributes

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Destination</p></td><td><div><div><p>String</p></div></div></td><td><p>Message destination</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Headers</p></td><td><div><div><p>Object</p></div></div></td><td><p>Message headers</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Properties</p></td><td><div><div><p>Object</p></div></div></td><td><p>Message properties</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>ID of the message</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Delivery Count</p></td><td><div><div><p>Number</p></div></div></td><td><p>Number of times the message was delivered</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Content Type</p></td><td><div><div><p>String</p></div></div></td><td><p>Content type of the message body</p></td><td></td><td></td></tr><tr><td><p>Ack Token</p></td><td><div><div><p>String</p></div></div></td><td><p>Acknowledgment token used to perform manual ACK and NACK operations, in MANUAL mode only</p></td><td></td><td></td></tr></tbody></table>

### Circuit Breaker

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>On Error Types</p></td><td><div><div><p>String</p></div></div></td><td><p>Error types that equal failure of the circuit when they occur during flow execution. By default, all errors result in failure.</p></td><td></td><td></td></tr><tr><td><p>Errors Threshold</p></td><td><div><div><p>Number</p></div></div></td><td><p>Of the errors considered by the circuit, how many must occur for the circuit to be opened.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Trip Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>How long the circuit remains open after <code>errorsThreshold</code> is reached</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Trip Timeout Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>The time unit bound to the tripTimeout value</p></td><td><p>MILLISECONDS</p></td><td></td></tr></tbody></table>

### Repeatable In Memory Stream

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Initial Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>The amount of memory allocated to consume the stream and provide random access to it. If the stream contains more data than can fit into this buffer, then the buffer expands according to the bufferSizeIncrement attribute, with an upper limit of maxInMemorySize.</p></td><td></td><td></td></tr><tr><td><p>Buffer Size Increment</p></td><td><div><div><p>Number</p></div></div></td><td><p>How much buffer size can expand. If set to 0 (zero) or less, STREAM_MAXIMUM_SIZE_EXCEEDED is raised when the buffer is full.</p></td><td></td><td></td></tr><tr><td><p>Max Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum amount of memory to use before STREAM_MAXIMUM_SIZE_EXCEEDED is raised. If set to 0 (zero) or less, memory is unlimited.</p></td><td></td><td></td></tr><tr><td><p>Buffer Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><p>Unit in which all these attributes are expressed</p></td><td></td><td></td></tr></tbody></table>

### Repeatable File Store Stream

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max In Memory Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum amount of memory that the stream can hold locally before content is buffered to disk</p></td><td></td><td></td></tr><tr><td><p>Buffer Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><p>Unit in which maxInMemorySize is expressed</p></td><td></td><td></td></tr></tbody></table>

### Redelivery Policy

For information on the redelivery policy, see
[Configure a Redelivery Policy](https://docs.mulesoft.com/mule-runtime/latest/redelivery-policy).

### Anypoint MQ Message Publish Attributes

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>ID of the message that was published</p></td><td></td><td><p>x</p></td></tr></tbody></table>

### Prefetch

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max Local Messages</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum number of messages to prefetch from the service and keep locally before dispatching to the flow.</p><p>NOTE: Due to a known issue, using <code>prefetch</code> mode with <code>maxConcurrency="1"</code> set on the <code>flow</code> element might result in message-processing latency.</p><p>When using <code>prefetch</code> mode, set <code>maxLocalMessages</code> to a value greater than <code>1</code> to avoid message-processing latency issues. When <code>maxLocalMessages</code> is set to <code>1</code>, latency can occur when the connector prefetches the message but the app doesn’t consume it, and the message returns to the queue for reprocessing.</p></td><td><p>30</p></td><td></td></tr></tbody></table>

### Polling

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Fetch size</p></td><td><div><div><p>Number</p></div></div></td><td><p>The maximum number of messages (1-10) to fetch on each polling execution</p><p>An error occurs if you configure a value greater than 10.</p></td><td><p>10</p></td><td></td></tr><tr><td><p>Scheduling Strategy</p></td><td><div><div><p>scheduling-strategy</p></div></div></td><td><div><div><p>Scheduling strategy for triggering the message fetch from the service</p></div><div><ul><li><p><a href="#fixed-frequency">Fixed Frequency</a></p></li><li><p><a href="#cron">Cron</a></p></li></ul></div></div></td><td></td><td><p>x</p></td></tr></tbody></table>

### Fixed Frequency

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>Polling frequency</p></td><td><div><div><p>1000ms</p></div><div><p>(1 second)</p></div></div></td><td></td></tr><tr><td><p>Start delay</p></td><td><div><div><p>Number</p></div></div></td><td><p>The amount of time for the scheduler to wait before starting</p></td><td><p>10</p></td><td></td></tr><tr><td><p>Time unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>DAYS</p></li><li><p>HOURS</p></li><li><p>MINUTES</p></li><li><p>SECONDS</p></li><li><p>MILLISECONDS</p></li></ul></div></div></td><td><p>Time unit to use in the <code>startDelay</code> configuration</p></td><td><p>MILLISECONDS</p></td><td></td></tr></tbody></table>

### Cron

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Expression</p></td><td><div><div><p>Cron expression</p></div></div></td><td></td><td></td><td><p>x</p></td></tr><tr><td><p>Time Zone</p></td><td><div><div><p>String</p></div></div></td><td><p>The ID of the time zone in which the expression is based</p></td><td></td><td></td></tr></tbody></table>

## See Also

- [Fixed Frequency](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#fixed-frequency)

- [Cron Expressions](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#cron-expressions)

<!-- document id=320f188ba439bd29b829af12cc117e5aadc002db6505d31ce41bdd3e5c4a12d2 url=/mulesoft/current/en-us/anypoint-mq-connector/2.x/anypoint-mq-connector-reference.md -->

---
product: Anypoint MQ Connector
version: 2.x
---

# Anypoint MQ Connector Reference — Mule 4

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Support Version: Select

Anypoint MQ Connector Version 2.x

Anypoint MQ is a multi-tenant, cloud messaging service that enables customers to perform advanced
asynchronous messaging among their applications.

## Configurations

---

### Default Subscriber

### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Name</p></td><td><p>String</p></td><td><p>Specifies the name for this configuration. Connectors refer to the configuration by using this name.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Connection</p></td><td><div><div><p><a href="#default-subscriber_connection">Connection</a></p></div></div></td><td><p>Specifies the connection types that can be provided to this configuration.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Expiration Policy</p></td><td><div><div><p><a href="#ExpirationPolicy">Expiration Policy</a></p></div></div></td><td><p>Configures the minimum amount of time that a dynamic configuration instance can remain idle before the runtime considers it eligible for purging. The platform purges expired instances as needed to free resources.</p></td><td></td><td></td></tr><tr><td><p>Acknowledgement Mode</p></td><td><div><div><p>Enumeration, <a href="#SubscriberAckMode">SubscriberAckMode</a>:</p></div><div><ul><li><p>IMMEDIATE</p></li><li><p>AUTO</p></li><li><p>MANUAL</p></li></ul></div></div></td><td><p>The acknowledgment mode to use for the messages retrieved by the subscribers. This mode affects only the Subscriber source and is unrelated to the Consume operation. Refer to <a href="#SubscriberAckMode">SubscriberAckMode</a> for more details about each strategy.</p></td><td><p>AUTO</p></td><td></td></tr><tr><td><p>Acknowledgement Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Specifies the duration that a message is held by a broker waiting for an Acknowledgment or Not Acknowledgment. If neither an Acknowledgment or a Not Acknowledgment occurs before the timeout is exceeded, then the message is automatically returned to the destination by the broker, making it again available to any subscriber for redelivery. By default, this timeout is decided by the subscriber, depending on which strategy is used. During polling, the ACK timeout is the one configured in the queue. When using the Prefetch strategy, messages are kept in a local buffer until they are dispatched to the flow. You can update the time to live (TTL) to avoid having messages be evicted. By default, Anypoint MQ fetches messages with a TTL of at least 2 minutes. The maximum value of this parameter is 12 hours.</p></td><td><p>0</p></td><td></td></tr><tr><td><p>Polling Time</p></td><td><div><div><p>Number</p></div></div></td><td><p>When prefetch is disabled, the polling time defines how often the subscriber should check for new messages. By default, this checks for messages every one second (only if the prefetch is disabled). The value of this parameter is defined in milliseconds.</p></td><td><p>1000</p></td><td></td></tr><tr><td><p>Max Redelivery</p></td><td><div><div><p>Number</p></div></div></td><td><p>Number of redeliveries to accept for any given message. When the message redelivery count is higher than this threshold, then the message is ignored by the subscriber and not dispatched to the flow. For the message to be removed from the queue, configure a dead letter queue from the admin console.</p></td><td><p>-1</p></td><td></td></tr><tr><td><p>Fetch Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum number of messages to receive on each request. The response can contain fewer messages than this number, depending on the load of the target queue. This number also affects the local buffer of the prefetched messages. Setting this fetchSize to zero disables message prefetch. The prefetch buffer has a target size of three times the fetchSize, meaning that requests to retrieve messages continue as long as the local buffer is not full. Only in the case of a slow consumer, where the Mule runtime engine has no more threads available to process the request, is the buffer limit going to be reached. Enable prefetch for maximum throughput, in cases where high performance on message delivery is required. In cases where controlled message retrieval is required, you can disable prefetch and use the fixed polling configuration. By default this tries to fetch the max number of 10 messages per request.</p></td><td><p>10</p></td><td></td></tr><tr><td><p>Fetch Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Maximum duration in milliseconds to wait for the required amount of messages. If this duration elapses, the response is sent with as many messages as received during the period.</p></td><td><p>1000</p></td><td></td></tr><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>Fixed frequency in milliseconds at which time the retrieval of messages is attempted when there are no more messages to process locally. If a queue is empty and all the messages retrieved are already processed, this frequency defines how long to wait before attempting to retrieve more messages. By default, this frequency is 5 seconds (5000 milliseconds).</p></td><td><p>5000</p></td><td></td></tr></tbody></table>

## Connection Types

### Connection

#### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>URL</p></td><td><div><div><p>String</p></div></div></td><td><p>The region URL where the queue resides. This URL can be obtained and configured from the Anypoint Platform &gt; MQ console. Copy and paste the region URL into this field.</p></td><td><p><code>https://mq-us-east-1.anypoint.mulesoft.com/api/v1</code></p></td><td></td></tr><tr><td><p>Client App ID</p></td><td><div><div><p>String</p></div></div></td><td><p>In Anypoint Platform &gt; MQ &gt; Client Apps, click an app name (or create a new app), and click Copy for the Client App ID field. Paste this value in the Anypoint Studio Client App ID field.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Client Secret</p></td><td><div><div><p>String</p></div></div></td><td><p>In Anypoint Platform &gt; MQ &gt; Client Apps, click an app name (or create a new app), and click Copy for the Client Secret field. Paste this value in the Studio Client Secret field.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Proxy Config</p></td><td><div><div><p><a href="#ProxyParameterGroup">Proxy Parameter Group</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>TCP Client Socket Properties</p></td><td><div><div><p><a href="#TcpClientSocketParameterGroup">TCP Client Socket Parameter Group</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>TLS Context</p></td><td><div><div><p><a href="#Tls">TLS</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Reconnection</p></td><td><div><div><p><a href="#Reconnection">Reconnection</a></p></div></div></td><td><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy.</p></td><td></td><td></td></tr></tbody></table>

## Associated Operations

- [Ack](#ack)

- [Consume](#consume)

- [Nack](#nack)

- [Publish](#publish)

## Associated Sources

- [Subscriber](#subscriber)

## Operations

## Ack

`<anypoint-mq:ack>`

Execute an Acknowledgment (ack) over a given
[Anypoint MQ Message Context](#AnypointMQMessageContext) object indicating that the message has been
consumed correctly, and then delete the message from the in transit status.

### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Message Context</p></td><td><div><div><p><a href="#AnypointMQMessageContext">Anypoint MQ Message Context</a></p></div></div></td><td><p>AnypointMQMessageContext object that represents the received message.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>A retry strategy in case of connectivity errors.</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

### For Configurations

- [Default Subscriber](#default-subscriber)

### Throws

- ANYPOINT-MQ:UNKNOWN

- ANYPOINT-MQ:RETRY\_EXHAUSTED

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:RESOURCE\_NOT\_FOUND

## Consume

`<anypoint-mq:consume>`

Consume a message from an Anypoint MQ queue.

### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Destination</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of the queue or message exchange from which to fetch a message.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Acknowledgement Mode</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>IMMEDIATE</p></li><li><p>MANUAL</p></li></ul></div></div></td><td><p>Acknowledgment mode to use for the messages retrieved from this subscriber. Can only be 'MANUAL' or 'NONE'.</p></td><td><p>MANUAL</p></td><td></td></tr><tr><td><p>Polling Time</p></td><td><div><div><p>Number</p></div></div></td><td><p>How much time in milliseconds to wait if the requested messages are not ready to be consumed.</p></td><td><p>10000</p></td><td></td></tr><tr><td><p>Acknowledgement Timeout</p></td><td><div><div><p>Number</p></div></div></td><td><p>Duration that a message is held by a broker waiting for an Acknowledgment (ack) or Not Acknowledgment (nack). After that duration expires, the message is again available to any subscriber.</p></td><td><p>0</p></td><td></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of this operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>The encoding of this operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Specifies to use repeatable streams.</p></td><td></td><td></td></tr><tr><td><p>Target Variable</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of a variable in which to place the operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Target Value</p></td><td><div><div><p>String</p></div></div></td><td><p>An expression to evaluate against the operation’s output and to store the outcome of that expression in the target variable.</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>A retry strategy in case of connectivity errors.</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMQMessageContext">Anypoint MQ Message Context</a></p></div></div></td></tr></tbody></table>

### For Configurations

- [Default Subscriber](#default-subscriber)

### Throws

- ANYPOINT-MQ:UNKNOWN

- ANYPOINT-MQ:RETRY\_EXHAUSTED

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:RESOURCE\_NOT\_FOUND

## Nack

`<anypoint-mq:nack>`

Execute a Not Acknowledgement (NACK) for an [Anypoint MQ Message Context](#AnypointMQMessageContext)
object and change the status of the message from In Flight to In Queue to be consumed again for a
subscriber.

### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Message Context</p></td><td><div><div><p><a href="#AnypointMQMessageContext">Anypoint MQ Message Context</a></p></div></div></td><td><p>AnypointMQMessageContext object that represents the received message.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>A retry strategy in case of connectivity errors.</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

### For Configurations

- [Default Subscriber](#default-subscriber)

### Throws

- ANYPOINT-MQ:UNKNOWN

- ANYPOINT-MQ:RETRY\_EXHAUSTED

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:RESOURCE\_NOT\_FOUND

## Publish

`<anypoint-mq:publish>`

Publish a message to an Anypoint MQ queue or message exchange.

### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Destination</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of the queue or message exchange from which to fetch a message.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Body</p></td><td><div><div><p>Binary</p></div></div></td><td><p>Body of the message.</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>ID of the message to publish.</p></td><td></td><td></td></tr><tr><td><p>Send Content Type</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Indicates whether the content type of the Mule message should be attached or not.</p></td><td><p>true</p></td><td></td></tr><tr><td><p>Properties</p></td><td><div><div><p>Object</p></div></div></td><td><p>Additional properties to be sent within the message.</p></td><td></td><td></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of this operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>The encoding of this operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Streaming Strategy</p></td><td><div><div><ul><li><p><a href="#repeatable-in-memory-stream">Repeatable In Memory Stream</a></p></li><li><p><a href="#repeatable-file-store-stream">Repeatable File Store Stream</a></p></li><li><p>non-repeatable-stream</p></li></ul></div></div></td><td><p>Specifies whether to use repeatable streams and their behavior.</p></td><td></td><td></td></tr><tr><td><p>Target Variable</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of a variable in which to place the operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Target Value</p></td><td><div><div><p>String</p></div></div></td><td><p>An expression to evaluate against the operation’s output and to store the outcome of that expression in the target variable.</p></td><td><p>#[payload]</p></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>A retry strategy in case of connectivity errors.</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p><a href="#AnypointMqMessagePublishAttributes">Anypoint MQ Message Publish Attributes</a></p></div></div></td></tr></tbody></table>

### For Configurations

- [Default Subscriber](#default-subscriber)

### Throws

- ANYPOINT-MQ:UNKNOWN

- ANYPOINT-MQ:RETRY\_EXHAUSTED

- ANYPOINT-MQ:CONNECTIVITY

- ANYPOINT-MQ:RESOURCE\_NOT\_FOUND

## Sources

## Subscriber

`<anypoint-mq:subscriber>`

Retrieves messages from the specified destination.

### Parameters

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Name</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Configuration</p></td><td><p>String</p></td><td><p>Name of the configuration to use.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Destination</p></td><td><div><div><p>String</p></div></div></td><td><p>Name of the queue from which messages are retrieved.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>Output Mime Type</p></td><td><div><div><p>String</p></div></div></td><td><p>MIME type of this operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Output Encoding</p></td><td><div><div><p>String</p></div></div></td><td><p>The encoding of this operation’s output.</p></td><td></td><td></td></tr><tr><td><p>Redelivery Policy</p></td><td><div><div><p><a href="#RedeliveryPolicy">Redelivery Policy</a></p></div></div></td><td><p>Defines a policy for processing redelivery of the message.</p></td><td></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>A retry strategy in case of connectivity errors.</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

### Output

<table><colgroup><col> <col></colgroup><tbody><tr><td><p>Type</p></td><td><p>Binary</p></td></tr><tr><td><p>Attributes Type</p></td><td><div><div><p>AnypointMQMessageContext</p></div></div></td></tr></tbody></table>

### For Configurations

- [Default Subscriber](#default-subscriber)

## Types

### SubscriberAckMode

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>IMMEDIATE</p></td><td><p>String</p></td><td><p>The message is acknowledged as soon as it is dispatched to the flow. If the processing of the message fails during the execution of the flow, it has to be handled by the application.</p></td><td></td><td></td></tr><tr><td><p>AUTO</p></td><td><p>String</p></td><td><p>The message is acknowledged only if the flow that processes it finishes successfully. If an error is propagated during the execution of the flow, finalizing the execution with an error, then the subscriber listener NACKs the message, effectively returning it to the destination for redelivery. If the flow processing does not finish before the acknowledgment TTL is evicted, then the message is returned automatically to the destination by the broker for its redelivery.</p></td><td></td><td></td></tr><tr><td><p>MANUAL</p></td><td><p>String</p></td><td><p>The subscriber does not handle any aspect of the acknowledgment of the message. Once the message is dispatched to the flow for processing, the application is in charge of performing either an Acknowledgment or a Not Acknowledgment. If none is performed before the acknowledgment TTL is evicted, then the message is returned automatically to the destination by the broker for its redelivery.</p></td><td></td><td></td></tr></tbody></table>

### Anypoint MQ Message Context

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>destination</p></td><td><p>String</p></td><td><p>Name of the destination from which the message was consumed.</p></td><td></td><td></td></tr><tr><td><p>message</p></td><td><p><a href="#AnypointMQMessage">Anypoint MQ Message</a></p></td><td><p>Metadata for the message consumed.</p></td><td></td><td></td></tr></tbody></table>

### Anypoint MQ Message

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>id</p></td><td><p>String</p></td><td><p>The ID of the message.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>lockId</p></td><td><p>Number</p></td><td><p>The ID used to update the lock on the message while it is In Flight status.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>deliveryCount</p></td><td><p>Number</p></td><td><p>How many times was this message delivered.</p></td><td></td><td><p>x</p></td></tr><tr><td><p>properties</p></td><td><p>Map</p></td><td><p>Custom properties of the message, used to port extra information related to the message body.</p></td><td></td><td></td></tr><tr><td><p>headers</p></td><td><p>Map</p></td><td><p>The headers of the message, containing information provided by the broker, such as creation time or delivery count.</p></td><td></td><td></td></tr></tbody></table>

### Proxy Parameter Group

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Host</p></td><td><div><div><p>String</p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Port</p></td><td><div><div><p>Number</p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Username</p></td><td><div><div><p>String</p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td></td><td></td><td></td></tr></tbody></table>

### TCP Client Socket Parameter Group

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Send Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Receive Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Client Timeout</p></td><td><div><div><p>Number</p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Send Tcp No Delay</p></td><td><div><div><p>Boolean</p></div></div></td><td></td><td><p>true</p></td><td></td></tr><tr><td><p>Linger</p></td><td><div><div><p>Number</p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Keep Alive</p></td><td><div><div><p>Boolean</p></div></div></td><td></td><td><p>false</p></td><td></td></tr><tr><td><p>Connection Timeout</p></td><td><div><div><p>Number</p></div></div></td><td></td><td><p>30000</p></td><td></td></tr></tbody></table>

### TLS

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Enabled Protocols</p></td><td><div><div><p>String</p></div></div></td><td><p>A comma-separated list of protocols enabled for this context.</p></td><td></td><td></td></tr><tr><td><p>Enabled Cipher Suites</p></td><td><div><div><p>String</p></div></div></td><td><p>A comma-separated list of cipher suites enabled for this context.</p></td><td></td><td></td></tr><tr><td><p>Trust Store</p></td><td><div><div><p><a href="#TrustStore">Trust Store</a></p></div></div></td><td></td><td></td><td></td></tr><tr><td><p>Key Store</p></td><td><div><div><p><a href="#KeyStore">Key Store</a></p></div></div></td><td></td><td></td><td></td></tr></tbody></table>

### Trust Store

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>The location of the trust store, which is resolved relative to the current classpath and file system, if possible.</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>The password used to protect the trust store.</p></td><td></td><td></td></tr><tr><td><p>Type</p></td><td><div><div><p>String</p></div></div></td><td><p>The type of store used.</p></td><td></td><td></td></tr><tr><td><p>Algorithm</p></td><td><div><div><p>String</p></div></div></td><td><p>The algorithm used by the trust store.</p></td><td></td><td></td></tr><tr><td><p>Insecure</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>If true, no certificate validations are performed, rendering connections vulnerable to attacks. Use at your own risk.</p></td><td></td><td></td></tr></tbody></table>

### Key Store

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Path</p></td><td><div><div><p>String</p></div></div></td><td><p>The location of the key store, which resolves relative to the current classpath and file system, if possible.</p></td><td></td><td></td></tr><tr><td><p>Type</p></td><td><div><div><p>String</p></div></div></td><td><p>The type of store used.</p></td><td></td><td></td></tr><tr><td><p>Alias</p></td><td><div><div><p>String</p></div></div></td><td><p>When the key store contains many private keys, this attribute indicates the alias of the key that should be used. If not defined, the first key in the file is used by default.</p></td><td></td><td></td></tr><tr><td><p>Key Password</p></td><td><div><div><p>String</p></div></div></td><td><p>The password used to protect the private key.</p></td><td></td><td></td></tr><tr><td><p>Password</p></td><td><div><div><p>String</p></div></div></td><td><p>The password used to protect the key store.</p></td><td></td><td></td></tr><tr><td><p>Algorithm</p></td><td><div><div><p>String</p></div></div></td><td><p>The algorithm used by the key store.</p></td><td></td><td></td></tr></tbody></table>

### Reconnection

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Fails Deployment</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>When the application is deployed, a connectivity test is performed on all connectors. If set to true, deployment fails if the test doesn’t pass after exhausting the associated reconnection strategy.</p></td><td></td><td></td></tr><tr><td><p>Reconnection Strategy</p></td><td><div><div><ul><li><p><a href="#reconnect">Reconnect</a></p></li><li><p><a href="#reconnect-forever">Reconnect Forever</a></p></li></ul></div></div></td><td><p>The reconnection strategy to use.</p><p>Anypoint MQ Connector doesn’t support this parameter. For more information, see <a href="https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector">Can I use a retry strategy with the Anypoint MQ connector?</a></p></td><td></td><td></td></tr></tbody></table>

### Reconnect

> [!NOTE] Anypoint MQ Connector doesn’t support this parameter. For more information, see
> [Can I use a retry strategy with the Anypoint MQ connector?](https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector)

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>How often in milliseconds to reconnect.</p></td><td></td><td></td></tr><tr><td><p>Count</p></td><td><div><div><p>Number</p></div></div></td><td><p>How many reconnection attempts to make.</p></td><td></td><td></td></tr><tr><td><p>blocking</p></td><td><p>Boolean</p></td><td><p>If false, the reconnection strategy runs in a separate, non-blocking thread.</p></td><td><p>true</p></td><td></td></tr></tbody></table>

### Reconnect Forever

> [!NOTE] Anypoint MQ Connector doesn’t support this parameter. For more information, see
> [Can I use a retry strategy with the Anypoint MQ connector?](https://docs.mulesoft.com/mq/mq-faq#can-i-use-a-retry-strategy-with-the-anypoint-mq-connector)

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Frequency</p></td><td><div><div><p>Number</p></div></div></td><td><p>How often in milliseconds to reconnect.</p></td><td></td><td></td></tr><tr><td><p>blocking</p></td><td><p>Boolean</p></td><td><p>If false, the reconnection strategy runs in a separate, non-blocking thread.</p></td><td><p>true</p></td><td></td></tr></tbody></table>

### Expiration Policy

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max Idle Time</p></td><td><div><div><p>Number</p></div></div></td><td><p>A scalar time value for the maximum amount of time a dynamic configuration instance should be allowed to be idle before it’s considered eligible for expiration.</p></td><td></td><td></td></tr><tr><td><p>Time Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>NANOSECONDS</p></li><li><p>MICROSECONDS</p></li><li><p>MILLISECONDS</p></li><li><p>SECONDS</p></li><li><p>MINUTES</p></li><li><p>HOURS</p></li><li><p>DAYS</p></li></ul></div></div></td><td><p>A time unit that qualifies the maxIdleTime attribute.</p></td><td></td><td></td></tr></tbody></table>

### Redelivery Policy

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max Redelivery Count</p></td><td><div><div><p>Number</p></div></div></td><td><p>The maximum number of times a message can be redelivered and processed unsuccessfully before triggering a process-failed-message.</p></td><td></td><td></td></tr><tr><td><p>Use Secure Hash</p></td><td><div><div><p>Boolean</p></div></div></td><td><p>Whether to use a secure hash algorithm to identify a redelivered message.</p></td><td></td><td></td></tr><tr><td><p>Message Digest Algorithm</p></td><td><div><div><p>String</p></div></div></td><td><p>The secure hashing algorithm to use. If not set, the default is SHA-256.</p></td><td></td><td></td></tr><tr><td><p>Id Expression</p></td><td><div><div><p>String</p></div></div></td><td><p>Defines one or more expressions to use to determine when a message has been redelivered. This property may only be set if useSecureHash is false.</p></td><td></td><td></td></tr><tr><td><p>Object Store</p></td><td><div><div><p>ObjectStore</p></div></div></td><td><p>The object store where the redelivery counter for each message is going to be stored.</p></td><td></td><td></td></tr></tbody></table>

### Repeatable In Memory Stream

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Initial Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>The amount of memory to allocate to consume the stream and provide random access to it. If the stream contains more data than can fit into this buffer, the buffer expands according to the bufferSizeIncrement attribute, with an upper limit of maxInMemorySize.</p></td><td></td><td></td></tr><tr><td><p>Buffer Size Increment</p></td><td><div><div><p>Number</p></div></div></td><td><p>By how much the buffer size expands if the buffer exceeds its initial size. Setting a value of zero or lower means that the buffer should not expand, meaning that a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised when the buffer gets full.</p></td><td></td><td></td></tr><tr><td><p>Max Buffer Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>This is the maximum amount of memory to use. If more than that is used, then a STREAM_MAXIMUM_SIZE_EXCEEDED error is raised. A value lower or equal to zero means no limit.</p></td><td></td><td></td></tr><tr><td><p>Buffer Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><p>The unit in which these attributes are expressed.</p></td><td></td><td></td></tr></tbody></table>

### Repeatable File Store Stream

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Max In Memory Size</p></td><td><div><div><p>Number</p></div></div></td><td><p>Defines the maximum memory that the stream should use to keep data in memory. If more than that is consumed, then the connector starts to buffer the content on disk.</p></td><td></td><td></td></tr><tr><td><p>Buffer Unit</p></td><td><div><div><p>Enumeration, one of:</p></div><div><ul><li><p>BYTE</p></li><li><p>KB</p></li><li><p>MB</p></li><li><p>GB</p></li></ul></div></div></td><td><p>The unit in which maxInMemorySize is expressed.</p></td><td></td><td></td></tr></tbody></table>

### Anypoint MQ Message Publish Attributes

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Field</th><th>Type</th><th>Description</th><th>Default Value</th><th>Required</th></tr></thead><tbody><tr><td><p>Message Id</p></td><td><div><div><p>String</p></div></div></td><td><p>The ID of the published message.</p></td><td></td><td><p>x</p></td></tr></tbody></table>

<!-- document id=6b6270eadf6cd53543632a177b924ec1c88298bc1991a3ad7d1beb86032a2b26 url=/mulesoft/current/en-us/anypoint-mq-connector/2.x/anypoint-mq-consume.md -->

---
product: Anypoint MQ Connector
version: 2.x
---

# Anypoint MQ Consume Operation

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Consume operation in the Anypoint MQ connector provides the ability to consume a message at any
time of the flow, from any destination.

## Consume A Message

The syntax to consume a message from a queue is:

```xml
<anypoint-mq:consume config-ref="MQ_config" destination="#[vars.destination]"/>
```

The operation above consumes the first available message in the queue identified by the destination,
and then converts it to a `MuleMessage` resulting in the following structure:

- The message’s content as payload.

- The message’s metadata in the message attributes.

By default, the ACK mode is `MANUAL`, so the message isn’t acknowledged. If you want the message to
be acknowledged as soon as it is consumed, set the mode to `IMMEDIATE`. For more information, see
[Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-ack).

## Wait for a Message

By default, the maximum wait time is configured in 10 seconds, producing a `null` result if no
message is available in that period. If configuring a timeout that fits better for your use case,
customize the `pollingTime` parameter.

## Incoming Message Metadata

As stated before, each message received consists of two parts:

- Payload - Contains the content of a message.

- Attributes - Contains the metadata for a message.

This metadata maps all the information available in a Anypoint MQ message, including:

- Message ID

- Headers

- Properties

See [Consume](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-connector-reference#consume) for details about the attributes structure.

## See Also

- Consume operation in the
  [Anypoint MQ Connector Reference - 2.x](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-connector-reference#consume)

- [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-ack)

<!-- document id=45a3c131ec422acc3e8b6a9ee564a63557b673f147135cbbc445a36707e3899a url=/mulesoft/current/en-us/anypoint-mq-connector/3.x/anypoint-mq-consume.md -->

---
product: Anypoint MQ Connector
version: 3.x
---

# Anypoint MQ Consume Operation

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The `consume` operation in the Anypoint MQ connector enables the app consume a single message at any
time of the flow, from any destination, using the acknowledgment strategy that supports your use
case.

## Incoming Message Structure

Every incoming message consists of two parts:

- `payload` - Represents the message body

- `attributes` - Contains metadata for the received message, such as its ID or other properties

![Anypoint MQ Message Attributes](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-consume-attributes.png)

## Message Consumption

The simplest way to consume a message from a queue is to drag the **Consume** operation from the
Mule palette to the canvas and configure the `Queue` parameter with the name of the queue from which
to retrieve the message:

![Anypoint MQ Consume Operation](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-consume-operation.png)

```xml
<anypoint-mq:consume config-ref="Anypoint_MQ_config" destination="myQueue"/>
```

The Consume operation in this example consumes the first available message in `myQueue` and converts
it to a `MuleMessage` instance with this structure:

- The message body as payload.

- The message metadata in the message attributes. Attributes might include `messageId` or
  `redeliveryCount`.

Use a DataWeave expression in the `Queue` parameter to dynamically change the target queue from
which to consume the message.

## Consumed Message Acknowledgment

- **Automatic**

  By default, `acknowledgementMode` is `IMMEDIATE`, meaning that the message is acknowledged as soon
  as it is consumed from the queue and before it’s delivered to the Mule flow. If the message
  acknowledgment fails, the Consume operation terminates with an `ANYPOINT-MQ:ACKING` error.

  For more information, see [Immediate Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack#immediate-acknowledgment).

- **Manual**

  To manually control the acknowledgment of the message, change `acknowledgementMode` to `MANUAL`.
  When using the `MANUAL` acknowledgment mode, the app logic decides when to perform the
  acknowledgment of the message, using the [ACK](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack) or [NACK](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack)
  operations.

  To perform the manual acknowledgment, you need the value of `ackToken` provided as part of the
  resulting message attributes.

  For more information, see [Manual Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack#manual-acknowledgment).

For information about acknowledgment timeouts, see
[Acknowledgment Timeout](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack#acknowledgment-timeout).

## Empty Queue Management

When a queue has messages, the Consume operation returns immediately with one of the messages.

When a queue is empty, the operation behavior depends on the value of the `pollingTime` parameter:

- No value

  By default, the Consume operation waits for 10000 milliseconds (10 seconds) for a new message to
  arrive when consuming from an empty queue.

  If Anypoint MQ receives no messages in that time, Consume fails with an `ANYPOINT-MQ:TIMEOUT`
  error.

- `0`

  If the value of `pollingTime` is `0`, the Consume operation waits for the default of 10000
  milliseconds (10 seconds).

  If Anypoint MQ receives no messages in that time, Consume produces a `null` message as the result
  and doesn’t produce an error.

- `1` to `20000`

  If the value of `pollingTime` is between one and 20000 milliseconds (the maximum value), Consume
  waits for the time specified by `pollingTime` for a new message to arrive.

  If Anypoint MQ receives no messages within the given time window, Consume fails with an
  `ANYPOINT-MQ:TIMEOUT` error.

- If the value of `pollingTime` is outside the range of 0-20000 milliseconds (20 seconds), Consume
  fails with an `ANYPOINT-MQ:CONSUMING` error.

## Output Message Metadata

Each message received consists of two parts: `Payload` and `Attributes`. `Attributes` contains the
metadata for the message.

This metadata maps all the information available in an Anypoint MQ message, including:

- Message ID

- Headers Map

- Properties Map

![Anypoint MQ Message Attributes](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-consume-attributes.png)

For information about the `attributes` structure, see the Consume operation in the
[Anypoint MQ Connector Reference - 3.x](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-connector-reference#consume).

## See Also

- [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack)

<!-- document id=cede518dcf9671fda63a58dd0ca4ae56002020ad71f58b934dbe3718550e2af3 url=/mulesoft/current/en-us/anypoint-mq-connector/latest/anypoint-mq-consume.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Anypoint MQ Consume Operation

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Consume operation in the Anypoint MQ connector enables the app to consume a single message from
a queue at any time in the flow using the acknowledgment strategy that supports your use case.

> [!NOTE] Anypoint MQ supports consuming from queues, not message exchanges.
>
> If an app attempts to consume from a message exchange, the Anypoint MQ REST API throws the
> following error: `The destination should be a queue.`

## Incoming Message Structure

Every incoming message consists of two parts:

- `payload` - Represents the message body

- `attributes` - Contains metadata for the received message, such as its ID or other properties

![Mule message, including payload and message attributes](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-consume-attributes.png)

## Message Consumption

The simplest way to consume a message from a queue is to drag the **Consume** operation from the
Mule palette to the canvas and configure the `Queue` parameter with the name of the queue from which
to retrieve the message:

![Connector configuration, including destination, acknowledgment mode and timeout, and polling timeout](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-consume-operation.png)

```xml
<anypoint-mq:consume config-ref="Anypoint_MQ_config" destination="myQueue"/>
```

The Consume operation in this example consumes the first available message in `myQueue` and converts
it to a `MuleMessage` instance with this structure:

- The message body as payload.

- The message metadata in the message attributes. Attributes might include `messageId` or
  `redeliveryCount`.

Use a DataWeave expression in the `Queue` parameter to dynamically change the target queue from
which to consume the message.

## Consumed Message Acknowledgment

- **Automatic**

  By default, `acknowledgementMode` is `IMMEDIATE`, meaning that the message is acknowledged as soon
  as it is consumed from the queue and before it’s delivered to the Mule flow. If the message
  acknowledgment fails, the Consume operation terminates with an `ANYPOINT-MQ:ACKING` error.

  For more information, see [Immediate Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack#immediate-acknowledgment).

- **Manual**

  To manually control the acknowledgment of the message, change `acknowledgementMode` to `MANUAL`.
  When using the `MANUAL` acknowledgment mode, the app logic decides when to perform the
  acknowledgment of the message, using the [ACK](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack) or [NACK](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack)
  operations.

  To perform the manual acknowledgment, you need the value of `ackToken` provided as part of the
  resulting message attributes.

  For more information, see [Manual Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack#manual-acknowledgment).

For information about acknowledgment timeouts, see
[Acknowledgment Timeout](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack#acknowledgment-timeout).

## Empty Queue Management

When a queue has messages, the Consume operation returns immediately with one of the messages.

When a queue is empty, the operation behavior depends on the value of the `pollingTime` parameter:

- No value

  By default, the Consume operation waits for 10000 milliseconds (10 seconds) for a new message to
  arrive when consuming from an empty queue.

  If Anypoint MQ receives no messages in that time, Consume fails with an `ANYPOINT-MQ:TIMEOUT`
  error.

- `0`

  If the value of `pollingTime` is `0`, the Consume operation waits for the default of 10000
  milliseconds (10 seconds).

  If Anypoint MQ receives no messages in that time, Consume produces a `null` message as the result
  and doesn’t produce an error.

- `1` to `20000`

  If the value of `pollingTime` is between one and 20000 milliseconds (the maximum value), Consume
  waits for the time specified by `pollingTime` for a new message to arrive.

  If Anypoint MQ receives no messages within the given time window, Consume fails with an
  `ANYPOINT-MQ:TIMEOUT` error.

- If the value of `pollingTime` is outside the range of 0-20000 milliseconds (20 seconds), Consume
  fails with an `ANYPOINT-MQ:CONSUMING` error.

## Output Message Metadata

Each message received consists of two parts: `Payload` and `Attributes`. `Attributes` contains the
metadata for the message.

This metadata maps all the information available in an Anypoint MQ message, including:

- Message ID

- Headers Map

- Properties Map

![Mule message, including payload and message attributes](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-consume-attributes.png)

For information about the `attributes` structure, see the Consume operation in the
[Anypoint MQ Connector Reference - 4.x](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-connector-reference#consume).

## See Also

- [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack)

<!-- document id=079463bb4ebdbcb2ed7e0b21e1f6e87f734d6fb574c81a0378761fcd14d71d87 url=/mulesoft/current/en-us/anypoint-mq-connector/2.x/anypoint-mq-publish.md -->

---
product: Anypoint MQ Connector
version: 2.x
---

# Anypoint MQ Publish Operation

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Publish operation in the Anypoint MQ connector lets you create a new Anypoint MQ message and
send it to the specified destination, be it a queue, FIFO queue, or a message exchange. With it, you
can configure not only the content of the message, but also all the headers and properties you need.

## Send a Message

When used in its default form, the connector publishes whatever is in its message payload:

```xml
<anypoint-mq:publish destination="invoiceQueue" config-ref="MQ_config"/>
```

But what happens if the payload is not in the correct format, and you actually need to make a
transformation? You can place a DataWeave transformation before the `publish` operation, but that
would cause the message payload to change and impact the operation placed after the `publish`
operation.

To avoid this undesired impact, you can now place the transformation inside the `publish` operation:

```xml
<anypoint-mq:publish destination="invoiceQueue" config-ref="MQ_config">
  <anypoint-mq:body>#[%dw 2.0
   output application/json
   ---
   payload.payments
   ]</anypoint-mq:body>
</anypoint-mq:publish>
```

The transformation can be used for generating the content that is published, without producing a
side effect on the message in transit.

## Configure User Properties

Every Anypoint MQ message can have a set of properties, which can be used in many different ways,
such as to provide compatibility with other messaging systems or to communicate the content-type of
a message. The `publish` operation allows you to configure these properties directly in the message.

When you need to set a property for an outgoing message, you can use the `properties` element in the
message:

```xml
<anypoint-mq:publish config-ref="MQ_config" destination="${bridgeDestination}"
                     properties="#[{AUTH_TYPE: 'jwt', AUTH_TOKEN: attributes.queryParams.token}]">
    <anypoint-mq:body>#["bridged_" ++ payload]</anypoint-mq:body>
</anypoint-mq:publish>
```

## See Also

- [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-listener)

<!-- document id=311c438dadeed8898736a9a80c99198d4b8925d17f58f65ed3942601f87adee3 url=/mulesoft/current/en-us/anypoint-mq-connector/3.x/anypoint-mq-publish.md -->

---
product: Anypoint MQ Connector
version: 3.x
---

# Anypoint MQ Publish Operation

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Publish operation enables you to create a new Anypoint MQ message and send it to the specified
destination: queue, FIFO queue, or message exchange. With it, you can configure both the content of
the message and all the headers and properties you need.

## Outgoing Message Structure

Messages contain these parameters:

- `body`

  Contains the body of the published Anypoint MQ message.

- `properties`

  Represents a simple key-value map of strings that are the message properties of the message.

## Send a Message

When used in its default form, the connector publishes the content found in the incoming message
`payload` as `body` of the Anypoint MQ message, serialized as a string, to the declared
`destination`:

![Anypoint MQ Publish Operation](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-operation.png)

```xml
<anypoint-mq:publish destination="invoiceQueue" config-ref="Anypoint_MQ_config"/>
```

This operation produces the following output:

- A copy of the body sent as payload

  For example, if you are sending a "Hello world" message, the resulting payload is the "Hello
  world" string.

- The message `messageId` value in the message attributes

![Anypoint MQ Publish Operation Output Attributes](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-attributes.png)

## Configure User Properties

You can define properties for outgoing messages, for example, to provide compatibility with other
messaging systems or to communicate the content type of a message. Anypoint MQ supports strings and
numbers in property values.

> [!IMPORTANT] If you create routing rules on numeric property values and you use Anypoint MQ
> Connector to publish messages, you must upgrade to Anypoint MQ Connector version 3.2.0 or later.
> Previous versions of the connector send all property values as strings, which results in messages
> not matching routing rules on numeric properties.

To configure these properties directly in the message, use the `properties` parameter of the Publish
operation and define a key-value map using DataWeave.

For example:

![Anypoint MQ Publish With Properties](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-properties.png)

```xml
<anypoint-mq:publish config-ref="Anypoint_MQ_Config"
    destination="invoiceQueue">
  <anypoint-mq:properties><![CDATA[#[output application/java ---
      {
          AUTH_TYPE: 'jwt',
          AUTH_TOKEN: attributes.queryParams.token
        }]]]>
      <anypoint-mq:properties>
</anypoint-mq:publish>
```

User properties that you define in the Publish operation appear in Anypoint MQ in the **Message
Browser** details pane for the message:

![User Properties in Message Browser details pane](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-user-props.png)

Figure 1. The screen shows (**1**) the **Message Browser** option and (**2**) the **User
Properties** in the details pane.

### Transform the Message Body

If the payload is not in the correct format, you can transform it to the correct format.

To transform a payload, declare an inline DataWeave transformation in the `body` parameter of the
Publish operation:

![Anypoint MQ Publish With Transformation](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-transformed.png)

```xml
<anypoint-mq:publish config-ref="Anypoint_MQ_Config"
   destination="invoiceQueue">
      <anypoint-mq:body ><![CDATA[#[output application/json ---
      {
        customer: payload.id,
        items: payload.invoice.items
      }]]]>
      </anypoint-mq:body>
</anypoint-mq:publish>
```

In this case, the result of the operation is the _transformed_ value as JSON.

## Advanced Configurations

You might want to set a unique custom message ID instead of letting Anypoint MQ generate it. You can
also add the content type of the message body as a property.

### Set a Custom Message ID

Instead of letting Anypoint MQ generate a unique `messageId` value for the new published message,
set a custom `messageId` value in the **Message Id** field in the **Advanced** tab:

![Anypoint MQ Publish Advanced Tab - Message Id](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-advanced.png)

The ID of an Anypoint MQ message must be unique. Make sure to choose a unique custom ID to avoid
unwanted side effects of duplicated IDs. FIFO queues provide message deduplication. If multiple
messages are sent to a FIFO queue containing the same message ID, the first message to arrive is
kept as the valid message. See
[FIFO Exactly-Once Delivery](https://docs.mulesoft.com/mq/mq-queues#fifo-exactly-once-delivery) for more information.

### Delay Message Delivery

Anypoint MQ supports the ability to publish a message and postpone making it visible to consumers
using the `deliveryDelay` parameter:

1.  Select the Publish operation.

2.  Click the **Advanced** tab.

3.  Set the **Delivery Delay** parameter to the amount of time to delay:

    ![Anypoint MQ Publish Advanced Tab - Delivery Delay](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-advanced-delay.png)

    By default, the `deliveryDelay` parameter is set to `0`, which specifies to deliver messages
    immediately (no delay). The maximum `deliveryDelay` value is 15 minutes.

    See [Delayed Message Delivery](https://docs.mulesoft.com/mq/mq-glossary#delay-messages) for more information.

4.  Select the unit from the **Delivery Delay Unit** menu.

### Set a Message Group ID

When using FIFO queues, you can assign a message group ID to an outgoing message using the
`messageGroupID` parameter:

1.  Select the Publish operation.

2.  Click the **Advanced** tab.

3.  Enter an ID in the **Message Group ID** field:

    ![Anypoint MQ Publish Advanced Tab - Message Group ID](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-publish-advanced-groupid.png)

    By default, all messages sent to a FIFO queue have the same autogenerated group ID.

    See [FIFO Queues and Message Groups](https://docs.mulesoft.com/mq/mq-queues#fifo-queues-msg-groups) for more
    information.

To get the maximum value from message groups, define more granular groups with fewer messages in
each group. For example, when processing messages from multiple users, to keep each user’s events in
relative order, use the value of the user’s `userId` as the message group ID.

### Propagate Content Type

To specify whether the content type of the message body is propagated as a property of the Anypoint
MQ message or not, use the `sendContentType` parameter.

Setting this parameter to `true` automatically adds a `contentType` property to the outgoing
message. This can be useful to declare that a message body is in `application/json` or
`application/xml` format.

## See Also

- [Anypoint MQ Subscriber Source](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-listener)

- [Anypoint MQ Glossary](https://docs.mulesoft.com/mq/mq-glossary)

- [Configuring and Using Queues](https://docs.mulesoft.com/mq/mq-queues)

<!-- document id=4736c67727afda9238a5103df49413314fe77cf759dd3b8d68333be19ca4cccb url=/mulesoft/current/en-us/anypoint-mq-connector/latest/anypoint-mq-publish.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Anypoint MQ Publish Operation

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Publish operation enables you to create a new Anypoint MQ message and send it to the specified
destination: queue, FIFO queue, or message exchange. With it, you can configure both the content of
the message and all the headers and properties you need.

## Outgoing Message Structure

Messages contain these parameters:

- `body`

  Contains the body of the published Anypoint MQ message.

- `properties`

  Represents a simple key-value map of strings that are the message properties of the message.

## Send a Message

When used in its default form, the connector publishes the content found in the incoming message
`payload` as `body` of the Anypoint MQ message, serialized as a string, to the declared
`destination`:

![Publish configuration window showing Destination set to invoiceQueue](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-publish-operation.png)

```xml
<anypoint-mq:publish destination="invoiceQueue" config-ref="Anypoint_MQ_config"/>
```

This operation produces the following output:

- A copy of the body sent as payload

  For example, if you are sending a "Hello world" message, the resulting payload is the "Hello
  world" string.

- The message `messageId` value in the message attributes

![Mule message output, including payload and message attributes](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-publish-attributes.png)

## Configure User Properties

You can define properties for outgoing messages, for example, to provide compatibility with other
messaging systems or to communicate the content type of a message. Anypoint MQ supports strings and
numbers in property values.

> [!IMPORTANT] If you create routing rules on numeric property values and you use Anypoint MQ
> Connector to publish messages, you must upgrade to Anypoint MQ Connector version 3.2.0 or later.
> Previous versions of the connector send all property values as strings, which results in messages
> not matching routing rules on numeric properties.

To configure these properties directly in the message, use the `properties` parameter of the Publish
operation and define a key-value map using DataWeave.

For example:

![Connector configuration showing AUTH\_TYPE and AUTH\_TOKEN attributes](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-publish-properties.png)

```xml
<anypoint-mq:publish config-ref="Anypoint_MQ_Config"
    destination="invoiceQueue">
  <anypoint-mq:properties><![CDATA[#[output application/java ---
      {
          AUTH_TYPE: 'jwt',
          AUTH_TOKEN: attributes.queryParams.token
        }]]]>
      <anypoint-mq:properties>
</anypoint-mq:publish>
```

User properties that you define in the Publish operation appear in Anypoint MQ in the **Message
Browser** details pane for the message:

![Message Browser showing the message’s user properties](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-publish-user-props.png)

### Transform the Message Body

If the payload is not in the correct format, you can transform it to the correct format.

To transform a payload, declare an inline DataWeave transformation in the `body` parameter of the
Publish operation:

![Connector configuration showing a DataWeave transformation](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-publish-transformed.png)

```xml
<anypoint-mq:publish config-ref="Anypoint_MQ_Config"
   destination="invoiceQueue">
      <anypoint-mq:body ><![CDATA[#[output application/json ---
      {
        customer: payload.id,
        items: payload.invoice.items
      }]]]>
      </anypoint-mq:body>
</anypoint-mq:publish>
```

In this case, the result of the operation is the _transformed_ value as JSON.

## Advanced Configurations

You might want to set a unique custom message ID instead of letting Anypoint MQ generate it. You can
also add the content type of the message body as a property.

### Set a Custom Message ID

Instead of letting Anypoint MQ generate a unique `messageId` value for the new published message,
set a custom `messageId` value in the **Message Id** field in the **Advanced** tab:

![Publish configuration window Advanced tab showing Message ID set to 12345](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-publish-advanced.png)

The ID of an Anypoint MQ message must be unique. Make sure to choose a unique custom ID to avoid
unwanted side effects of duplicated IDs. FIFO queues provide message deduplication. If multiple
messages are sent to a FIFO queue containing the same message ID, the first message to arrive is
kept as the valid message. See
[FIFO Exactly-Once Delivery](https://docs.mulesoft.com/mq/mq-queues#fifo-exactly-once-delivery) for more information.

### Delay Message Delivery

Anypoint MQ supports the ability to publish a message and postpone making it visible to consumers
using the `deliveryDelay` parameter:

1.  Select the Publish operation.

2.  Click the **Advanced** tab.

3.  Set the **Delivery Delay** parameter to the amount of time to delay:

    ![Publish configuration window Advanced tab showing Delivery Delay set to 2000](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-publish-advanced-delay.png)

    By default, the `deliveryDelay` parameter is set to `0`, which specifies to deliver messages
    immediately (no delay). The maximum `deliveryDelay` value is 15 minutes.

    See [Delayed Message Delivery](https://docs.mulesoft.com/mq/mq-glossary#delay-messages) for more information.

4.  Select the unit from the **Delivery Delay Unit** menu.

### Set a Message Group ID

When using FIFO queues, you can assign a message group ID to an outgoing message using the
`messageGroupID` parameter:

1.  Select the Publish operation.

2.  Click the **Advanced** tab.

3.  Enter an ID in the **Message Group ID** field:

    ![Publish configuration window Advanced tab showing Message Group ID set to #\[vars.userId\]](_images/amq-4x-publish-advanced-groupid.png)

    By default, all messages sent to a FIFO queue have the same autogenerated group ID.

    See [FIFO Queues and Message Groups](https://docs.mulesoft.com/mq/mq-queues#fifo-queues-msg-groups) for more
    information.

To get the maximum value from message groups, define more granular groups with fewer messages in
each group. For example, when processing messages from multiple users, to keep each user’s events in
relative order, use the value of the user’s `userId` as the message group ID.

### Propagate Content Type

To specify whether the content type of the message body is propagated as a property of the Anypoint
MQ message or not, use the `sendContentType` parameter.

Setting this parameter to `true` automatically adds a `contentType` property to the outgoing
message. This can be useful to declare that a message body is in `application/json` or
`application/xml` format.

## See Also

- [Anypoint MQ Subscriber Source](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-listener)

- [Anypoint MQ Glossary](https://docs.mulesoft.com/mq/mq-glossary)

- [Configuring and Using Queues](https://docs.mulesoft.com/mq/mq-queues)

<!-- document id=9214543ed70e93683dd405cf7d0662e737cb437e26752b1ad096dfd12edf4e30 url=/mulesoft/current/en-us/anypoint-mq-connector/2.x/anypoint-mq-listener.md -->

---
product: Anypoint MQ Connector
version: 2.x
---

# Anypoint MQ Subscriber Source

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Subscriber source in the Anypoint MQ connector provides the ability to consume messages as they
arrive to the destination. Tuning the subscriber behavior is done from within a connector’s
configuration.

## Message Prefetch

By default, a connector provides a configuration that optimizes maximum message throughput. This
means that when message `prefetch` is enabled, the maximum `fetchSize` is possible.

> [!IMPORTANT] When using `prefetch` mode, the subscriber attempts to keep a local buffer of three
> times the `fetchSize` filled at any given time, meaning that it makes as many service calls as
> needed (with up to three concurrent calls) to retrieve messages and make them available to the
> buffer. Messages are then taken from the local buffer and dispatched to the flow for processing.

The buffer is most likely to never be full in that Mule accepts many messages very fast and uses as
many threads as possible to process them concurrently. Not all the requests to the service may
provide the maximum number of messages possible defined by the **fetchSize**, so more than three
requests may be necessary to fill the buffer in cases of low load.

> [!NOTE] Due to a known issue, using `prefetch` mode with `maxConcurrency="1"` set on the `flow`
> element might result in message-processing latency. NOTE: Due to a known issue, using `prefetch`
> mode with `maxConcurrency="1"` set on the `flow` element might result in message-processing
> latency.

Prefetch can be tuned using the configuration element:

```xml
<anypoint-mq:default-subscriber-config name="defaultPrefetchConfig"
        fetchSize="5"
        fetchTimeout="1000"
        frequency="4000">
    <anypoint-mq:connection url="${providerUrl}" clientId="${clientId}"
            clientSecret="${clientSecret}"/>
</anypoint-mq:default-subscriber-config>

<flow name="prefetchedListener">
    <anypoint-mq:subscriber config-ref="defaultPrefetchConfig"
    destination="${invoiceQueue}"/>

    <!-- Message processing-->
</flow>
```

In this example, reducing the amount of messages retrieved per API call reduces the buffer size,
effectively having a buffer of 15 messages instead of the 30 that are preserved by default.

Other parameters like `fetchTimeout` and `frequency` modify the behavior of the subscriber when the
queue is empty and when the connector is waiting for a message to arrive.

For details on how each parameter works, see the
[Anypoint MQ Connector Reference - 2.x](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-connector-reference#configurations).

### Buffer, Acknowledgment, and Acknowledgment Timeout

While in the buffer, messages are kept as in-flight for the broker, so no redelivery occurs as long
as needed for the message to be dispatched to the flow, or until the Subscriber source is stopped
and the buffer cleared. Once dispatched, a message remains in-flight until the
`acknowledgementTimeout` elapses.

By default, a consumed message is acknowledged only when the execution of the flow receiving the
message finishes successfully. If an error occurs during the execution of the flow, the session
recovers and the message is redelivered.

For more information, see [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-ack).

## Poll for New Messages

To have more control on how many messages are consumed by each subscriber, you can use a **polling**
configuration, thus polling for messages from the service at a fixed rate.

This behavior is achieved effectively by disabling `prefetch` by setting a `fetchSize` of zero. When
using the polling mode, the connector always attempts to fetch 10 messages per request, where each
request is done at the fixed rate defined by the `pollingTime`. No overlapping requests are executed
and only one request per poll is handled by the service.

The syntax to listen for new messages from a queue at a fixed rate is:

```xml
<anypoint-mq:default-subscriber-config name="pollingConfig"
                                       fetchSize="0"
                                       pollingTime="1000"
                                       acknowledgementTimeout="5000">
    <anypoint-mq:connection url="${providerUrl}"
                                      clientId="${clientId}"
                                      clientSecret="${clientSecret}"/>
</anypoint-mq:default-subscriber-config>

<flow name="prefetchedListener">
    <anypoint-mq:subscriber config-ref="pollingConfig" destination="${invoiceQueue}"/>

    <!-- Message processing-->
</flow>
```

This source tries to retrieve 10 messages from the queue identified by the destination every 1
second, and then dispatches each to the flow as a `MuleMessage`. In this case, the message remains
in flight for 5 seconds.

The Mule message has:

- The message’s content as its payload.

- The message’s metadata in the message attributes.

By default, the message consumed is acknowledged only when the execution of the flow receiving the
message finishes successfully. If instead, an error occurs during the execution of the flow, the
session is recovered and the message is redelivered.

For more information, see [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-ack).

## Circuit Breaker Capability

Since version 2.1.0, the Anypoint MQ connector Subscriber source provides circuit breaking
capability, enabling you to have more control on how the connector deals with errors that occurred
while processing a consumed message.

### Circuit Breaker

In any scenario in which you need to connect to a service, consider what happens when an external
service fails. A common pattern to deal with downtime of an external service is the Circuit Breaker,
which allows the system to stop making requests that are doomed to fail, and also allowing the
external service to recover under a reduced load. The Circuit Breaker goes through three different
states (Closed, Open, Half Open), changing the behavior of the app based on the current state. See
the
[Microsoft Circuit Breaker Pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)
site for more information.

In a Mule 4 app using Anypoint MQ means having a Mule flow with an Anypoint MQ Subscriber that
consumes messages from a queue, and processes it using an external service. When this service is not
available and the request fails, an error propagates and processing of the message finishes as a
failure or as a custom error for handling the message, such as sending it to a DLQ. When the
external service is not available, every attempt to process a message results in a failure, forcing
the app to loop on consuming messages that cannot succeed. This can be avoided if the subscriber is
notified of the error in a way that prevents it from consuming more messages for a certain period.

### Circuit Breaker Processes

The circuit breaker capability provided by the `anypoint-mq:subscriber` is bound to the error
handling mechanism that Mule provides out of the box, using the errors notification mechanism to
keep a count of errors related to an external service, which is known as circuit failures. You can
bind any error to a circuit failure, for example you can bind `HTTP:TIMEOUT`,
`FTP:SERVICE_NOT_AVAILABLE`, or even a custom error from your app like `ORG:EXTERNAL_ERROR`.

If a Mule flow finishes its execution with an error, the subscriber checks if the error is one of
the `onErrorTypes` that indicate an external service error, and counts consecutive occurrences until
the `errorsThreshold` is reached. When the `errorsThreshold` is reached, the circuit trips and stops
polling for new messages for a configurable `tripTimeout` duration. Messages are consumed again on
the next poll after the tripTimeout elapses. By default, the circuit breaking feature is disabled.

### Circuit Breaker States

- Closed

  The starting state where the subscriber retrieves messages normally from Anypoint MQ based on its
  configuration, effectively working as if the Circuit Breaker is not present.

- Closed-Open Transition

  When the amount of failures occurs one after the other during message processing, without any
  success in between the failures and reaches the `errorsThreshold` value, then the circuit breaker
  trips and transition changes to an open state.

  Messages that were already dispatched to the flow then finishes processing, regardless if the
  result is success or failure.

  Messages kept locally which are in-flight for the broker but haven’t been dispatched yet, are not
  acknowledged and returned to the queue for redelivery to another consumer.

- Open

  The subscriber doesn’t attempt to retrieve messages, and skips the iterations silently until the
  `tripTimeout` is reached.

- Half Open

  After the `tripTimeout` elapses, the subscriber goes to a Half Open state meaning that in the next
  poll for messages, it retrieves a single message from the service and uses that message to check
  if the system has recovered before going back to the normal Closed state.

  When a single message is successfully fetched, dispatched to the flow, and its processing finishes
  with a success, then the subscriber goes back to normal and immediately attempts to fetch more
  messages.

  If Mule flow processing fails with one of the expected `onErrorTypes`, the circuit goes back to an
  Open state and resets the `tripTimeout` timer.

### Configure the Circuit Breaker

You can configure a Circuit Breaker as part of the `anypoint-mq:default-subscriber-config`.

In Anypoint Studio in the Advanced tab, enable the Circuit Breaker group and populate the following
fields as needed:

- onErrorTypes

  The error types whose occurrence during the flow execution counts as a failure in the circuit. An
  error occurrence counts only when the flow finishes with an error propagation. By default all
  errors count as a circuit failure.

- errorsThreshold

  The number of `onErrorTypes` errors have to occur for the circuit breaker to open.

- tripTimeout

  How long the circuit remains open once the `errorsThreshold` is reached.

- circuitName

  The name of a circuit breaker to bind to this configuration. By default each queue has its own
  circuit breaker.

#### Circuit Configuration for a Single Subscriber

In an example scenario where there’s a single `anypoint-mq:subscriber` consuming messages from a
queue and posting the messages to another service using its REST API, you can stop processing
messages after 5 requests to the external service result in a timeout. Once that happens, the
example waits for 30 seconds for the service to recover before retrying with a new message.

For this one config is needed with these circuit breaker parameters:

```xml
<anypoint-mq:default-subscriber-config name="ConfigWithCircuit" >
   	<anypoint-mq:connection url="${providerUrl}" clientId="${clientId}" clientSecret="${clientSecret}"/>
<anypoint-mq:circuit-breaker
           onErrorTypes="HTTP:TIMEOUT" (1)
           errorsThreshold="5" (2)
           tripTimeout="30" (3)
           tripTimeoutUnit="SECONDS"/>
</anypoint-mq:default-subscriber-config>

<flow name="subscribe">
   <anypoint-mq:subscriber config-ref="ConfigWithCircuit" destination="${subscriberQueue}"/> (4)
    <http:request config-ref="RequesterConfig" path="/external" method="POST"/> (5)
</flow>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Configure the error types to trip the circuit. When an error occurs for an <code>errorsThreshold</code> amount of times, polling stops.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Set the threshold for how many consequent messages have to occur to consider that the circuit is in a failure state.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>After the circuit breaker trips because the <code>errorsThreshold</code> is reached, configure how long to wait before you resume polling new messages.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>On the subscriber, we just need to reference the config with the circuit breaker.</td></tr><tr><td><i data-value="5"></i><b>5</b></td><td>Define the operation to throw the error expected by the <code>onErrorTypes</code> parameters.</td></tr></tbody></table>

It’s important to notice that any other error not listed in the `onErrorTypes` parameter is ignored
by the circuit breaker. For this example, errors like \`HTTP:BAD\_REQUEST\`are ignored.

#### Share a Circuit From Different Queues

In many cases there’s a single common service between the processing of messages from different
queues. This example configures the `circuitName` parameter to bind both subscribers to a single
circuit:

```xml
<anypoint-mq:default-subscriber-config name="ConfigWithCircuit" >
   	<anypoint-mq:connection url="${providerUrl}" clientId="${clientId}" clientSecret="${clientSecret}"/>
<anypoint-mq:circuit-breaker
           circuitName="InvoiceProcess" (1)
           onErrorTypes="FTP:RETRY_EXHAUSTED, HTTP:SERVICE_UNAVAILABLE" (2)
           errorsThreshold="10"
           tripTimeout="5"
           tripTimeoutUnit="MINUTES"/>
</anypoint-mq:default-subscriber-config>

<flow name="subscribe">
    <anypoint-mq:subscriber  config-ref="ConfigWithCircuit" destination="${reservationsQueue}"/> (3)
    <flow-ref name="invoiceProcess">
</flow>

<flow name="otherSubscribe">
    <anypoint-mq:subscriber  config-ref="ConfigWithCircuit" destination="${paymentsQueue}"/> (3)
    <flow-ref name="invoiceProcess">
</flow>

<sub-flow name="invoiceProcess">
  <ftp:write path="${auditFolder}" config-ref="ftp-config"/> (4)
  <http:request config-ref="requestConfig" path="/external"/> (5)
</sub-flow>
```

<table><tbody><tr><td><i data-value="1"></i><b>1</b></td><td>Set the <code>circuitName</code> parameter to share a common circuit breaker on multiple queues.</td></tr><tr><td><i data-value="2"></i><b>2</b></td><td>Consider the two different errors that can affect the processing of messages from the subscriber, passing each as a CSV list.</td></tr><tr><td><i data-value="3"></i><b>3</b></td><td>For both subscribers, reference the config with the circuit breaker configuration.</td></tr><tr><td><i data-value="4"></i><b>4</b></td><td>This component may throw an <code>FTP:RETRY_EXHAUSTED</code> error along with many others. Only the <code>FTP:RETRY_EXHAUSTED</code> error is taken into account by the circuit breaker.</td></tr><tr><td><i data-value="5"></i><b>5</b></td><td>The HTTP connector may throw an <code>HTTP:SERVICE_UNAVAILABLE</code> preventing the message to be processed.</td></tr></tbody></table>

In this scenario, both subscribers stop polling for messages as soon as the error count reaches the
`errorsThreshold="10"` value, counting both `FTP:RETRY_EXHAUSTED` and `HTTP:SERVICE_UNAVAILABLE`
errors. When the `tripTimeout` value elapses, one of the subscribers polls for a message and uses it
to test the circuit, enabling the polling for both subscribers if the processing of that message
succeeds.

## FIFO Queues

FIFO queues are most suitable for single-consumer scenarios. When one consumer is accessing a
message, all other consumers are blocked until the first batch is processed. No messages are
delivered until all in-flight messages are acknowledged or not acknowledged.

With message groups, multiple consumers can access messages in a FIFO queue at the same time. In
this case, one consumer accesses messages in a group and another consumer accesses messages in
another group. Message order is preserved within each message group.

Always use a single-thread flow configuration when consuming messages from a FIFO queue. If flow
processing is not single-threaded, messages processing order might be lost.

### FIFO Queues and Clustering

FIFO queues behave the same in a clustered environment as in a non-clustered environment.

FIFO queues consume messages in the specified order. After the message is consumed, any further
message processing can be distributed to other nodes. In this case, if the consumer acknowledges a
message before it is fully processed, message order might be lost during message processing.

- In an
  [on-premises, high availability clustering environment](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters),
  the Subscriber source in the Anypoint MQ connector runs on all nodes by default.

  You can change the behavior to run as a primary node by selecting **Primary node only** in the
  **Advanced** tab.

- In [CloudHub](https://docs.mulesoft.com/cloudhub/) with multiple workers, all workers are run as a primary node.

  In this case, all workers running the application consume from the same FIFO queue.

## See Also

- [Anypoint MQ Consume Operation](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-consume)

- [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/2.x/anypoint-mq-ack)

<!-- document id=280e5bce9368f83c3b4a40c18245691a7c94d0caf696b85e2e8c843e95db6a22 url=/mulesoft/current/en-us/anypoint-mq-connector/3.x/anypoint-mq-listener.md -->

---
product: Anypoint MQ Connector
version: 3.x
---

# Anypoint MQ Subscriber Source

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Subscriber source in the Anypoint MQ connector enables the app to listen for new messages and
consume them as they arrive at the destination. You can configure different listening strategies
that enable you to tune the consumption for performance, predictability, and schedules.

## Maximum Message Throughput

By default, the Subscriber source works in continuous listening mode, providing maximum throughput
by consuming messages as soon as they arrive in the queue. This is called the `prefetch`
subscriber-type configuration. When using the `prefetch` mode, the Subscriber source attempts to
keep a local buffer of messages full, making them available to be dispatched to the Mule flow as
soon as the app can accept them.

![Prefetch subscriber type](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-subscriber-prefetch.png)

Figure 1. The arrow shows **Subscriber type** set to **Prefetch** in the **Subscriber** properties
window.

> [!NOTE] Due to a known issue, using `prefetch` mode with `maxConcurrency="1"` set on the `flow`
> element might result in message-processing latency.

For the `prefetch` subscriber-type configuration, you configure the `maxLocalMessages` parameter to
specify the target size for a full buffer, which controls how quickly messages are taken from the
queue.

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config" destination="myQueue">
</anypoint-mq:subscriber>
```

- Use a larger buffer size for maximum performance, keeping in mind that the messages kept locally
  won’t be available for any other consumer.

  When a consumer takes a message from the queue and stores it in the local buffer, the message
  appears as in-flight for any other consumer and prevents them from consuming it. The message
  remains in this in-flight state for as long as necessary for the app to begin the processing.

- Use a smaller buffer size to process messages as they are published to the queue.

  The smaller buffer restricts app-level throughput and avoids blocking competing consumers.

  When using `prefetch` mode, set `maxLocalMessages` to a value greater than `1` to avoid
  message-processing latency issues. When `maxLocalMessages` is set to `1`, latency can occur when
  the connector prefetches the message but the app doesn’t consume it, and the message returns to
  the queue for reprocessing.

### FIFO Queues and Prefetch Mode

When using the `prefetch` mode, the `acknowledgementTimeout` timer begins when the message is taken
from the queue. Anypoint MQ attempts to honor the expiration time specified by
`acknowledgementTimeout`. However, Anypoint MQ extends the expiration timeout if the time that the
message remains in the buffer reaches 80% of the timeout value.

Don’t use `prefetch` mode in the following situations:

- Applications with long processing times that use the `maxConcurrency` attribute to limit
  concurrent processing.

  These options can cause messages to remain in the buffer longer, which can result in the messages
  expiring and being sent back to the queue.

- When using FIFO queues

  Because Anypoint MQ can’t guarantee ordering when using `prefetch` mode, don’t use it with FIFO
  queues.

  Using `prefetch` mode for applications with long processing times can consume significant
  resources because Anypoint MQ monitors the ACK TTL for all messages in the local buffer and
  extends the TTL to avoid sending messages back to the queue.

## Predictable Message Consumption

If your app requires predictable and controlled message consumption rather than maximum throughput,
you can configure the Subscriber as a polling source. The Subscriber source checks for new messages
in the queue at a fixed scheduling rate. Every time the poll is triggered, the Subscriber source
retrieves between 1 and 10 messages to dispatch to the flow individually in order.

Messages aren’t consumed immediately. Instead, they remain in the queue until the next poll of the
Subscriber source is triggered. The queue contains up to 10 messages to be retrieved. For example,
if your queue has 15 messages, one poll consumes the first 10 messages and the remaining 5 messages
wait for the next poll.

To configure the Subscriber as a polling source, specify the `polling` subscriber-type.

The default `polling` subscriber-type declaration looks like this:

![Polling subscriber type](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-subscriber-polling.png)

Figure 2. The arrow shows **Subscriber type** set to **Polling** in the **Subscriber** properties
window.

```xml
<anypoint-mq:subscriber doc:name="Subscriber" config-ref="Anypoint_MQ_Config" destination="myQueue">
  <anypoint-mq:subscriber-type >
    <anypoint-mq:polling >
      <scheduling-strategy >
        <fixed-frequency />
      </scheduling-strategy>
    </anypoint-mq:polling>
  </anypoint-mq:subscriber-type>
</anypoint-mq:subscriber>
```

The default `polling` subscriber-type declaration attempts to retrieve 10 messages from the declared
destination every 1 second, dispatching the retrieved messages to the flow individually as a
`MuleMessage` instance.

The resulting `MuleMessage` has:

- The message body as its payload

- The message metadata in the message attributes

![Message output payload and attributes](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-subscriber-output.png)

Figure 3. The screenshot shows (**1**) **Payload** and (**2**) **Attributes** of the message in the
**Output** tab.

You can customize the Subscriber source polling strategy using the standard Mule runtime engine
scheduling strategies:

- [Fixed Frequency](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#fixed-frequency)

- [Cron Expressions](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#cron-expressions)

### Customized Fixed Polling

You can customize the frequency at which the Subscriber source polls for new messages by declaring a
`polling` subscriber-type strategy with a customized `fixed-frequency` scheduling strategy.

The default `fixed-frequency` scheduling strategy declaration looks like this:

![Fixed Frequency Scheduling Strategy](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-subscriber-polling-fixed.png)

Figure 4. The arrow shows **Scheduling Strategy** set to **Fixed Frequency** in the **Subscriber**
properties window.

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config" destination="myQueue">
  <anypoint-mq:subscriber-type >
    <anypoint-mq:polling>
      <scheduling-strategy >
        <fixed-frequency/>
      </scheduling-strategy>
    </anypoint-mq:polling>
  </anypoint-mq:subscriber-type>
</anypoint-mq:subscriber>
```

### Cron-Based Polling

The Anypoint MQ Subscriber can also use a `cron` scheduling strategy, which enables you to schedule
jobs such as "Run every minute starting at 2pm and ending at 2:59pm, every day". To use this
scheduling strategy, declare a `polling` subscriber-type strategy with a customized `cron`
scheduling strategy:

![Cron Scheduling Strategy](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-subscriber-polling-cron.png)

Figure 5. The arrow shows **Scheduling Strategy** set to **Cron** in the **Subscriber** properties
window.

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config" destination="myQueue">
  <anypoint-mq:subscriber-type >
    <anypoint-mq:polling >
      <scheduling-strategy >
        <cron expression="0 * 14 * * ?" timeZone="America/Los_Angeles" />
      </scheduling-strategy>
    </anypoint-mq:polling>
  </anypoint-mq:subscriber-type>
</anypoint-mq:subscriber>
```

## Message Acknowledgment

You can acknowledge received messages automatically only if the flow execution finishes successfully
or as your app consumes them, before processing them.

- **Automatic**

  By default, the Subscriber source uses the AUTO acknowledgment mode. With this mode, the messages
  that the Subscriber source retrieves are acknowledged automatically after message flow processing
  succeeds. This means that the Subscriber source receives a message, dispatches it to the flow, and
  waits to see how the message processing finishes. It executes an ACK only when the processing
  finishes without exceptions.

  If the execution of the processing flow finishes with a propagated exception, the message is
  automatically not acknowledged and is returned to the queue for redelivery.

  For more information, see [Automatic Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack#automatic-acknowledgment).

- **Immediate**

  When you use the `IMMEDIATE` acknowledgment mode, the consumed message is acknowledged (deleted
  from the queue) and then dispatched to the Mule flow for processing. If the message acknowledgment
  fails, the message is discarded. The message isn’t dispatched to the flow and remains in-flight
  until the acknowledgment timeout.

  If the app restarts between being acknowledged and dispatched, the message might not be available
  again because it was deleted from the queue. To prevent message deletion until after processing,
  use the `AUTO` or `MANUAL` acknowledgment mode instead.

  Using the Subscriber source in Prefetch mode with the `IMMEDIATE` acknowledgment mode sometimes
  results in thread accumulation and an unresponsive application.

  For more information, see [Immediate Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack#immediate-acknowledgment).

- **Manual**

  When you use the MANUAL acknowledgment mode, the app logic decides when to perform the
  acknowledgment of the message, using the [ACK](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack) or [NACK](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack)
  sources.

  To perform the manual acknowledgment, you need the value of `ackToken` provided as part of the
  resulting message attributes.

  For more information, see [Manual Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack#manual-acknowledgment).

For information about acknowledgment timeouts, see
[Acknowledgment Timeout](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack#acknowledgment-timeout).

## Circuit Breaker Capability

The Subscriber source provides circuit breaking capability, which enables you to control how the
connector handles errors that occur while processing a consumed message.

For example, when connecting to an external service, you can use the circuit breaker to handle any
downtime of that service. The circuit breaker allows the system to stop making requests and allows
the external service to recover under a reduced load.

Using Anypoint MQ in a Mule 4 app means having a Mule flow with an MQ subscriber that consumes
messages from a queue and processes them using an external service. When this service isn’t
available:

1.  The request fails.

2.  An error results.

3.  Message processing finishes as either a failure or as a custom error for handling the message,
    such as sending it to a dead letter queue (DLQ).

When the external service is not available, every attempt to process a message results in a failure,
forcing the app to loop, consuming messages that cannot succeed. You can avoid this behavior by
notifying the subscriber of the error in a way that prevents it from consuming more messages for a
certain period.

### Circuit Breaker Processes

The circuit breaker capability that the Subscriber source provides is bound to the error handling
mechanism provided by Mule. It uses the error notification mechanism to count errors related to an
external service, which is known as a circuit failure. You can bind any error to a circuit failure.
For example, you can bind `HTTP:TIMEOUT`, `FTP:SERVICE_NOT_AVAILABLE`, or even a custom error from
your app, such as `ORG:EXTERNAL_ERROR`.

If a Mule flow finishes its execution with an error, the Subscriber source checks if the error is
one of the `onErrorTypes` that indicates an external service error, and counts consecutive
occurrences until `errorsThreshold` is reached.

When `errorsThreshold` is reached, the circuit trips and remains open for the duration specified by
`tripTimeout`. While the circuit is open, all polled or consumed messages are not acknowledged
(NACK) and Anypoint MQ halts any future operations (poll, ACK, NACK, and Publish) until
`tripTimeout` elapses.

After `tripTimeout` elapses, the circuit breaker transitions to a new
[state](#circuit-breaker-states). If the new state is **Closed**, clients can consume messages on
the next poll.

The behavior varies depending on whether you deploy the app to CloudHub with a single worker or
multiple workers:

Single worker

The worker processes messages individually from the queue and opens the circuit breaker when the
number of errors reaches the value of `errorsThreshold`.

Multiple workers

Each worker has an associated circuit breaker and tracks the values of `errorsThreshold` and
`tripTimeout` individually. Each worker processes messages individually from the queue and opens the
circuit breaker when the number of errors reaches the value of `errorsThreshold` set on the worker.

By default, the circuit breaking feature is disabled.

### Circuit Breaker States

The circuit breaker has three states: Closed, Open, and Half Open. The behavior of the app changes
based on the current state. See the
[Microsoft Circuit Breaker pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)
for more information.

![Circuit Breaker States Diagram](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-subscriber-states-view.png)

- **Closed**

  The starting state where the Subscriber source retrieves messages normally from MQ based on its
  configuration, effectively working as if the circuit breaker is not present.

- **Closed-Open Transition**

  When the number of failures occurs in succession during message processing, without successes, and
  reaches the `errorsThreshold` value, the circuit breaker trips and the circuit breaker transitions
  to an Open state.

  Messages that were already dispatched to the flow then finish processing, regardless of whether
  the result is success or failure.

  Messages kept locally that are in-flight for the broker but haven’t been dispatched yet are not
  acknowledged and returned to the queue for redelivery to another consumer.

- **Open**

  The Subscriber source doesn’t attempt to retrieve messages, and skips the iterations silently
  until `tripTimeout` is reached.

- **Half Open**

  After `tripTimeout` elapses, the Subscriber source goes to a Half Open state. In the next poll for
  messages, the Subscriber source retrieves a single message from the service and uses that message
  to check if the system has recovered before going back to the normal Closed state.

  When the Subscriber source successfully fetches a single message, dispatches it to the flow, and
  processing finishes successfully, the Subscriber source returns to normal and immediately attempts
  to fetch more messages.

  If Mule flow processing fails with one of the expected `onErrorTypes`, the circuit goes back to an
  Open state and resets the `tripTimeout` timer.

### Configure the Circuit Breaker

You can configure a Circuit Breaker as either a Global Circuit Breaker or a Private Circuit Breaker.

Either way, the configuration parameters are the same:

- `onErrorTypes`

  The error types that count as a failure during the flow execution. An error occurrence counts only
  when the flow finishes with an error propagation. By default, all errors count as a circuit
  failure.

- `errorsThreshold`

  The number of `onErrorTypes` errors that must occur for the circuit breaker to open.

- `tripTimeout`

  How long the circuit remains open once `errorsThreshold` is reached.

- `circuitName`

  The name of a circuit breaker to bind to this configuration. By default, each queue has its own
  circuit breaker.

#### Global Circuit Breaker

Use a Global Circuit Breaker when you want to share the circuit state across multiple subscribers,
as if subscribers are part of the same "circuit".

1.  In Anypoint Studio, click the **Global Elements** tab in the canvas.

2.  Select **Create > Component Configuration > Circuit Breaker**.

    ![Circuit breaker configuration properties in the Global Element Properties window](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-cb-global-canvas.png)

    Figure 6. The screenshot shows the circuit breaker configuration properties in the **Global
    Element Properties** window.

    In the configuration wizard, populate the following fields as needed. Once the configuration is
    complete, you can reference this `Circuit_breaker` declaration from any Anypoint MQ Subscriber.

To reference a circuit breaker:

1.  Select the Subscriber source in the canvas.

2.  Click the **Advanced** tab.

3.  Select **Circuit Breaker > Global Reference** and select a global circuit breaker configuration
    from the list.

    ![Circuit breaker global reference in the Advanced tab of the Subscriber properties window](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-cb-global-ref.png)

    Figure 7. The arrow shows the circuit breaker global reference in the **Advanced** tab of the
    Subscriber properties window.

#### Private Circuit Breaker

You declare a Private Circuit Breaker internally on a single subscriber. This circuit declaration is
used only in the flow where the Subscriber source is declared, isolated from all the other circuits.

To use this configuration:

1.  Select the Subscriber source in the canvas.

2.  Click the **Advanced** tab.

3.  Select **Circuit breaker > Edit Inline**, and then complete the fields.

    ![Edit inline selected for the circuit breaker in the Advanced tab of the Subscriber properties window](/mulesoft/current/en-us/anypoint-mq-connector/3.x/_images/amq-3x-cb-inline.png)

    Figure 8. The arrow shows **Edit inline** selected for the circuit breaker in the **Advanced**
    tab of the Subscriber properties window.

### Circuit Breaker Examples

#### Circuit Configuration for a Single Subscriber

In this example, a single subscriber consumes messages from a queue and posts the messages to
another service using its REST API. You can stop processing messages after 5 requests to the
external service result in a timeout. Once processing stops, the Subscriber source waits for 30
seconds for the service to recover before retrying with a new message.

For this example, you need one config with these circuit breaker parameters:

```xml
<anypoint-mq:config name="Anypoint_MQ_Config">
    <anypoint-mq:connection url="${providerUrl}"
    clientId="${clientId}"
    clientSecret="${clientSecret}"/>
</anypoint-mq:config>

<flow name="subscribe">
   <anypoint-mq:subscriber config-ref="Anypoint_MQ_Config"
      destination="${subscribedQueue}">
        <anypoint-mq:circuit-breaker
          onErrorTypes="HTTP:TIMEOUT"   <!-- (1) -->
          errorsThreshold="5"           <!-- (2) -->
          tripTimeout="30"              <!-- (3) -->
          tripTimeoutUnit="SECONDS"/>
   </anypoint-mq:subscriber>
    <http:request config-ref="RequesterConfig"
       path="/external" method="POST"/> <!-- (4) -->
</flow>
```

<table><colgroup><col> <col></colgroup><tbody><tr><td><p><strong>(1)</strong></p></td><td><p>Configures the error types to trip the circuit. When an error occurs for an <code>errorsThreshold</code> amount of times, polling stops.</p></td></tr><tr><td><p><strong>(2)</strong></p></td><td><p>Sets the threshold for how many consequent messages must occur to consider the circuit to be in a failure state.</p></td></tr><tr><td><p><strong>(3)</strong></p></td><td><p>Specifies how long to wait before resuming new message polling after the circuit breaker trips because <code>errorsThreshold</code> is reached.</p></td></tr><tr><td><p><strong>(4)</strong></p></td><td><p>Defines the operation to throw the error expected by the <code>onErrorTypes</code> parameters.</p></td></tr></tbody></table>

The circuit breaker ignores all errors that aren’t listed in the `onErrorTypes` parameter. In this
example, the circuit breaker ignores errors such as `HTTP:BAD_REQUEST`.

#### Share a Circuit from Different Queues

In many cases, a single common service processes messages from different queues. This example
configures the `circuitName` parameter to bind both subscribers to a single circuit:

```xml
<anypoint-mq:config name="Anypoint_MQ_Config">
    <anypoint-mq:connection url="${providerUrl}"
       clientId="${clientId}"
       clientSecret="${clientSecret}"/>
</anypoint-mq:config>

<anypoint-mq:circuit-breaker
    name="InvoiceProcess"                    <!-- (1) -->
    onErrorTypes="FTP:RETRY_EXHAUSTED, HTTP:SERVICE_UNAVAILABLE" <!-- (2) -->
    errorsThreshold="10"
    tripTimeout="5"
    tripTimeoutUnit="MINUTES"/>

<flow name="subscribe">
    <anypoint-mq:subscriber destination="${reservationsQueue}"
       config-ref="Anypoint_MQ_Config"
        circuitBreaker="GlobalCircuit"/>     <!-- (3) -->
    <flow-ref name="invoiceProcess">
</flow>

<flow name="otherSubscribe">
    <anypoint-mq:subscriber
      destination="${paymentsQueue}"
        config-ref="Anypoint_MQ_Config"
        circuitBreaker="GlobalCircuit"/>    <!-- (3) -->
    <flow-ref name="invoiceProcess">
</flow>

<sub-flow name="invoiceProcess">
  <ftp:write path="${auditFolder}"          <!-- (4) -->
	   config-ref="ftp-config"/>
  <http:request config-ref="requestConfig"  <!-- (5) -->
	   path="/external"/>
</sub-flow>
```

<table><colgroup><col> <col></colgroup><tbody><tr><td><p><strong>(1)</strong></p></td><td><p>Sets the <code>name</code> parameter to share a common circuit breaker on multiple queues.</p></td></tr><tr><td><p><strong>(2)</strong></p></td><td><p>Identifies two errors that can affect the processing of messages from the Subscriber source and passes each as a CSV list.</p></td></tr><tr><td><p><strong>(3)</strong></p></td><td><p>For both subscribers, references the global circuit breaker configuration.</p></td></tr><tr><td><p><strong>(4)</strong></p></td><td><p>Might throw several errors, but only <code>FTP:RETRY_EXHAUSTED</code> is relevant to the circuit breaker.</p></td></tr><tr><td><p><strong>(5)</strong></p></td><td><p>The HTTP connector might throw an <code>HTTP:SERVICE_UNAVAILABLE</code> error, preventing the message from being processed.</p></td></tr></tbody></table>

In this scenario, both subscribers stop polling for messages as soon as the error count reaches the
`errorsThreshold="10"` value, counting both `FTP:RETRY_EXHAUSTED` and `HTTP:SERVICE_UNAVAILABLE`
errors. When the `tripTimeout` value elapses, one of the subscribers polls for a message and uses it
to test the circuit, enabling the polling for both subscribers if the processing of that message
succeeds.

## FIFO Queues

FIFO queues are most suitable for single-consumer scenarios. When one consumer is accessing a
message, all other consumers are blocked until the first batch is processed. No messages are
delivered until all in-flight messages are acknowledged or not acknowledged.

With message groups, multiple consumers can access messages in a FIFO queue at the same time. In
this case, one consumer accesses messages in a group and another consumer accesses messages in
another group. Message order is preserved within each message group.

FIFO queues do not support retrieving messages by message group ID.

> [!IMPORTANT] To preserve message processing order, set the value of `maxConcurrency` to `1` for
> flows that consume messages from a FIFO queue.

### FIFO Queues and Clustering

FIFO queues behave the same in a clustered environment as in a non-clustered environment.

FIFO queues consume messages in the specified order. After the message is consumed, any further
message processing can be distributed to other nodes. In this case, if the consumer acknowledges a
message before it is fully processed, message order might be lost during message processing.

- In an
  [on-premises, high availability clustering environment](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters),
  the Subscriber source in the Anypoint MQ connector runs on all nodes by default.

  You can change the behavior to run as a primary node by selecting **Primary node only** in the
  **Advanced** tab.

- In [CloudHub](https://docs.mulesoft.com/cloudhub/) with multiple workers, all workers are run as a primary node.

  In this case, all workers running the application consume from the same FIFO queue.

## See Also

- [Anypoint MQ Consume Operation](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-consume)

- [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-ack)

- [Anypoint MQ Connector Reference](https://docs.mulesoft.com/anypoint-mq-connector/3.x/anypoint-mq-connector-reference)

<!-- document id=b791efcf0a64b5ce8267b22494bc077fdbdfe09271310218b427ad9159544d3d url=/mulesoft/current/en-us/anypoint-mq-connector/latest/anypoint-mq-listener.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Anypoint MQ Subscriber Source

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

The Subscriber source in the Anypoint MQ connector enables a Mule app to listen for and consume
messages from an Anypoint MQ queue or exchange as they arrive. Use the Subscriber source when your
flow needs to react to incoming messages continuously or on a schedule. To retrieve a single message
on demand instead, use the [Anypoint MQ Consume operation](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-consume).

## Subscriber Strategies

The Subscriber source supports two retrieval strategies with different goals:

<table><colgroup><col> <col></colgroup><thead><tr><th>Strategy</th><th>Best for</th></tr></thead><tbody><tr><td><p>Prefetch (default)</p></td><td><p>Maximum throughput. Proactively fills a local in-memory buffer so the flow always has messages ready to process. Best when ordering is not required.</p></td></tr><tr><td><p>Polling</p></td><td><p>Controlled, demand-driven intake. Retrieves messages in step with the flow: bounded in-flight messages, predictable memory, and (with <code>maxConcurrency = 1</code>) strict message ordering.</p></td></tr></tbody></table>

> [!TIP] Choose prefetch to buffer messages and maximize throughput. Choose polling to pace message
> intake to your flow’s processing capacity, or when strict ordering is required.

- Prefetch is the default and requires no additional configuration for most use cases. Choose
  prefetch when throughput is the priority and you don’t need messages processed in a specific
  order.

- Polling gives you control: when backpressure is enabled, it fetches messages only when the flow
  has capacity, which keeps memory usage predictable and prevents the subscriber from building up an
  unbounded backlog. Choose polling when you need strict ordering, want to limit how many messages
  are in-flight at once, or want to tie message intake to a specific schedule using a fixed
  frequency or cron expression.

Use this table to choose the strategy that matches your priority:

<table><colgroup><col> <col> <col></colgroup><thead><tr><th>Priority</th><th>Recommended strategy</th><th>Billing and throughput note</th></tr></thead><tbody><tr><td><p>Buffer messages or bulk-retrieve many at once</p></td><td><p>Prefetch</p></td><td><p>Best batching, lowest request count, highest throughput. Unaffected by backpressure.</p></td></tr><tr><td><p>High throughput, ordering not required</p></td><td><p>Prefetch</p></td><td><p>Best batching, lowest request count, highest throughput. Unaffected by backpressure.</p></td></tr><tr><td><p>Bounded in-flight messages or predictable memory</p></td><td><p>Polling</p></td><td><p>Batching efficiency depends on Max Concurrency setting.</p></td></tr><tr><td><p>Strict ordering (<code>maxConcurrency = 1</code>)</p></td><td><p>Polling</p></td><td><p>Highest request count: batching is effectively disabled by design.</p></td></tr></tbody></table>

## Prefetch Strategy

By default, the Subscriber source runs in continuous listening mode to provide maximum throughput by
consuming messages when they arrive in the queue. With the prefetch strategy, the source maintains a
full local buffer of messages, ready to dispatch to the MuleSoft flow when the app accepts them.

![Subscriber configuration window showing Subscriber Type set to Prefetch](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-subscriber-prefetch.png)

> [!NOTE] Due to a known issue, using `prefetch` mode with `maxConcurrency="1"` set on the `flow`
> element might result in message-processing latency.

For the prefetch strategy, you configure the `maxLocalMessages` parameter to specify the target size
for a full buffer, which controls how quickly messages are taken from the queue.

To configure the Subscriber source using the prefetch strategy, specify the `prefetch`
subscriber-type.

This example shows the default prefetch strategy, which uses the default buffer size and begins
consuming messages from `myQueue` immediately:

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config" destination="myQueue">
</anypoint-mq:subscriber>
```

Use these guidelines to tune the buffer size for your use case:

- Use a larger buffer size for maximum performance, keeping in mind that the messages kept locally
  won’t be available for any other consumer.

  When a consumer takes a message from the queue and stores it in the local buffer, the message
  appears as in-flight for any other consumer and prevents them from consuming it. The message
  remains in this in-flight state for as long as necessary for the app to begin the processing.

- Use a smaller buffer size to process messages as they are published to the queue.

  The smaller buffer restricts app-level throughput and avoids blocking competing consumers.

  When using `prefetch` mode, set `maxLocalMessages` to a value greater than `1` to avoid
  message-processing latency issues. When `maxLocalMessages` is set to `1`, latency can occur when
  the connector prefetches the message but the app doesn’t consume it, and the message returns to
  the queue for reprocessing.

### FIFO Queues and the Prefetch Strategy

When using the prefetch strategy, the `acknowledgementTimeout` timer begins when the message is
taken from the queue. Anypoint MQ attempts to honor the expiration time specified by
`acknowledgementTimeout`. However, Anypoint MQ extends the expiration timeout if the time that the
message remains in the buffer reaches 80% of the timeout value.

Don’t use `prefetch` mode in the following situations:

- Applications with long processing times that use the `maxConcurrency` attribute to limit
  concurrent processing.

  These options can cause messages to remain in the buffer longer, which can result in the messages
  expiring and being sent back to the queue.

- When using FIFO queues

  Because Anypoint MQ can’t guarantee ordering when using `prefetch` mode, don’t use it with FIFO
  queues.

  Using `prefetch` mode for applications with long processing times can consume significant
  resources because Anypoint MQ monitors the ACK TTL for all messages in the local buffer and
  extends the TTL to avoid sending messages back to the queue.

## Polling Strategy

If your app requires predictable and controlled message consumption rather than maximum throughput,
you can configure the Subscriber as a polling strategy. The Subscriber source checks for new
messages in the queue at a fixed scheduling rate. Every time the poll is triggered, the Subscriber
source retrieves up to 10 messages and dispatches them to the flow individually in order. When
backpressure is enabled and `maxConcurrency` is set on the flow, the fetch size is further capped to
the flow’s remaining capacity. See
[Backpressure and Max Concurrency](#backpressure-and-max-concurrency) for details.

Messages aren’t consumed immediately. Instead, they remain in the queue until the next poll is
triggered. Each poll retrieves up to 10 messages at a time. For example, if your queue has 15
messages, one poll retrieves the first 10 and the remaining 5 wait for the next poll.

To configure the Subscriber source using the polling strategy, specify the `polling`
subscriber-type.

This example shows the default polling strategy, which polls `myQueue` every 1 second and retrieves
up to 10 messages per poll:

![Subscriber configuration window showing Subscriber Type set to Polling](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-subscriber-polling.png)

```xml
<anypoint-mq:subscriber doc:name="Subscriber" config-ref="Anypoint_MQ_Config" destination="myQueue">
  <anypoint-mq:subscriber-type >
    <anypoint-mq:polling >
      <scheduling-strategy >
        <fixed-frequency />
      </scheduling-strategy>
    </anypoint-mq:polling>
  </anypoint-mq:subscriber-type>
</anypoint-mq:subscriber>
```

The default polling strategy attempts to retrieve up to 10 messages from the declared destination
every 1 second, dispatching each message to the flow individually as a `MuleMessage` instance.

The resulting `MuleMessage` has:

- The message body as its payload

- The message metadata in the message attributes

![Mule message output, including payload and message attributes](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-subscriber-output.png)

You can customize the polling strategy using the standard Mule runtime engine scheduling strategies:

- [Fixed Frequency](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#fixed-frequency)

- [Cron Expressions](https://docs.mulesoft.com/mule-runtime/latest/scheduler-concept#cron-expressions)

### Customized Fixed Polling

You can customize the frequency at which the Subscriber source polls for new messages by specifying
a `fixed-frequency` scheduling strategy within the polling strategy. Use this configuration when you
want to control the polling interval, for example, to reduce broker requests during low-traffic
periods.

This example shows the polling strategy configured with a customized fixed-frequency schedule:

![Subscriber configuration window showing Scheduling Strategy set to Fixed Frequency](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-subscriber-polling-fixed.png)

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config" destination="myQueue">
  <anypoint-mq:subscriber-type >
    <anypoint-mq:polling>
      <scheduling-strategy >
        <fixed-frequency/>
      </scheduling-strategy>
    </anypoint-mq:polling>
  </anypoint-mq:subscriber-type>
</anypoint-mq:subscriber>
```

### Cron-Based Polling

The Anypoint MQ Subscriber can also use a `cron` scheduling strategy, which enables you to schedule
polling jobs such as "Run every minute starting at 2pm and ending at 2:59pm, every day". Use this
configuration when message intake should align with a specific time window rather than run
continuously.

This example shows the polling strategy configured with a cron expression that polls every minute
between 2:00pm and 2:59pm Pacific time:

![Subscriber configuration window showing Scheduling Strategy set to Cron](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-subscriber-polling-cron.png)

```xml
<anypoint-mq:subscriber config-ref="Anypoint_MQ_Config" destination="myQueue">
  <anypoint-mq:subscriber-type >
    <anypoint-mq:polling >
      <scheduling-strategy >
        <cron expression="0 * 14 * * ?" timeZone="America/Los_Angeles" />
      </scheduling-strategy>
    </anypoint-mq:polling>
  </anypoint-mq:subscriber-type>
</anypoint-mq:subscriber>
```

### Backpressure and Max Concurrency

Backpressure for the polling strategy is opt-in and disabled by default. Existing applications are
unaffected unless you explicitly enable it.

When enabled, the polling strategy paces message retrieval to match your flow’s actual processing
capacity. It tracks how many messages the flow is currently processing and holds off fetching more
until capacity is available. Capacity is released only when a message finishes processing (success
or error), not when it is dispatched to the flow. When used with FIFO queues and message groups,
backpressure also improves fairness — preventing a backlog in one message group from stalling
processing of others.

> [!NOTE] Backpressure affects only when messages are fetched. Acknowledgment behavior (AUTO,
> MANUAL, and IMMEDIATE modes), redelivery, and error handling are unchanged.

The feature is controlled by the system property `anypoint.mq.subscriber.backpressure.enabled`
(default `false`). The property is global to the application: it applies to every polling strategy
subscriber in that app and has no effect on prefetch strategy subscribers.

#### Enable Backpressure

To enable backpressure, set the `anypoint.mq.subscriber.backpressure.enabled` system property to
`true`. This property is set to `false` by default.

To set this application property in Runtime Manager:

1.  Sign in to Anypoint Platform and click **Runtime Manager** in the navigation menu.

2.  Deploy a new app or change the settings for a deployed app.

3.  On the **Properties** tab, specify the value for the property, for example:

    ![Properties table with anypoint.mq.subscriber.backpressure.enabled set to true](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-subscriber-backpressure-enabled.png)

Alternatively, set the property in **Run Configurations** in Anypoint Studio. For more information,
see [System Properties in Mule Apps](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system).

When backpressure is enabled, the number of messages fetched per poll is capped to your flow’s
remaining capacity.

#### Fetching Behavior by Configuration

The following table shows how backpressure affects message fetching depending on whether it is
enabled and whether `maxConcurrency` is set on the flow:

<table><colgroup><col> <col></colgroup><thead><tr><th>Configuration</th><th>Fetching behavior</th></tr></thead><tbody><tr><td><p>Backpressure disabled (default)</p></td><td><p>The polling subscriber fetches up to the configured fetch size on each poll, regardless of how many messages the flow is currently processing.</p></td></tr><tr><td><p>Backpressure enabled, <code>maxConcurrency</code> not set</p></td><td><p>The polling subscriber fetches up to the configured fetch size on each poll. With no <code>maxConcurrency</code> set, the in-flight cap is unbounded and fetching is not throttled.</p></td></tr><tr><td><p>Backpressure enabled, <code>maxConcurrency</code> set</p></td><td><p>The polling subscriber fetches only as many messages as the flow has remaining capacity for. Fetching pauses when the flow reaches <code>maxConcurrency</code> and resumes as messages finish processing.</p></td></tr></tbody></table>

#### Adopt Backpressure

No action is required to upgrade. Backpressure is off by default and existing applications are
unaffected.

To enable and configure backpressure:

1.  Enable backpressure by setting `-Danypoint.mq.subscriber.backpressure.enabled=true`. Validate in
    a non-production environment first and confirm the `enabled` startup log line.

2.  Set **Max Concurrency** on your flow to the number of messages you want processed in parallel.
    This becomes the in-flight fetch cap.

3.  If you need strict ordering, use the polling strategy with `maxConcurrency = 1` and expect a
    higher API request volume.

To roll back at any time, remove the property or set it to `false` and restart. No redeployment of a
different artifact is required.

## Message Acknowledgment

You can acknowledge received messages automatically only if the flow execution finishes successfully
or as your app consumes them, before processing them.

- **Automatic**

  By default, the Subscriber source uses the `AUTO` acknowledgment mode. With this mode, the
  messages that the Subscriber source retrieves are acknowledged automatically after message flow
  processing succeeds. This means that the Subscriber source receives a message, dispatches it to
  the flow, and waits to see how the message processing finishes. It executes an ACK only when the
  processing finishes without exceptions.

  If the execution of the processing flow finishes with a propagated exception, the message is
  automatically not acknowledged and is returned to the queue for redelivery.

  For more information, see [Automatic Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack#automatic-acknowledgment).

- **Immediate**

  When you use the `IMMEDIATE` acknowledgment mode, the consumed message is acknowledged (deleted
  from the queue) and then dispatched to the Mule flow for processing. If the message acknowledgment
  fails, the message is discarded. The message isn’t dispatched to the flow and remains in-flight
  until the acknowledgment timeout.

  If the app restarts between being acknowledged and dispatched, the message might not be available
  again because it was deleted from the queue. To prevent message deletion until after processing,
  use the `AUTO` or `MANUAL` acknowledgment mode instead.

  Using the Subscriber source with the prefetch strategy and the `IMMEDIATE` acknowledgment mode
  sometimes results in thread accumulation and an unresponsive application.

  For more information, see [Immediate Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack#immediate-acknowledgment).

- **Manual**

  When you use the `MANUAL` acknowledgment mode, the app logic decides when to perform the
  acknowledgment of the message, using the [ACK](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack) or [NACK](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack)
  sources.

  To perform the manual acknowledgment, you need the value of `ackToken` provided as part of the
  resulting message attributes.

  For more information, see [Manual Acknowledgment](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack#manual-acknowledgment).

For information about acknowledgment timeouts, see
[Acknowledgment Timeout](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack#acknowledgment-timeout).

> [!NOTE] Backpressure does not affect acknowledgment behavior. The AUTO, MANUAL, and IMMEDIATE
> modes work the same way regardless of whether backpressure is enabled. Redelivery, acknowledgment
> timeouts, and error handling are also unchanged.

## Circuit Breaker Capability

The Subscriber source provides circuit breaking capability, which enables you to control how the
connector handles errors that occur while processing a consumed message.

For example, when connecting to an external service, you can use the circuit breaker to handle any
downtime of that service. The circuit breaker allows the system to stop making requests and allows
the external service to recover under a reduced load.

Using Anypoint MQ in a Mule 4 app means having a Mule flow with an MQ subscriber that consumes
messages from a queue and processes them using an external service. When this service isn’t
available:

1.  The request fails.

2.  An error results.

3.  Message processing finishes as either a failure or as a custom error for handling the message,
    such as sending it to a dead letter queue (DLQ).

When the external service is not available, every attempt to process a message results in a failure,
forcing the app to loop, consuming messages that cannot succeed. You can avoid this behavior by
notifying the subscriber of the error in a way that prevents it from consuming more messages for a
certain period.

### Circuit Breaker Processes

The circuit breaker capability that the Subscriber source provides is bound to the error handling
mechanism provided by Mule. It uses the error notification mechanism to count errors related to an
external service, which is known as a circuit failure. You can bind any error to a circuit failure.
For example, you can bind `HTTP:TIMEOUT`, `FTP:SERVICE_NOT_AVAILABLE`, or even a custom error from
your app, such as `ORG:EXTERNAL_ERROR`.

If a Mule flow finishes its execution with an error, the Subscriber source checks if the error is
one of the `onErrorTypes` that indicates an external service error, and counts consecutive
occurrences until `errorsThreshold` is reached.

When `errorsThreshold` is reached, the circuit trips and remains open for the duration specified by
`tripTimeout`. While the circuit is open, all polled or consumed messages are not acknowledged
(NACK) and Anypoint MQ halts any future operations (poll, ACK, NACK, and Publish) until
`tripTimeout` elapses.

After `tripTimeout` elapses, the circuit breaker transitions to a new
[state](#circuit-breaker-states). If the new state is **Closed**, clients can consume messages on
the next poll.

The behavior varies depending on whether you deploy the app to CloudHub with a single worker or
multiple workers:

Single worker

The worker processes messages individually from the queue and opens the circuit breaker when the
number of errors reaches the value of `errorsThreshold`.

Multiple workers

Each worker has an associated circuit breaker and tracks the values of `errorsThreshold` and
`tripTimeout` individually. Each worker processes messages individually from the queue and opens the
circuit breaker when the number of errors reaches the value of `errorsThreshold` set on the worker.

By default, the circuit breaking feature is disabled.

### Circuit Breaker States

The circuit breaker has three states: Closed, Open, and Half Open. The behavior of the app changes
based on the current state. See the
[Microsoft Circuit Breaker pattern](https://learn.microsoft.com/en-us/azure/architecture/patterns/circuit-breaker)
for more information.

![Flow showing the states of the circuit breaker: closed, half-open, and open](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-subscriber-states-view.png)

- **Closed**

  The starting state where the Subscriber source retrieves messages normally from MQ based on its
  configuration, effectively working as if the circuit breaker is not present.

- **Closed-Open Transition**

  When the number of failures occurs in succession during message processing, without successes, and
  reaches the `errorsThreshold` value, the circuit breaker trips and the circuit breaker transitions
  to an Open state.

  Messages that were already dispatched to the flow then finish processing, regardless of whether
  the result is success or failure.

  Messages kept locally that are in-flight for the broker but haven’t been dispatched yet are not
  acknowledged and returned to the queue for redelivery to another consumer.

- **Open**

  The Subscriber source doesn’t attempt to retrieve messages, and skips the iterations silently
  until `tripTimeout` is reached.

- **Half Open**

  After `tripTimeout` elapses, the Subscriber source goes to a Half Open state. In the next poll for
  messages, the Subscriber source retrieves a single message from the service and uses that message
  to check if the system has recovered before going back to the normal Closed state.

  When the Subscriber source successfully fetches a single message, dispatches it to the flow, and
  processing finishes successfully, the Subscriber source returns to normal and immediately attempts
  to fetch more messages.

  If Mule flow processing fails with one of the expected `onErrorTypes`, the circuit goes back to an
  Open state and resets the `tripTimeout` timer.

### Configure the Circuit Breaker

You can configure a Circuit Breaker as either a Global Circuit Breaker or a Private Circuit Breaker.

Either way, the configuration parameters are the same:

- `onErrorTypes`

  The error types that count as a failure during the flow execution. An error occurrence counts only
  when the flow finishes with an error propagation. By default, all errors count as a circuit
  failure.

- `errorsThreshold`

  The number of `onErrorTypes` errors that must occur for the circuit breaker to open.

- `tripTimeout`

  How long the circuit remains open once `errorsThreshold` is reached.

- `circuitName`

  The name of a circuit breaker to bind to this configuration. By default, each queue has its own
  circuit breaker.

#### Global Circuit Breaker

Use a Global Circuit Breaker when you want to share the circuit state across multiple subscribers,
as if subscribers are part of the same "circuit".

1.  In Anypoint Studio, click the **Global Elements** tab in the canvas.

2.  Select **Create > Component Configuration > Circuit Breaker**.

    ![Circuit breaker configuration window including error types, error threshold, trip timeout, and trip timeout unit](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-cb-global-canvas.png)

    In the configuration wizard, populate these fields as needed. Once the configuration is
    complete, you can reference this `Circuit_breaker` declaration from any Anypoint MQ Subscriber.

To reference a circuit breaker:

1.  Select the Subscriber source in the canvas.

2.  Click the **Advanced** tab.

3.  Select **Circuit Breaker > Global Reference** and select a global circuit breaker configuration
    from the list.

    ![Subscriber configuration window showing Global reference set to Circuit\_breaker](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-cb-global-ref.png)

#### Private Circuit Breaker

You declare a Private Circuit Breaker internally on a single subscriber. This circuit declaration is
used only in the flow where the Subscriber source is declared, isolated from all the other circuits.

To use this configuration:

1.  Select the Subscriber source in the canvas.

2.  Click the **Advanced** tab.

3.  Select **Circuit breaker > Edit Inline**, and then complete the fields.

    ![Subscriber configuration window showing Circuit breaker set to Edit Inline](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/amq-4x-cb-inline.png)

### Circuit Breaker Examples

#### Circuit Configuration for a Single Subscriber

In this example, a single subscriber consumes messages from a queue and posts the messages to
another service using its REST API. You can stop processing messages after 5 requests to the
external service result in a timeout. Once processing stops, the Subscriber source waits for 30
seconds for the service to recover before retrying with a new message.

For this example, you need one config with these circuit breaker parameters:

```xml
<anypoint-mq:config name="Anypoint_MQ_Config">
    <anypoint-mq:connection url="${providerUrl}"
    clientId="${clientId}"
    clientSecret="${clientSecret}"/>
</anypoint-mq:config>

<flow name="subscribe">
   <anypoint-mq:subscriber config-ref="Anypoint_MQ_Config"
      destination="${subscribedQueue}">
        <anypoint-mq:circuit-breaker
          onErrorTypes="HTTP:TIMEOUT"   <!-- (1) -->
          errorsThreshold="5"           <!-- (2) -->
          tripTimeout="30"              <!-- (3) -->
          tripTimeoutUnit="SECONDS"/>
   </anypoint-mq:subscriber>
    <http:request config-ref="RequesterConfig"
       path="/external" method="POST"/> <!-- (4) -->
</flow>
```

<table><colgroup><col> <col></colgroup><tbody><tr><td><p><strong>(1)</strong></p></td><td><p>Configures the error types to trip the circuit. When an error occurs for an <code>errorsThreshold</code> amount of times, polling stops.</p></td></tr><tr><td><p><strong>(2)</strong></p></td><td><p>Sets the threshold for how many consequent messages must occur to consider the circuit to be in a failure state.</p></td></tr><tr><td><p><strong>(3)</strong></p></td><td><p>Specifies how long to wait before resuming new message polling after the circuit breaker trips because <code>errorsThreshold</code> is reached.</p></td></tr><tr><td><p><strong>(4)</strong></p></td><td><p>Defines the operation to throw the error expected by the <code>onErrorTypes</code> parameters.</p></td></tr></tbody></table>

The circuit breaker ignores all errors that aren’t listed in the `onErrorTypes` parameter. In this
example, the circuit breaker ignores errors such as `HTTP:BAD_REQUEST`.

#### Share a Circuit from Different Queues

In many cases, a single common service processes messages from different queues. This example
configures the `circuitName` parameter to bind both subscribers to a single circuit:

```xml
<anypoint-mq:config name="Anypoint_MQ_Config">
    <anypoint-mq:connection url="${providerUrl}"
       clientId="${clientId}"
       clientSecret="${clientSecret}"/>
</anypoint-mq:config>

<anypoint-mq:circuit-breaker
    name="InvoiceProcess"                    <!-- (1) -->
    onErrorTypes="FTP:RETRY_EXHAUSTED, HTTP:SERVICE_UNAVAILABLE" <!-- (2) -->
    errorsThreshold="10"
    tripTimeout="5"
    tripTimeoutUnit="MINUTES"/>

<flow name="subscribe">
    <anypoint-mq:subscriber destination="${reservationsQueue}"
       config-ref="Anypoint_MQ_Config"
        circuitBreaker="GlobalCircuit"/>     <!-- (3) -->
    <flow-ref name="invoiceProcess">
</flow>

<flow name="otherSubscribe">
    <anypoint-mq:subscriber
      destination="${paymentsQueue}"
        config-ref="Anypoint_MQ_Config"
        circuitBreaker="GlobalCircuit"/>    <!-- (3) -->
    <flow-ref name="invoiceProcess">
</flow>

<sub-flow name="invoiceProcess">
  <ftp:write path="${auditFolder}"          <!-- (4) -->
	   config-ref="ftp-config"/>
  <http:request config-ref="requestConfig"  <!-- (5) -->
	   path="/external"/>
</sub-flow>
```

<table><colgroup><col> <col></colgroup><tbody><tr><td><p><strong>(1)</strong></p></td><td><p>Sets the <code>name</code> parameter to share a common circuit breaker on multiple queues.</p></td></tr><tr><td><p><strong>(2)</strong></p></td><td><p>Identifies two errors that can affect the processing of messages from the Subscriber source and passes each as a CSV list.</p></td></tr><tr><td><p><strong>(3)</strong></p></td><td><p>For both subscribers, references the global circuit breaker configuration.</p></td></tr><tr><td><p><strong>(4)</strong></p></td><td><p>Might throw several errors, but only <code>FTP:RETRY_EXHAUSTED</code> is relevant to the circuit breaker.</p></td></tr><tr><td><p><strong>(5)</strong></p></td><td><p>The HTTP connector might throw an <code>HTTP:SERVICE_UNAVAILABLE</code> error, preventing the message from being processed.</p></td></tr></tbody></table>

In this scenario, both subscribers stop polling for messages as soon as the error count reaches the
`errorsThreshold="10"` value, counting both `FTP:RETRY_EXHAUSTED` and `HTTP:SERVICE_UNAVAILABLE`
errors. When the `tripTimeout` value elapses, one of the subscribers polls for a message and uses it
to test the circuit, enabling the polling for both subscribers if the processing of that message
succeeds.

## FIFO Queues

FIFO queues are most suitable for single-consumer scenarios. When one consumer is accessing a
message, all other consumers are blocked until the first batch is processed. No messages are
delivered until all in-flight messages are acknowledged or not acknowledged.

With message groups, multiple consumers can access messages in a FIFO queue at the same time. In
this case, one consumer accesses messages in a group and another consumer accesses messages in
another group. Message order is preserved within each message group.

FIFO queues do not support retrieving messages by message group ID.

> [!IMPORTANT] To preserve message processing order, set the value of `maxConcurrency` to `1` for
> flows that consume messages from a FIFO queue. When using the polling strategy with backpressure
> enabled and `maxConcurrency = 1`, each fetch retrieves one message at a time, which can result in
> a significantly higher API request volume. See
> [Backpressure and Max Concurrency](#backpressure-and-max-concurrency) for details.

> [!NOTE] When you configure the polling strategy with `fetchSize=1` and `maxConcurrency=1` on a
> FIFO queue with message groups, the subscriber fetches one message per poll and dispatches it to
> the flow. Before the first message is acknowledged, the next poll can fetch a second message,
> which waits to be processed until the flow finishes processing the first one. Both messages are
> considered in-flight at the broker level until they’re acknowledged. This configuration preserves
> message order but can result in two in-flight messages per message group at a time, which is
> expected behavior.

### FIFO Queues and Clustering

FIFO queues behave the same in a clustered environment as in a non-clustered environment.

FIFO queues consume messages in the specified order. After the message is consumed, any further
message processing can be distributed to other nodes. In this case, if the consumer acknowledges a
message before it is fully processed, message order might be lost during message processing.

- In an
  [on-premises, high availability clustering environment](https://docs.mulesoft.com/on-premises/latest/mule-high-availability-ha-clusters),
  the Subscriber source in the Anypoint MQ connector runs on all nodes by default.

  You can change the behavior to run as a primary node by selecting **Primary node only** in the
  **Advanced** tab.

- In [CloudHub](https://docs.mulesoft.com/cloudhub/) with multiple workers, all workers are run as a primary node.

  In this case, all workers running the application consume from the same FIFO queue.

## See Also

- [Anypoint MQ Consume Operation](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-consume)

- [Anypoint MQ ACK and NACK Operations](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-ack)

- [Anypoint MQ Connector Reference](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-connector-reference)

<!-- document id=c88e7d2fd0717e75a81e57b0f566eee20cee9e1ebf7df910b26bdad890cfc56b url=/mulesoft/current/en-us/anypoint-mq-connector/latest/anypoint-mq-failover.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Configuring Cross-Region Failover in Your App

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

Anypoint MQ Connector for Mule 4 version 4.0.7 and later provides failover capability for standard
queues.

This feature is not enabled by default. Before using this feature, review
[Configuring Cross-Region Failover for Standard Queues](https://docs.mulesoft.com/mq/mq-failover).

> [!IMPORTANT] When you enable failover for a queue and the primary region goes down, your data
> might reside in a region outside the country until the primary region is available

To use the failover feature, do the following:

- In your app:

  1.  Upgrade Anypoint MQ Connector to version 4.0.7 or later.

  2.  [Enable failover in your app.](#enable-failover-feature)

  3.  (Optional) [Change the check frequencies](#configure-check-frequency).

- In Anypoint MQ:

  1.  Create or modify a queue and
      [enable failover on the queue](https://docs.mulesoft.com/mq/mq-failover#enable-failover).

## Enable Failover in Your App

To enable the failover feature in your app, set the `cross.region.failover.feature.enabled` system
property to `true`. This property is set to `false` by default.

> [!NOTE] When the failover property is enabled, the connector handles processing messages for both
> the primary and failover queues. To prevent interruptions, the app can’t publish or consume
> directly from the fallback queue. See
> [Process Messages Directly from the Fallback Queue](#consume-directly-fallback) for information.

To set this application property in Runtime Manager:

1.  Sign in to Anypoint Platform and click **Runtime Manager** in the navigation menu.

2.  Deploy a new app or change the settings for a deployed app.

3.  On the **Properties** tab, specify the value for the property, for example:

    ![Properties table with cross.region.failover.feature.enabled set to true](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/mq-set-properties-failover-enabled.png)

Alternatively, set the property in **Run Configurations** in Anypoint Studio. For more information,
see [System Properties in Mule Apps](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system).

## Process Messages Directly from the Fallback Queue

If failover is enabled for an app, Anypoint MQ Connector manages the fallback queue (with the `_fb`
suffix) and prevents publish, consume, or subscribe operations on the fallback queue directly. If
the app connects to the fallback queue directly, Anypoint MQ Connector returns an error:

```none
java.lang.IllegalArgumentException: Using fallback queue directly is not supported
```

If you disable failover on a queue (from the Anypoint MQ UI) and restart the application, the
connector no longer publishes or consumes from the fallback queue.

To process any messages that remain in the fallback queue after disabling failover:

1.  Configure the app to process directly from the fallback queue.

    For the Consume or Subscriber operations, set the **Queue** field to the name of the fallback
    queue, for example:

    ![Subscriber configuration with the queue name, myDemoQueue\_fb](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/mq-publish-fallback-queue-subscribe.png)

2.  Allow the app to consume messages directly from the fallback queue:

    1.  Sign in to Anypoint Platform and click **Runtime Manager** in the navigation menu.

    2.  Change the settings for a deployed app.

    3.  On the **Properties** tab, set the `cross.region.failover.feature.enabled` system property
        to `false`, for example:

        ![Properties table with cross.region.failover.feature.enabled set to false](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/mq-set-properties-failover-disabled.png)

        Alternatively, set the property in **Run Configurations** in Anypoint Studio. For more
        information, see
        [System Properties in Mule Apps](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system).

## Configure the Frequency of Fallback Queue Checks

By default, when the primary region is down, Anypoint MQ Connector checks the:

- Fallback queue once every five minutes for new messages (300,000 milliseconds)

- Primary queue to see if the primary region is back up once per minute (60,000 milliseconds)

To change this behavior, set the following properties:

<table><colgroup><col> <col> <col> <col> <col></colgroup><thead><tr><th>Property</th><th>Description</th><th>Minimum Value</th><th>Maximum Value</th><th>Default Value</th></tr></thead><tbody><tr><td colspan="5"><p><code>primary.region.status.check.interval.ms</code></p></td></tr><tr><td></td><td><p>How often the connector checks the availability of the primary region when processing from the fallback region</p></td><td><p>1 minute (60,000 milliseconds)</p></td><td><p>15 minutes (900,000 milliseconds)</p></td><td><p>1 minute (60,000 milliseconds)</p></td></tr><tr><td colspan="5"><p><code>fallback.messages.check.interval.ms</code></p></td></tr><tr><td></td><td><p>How often the connector checks the fallback queue for received messages</p></td><td><p>1 minute (60,000 milliseconds)</p></td><td><p>12 hours (43.2 million milliseconds)</p></td><td><p>5 minutes (300,000 milliseconds)</p></td></tr></tbody></table>

To set these application properties in Runtime Manager:

1.  Sign in to Anypoint Platform and click **Runtime Manager** in the navigation menu.

2.  Deploy a new app or change the settings for a deployed app.

3.  On the **Properties** tab, specify values for the following properties (in milliseconds):

    ![Properties table with intervals for primary and fallback status check intervals](/mulesoft/current/en-us/anypoint-mq-connector/latest/_images/mq-set-properties-failover.png)

Alternatively, set these properties in **Run Configurations** in Anypoint Studio. For more
information, see
[System Properties in Mule Apps](https://docs.mulesoft.com/mule-runtime/latest/mule-app-properties-system)

### Check Interval Considerations

To determine how to set the application property values to fine-tune the check intervals:

- When publishing to the fallback region during primary region downtime, the Publish operation of
  Anypoint MQ Connector checks if the primary region is back up once per minute by default.

  If a flow triggers the Publish operation less frequently than once per minute, the connector
  checks to see if the primary region is back up every time the operation is triggered.

  To fine-tune this behavior, set the value of `primary.region.status.check.interval.ms` to be
  greater than the frequency at which your flow triggers the Publish operation.

- When a flow triggers the Consumer or Subscriber operation of Anypoint MQ Connector, the connector
  checks the fallback queue (every five minutes by default) for new messages before checking the
  primary queue.

  If a flow triggers the Consumer or Subscriber operation less frequently than every five minutes,
  the connector first checks the fallback queue for new messages before consuming from the primary
  queue.

  To reduce the frequency of checking the fallback queue, set the value of
  `fallback.messages.check.interval.ms` to be greater than the frequency at which your flow triggers
  the Consumer or Subscriber operation.

  > [!NOTE] Setting this property to a high value might result in out-of-order messages because
  > messages in the fallback queue are not processed as frequently.

## See Also

- [Configuring Cross-Region Failover for Standard Queues](https://docs.mulesoft.com/mq/mq-failover)

- [Changing App Behavior with Properties on CloudHub 2.0](https://docs.mulesoft.com/cloudhub-2/ch2-manage-props)

- [Manage Properties for Applications on CloudHub](https://docs.mulesoft.com/cloudhub/cloudhub-manage-props)

- [Anypoint MQ Connector in Anypoint Exchange](https://anypoint.mulesoft.com/exchange/com.mulesoft.connectors/anypoint-mq-connector/)

- [Anypoint MQ Connector Release Notes for Mule 4](https://docs.mulesoft.com/release-notes/connector/anypoint-mq-connector-release-notes-mule-4)

<!-- document id=70c646f60709d933490a2451e22378e75982832c49d2b5e6603e53ac35d7aaa9 url=/mulesoft/current/en-us/anypoint-mq-connector/latest/anypoint-mq-connector-upgrade-migrate.md -->

---
product: Anypoint MQ Connector
version: 4.x
is-latest-version: true
---

# Upgrading and Migrating Anypoint MQ Connector

> For the full documentation index, see: https://docs.mulesoft.com/llms.txt

To use the latest features, upgrade Anypoint Connector for Anypoint MQ (Anypoint MQ Connector) from
version 3.x to version 4.x.

## Supported Upgrade Paths

<table><colgroup><col> <col></colgroup><thead><tr><th>From Version</th><th>To Version</th></tr></thead><tbody><tr><td><div><div><p>3.x</p></div></div></td><td><div><div><p>4.x</p></div></div></td></tr></tbody></table>

## Changes in This Release

Some changes included in version 4.x break backward compatibility with version 3.x.

Anypoint MQ Connector 4.x includes support for these features:

- Cross-Region Failover

  Anypoint MQ Connector for Mule 4 version 4.0.7 and later provides failover capability for standard
  queues.

  When enabled, if a Mule app can’t reach an Anypoint MQ server in a region, the connector switches
  to the fallback queue in the fallback region to publish and consume messages.

  For information, see:

  - [Configuring Cross-Region Failover for Standard Queues](https://docs.mulesoft.com/mq/mq-failover)

  - [Configuring Cross-Region Failover in Your App](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-failover)

- Connected Apps

  Anypoint MQ Connector for Mule 4 version 4.0.1 and later includes a new format for the **URL**
  field in the **Global Element Properties** page.

  - In Anypoint MQ Connector 3.x, the URL format was:

    `https://mq-us-east-1.anypoint.mulesoft.com/api/v1`

  - In Anypoint MQ Connector 4.x, the URL format includes `{orgID}` and `{envID}`. For example:

    `https://mq-us-east-1.anypoint.mulesoft.com/api/v1/organizations/{orgID}/environments/{envID}`

  > [!IMPORTANT] If you configure the connector with the wrong version of the URL, Anypoint MQ
  > returns the following error:
  >
  > `Invalid api url provided`

To use the failover feature, see
[Configuring Cross-Region Failover in Your App](https://docs.mulesoft.com/anypoint-mq-connector/latest/anypoint-mq-failover).

## Upgrade Prerequisites

Before you perform the upgrade, create a backup of your files, data, and configurations in case you
need to revert to the previous version.

## Upgrade Steps

To upgrade to Anypoint MQ Connector 4.x:

1.  In Anypoint MQ, in the **Destinations** page, click **Copy** and select **Connector version 4.x
    and later** from the menu:

    ![Copy button and menu with connector version options](/mulesoft/current/en-us/mq/_images/mq-tutorial-url.png)

2.  In Anypoint Studio, open the Mule project.

3.  In the Mule Palette view, click **Search in Exchange**.

4.  In **Add Dependencies to Project**, type `Anypoint MQ` in the search field.

5.  In **Available modules**, select **Anypoint MQ Connector - Mule 4** and then click **Add**.

6.  Click **Finish**.

    Anypoint Studio upgrades the connector automatically.

7.  Verify that the `mq-connector` dependency version is `4.0.5` or later in the `pom.xml` file:

    ```xml
    <dependency>
    	<groupId>com.mulesoft.connectors</groupId>
    	<artifactId>anypoint-mq-connector</artifactId>
    	<version>4.0.5</version>
    	<classifier>mule-plugin</classifier>
    </dependency>
    ```

8.  In Anypoint Studio, in the **Anypoint MQ Config** window, paste the URL in the **URL** field:

    ![Anypoint MQ Config page displaying the URL, client app ID, and client secret](/mulesoft/current/en-us/mq/_images/mq-tutorial-studio7-mq-config.png)

9.  Depending on your authentication method, complete the **Client App ID** and **Client Secret**
    fields:

    - **Connected App**:

      Paste the values of **ID** and **Secret** from **Anypoint Platform** > **Access Management** >
      **Connected Apps**.

      For information about configuring Connected Apps in Anypoint MQ, see
      [Configuring Connected Apps](https://docs.mulesoft.com/mq/mq-connected-apps).

    - **Client App**:

      Paste the values of **Client App ID** and **Client Secret** from **Anypoint Platform** >
      **MQ** > **Client Apps**.

      For information about configuring Client Apps in Anypoint MQ, see
      [Configuring Client Apps](https://docs.mulesoft.com/mq/mq-client-apps).

## Post Upgrade Steps

After you install the latest version of the connector, follow these steps to complete the upgrade:

1.  In Anypoint Studio, verify that there are no errors in the **Problems** or **Console** views.

2.  Check the project pom.xml and verify that there are no problems.

3.  Test the connection and verify that the operations work.

## Troubleshooting

If you experience problems with caching the parameters and caching the metadata, restart Anypoint
Studio.

### Reverting the Upgrade

To revert to the previous version of Anypoint MQ Connector, in Anypoint Studio, change the
`mq-connector` dependency version in the project’s `pom.xml` file to the previous version.

## See Also

- [Introduction to Anypoint Connectors](https://docs.mulesoft.com/connectors/introduction/introduction-to-anypoint-connectors)

- [Salesforce Help](https://help.salesforce.com)