receiveFromRabbitMq
Source processor that consumes messages from a RabbitMQ queue.
If no errors are reported from the flow pipeline, the message will be ACKed. For transient errors, the message will be NACKed and set for redelivery, while non-transient errors will be NACKed without redelivery. Special case: When a dead letter flow (DLF) is defined, transient errors will be handled by the DLF and therefore ACKed to RabbitMQ and not scheduled for redelivery from the broker.
RabbitMQ broker redeliveries are normally not throttled. This can lead to spurious redeliveries when transient errors take a while to be corrected. To alleviate this, the client attempts some local redeliveries driven by an exponential backoff algorithm before delegating redeliveries back to the broker. This throttles the redelivery rate, since each redelivery from the broker is subject to the backed off redelivery strategy on the client.
If possible, ensure that there is also a proper error handling setup in the broker (e.g. TTL, DLQ etc.).
The source is a singleton. To set up multiple consumers, multiple flows are required.
Properties
Name | Summary |
---|---|
|
A list of host/port pairs to use for establishing the initial connection to the RabbitMQ server. Required and must be a string in the form of |
|
Name of the RabbitMQ queue to listen to. Required. |
|
Name of the RabbitMQ virtual host. Optional. |
|
Key from the server configuration used to look up the credentials needed to connect to the RabbitMQ broker. Optional. If not set, RabbitMQ setting "guest/guest" will be used. |
|
Connection timeout value. Optional. Will fetch value from server config value if not set. |
|
Socket timeout value. Optional. Will fetch value from server config value if not set. |
|
Whether to enable encryption for the RabbitMQ session. Optional and not enabled by default. The |
|
Key from the server configuration used to look up SSL credentials for server and client authentication. Optional and should only be used if the flag |
|
Optional, descriptive name for the processor. |
|
Required identifier of the processor, unique across all processors within the flow. Must be between 3 and 30 characters long; contain only lower and uppercase alphabetical characters (a-z and A-Z), numbers, dashes ("-"), and underscores ("_"); and start with an alphabetical character. In other words, it adheres to the regex pattern |
|
Optional set of custom properties in a simple jdk-format, that are added to the message exchange properties before processing the incoming payload. Any existing properties with the same name will be replaced by properties defined here. |
|
Whether the incoming payload is available for error processing on failure. Defaults to |
Sub-builders
Name | Summary |
---|---|
Strategy for describing the external system integration. Optional. |
|
Strategy for describing how a processor’s message is logged on the server. |
|
Strategy for archiving payloads. |
|
Strategy that customizes the conversion of an incoming payload by a processor (e.g., string to object). Should be used when the processor’s default conversion logic cannot be used. |
Details
Authentication
The authenticationConfigKey
property supports secrets of type UserNameAndPassword.
See the Secret Types documentation for formatting details.
TLS (SSL) Configuration
The RabbitMQ consumer can be configured to use TLS/SSL on the transport level. :imageprefix:
If the target service is using a valid SSL certificate, signed by a trusted CA, there is no need for additional configuration. However, configuration must be provided if you require one of the following features:
-
Providing a client certificate (if requested by the server).
-
Providing a truststore for server certificate validation. This is useful, for example, when the root certificate has not been signed by a trusted CA.
-
Limiting the server certificate to a specified public key.
-
Accepting a self-signed server certificate.
-
Accepting a server certificate issued for a host other than the one being requested.
To enable these features, the sslAuthenticationConfigKey
property must be set and point to a secret of type Tls.
See the Secret Types documentation for formatting details.
Client Key Store Usage
RabbitMQ supports the following types of client key store usage:
-
Client TLS (x.509) certificate authentication. Used instead of username and password credentials.
-
Peer verification. Used in addition to username and password credentials.