Skip to main content

ActiveMQ Source Node

Quick Reference​

Use Credentials (Optional) Username/password for the broker. Leave blank to connect anonymously.

Broker URL The ActiveMQ broker to connect to. ex: tcp://localhost:61616

Broker Type Classic for ActiveMQ Classic (5.x), Artemis for ActiveMQ Artemis. These use different clients — pick the one matching your broker.

Destination The queue or topic name to consume from. ex: my-queue

Destination Type Queue for point-to-point consumption, Topic for a durable subscription.

Encoding Type The format of the message bodies.

Client ID / Subscription Name Required when Destination Type is Topic — together they identify the durable subscription.

Overview​

The ActiveMQ Source node consumes messages from an Apache ActiveMQ broker and passes them into your workflow. It acts as the starting point of a workflow and supports both broker families — ActiveMQ Classic (the 5.x line) and ActiveMQ Artemis, which also underpins Red Hat AMQ 7.

Messages are consumed inside a transacted session, so they are acknowledged only once the workflow has committed them. If the workflow restarts mid-batch, the broker redelivers the uncommitted messages rather than losing them.

You can read from either a queue, where messages are distributed among consumers, or a topic via a durable subscription, where the broker retains messages published while your workflow is offline.

Configuration​

FieldDescriptionRequiredDefault
Use CredentialsSelect or create a username/password credential for the broker. Leave blank to connect anonymously.No—
Broker URLThe ActiveMQ broker URL (e.g. tcp://localhost:61616).Yes—
Broker TypeThe broker family: Classic or Artemis. Each uses its own client library.YesClassic
DestinationThe name of the queue or topic to consume from.Yes—
Destination TypeQueue for point-to-point consumption, or Topic for a durable subscription.YesQueue
Encoding TypeHow each message body should be interpreted. Options: CSV, JSON Object, JSON Array, JSON Lines, String Line, Text, XML. More info here.YesJSON Object
Client IDJMS client id identifying this connection to the broker. Shown and required only when Destination Type is Topic.Conditional—
Subscription NameName of the durable subscription. Shown and required only when Destination Type is Topic.Conditional—
note

Where source connection profiles are enabled, Use Credentials and Broker URL are replaced by a single Connection Profile selector that supplies both. The remaining fields are unchanged.

Broker Type​

ActiveMQ Classic and ActiveMQ Artemis are separate products with separate client libraries, and this field selects between them. Choosing the wrong one generally fails at connection time rather than producing subtly wrong behavior.

  • Classic — Apache ActiveMQ Classic, the 5.x line. Default port 61616.
  • Artemis — Apache ActiveMQ Artemis, also the basis of Red Hat AMQ 7 and EAP messaging.

Queue vs Topic​

Queue​

Each message goes to exactly one consumer. Running the workflow with multiple workers spreads the queue's messages between them, which is the straightforward way to scale throughput.

Topic​

Selecting Topic creates a durable subscription, which is why Client ID and Subscription Name become required. The broker holds messages for that subscription even while your workflow is stopped, so nothing published during a restart or deployment is missed.

Two things to keep in mind:

  • Keep both values stable. The broker identifies the subscription by the Client ID / Subscription Name pair. Changing either one creates a new, empty subscription — and leaves the old one on the broker accumulating messages that nothing consumes.
  • A durable subscription allows one active connection at a time. A topic-based workflow therefore cannot be scaled across multiple concurrent workers sharing the same Client ID.

Notes​

Delivery is at-least-once. Because acknowledgement is tied to the workflow's commit, messages consumed but not yet committed are redelivered after a crash or restart. Downstream steps should tolerate the occasional duplicate.

Text and binary messages are both supported. JMS TextMessage and BytesMessage bodies are read; other JMS message types raise an error.