What it does in BusinessWorks
Sends a message to a JMS queue and blocks until a correlated reply arrives on a temporary or
configured reply destination, or until the activity’s timeout expires. Configuration is the same
shape as JMS Queue Sender: destination, delivery settings and connection
under <config><SessionAttributes>, plus a request timeout the input mapping can override. The
activity’s output is the reply body and headers, not a send confirmation.
Where a process needs a synchronous answer over a queue-based integration rather than a topic broadcast or a fire-and-forget send, this is the activity that provides it.
The Camel equivalent
The rule this activity dispatches to is the request-reply sibling of the one described in full on
JMS Queue Sender: same destination lookup, same fallback heuristic, same
TODO_HUMAN outcome when neither resolves. That page has the worked example; this one covers only
what differs for the request-reply form.
Where the semantics diverge
Everything under JMS Queue Sender about the destination never being read
from where Designer actually writes it applies here without change, because both activities are
parsed the same way and dispatch to the same destination-resolution logic. In a real run of this
toolchain, this activity’s unresolved path produces the same warning, worded for a request-reply
rather than a send, and no .to(...) at all.
The correlation and the timeout disappear with it. Even where the destination does resolve, the
rule that succeeds emits a plain .to(...) on the resolved endpoint or a direct: hop, neither of
which waits for a correlated reply the way the source activity did. Request-reply semantics, and
the configured timeout that bounded them, are not part of what this rule produces either way.
Anywhere this activity appears, plan on writing the request-reply exchange by hand: a real
InOut endpoint once the destination is known, or a direct: call into whatever actually answers
the request if the reply was really coming from inside the same estate.
What the toolchain does
The same rule shape as JMS Queue Sender, with request-reply’s own wording on the warning: an index
lookup first, the input-binding heuristic second, and a TODO_HUMAN log when both come up empty.
Where the index resolves the destination to a single known component, the call is replaced outright
with a plain direct: hop into it, dropping JMS entirely. Where a destination string is available
but not indexed, it stays JMS with an explicit ?exchangePattern=InOut.