This is an automated email from the ASF dual-hosted git repository.
davsclaus pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/camel.git
The following commit(s) were added to refs/heads/master by this push:
new 89b452d CAMEL-14191: EIP docs - Add links to last EIP patterns and
add new pages if missing content
89b452d is described below
commit 89b452d5178b9d07018429788c9d51aca0c5ca1a
Author: Claus Ibsen <[email protected]>
AuthorDate: Wed Nov 20 06:21:11 2019 +0100
CAMEL-14191: EIP docs - Add links to last EIP patterns and add new pages if
missing content
---
.../modules/ROOT/pages/amqp-component.adoc | 6 ++-
.../assets/images/eip/DistributionAggregate.gif | Bin 0 -> 6302 bytes
.../ROOT/pages/composed-message-processor.adoc | 51 +++++++++++++++++++++
.../pages/enterprise-integration-patterns.adoc | 2 +-
4 files changed, 56 insertions(+), 3 deletions(-)
diff --git a/docs/components/modules/ROOT/pages/amqp-component.adoc
b/docs/components/modules/ROOT/pages/amqp-component.adoc
index eb000ee..7230202 100644
--- a/docs/components/modules/ROOT/pages/amqp-component.adoc
+++ b/docs/components/modules/ROOT/pages/amqp-component.adoc
@@ -41,13 +41,14 @@ xref:jms-component.adoc[JMS] component after the
destination name.
// component options: START
-The AMQP component supports 82 options, which are listed below.
+The AMQP component supports 83 options, which are listed below.
[width="100%",cols="2,5,^1,2",options="header"]
|===
| Name | Description | Default | Type
+| *includeAmqpAnnotations* (common) | Whether to include AMQP annotations when
mapping from AMQP to Camel Message. Setting this to true will map AMQP message
annotations to message headers. Due to limitations in Apache Qpid JMS API,
currently delivery annotations are ignored. | false | boolean
| *configuration* (advanced) | To use a shared JMS configuration | |
JmsConfiguration
| *acceptMessagesWhile Stopping* (consumer) | Specifies whether the consumer
accept messages while it is stopping. You may consider enabling this option, if
you start and stop JMS routes at runtime, while there are still messages
enqueued on the queue. If this option is false, and you stop the JMS route,
then messages may be rejected, and the JMS broker would have to attempt
redeliveries, which yet again may be rejected, and eventually the message may
be moved at a dead letter queue on t [...]
| *allowReplyManagerQuick Stop* (consumer) | Whether the
DefaultMessageListenerContainer used in the reply managers for request-reply
messaging allow the DefaultMessageListenerContainer.runningAllowed flag to
quick stop in case JmsConfiguration#isAcceptMessagesWhileStopping is enabled,
and org.apache.camel.CamelContext is currently being stopped. This quick stop
ability is enabled by default in the regular JMS consumers but to enable for
reply managers you must enable this flag. | false [...]
@@ -276,7 +277,7 @@ When using Spring Boot make sure to use the following Maven
dependency to have s
----
-The component supports 83 options, which are listed below.
+The component supports 84 options, which are listed below.
@@ -323,6 +324,7 @@ The component supports 83 options, which are listed below.
| *camel.component.amqp.idle-consumer-limit* | Specify the limit for the
number of consumers that are allowed to be idle at any given time. | 1 | Integer
| *camel.component.amqp.idle-task-execution-limit* | Specifies the limit for
idle executions of a receive task, not having received any message within its
execution. If this limit is reached, the task will shut down and leave
receiving to other executing tasks (in the case of dynamic scheduling; see the
maxConcurrentConsumers setting). There is additional doc available from Spring.
| 1 | Integer
| *camel.component.amqp.include-all-j-m-s-x-properties* | Whether to include
all JMSXxxx properties when mapping from JMS to Camel Message. Setting this to
true will include properties such as JMSXAppID, and JMSXUserID etc. Note: If
you are using a custom headerFilterStrategy then this option does not apply. |
false | Boolean
+| *camel.component.amqp.include-amqp-annotations* | Whether to include AMQP
annotations when mapping from AMQP to Camel Message. Setting this to true will
map AMQP message annotations to message headers. Due to limitations in Apache
Qpid JMS API, currently delivery annotations are ignored. | false | Boolean
| *camel.component.amqp.include-sent-j-m-s-message-i-d* | Only applicable when
sending to JMS destination using InOnly (eg fire and forget). Enabling this
option will enrich the Camel Exchange with the actual JMSMessageID that was
used by the JMS client when the message was sent to the JMS destination. |
false | Boolean
| *camel.component.amqp.jms-key-format-strategy* | Pluggable strategy for
encoding and decoding JMS keys so they can be compliant with the JMS
specification. Camel provides two implementations out of the box: default and
passthrough. The default strategy will safely marshal dots and hyphens (. and
-). The passthrough strategy leaves the key as is. Can be used for JMS brokers
which do not care whether JMS header keys contain illegal characters. You can
provide your own implementation of t [...]
| *camel.component.amqp.jms-operations* | Allows you to use your own
implementation of the org.springframework.jms.core.JmsOperations interface.
Camel uses JmsTemplate as default. Can be used for testing purpose, but not
used much as stated in the spring API docs. The option is a
org.springframework.jms.core.JmsOperations type. | | String
diff --git
a/docs/user-manual/modules/ROOT/assets/images/eip/DistributionAggregate.gif
b/docs/user-manual/modules/ROOT/assets/images/eip/DistributionAggregate.gif
new file mode 100644
index 0000000..6f4a777
Binary files /dev/null and
b/docs/user-manual/modules/ROOT/assets/images/eip/DistributionAggregate.gif
differ
diff --git
a/docs/user-manual/modules/ROOT/pages/composed-message-processor.adoc
b/docs/user-manual/modules/ROOT/pages/composed-message-processor.adoc
new file mode 100644
index 0000000..15c17b9
--- /dev/null
+++ b/docs/user-manual/modules/ROOT/pages/composed-message-processor.adoc
@@ -0,0 +1,51 @@
+[[Composed-Message-Processor]]
+= Composed Message Processor
+
+The
+http://www.enterpriseintegrationpatterns.com/MessageRouter.html[Composed
+Message Processor] from the xref:enterprise-integration-patterns.adoc[EIP
patterns]
+
+How can you maintain the overall message flow when processing a message
consisting of multiple elements, each of which may require different processing?
+
+image::eip/DistributionAggregate.gif[image]
+
+Use Composed Message Processor to process a composite message.
+The Composed Message Processor splits the message up, routes the sub-messages
to the appropriate destinations
+and re-aggregates the responses back into a single message.
+
+With Camel this pattern is implemented by the xref:split-eip.adoc[Splitter]
+which has built-in aggregation to re-aggregate the responses back into a
single message.
+
+== Sample
+
+This sample uses the xref:split-eip.adoc[Splitter] as composed message
processor to process each splitted message,
+aggregate and return a combined single response.
+
+The route and the code comments below explains how you can use the
xref:split-eip.adoc[Splitter] to
+split each message to sub-message which are processed individuallay and then
combined back into
+a single response message via the custom ``aggregationStrategy`
(`MyOrderStategy`), which
+then are the output of the splitter, that are then further processed at the
end of the route.
+
+[source,java]
+----
+// this routes starts from the direct:start endpoint
+// the body is then splitted based on @ separator
+// the splitter in Camel supports InOut as well and for that we need
+// to be able to aggregate what response we need to send back, so we provide
our
+// own strategy with the class MyOrderStrategy.
+from("direct:start")
+ .split(body().tokenize("@"), new MyOrderStrategy())
+ // each splitted message is then send to this bean where we can
process it
+ .to("bean:MyOrderService?method=handleOrder")
+ // this is important to end the splitter route as we do not want to do
more routing
+ // on each splitted message
+ .end()
+ // after we have splitted and handled each message we want to send a
single combined
+ // response back to the original caller, so we let this bean build it for
us
+ // this bean will receive the result of the aggregate strategy:
MyOrderStrategy
+ .to("bean:MyOrderService?method=buildCombinedResponse")
+----
+
+== More details
+
+See the xref:split-eip.adoc[Splitter] EIP.
diff --git
a/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
b/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
index 9a41130..9046138 100644
--- a/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
+++ b/docs/user-manual/modules/ROOT/pages/enterprise-integration-patterns.adoc
@@ -133,7 +133,7 @@ a|image::eip/ResequencerIcon.gif[image]
but out-of-sequence messages back into the correct order?
a|image::eip/DistributionAggregateIcon.gif[image]
-|Composed Message Processor |How
+|xref:composed-message-processor.adoc[Composed Message Processor] |How
can you maintain the overall message flow when processing a message
consisting of multiple elements, each of which may require different
processing?
