[camel] branch master updated: CAMEL-14191: EIP docs - Add links to last EIP patterns and add new pages if missing content

[da...@apache.org]

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 <cl...@gmail.com>
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?