This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/main by this push:
new 779f7cf4bc64 CAMEL-26385: camel-core - Enrich EIP docs: keep the
message with variableReceive (#28635)
779f7cf4bc64 is described below
commit 779f7cf4bc64ff0eea8268a308baa54abcf0f6c1
Author: Claus Ibsen <[email protected]>
AuthorDate: Thu Oct 29 07:09:28 2026 +0100
CAMEL-26385: camel-core - Enrich EIP docs: keep the message with
variableReceive (#28635)
The page explained only the aggregation strategy. A first section now shows
variableReceive (Java, XML and YAML): the reply goes into a variable and the
body and headers stay as they are.
Co-Authored-By: Claude Opus 5.5 <[email protected]>
Co-Authored-By: Claude Sonnet 5.5 <[email protected]>
Signed-off-by: Claus Ibsen <[email protected]>
---
.../org/apache/camel/catalog/docs/enrich-eip.adoc | 68 +++++++++++++++++++++-
.../main/docs/modules/eips/pages/enrich-eip.adoc | 68 +++++++++++++++++++++-
.../dsl/jbang/core/commands/ai/eip-samples.json | 4 ++
3 files changed, 138 insertions(+), 2 deletions(-)
diff --git
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/enrich-eip.adoc
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/enrich-eip.adoc
index 51b5a5b0981f..786cc751fb67 100644
---
a/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/enrich-eip.adoc
+++
b/catalog/camel-catalog/src/generated/resources/org/apache/camel/catalog/docs/enrich-eip.adoc
@@ -51,6 +51,71 @@ Enrich EIP is the most common content enricher that uses a
`Producer` to obtain
The content enricher (`enrich`) retrieves additional data from a _resource
endpoint_
to enrich an incoming message (contained in the _original exchange_).
+=== Keeping the message: the reply in a variable
+
+By default, the reply of the resource endpoint becomes the message, as with
`to`: the reply body replaces the body.
+To keep the message as it is, set `variableReceive`: the reply body is stored
in that variable, and the message body
+and headers stay unchanged. This is the simplest way to enrich, with no
aggregation strategy to write.
+
+For example, the body is an order that is sent to the stock service with
request-reply, and the order stays the body,
+so it can be sent on after the stock service has answered:
+
+[tabs]
+====
+Java::
++
+[source,java]
+----
+from("jms:queue:orders")
+ .enrich().constant("jms:queue:stock").variableReceive("stock")
+ .log("Stock service answered for ${header.orderId}: ${variable.stock}")
+ .to("jms:queue:reserved");
+----
+
+XML::
++
+[source,xml]
+----
+<route>
+ <from uri="jms:queue:orders"/>
+ <enrich variableReceive="stock">
+ <constant>jms:queue:stock</constant>
+ </enrich>
+ <log message="Stock service answered for ${header.orderId}:
${variable.stock}"/>
+ <to uri="jms:queue:reserved"/>
+</route>
+----
+
+YAML::
++
+[source,yaml]
+----
+- route:
+ from:
+ uri: jms:queue:orders
+ steps:
+ - enrich:
+ expression:
+ constant: jms:queue:stock
+ variableReceive: stock
+ - log:
+ message: "Stock service answered for ${header.orderId}:
${variable.stock}"
+ - to:
+ uri: jms:queue:reserved
+----
+====
+
+The headers of the reply are stored as variables too, using the pattern
`header:<variable>.<headerName>`, for example
+`header:stock.JMSCorrelationID`. To send something other than the message body
to the resource endpoint,
+set `variableSend` to the name of a variable that holds the request body; the
message body is then not sent at all.
+
+`variableReceive` works the same with `to` when it uses request-reply
(`exchangePattern: InOut`) and with
+xref:pollEnrich-eip.adoc[Poll Enrich]. See
xref:manual::variables.adoc[Variables] for more about `variableSend`
+and `variableReceive`. When an aggregation strategy is set as well, the result
of the strategy is stored in the
+variable.
+
+=== Merging the reply with an aggregation strategy
+
An `AggregationStrategy` is used to combine the original exchange and the
_resource exchange_. The first parameter of the
`AggregationStrategy.aggregate(Exchange, Exchange)` method corresponds to the
original exchange, the second parameter the resource exchange.
Here's an example for implementing an `AggregationStrategy`, which merges the
two data
@@ -128,7 +193,8 @@ YAML::
=== Aggregation Strategy is optional
The aggregation strategy is optional.
-If not provided, then Camel will just use the result exchange as the result.
+If not provided, then Camel will just use the result exchange as the result:
the reply replaces the message body.
+To keep the message, store the reply in a variable with `variableReceive`, as
shown above.
The following example:
diff --git
a/core/camel-core-engine/src/main/docs/modules/eips/pages/enrich-eip.adoc
b/core/camel-core-engine/src/main/docs/modules/eips/pages/enrich-eip.adoc
index 51b5a5b0981f..786cc751fb67 100644
--- a/core/camel-core-engine/src/main/docs/modules/eips/pages/enrich-eip.adoc
+++ b/core/camel-core-engine/src/main/docs/modules/eips/pages/enrich-eip.adoc
@@ -51,6 +51,71 @@ Enrich EIP is the most common content enricher that uses a
`Producer` to obtain
The content enricher (`enrich`) retrieves additional data from a _resource
endpoint_
to enrich an incoming message (contained in the _original exchange_).
+=== Keeping the message: the reply in a variable
+
+By default, the reply of the resource endpoint becomes the message, as with
`to`: the reply body replaces the body.
+To keep the message as it is, set `variableReceive`: the reply body is stored
in that variable, and the message body
+and headers stay unchanged. This is the simplest way to enrich, with no
aggregation strategy to write.
+
+For example, the body is an order that is sent to the stock service with
request-reply, and the order stays the body,
+so it can be sent on after the stock service has answered:
+
+[tabs]
+====
+Java::
++
+[source,java]
+----
+from("jms:queue:orders")
+ .enrich().constant("jms:queue:stock").variableReceive("stock")
+ .log("Stock service answered for ${header.orderId}: ${variable.stock}")
+ .to("jms:queue:reserved");
+----
+
+XML::
++
+[source,xml]
+----
+<route>
+ <from uri="jms:queue:orders"/>
+ <enrich variableReceive="stock">
+ <constant>jms:queue:stock</constant>
+ </enrich>
+ <log message="Stock service answered for ${header.orderId}:
${variable.stock}"/>
+ <to uri="jms:queue:reserved"/>
+</route>
+----
+
+YAML::
++
+[source,yaml]
+----
+- route:
+ from:
+ uri: jms:queue:orders
+ steps:
+ - enrich:
+ expression:
+ constant: jms:queue:stock
+ variableReceive: stock
+ - log:
+ message: "Stock service answered for ${header.orderId}:
${variable.stock}"
+ - to:
+ uri: jms:queue:reserved
+----
+====
+
+The headers of the reply are stored as variables too, using the pattern
`header:<variable>.<headerName>`, for example
+`header:stock.JMSCorrelationID`. To send something other than the message body
to the resource endpoint,
+set `variableSend` to the name of a variable that holds the request body; the
message body is then not sent at all.
+
+`variableReceive` works the same with `to` when it uses request-reply
(`exchangePattern: InOut`) and with
+xref:pollEnrich-eip.adoc[Poll Enrich]. See
xref:manual::variables.adoc[Variables] for more about `variableSend`
+and `variableReceive`. When an aggregation strategy is set as well, the result
of the strategy is stored in the
+variable.
+
+=== Merging the reply with an aggregation strategy
+
An `AggregationStrategy` is used to combine the original exchange and the
_resource exchange_. The first parameter of the
`AggregationStrategy.aggregate(Exchange, Exchange)` method corresponds to the
original exchange, the second parameter the resource exchange.
Here's an example for implementing an `AggregationStrategy`, which merges the
two data
@@ -128,7 +193,8 @@ YAML::
=== Aggregation Strategy is optional
The aggregation strategy is optional.
-If not provided, then Camel will just use the result exchange as the result.
+If not provided, then Camel will just use the result exchange as the result:
the reply replaces the message body.
+To keep the message, store the reply in a variable with `variableReceive`, as
shown above.
The following example:
diff --git
a/dsl/camel-jbang/camel-jbang-core/src/generated/resources/org/apache/camel/dsl/jbang/core/commands/ai/eip-samples.json
b/dsl/camel-jbang/camel-jbang-core/src/generated/resources/org/apache/camel/dsl/jbang/core/commands/ai/eip-samples.json
index 42e193f5a7b0..8623d5207649 100644
---
a/dsl/camel-jbang/camel-jbang-core/src/generated/resources/org/apache/camel/dsl/jbang/core/commands/ai/eip-samples.json
+++
b/dsl/camel-jbang/camel-jbang-core/src/generated/resources/org/apache/camel/dsl/jbang/core/commands/ai/eip-samples.json
@@ -364,6 +364,10 @@
}
],
"enrich": [
+ {
+ "source": "enrich-eip.adoc",
+ "yaml": "- route:\n from:\n uri: jms:queue:orders\n
steps:\n - enrich:\n expression:\n constant:
jms:queue:stock\n variableReceive: stock\n - log:\n
message: \"Stock service answered for ${header.orderId}: ${variable.stock}\"\n
- to:\n uri: jms:queue:reserved\n"
+ },
{
"source": "enrich-eip.adoc",
"yaml": "- route:\n from:\n uri: direct:start\n steps:\n
- enrich:\n expression:\n constant:
http:remoteserver\/foo\n aggregationStrategy: \"#myStrategy\"\n
- to:\n uri: mock:result\n- beans:\n - name: myStrategy\n
type: com.foo.ExampleAggregationStrategy\n"
