What it does in BusinessWorks
Publishes one message to a JMS topic, so every active subscriber receives it, unlike a queue send
where one consumer takes the message. Configuration is the same shape as
JMS Queue Sender: destination, delivery mode and connection under
<config><SessionAttributes>. The activity carries no reply and no acknowledgement beyond the
publish itself.
Topics are the usual choice for the fan-out side of an event pattern: a status change or a business event published once and picked up by however many downstream systems subscribed to it, with the publisher never aware of how many that is.
The Camel equivalent
This activity dispatches to the same destination-resolution rule as JMS Queue Sender, parameterised for a topic instead of a queue. Read that page for the worked example and the config-nesting mismatch that causes it to fail in practice; this page covers only what is specific to publishing.
Where the semantics diverge
The destination-resolution failure described on JMS Queue Sender
applies here unchanged: the rule looks for a top-level destination key that Designer never
writes, falls back to a heuristic over the input bindings that XSLT-driven values rarely satisfy,
and warns instead of publishing when both come up empty.
A missed publish is a different failure than a missed send. A queue send with no consumer listening is usually a stuck message somewhere recoverable. A topic publish that never happens is gone: there is no subscriber that can later notice it did not arrive, because a topic has no queue behind it holding the message. Every system that should have reacted to the event silently does not, and there is nothing in the generated route or its logs pointing at which downstream reaction is now missing.
Treat every unresolved Topic Publisher as a fan-out that has to be rebuilt deliberately: identify every real subscriber the original topic had, and either publish to a real broker topic once its name is known or replace the fan-out with explicit calls to each subscriber.
What the toolchain does
The same rule as JMS Queue Sender: an index lookup, a fallback heuristic over the input bindings,
and a TODO_HUMAN warning when neither resolves. Where the index does resolve the destination to a
single known component, the publish is replaced with a direct: hop into it; camel-jms is not used
at all in that case.