Aggregator2Page edited by Claus IbsenChanges (1)
Full ContentAggregatorThis applies for Camel version 2.3 or newer. If you use an older version then use this Aggregator link instead. The Aggregator from the EIP patterns allows you to combine a number of messages together into a single message. A correlation _expression_ is used to determine the messages which should be aggregated together. If you want to aggregate all messages into a single message, just use a constant _expression_. An AggregationStrategy is used to combine all the message exchanges for a single correlation key into a single message exchange. Aggregator optionsThe aggregator supports the following options:
Exchange PropertiesThe following properties are set on each aggregated Exchange:
About AggregationStrategyThe AggregationStrategy is used for aggregating the old (lookup by its correlation id) and the new exchanges together into a single exchange. Possible implementations include performing some kind of combining or delta processing, such as adding line items together into an invoice or just using the newest exchange and removing old exchanges such as for state tracking or market data prices; where old values are of little use. Notice the aggregation strategy is a mandatory option and must be provided to the aggregator. Here are a few example AggregationStrategy implementations that should help you create your own custom strategy.
//simply combines Exchange String body values using '+' as a delimiter
class StringAggregationStrategy implements AggregationStrategy {
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
if (oldExchange == null) {
return newExchange;
}
String oldBody = oldExchange.getIn().getBody(String.class);
String newBody = newExchange.getIn().getBody(String.class);
oldExchange.getIn().setBody(oldBody + "+" + newBody);
return oldExchange;
}
}
//simply combines Exchange body values into an ArrayList<Object>
class ArrayListAggregationStrategy implements AggregationStrategy {
public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
Object newBody = newExchange.getIn().getBody();
ArrayList<Object> list = null;
if (oldExchange == null) {
list = new ArrayList<Object>();
list.add(newBody);
newExchange.getIn().setBody(list);
return newExchange;
} else {
list = oldExchange.getIn().getBody(ArrayList.class);
list.add(newBody);
return oldExchange;
}
}
}
About completionWhen aggregation Exchanges at some point you need to indicate that the aggregated exchanges is complete, so they can be send out of the aggregator. Camel allows you to indicate completion in various ways as follows:
Notice that all the completion ways are per correlation key. And you can combine them in any way you like. It's basically the first which triggers that wins. So you can use a completion size together with a completion timeout. Only completionTimeout and completionInterval cannot be used at the same time. Notice the completion is a mandatory option and must be provided to the aggregator. If not provided Camel will thrown an Exception on startup.
Persistent AggregationRepositoryThe aggregator provides a pluggable repository which you can implement your own org.apache.camel.spi.AggregationRepository. ExamplesSee some examples from the old Aggregator which is somewhat similar to this new aggregator.
Using completionTimeoutIn this example we want to aggregate all incoming messages and after 3 seconds of inactivity we want the aggregation to complete. This is done using the completionTimeout option as shown: And the same example using Spring XML: Using TimeoutAwareAggregationStrategyAvailable as of Camel 2.9.2 If your aggregation strategy implements TimeoutAwareAggregationStrategy, then Camel will invoke the timeout method when the timeout occurs. Notice that the values for index and total parameters will be -1, and the timeout parameter will be provided only if configured as a fixed value. You must not throw any exceptions from the timeout method. Using CompletionAwareAggregationStrategyAvailable as of Camel 2.9.3 If your aggregation strategy implements CompletionAwareAggregationStrategy, then Camel will invoke the onComplete method when the aggregated Exchange is completed. This allows you to do any last minute custom logic such as to cleanup some resources, or additional work on the exchange as it's now completed. Using completionSizeIn this example we want to aggregate all incoming messages and when we have 3 messages aggregated (in the same correlation group) we want the aggregation to complete. This is done using the completionSize option as shown: And the same example using Spring XML: Using completionPredicateIn this example we want to aggregate all incoming messages and use a Predicate to determine when we are complete. The Predicate can be evaluated using either the aggregated exchange (default) or the incoming exchange. We will so both situations as examples. We start with the default situation as shown: And the same example using Spring XML: And the other situation where we use the eagerCheckCompletion option to tell Camel to use the incoming Exchange. Notice how we can just test in the completion predicate that the incoming message is the END message: And the same example using Spring XML: Using dynamic completionTimeoutIn this example we want to aggregate all incoming messages and after a period of inactivity we want the aggregation to complete. The period should be computed at runtime based on the timeout header in the incoming messages. This is done using the completionTimeout option as shown: And the same example using Spring XML: Note: You can also add a fixed timeout value and Camel will fallback to use this value if the dynamic value was null or 0. Using dynamic completionSizeIn this example we want to aggregate all incoming messages based on a dynamic size per correlation key. The size is computed at runtime based on the mySize header in the incoming messages. This is done using the completionSize option as shown: And the same example using Spring XML: Note: You can also add a fixed size value and Camel will fallback to use this value if the dynamic value was null or 0. Using This PatternIf you would like to use this EIP Pattern then please read the Getting Started, you may also find the Architecture useful particularly the description of Endpoint and URIs. Then you could try out some of the Examples first before trying this pattern out. Manually Force the Completion of All Aggregated Exchanges ImmediatelyAvailable as of Camel 2.9 Available as of Camel 2.11 Using a List<V> in AggregationStrategyAvailable as of Camel 2.11 If you want to aggregate some value from the messages <V> into a List<V> then we have added a org.apache.camel.processor.aggregate.AbstractListAggregationStrategy abstract class in Camel 2.11 that makes this easier. The completed Exchange that is sent out of the aggregator will contain the List<V> in the message body. For example to aggregate a List<Integer> you can extend this class as shown below, and implement the getValue method: Using POJOs as AggregationStrategyAvailable as of Camel 2.12
To use the AggregationStrategy you had to implement the org.apache.camel.processor.aggregate.AggregationStrategy interface, which means your logic would be tied to the Camel API. From Camel 2.12 onwards you can use a POJO for the logic and let Camel adapt to your POJO. To use a POJO a convention must be followed:
The paired methods is expected to be ordered as follows:
This convention is best explained with some examples. In the method below, we have only 2 parameters, so the 1st parameter is the body of the oldExchange, and the 2nd is paired to the body of the newExchange:
public String append(String existing, String next) {
return existing + next;
}
In the method below, we have only 4 parameters, so the 1st parameter is the body of the oldExchange, and the 2nd is the Map of the oldExchange} headers, and the 3rd is paired to the body of the {{newExchange, and the 4th parameter is the Map of the newExchange headers:
public String append(String existing, Map existingHeaders, String next, Map nextHeaders) {
return existing + next;
}
And finally if we have 6 parameters the we also have the properties of the Exchanges:
public String append(String existing, Map existingHeaders, Map existingProperties, String next, Map nextHeaders, Map nextProperties) {
return existing + next;
}
To use this with the Aggregate EIP we can use a POJO with the aggregate logic as follows:
public class MyBodyAppender {
public String append(String existing, String next) {
return next + existing;
}
}
And then in the Camel route we create an instance of our bean, and then refer to the bean in the route using bean method from org.apache.camel.util.toolbox.AggregationStrategies as shown:
private MyBodyAppender appender = new MyBodyAppender();
public void configure() throws Exception {
from("direct:start")
.aggregate(constant(true), AggregationStrategies.bean(appender, "append"))
.completionSize(3)
.to("mock:result");
}
We can also provide the bean type directly:
public void configure() throws Exception {
from("direct:start")
.aggregate(constant(true), AggregationStrategies.bean(MyBodyAppender.class, "append"))
.completionSize(3)
.to("mock:result");
}
And if the bean has only one method we do not need to specify the name of the method:
public void configure() throws Exception {
from("direct:start")
.aggregate(constant(true), AggregationStrategies.bean(MyBodyAppender.class))
.completionSize(3)
.to("mock:result");
}
And the append method could be static:
public class MyBodyAppender {
public static String append(String existing, String next) {
return next + existing;
}
}
If you are using XML DSL then we need to declare a <bean> with the POJO:
<bean id="myAppender" class="com.foo.MyBodyAppender"/>
And in the Camel route we use strategyRef to refer to the bean by its id, and the strategyMethodName can be used to define the method name to call:
<camelContext xmlns="http://camel.apache.org/schema/spring">
<route>
<from uri="direct:start"/>
<aggregate strategyRef="myAppender" strategyMethodName="append" completionSize="3">
<correlationExpression>
<constant>true</constant>
</correlationExpression>
<to uri="mock:result"/>
</aggregate>
</route>
</camelContext>
When using XML DSL you must define the POJO as a <bean>. Aggregating when no dataBy default when using POJOs as AggregationStrategy, then the method is only invoked when there is data to be aggregated. Where as without using POJOs then you may have null as oldExchange or newExchange parameters. For example the Aggregate EIP will invoke the AggregationStrategy with oldExchange as null, for the first Exchange incoming to the aggregator. And then for subsequent Exchanges then oldExchange and newExchange parameters are both not null. Example with Content Enricher and no dataThough with POJOs as AggregationStrategy we made this simpler and only call the method when oldExchange and newExchange is not null, as that would be the most common use-case. If you need to allow oldExchange or newExchange to be null, then you can configure this with the POJO using the AggregationStrategyBeanAdapter as shown below. On the bean adapter we call setAllowNullNewExchange to allow the new exchange to be null.
public void configure() throws Exception {
AggregationStrategyBeanAdapter myStrategy = new AggregationStrategyBeanAdapter(appender, "append");
myStrategy.setAllowNullNewExchange(true);
from("direct:start")
.pollEnrich("seda:foo", 1000, myStrategy)
.to("mock:result");
}
Then the append method in the POJO would need to deal with the situation that newExchange can be null:
public class MyBodyAppender {
public String append(String existing, String next) {
if (next == null) {
return "NewWasNull" + existing;
} else {
return existing + next;
}
}
}
In the example above we use the Content Enricher EIP using pollEnrich. The newExchange will be null in the situation we could not get any data from the "seda:foo" endpoint, and therefore the timeout was hit after 1 second. So if we need to do some special merge logic we would need to set setAllowNullNewExchange=true, so the append method will be invoked. If we do not do that then when the timeout was hit, then the append method would normally not be invoked, meaning the Content Enricher did not merge/change the message. There is also a method setAllowNullOldExchange to set whether the oldExchange is allowed to be null. See also
Stop watching space
|
Change email notification preferences
View Online
|
View Changes
|
Add Comment
|
- [CONF] Apache Camel > Aggregator2 confluence
- [CONF] Apache Camel > Aggregator2 confluence
- [CONF] Apache Camel > Aggregator2 Claus Ibsen (Confluence)
- [CONF] Apache Camel > Aggregator2 Claus Ibsen (Confluence)
- [CONF] Apache Camel > Aggregator2 Claus Ibsen (Confluence)
- [CONF] Apache Camel > Aggregator2 Claus Ibsen (Confluence)
- [CONF] Apache Camel > Aggregator2 Claus Ibsen (Confluence)
- [CONF] Apache Camel > Aggregator2 Claus Ibsen (Confluence)
- [CONF] Apache Camel > Aggregator2 Claus Ibsen (Confluence)
