Enterprise Documentation
You are viewing a previous version of KrakenD Enterprise Edition (v2.3)
, go to the latest version
Gateway integration with RabbitMQ producers
Document updated on Mar 16, 2023
About this feature
| Since | v0.9 |
|---|---|
| Namespace | backend/amqp/producer |
| Log prefix | [BACKEND: /foo][AMQP] |
| Scope | backend |
| Source | krakendio/krakend-amqp |
The AMQP producer component allows to send messages to a queue through the API Gateway.
The configuration of the queue is a straightforward process. To connect the endpoints to the messaging system you only need to include the extra_config key with the namespace backend/amqp/producer.
The parameters of this integration follow the AMQP specification. To understand what are the implications of a certain parameter, see the AMQP Complete Reference Guide.
KrakenD creates both the exchange and the queue for you.
Producer Configuration
{
"backend": [{
"host": ["amqp://guest:[email protected]:5672"],
"disable_host_sanitize": true,
"extra_config": {
"backend/amqp/producer": {
"name": "queue-1",
"exchange": "some-exchange",
"durable": true,
"delete": false,
"no_wait": true,
"no_local": false,
"routing_key": "#",
"mandatory": false,
"immediate": false,
"backoff_strategy": "exponential-jitter"
}
}
}]
}
Fields of AMQP Producer
* required fields
| When the connection to your event source gets interrupted for whatever reason, KrakenD keeps trying to reconnect until it succeeds or until it reaches the max_retries. The backoff strategy defines the delay in seconds in between consecutive failed retries. Check the meaning of each strategy.Possible values are: "linear" , "linear-jitter" , "exponential" , "exponential-jitter" , "fallback"Defaults to "fallback" |
| When true, AMQP deletes the queue when there are no remaining connections. This option is not recommended in most of the scenarios. If for instance, the connectivity between KrakenD and AMQP is lost for whatever reason and it’s the only client, AMQP will delete the queue no matter the number of messages there are inside, and when KrakenD gets the connection again the queue won’t exist and future connections will recreate it again.Defaults to false |
| true is recommended, but depends on the use case. Durable queues will survive server restarts and remain when there are no remaining consumers or bindings. Defaults to false |
| The exchange name (must have a topic type if already exists). Example: "some-exchange" |
| When true, AMQP will allow a single KrakenD instance to access the queue. This option is not recommended in environments where the gateway needs high availability and you have several instances running.Defaults to false |
| Take a parameter from a {placeholder} in the endpoint definition to use as the expiration key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.Defaults to "" |
| A consumer must be connected to the queue when true. Defaults to false |
| The exchange must have at least one queue bound when true. Defaults to false |
| The maximum number of times you will allow KrakenD to retry reconnecting to a broken messaging system. During startup KrakenD will wait for a maximum of 3 retries before starting to use this policy. Use 0 for unlimited retries. Defaults to 0 |
| Take a parameter from a {placeholder} in the endpoint definition to use as the message identifier. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.Defaults to "" |
| Queue name. |
| The no_local flag is not supported by RabbitMQ. |
| When true, do not wait for the server to confirm the request and immediately begin deliveries. If it is not possible to consume, a channel exception will be raised and the channel will be closed. |
| Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.Defaults to "" |
| Take a parameter from a {placeholder} in the endpoint definition to use as the reply key. The key must have the first letter uppercased. For instance, when an endpoint parameter is defined as {id}, you must write Id.Defaults to "" |
| The routing key you will use to send messages, case sensitive. Defaults to "#" |
Additionally, the items below are parameter keys that can be present in the endpoint URL and are passed to the producer. Parameters need capitalization on the first letter.
Parameters’ first character uppercased
Notice the capitalization of the first letter of the parameter names at the configuration below used in
exp_key, reply_to_key, msg_id_key, priority_key, and routing_key.For instance, an endpoint URL could be declared as /produce/{a}/{b}/{id}/{prio}/{route} and the producer knows how to map them with a configuration like this:
{
"backend/amqp/producer": {
"@comment": "Rest of the settings omitted",
"exp_key":"A",
"reply_to_key":"B",
"msg_id_key":"Id",
"priority_key":"Prio",
"routing_key":"Route"
}
}
Connection retries
The gateway will try to reconnect to the AMQP server if the connection is lost for any reason. You can set the back-off strategy that better fits your needs.
