The Wire Tap from the EIP patterns allows you to route messages to a separate tap location while it is forwarded to the ultimate destination.
|The URI of the endpoint to which the wire-tapped message will be sent. You should use either uri or ref.|
|Reference identifier of the endpoint to which the wire-tapped message will be sent. You should use either uri or ref.|
|Reference identifier of a custom Thread Pool to use when processing the wire-tapped messages. If not set, Camel will use a default thread pool.|
|Reference identifier of a custom Processor to use for creating a new message (e.g., the "send a new message" mode).|
|true||Whether to copy the Exchange before wire-tapping the message.|
|Reference identifier of a custom Processor to prepare the copy of the Exchange to be wire-tapped. This allows you to do any custom logic, such as deep-cloning the message payload.|
Camel's WireTap node supports two flavors when tapping an Exchange.
With the traditional Wire Tap, Camel will copy the original Exchange and set its Exchange Pattern to InOnly, as we want the tapped Exchange to be sent in a fire and forget style. The tapped Exchange is then sent in a separate thread so it can run in parallel with the original. Beware that only the Exchange is copied - Wire Tap won't do a deep clone (unless you specify a custom processor via onPrepareRef which does that). So all copies could share objects from the original Exchange.
Camel also provides an option of sending a new Exchange allowing you to populate it with new values. See the Camel Website for dynamically maintained examples of this pattern in use.