Source processor that consumes messages from a JMS broker.

Messages will not be acknowledged (ACKed) to the broker until they have been successfully persisted in the source processor. Failure to persist messages will result in a NACK with retry. For other errors, messages will still be ACKed. Setting up dead letter flows to handle these errors should be considered.


Name Summary


ID of the JMS provider to use.


A list of host/port pairs to use for establishing the initial connection to the JMS server. This string must be in the form of host1:port1,host2:port2, etc.


Name of the JMS destination where data is consumed from.


The JmsDestinationType. Can be either QUEUE (default) or TOPIC.


Key from the server configuration used to look up the credentials needed to connect to the JMS broker.


Key from the server configuration used to look up SSL credentials for server and client authentication. Optional.


Number of concurrent consumers that will be used to get JMS messages. Optional and should only be set if you have a specific requirement for it. When this consumer is deployed in a cluster, all nodes will already compete for messages, which will usually provide sufficient concurrency. This option is only available for listening to queues and not topics.


Connection timeout value. Optional


Socket timeout value. Optional


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 [a-zA-Z][a-zA-Z0-9_-]{2,29}.


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 false.


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.


Provider Types

The providerType property determines which JMS provider to use when creating the ConnectionFactory for integrating with a JMS broker. Utilihive currently supports the following provider type:

Provider Type ID Supported Brokers


Any broker supporting the AMQP 1.0 protocol.


The authenticationConfigKey property supports secrets of type UserNameAndPassword. See the Secret Types documentation for formatting details.

TLS (SSL) Configuration

Both the JMS consumer and producer 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.