Enterprise Integration Patterns

Enterprise Integration Patterns

Camel supports most of the Enterprise Integration Patterns from the excellent book of the same name by Gregor Hohpe and Bobby Woolf. Its a highly recommended book, particularly for users of Camel.

Pattern Index

There now follows a list of the Enterprise Integration Patterns from the book along with examples of the various patterns using Apache Camel

Messaging Systems

Message Channel How does one application communicate with another using messaging?
Message How can two applications connected by a message channel exchange a piece of information?
Pipes and Filters How can we perform complex processing on a message while maintaining independence and flexibility?
Message Router How can you decouple individual processing steps so that messages can be passed to different filters depending on a set of conditions?
Message Translator How can systems using different data formats communicate with each other using messaging?
Message Endpoint How does an application connect to a messaging channel to send and receive messages?

Messaging Channels

Point to Point Channel How can the caller be sure that exactly one receiver will receive the document or perform the call?
Publish Subscribe Channel How can the sender broadcast an event to all interested receivers?
Dead Letter Channel What will the messaging system do with a message it cannot deliver?
Guaranteed Delivery How can the sender make sure that a message will be delivered, even if the messaging system fails?
Message Bus What is an architecture that enables separate applications to work together, but in a de-coupled fashion such that applications can be easily added or removed without affecting the others?

Message Construction

Event Message How can messaging be used to transmit events from one application to another?
Request Reply When an application sends a message, how can it get a response from the receiver?
Correlation Identifier How does a requestor that has received a reply know which request this is the reply for?
Return Address How does a replier know where to send the reply?

Message Routing

Content Based Router How do we handle a situation where the implementation of a single logical function (e.g., inventory check) is spread across multiple physical systems?
Message Filter How can a component avoid receiving uninteresting messages?
Dynamic Router How can you avoid the dependency of the router on all possible destinations while maintaining its efficiency?
Recipient List How do we route a message to a list of (static or dynamically) specified recipients?
Splitter How can we process a message if it contains multiple elements, each of which may have to be processed in a different way?
Aggregator How do we combine the results of individual, but related messages so that they can be processed as a whole?
Resequencer How can we get a stream of related but out-of-sequence messages back into the correct order?
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?
Scatter-Gather How do you maintain the overall message flow when a message needs to be sent to multiple recipients, each of which may send a reply?
Routing Slip How do we route a message consecutively through a series of processing steps when the sequence of steps is not known at design-time and may vary for each message?
Throttler How can I throttle messages to ensure that a specific endpoint does not get overloaded, or we don't exceed an agreed SLA with some external service?
Sampling How can I sample one message out of many in a given period to avoid downstream route does not get overloaded?
Delayer How can I delay the sending of a message?
Load Balancer How can I balance load across a number of endpoints?
Multicast How can I route a message to a number of endpoints at the same time?
Loop How can I repeat processing a message in a loop?

Message Transformation

Content Enricher How do we communicate with another system if the message originator does not have all the required data items available?
Content Filter How do you simplify dealing with a large message, when you are interested only in a few data items?
Claim Check How can we reduce the data volume of message sent across the system without sacrificing information content?
Normalizer How do you process messages that are semantically equivalent, but arrive in a different format?
Sort How can I sort the body of a message?
Validate How can I validate a message?

Messaging Endpoints

Messaging Mapper How do you move data between domain objects and the messaging infrastructure while keeping the two independent of each other?
Event Driven Consumer How can an application automatically consume messages as they become available?
Polling Consumer How can an application consume a message when the application is ready?
Competing Consumers How can a messaging client process multiple messages concurrently?
Message Dispatcher How can multiple consumers on a single channel coordinate their message processing?
Selective Consumer How can a message consumer select which messages it wishes to receive?
Durable Subscriber How can a subscriber avoid missing messages while it's not listening for them?
Idempotent Consumer How can a message receiver deal with duplicate messages?
Transactional Client How can a client control its transactions with the messaging system?
Messaging Gateway How do you encapsulate access to the messaging system from the rest of the application?
Service Activator How can an application design a service to be invoked both via various messaging technologies and via non-messaging techniques?

System Management

Detour How can you route a message through intermediate steps to perform validation, testing or debugging functions?
Wire Tap How do you inspect messages that travel on a point-to-point channel?
Log How can I log processing a message?

For a full breakdown of each pattern see the Book Pattern Appendix

Pattern Appendix

There now follows a breakdown of the various Enterprise Integration Patterns that Camel supports

Messaging Systems

Message Channel

Camel supports the Message Channel from the EIP patterns. The Message Channel is an internal implementation detail of the Endpoint interface and all interactions with the Message Channel are via the Endpoint interfaces.

Enterprise Integration Patterns_第1张图片

For more details see

  • Message
  • Message Endpoint

Using This Pattern

If 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.

Message

Camel supports the Message from the EIP patterns using the Message interface.

To support various message exchange patterns like one way Event Message and Request Reply messages Camel uses an Exchange interface which has a pattern property which can be set to InOnly for an Event Message which has a single inbound Message, or InOut for a Request Reply where there is an inbound and outbound message.

Here is a basic example of sending a Message to a route in InOnly and InOut modes

Requestor Code

//InOnly
getContext().createProducerTemplate().sendBody("direct:startInOnly", "Hello World");

//InOut
String result = (String) getContext().createProducerTemplate().requestBody("direct:startInOut", "Hello World");

Route Using the Fluent Builders

from("direct:startInOnly").inOnly("bean:process");

from("direct:startInOut").inOut("bean:process");

Route Using the Spring XML Extensions


  "direct:startInOnly"/>
  "bean:process"/>



  "direct:startInOut"/>
  "bean:process"/>

Using This Pattern

If 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.

Pipes and Filters

Camel supports the Pipes and Filters from the EIP patterns in various ways.

With Camel you can split your processing across multiple independent Endpoint instances which can then be chained together.

Using Routing Logic

You can create pipelines of logic using multiple Endpoint or Message Translator instances as follows

from("direct:a").pipeline("direct:x", "direct:y", "direct:z", "mock:result");

Though pipeline is the default mode of operation when you specify multiple outputs in Camel. The opposite to pipeline is multicast; which fires the same message into each of its outputs. (See the example below).

In Spring XML you can use the element as of 1.4.0 onwards


  "activemq:SomeQueue"/>
  
    "foo"/>
    "bar"/>
    "activemq:OutputQueue"/>
  

In the above the pipeline element is actually unnecessary, you could use this...


  "activemq:SomeQueue"/>
  "foo"/>
  "bar"/>
  "activemq:OutputQueue"/>

Its just a bit more explicit. However if you wish to use to avoid a pipeline - to send the same message into multiple pipelines - then the element comes into its own.


  "activemq:SomeQueue"/>
  
    
      "something"/>
      "log:Something"/>
    
    
      "foo"/>
      "bar"/>
      "activemq:OutputQueue"/>
    
  

In the above example we are routing from a single Endpoint to a list of different endpoints specified using URIs. If you find the above a bit confusing, try reading about the Architecture or try the Examples

Using This Pattern

If 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.

Message Router

The Message Router from the EIP patterns allows you to consume from an input destination, evaluate some predicate then choose the right output destination.

Enterprise Integration Patterns_第2张图片

The following example shows how to route a request from an input queue:a endpoint to either queue:b, queue:c or queue:d depending on the evaluation of various Predicate expressions

Using the Fluent Builders

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("mock:error"));

        from("direct:a")
            .choice()
                .when(header("foo").isEqualTo("bar"))
                    .to("direct:b")
                .when(header("foo").isEqualTo("cheese"))
                    .to("direct:c")
                .otherwise()
                    .to("direct:d");
    }
};

Using the Spring XML Extensions

"errorHandler" xmlns="http://camel.apache.org/schema/spring">
    
        "direct:a"/>
        
            
                $foo = 'bar'
                "direct:b"/>
            
            
                $foo = 'cheese'
                "direct:c"/>
            
            
                "direct:d"/>
            
        
    

Choice without otherwise

If you use a choice without adding an otherwise, any unmatched exchanges will be dropped by default.

Using This Pattern

If 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.

Message Translator

Camel supports the Message Translator from the EIP patterns by using an arbitrary Processor in the routing logic, by using a bean to perform the transformation, or by using transform() in the DSL. You can also use a Data Format to marshal and unmarshal messages in different encodings.

Enterprise Integration Patterns_第3张图片

Using the Fluent Builders

You can transform a message using Camel's Bean Integration to call any method on a bean in your Registry such as your Spring XML configuration file as follows

from("activemq:SomeQueue").
  beanRef("myTransformerBean", "myMethodName").
  to("mqseries:AnotherQueue");

Where the "myTransformerBean" would be defined in a Spring XML file or defined in JNDI etc. You can omit the method name parameter from beanRef() and the Bean Integration will try to deduce the method to invoke from the message exchange.

or you can add your own explicit Processor to do the transformation

from("direct:start").process(new Processor() {
    public void process(Exchange exchange) {
        Message in = exchange.getIn();
        in.setBody(in.getBody(String.class) + " World!");
    }
}).to("mock:result");

or you can use the DSL to explicitly configure the transformation

from("direct:start").transform(body().append(" World!")).to("mock:result");

Use Spring XML

You can also use Spring XML Extensions to do a transformation. Basically any Expression language can be substituted inside the transform element as shown below

"http://camel.apache.org/schema/spring">
  
    "direct:start"/>
    
      ${in.body} extra data!
    
    "mock:end"/>
  

Or you can use the Bean Integration to invoke a bean


  "activemq:Input"/>
  "myBeanName" method="doTransform"/>
  "activemq:Output"/>

You can also use Templating to consume a message from one destination, transform it with something like Velocity or XQuery and then send it on to another destination. For example using InOnly (one way messaging)

from("activemq:My.Queue").
  to("velocity:com/acme/MyResponse.vm").
  to("activemq:Another.Queue");

If you want to use InOut (request-reply) semantics to process requests on the My.Queue queue on ActiveMQ with a template generated response, then sending responses back to the JMSReplyTo Destination you could use this.

from("activemq:My.Queue").
  to("velocity:com/acme/MyResponse.vm");

Using This Pattern

If 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.

  • Content Enricher
  • Using getIn or getOut methods on Exchange

Message Endpoint

Camel supports the Message Endpoint from the EIP patterns using the Endpoint interface.

Enterprise Integration Patterns_第4张图片

When using the DSL to create Routes you typically refer to Message Endpoints by their URIs rather than directly using the Endpoint interface. Its then a responsibility of the CamelContext to create and activate the necessary Endpoint instances using the available Component implementations.

For more details see

  • Message

Using This Pattern

If 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.

Messaging Channels

Point to Point Channel

Camel supports the Point to Point Channel from the EIP patterns using the following components

  • SEDA for in-VM seda based messaging
  • JMS for working with JMS Queues for high performance, clustering and load balancing
  • JPA for using a database as a simple message queue
  • XMPP for point-to-point communication over XMPP (Jabber)
  • and others

Using This Pattern

If 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.

Publish Subscribe Channel

Camel supports the Publish Subscribe Channel from the EIP patterns using for example the following components:

  • JMS for working with JMS Topics for high performance, clustering and load balancing
  • XMPP when using rooms for group communication
  • SEDA for working with SEDA in the same CamelContext which can work in pub-sub, but allowing multiple consumers.
  • VM as SEDA but for intra-JVM.

Enterprise Integration Patterns_第5张图片

Using Routing Logic

Another option is to explicitly list the publish-subscribe relationship in your routing logic; this keeps the producer and consumer decoupled but lets you control the fine grained routing configuration using the DSL or Xml Configuration.

Using the Fluent Builders

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("mock:error"));

        from("direct:a")
            .multicast().to("direct:b", "direct:c", "direct:d");
    }
};

Using the Spring XML Extensions

"errorHandler" xmlns="http://camel.apache.org/schema/spring">
    
        "direct:a"/>
        
            "direct:b"/>
            "direct:c"/>
            "direct:d"/>
        
    

Using This Pattern

If 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.

Dead Letter Channel

Camel supports the Dead Letter Channel from the EIP patterns using the DeadLetterChannel processor which is an Error Handler.

Enterprise Integration Patterns_第6张图片

Difference between Dead Letter Channel and Default Error Handler
The major difference is that Dead Letter Channel has a dead letter queue that whenever an Exchange could not be processed is moved to. It will always moved failed exchanges to this queue.

Unlike the Default Error Handler that does not have a dead letter queue. So whenever an Exchange could not be processed the error is propagated back to the client.

Notice: You can adjust this behavior of whether the client should be notified or not with the handled option.

Redelivery

It is common for a temporary outage or database deadlock to cause a message to fail to process; but the chances are if its tried a few more times with some time delay then it will complete fine. So we typically wish to use some kind of redelivery policy to decide how many times to try redeliver a message and how long to wait before redelivery attempts.

The RedeliveryPolicy defines how the message is to be redelivered. You can customize things like

  • how many times a message is attempted to be redelivered before it is considered a failure and sent to the dead letter channel
  • the initial redelivery timeout
  • whether or not exponential backoff is used (i.e. the time between retries increases using a backoff multiplier)
  • whether to use collision avoidance to add some randomness to the timings
  • delay pattern a new option in Camel 2.0, see below for details.

Once all attempts at redelivering the message fails then the message is forwarded to the dead letter queue.

About moving Exchange to dead letter queue and using handled

Handled on Dead Letter Channel was introduced in Camel 2.0, this feature does not exist in Camel 1.x

When all attempts of redelivery have failed the Exchange is moved to the dead letter queue (the dead letter endpoint). The exchange is then complete and from the client point of view it was processed. As such the Dead Letter Channel have handled the Exchange.

For instance configuring the dead letter channel as:

Using the Fluent Builders

errorHandler(deadLetterChannel("jms:queue:dead")
    .maximumRedeliveries(3).redeliveryDelay(5000));

Using the Spring XML Extensions

"myDeadLetterErrorHandler">
   ...


"myDeadLetterErrorHandler" class="org.apache.camel.builder.DeadLetterChannelBuilder">
    "deadLetterUri" value="jms:queue:dead"/>
    "redeliveryPolicy" ref="myRedeliveryPolicyConfig"/>


"myRedeliveryPolicyConfig" class="org.apache.camel.processor.RedeliveryPolicy">
    "maximumRedeliveries" value="3"/>
    "redeliveryDelay" value="5000"/>


The Dead Letter Channel above will clear the caused exception (setException(null)), by moving the caused exception to a property on the Exchange, with the key Exchange.EXCEPTION_CAUGHT. Then the Exchange is moved to the "jms:queue:dead" destination and the client will not notice the failure.

About moving Exchange to dead letter queue and using the original message

Available as of Camel 2.0
The option useOriginalMessage is used for routing the original input message instead of the current message that potentially is modified during routing.

For instance if you have this route:

   from("jms:queue:order:input")
       .to("bean:validateOrder")
       .to("bean:transformOrder")
       .to("bean:handleOrder");

The route listen for JMS messages and validates, transforms and handle it. During this the Exchange payload is transformed/modified. So in case something goes wrong and we want to move the message to another JMS destination, then we can configure our Dead Letter Channel with the useOriginalBody option. But when we move the Exchange to this destination we do not know in which state the message is in. Did the error happen in before the transformOrder or after? So to be sure we want to move the original input message we received from jms:queue:order:input. So we can do this by enabling the useOriginalMessage option as shown below:

    // will use original body
    errorHandler(deadLetterChannel("jms:queue:dead")
       .useOriginalMessage().mamimumRedeliveries(5).redeliverDelay(5000);

Then the messages routed to the jms:queue:dead is the original input. If we want to manually retry we can move the JMS message from the failed to the input queue, with no problem as the message is the same as the original we received.

OnRedelivery

Available in Camel 1.6.0 onwards

When Dead Letter Channel is doing redeliver its possible to configure a Processor that is executed just before every redelivery attempt. This can be used for the situations where you need to alter the message before its redelivered. See below for sample.

onException and onRedeliver
In Camel 2.0 we also added support for per onException to set a onRedeliver. That means you can do special on redelivery for different exceptions, as opposed to onRedelivery set on Dead Letter Channel can be viewed as a global scope.

Redelivery default values

In Camel 2.0 redelivery is disabled by default, as opposed to Camel 1.x in which Dead Letter Channel is configured with maximumRedeliveries=5.

The default redeliver policy will use the following values:

  • maximumRedeliveries=0 (in Camel 1.x the default value is 5)
  • redeliverDelay=1000L (1 second, new as of Camel 2.0)
    • use initialRedeliveryDelay for previous versions
  • maximumRedeliveryDelay = 60 * 1000L (60 seconds)
  • And the exponential backoff and collision avoidance is turned off.
  • The retriesExhaustedLogLevel are set to LoggingLevel.ERROR
  • The retryAttemptedLogLevel are set to LoggingLevel.DEBUG
  • Stack traces is logged for exhausted messages from Camel 2.2 onwards.
  • Handled exceptions is not logged from Camel 2.3 onwards

The maximum redeliver delay ensures that a delay is never longer than the value, default 1 minute. This can happen if you turn on the exponential backoff.

The maximum redeliveries is the number of re delivery attempts. By default Camel will try to process the exchange 1 + 5 times. 1 time for the normal attempt and then 5 attempts as redeliveries.
Setting the maximumRedeliveries to a negative value such as -1 will then always redelivery (unlimited).
Setting the maximumRedeliveries to 0 will disable any re delivery attempt.

Camel will log delivery failures at the DEBUG logging level by default. You can change this by specifying retriesExhaustedLogLevel and/or retryAttemptedLogLevel. See ExceptionBuilderWithRetryLoggingLevelSetTest for an example.

In Camel 2.0 you can turn logging of stack traces on/off. If turned off Camel will still log the redelivery attempt. Its just much less verbose.

Redeliver Delay Pattern

Available as of Camel 2.0
Delay pattern is used as a single option to set a range pattern for delays. If used then the following options does not apply: (delay, backOffMultiplier, useExponentialBackOff, useCollisionAvoidance, maximumRedeliveryDelay).

The idea is to set groups of ranges using the following syntax: limit:delay;limit 2:delay 2;limit 3:delay 3;...;limit N:delay N

Each group has two values separated with colon

  • limit = upper limit
  • delay = delay in millis
    And the groups is again separated with semi colon.
    The rule of thumb is that the next groups should have a higher limit than the previous group.

Lets clarify this with an example:
delayPattern=5:1000;10:5000;20:20000

That gives us 3 groups:

  • 5:1000
  • 10:5000
  • 20:20000

Resulting in these delays for redelivery attempt:

  • Redelivery attempt number 1..4 = 0 millis (as the first group start with 5)
  • Redelivery attempt number 5..9 = 1000 millis (the first group)
  • Redelivery attempt number 10..19 = 5000 millis (the second group)
  • Redelivery attempt number 20.. = 20000 millis (the last group)

Note: The first redelivery attempt is 1, so the first group should start with 1 or higher.

You can start a group with limit 1 to eg have a starting delay: delayPattern=1:1000;5:5000

  • Redelivery attempt number 1..4 = 1000 millis (the first group)
  • Redelivery attempt number 5.. = 5000 millis (the last group)

There is no requirement that the next delay should be higher than the previous. You can use any delay value you like. For example with delayPattern=1:5000;3:1000 we start with 5 sec delay and then later reduce that to 1 second.

Redelivery header

When a message is redelivered the DeadLetterChannel will append a customizable header to the message to indicate how many times its been redelivered.
In Camel 1.x: The header is org.apache.camel.redeliveryCount.
In Camel 2.0: The header is CamelRedeliveryCounter, which is also defined on the Exchange.REDELIVERY_COUNTER.
In Camel 2.6: The header CamelRedeliveryMaxCounter, which is also defined on the Exchange.REDELIVERY_MAX_COUNTER, contains the maximum redelivery setting. This header is absent if you use retryWhile or have unlimited maximum redelivery configured.

And a boolean flag whether it is being redelivered or not (first attempt)
In Camel 1.x: The header org.apache.camel.Redelivered contains a boolean if the message is redelivered or not.
In Camel 2.0: The header CamelRedelivered contains a boolean if the message is redelivered or not, which is also defined on the Exchange.REDELIVERED.

Dynamically calculated delay from the exchange
In Camel 2.9 and 2.8.2: The header is CamelRedeliveryDelay, which is also defined on the Exchange.REDELIVERY_DELAY.
Is this header is absent, normal redelivery rules apply.

Which endpoint failed

Available as of Camel 2.1

When Camel routes messages it will decorate the Exchange with a property that contains the last endpoint Camel send the Exchange to:

String lastEndpointUri = exchange.getProperty(Exchange.TO_ENDPOINT, String.class);

The Exchange.TO_ENDPOINT have the constant value CamelToEndpoint.

This information is updated when Camel sends a message to any endpoint. So if it exists its the last endpoint which Camel send the Exchange to.

When for example processing the Exchange at a given Endpoint and the message is to be moved into the dead letter queue, then Camel also decorates the Exchange with another property that contains that last endpoint:

String failedEndpointUri = exchange.getProperty(Exchange.FAILURE_ENDPOINT, String.class);

The Exchange.FAILURE_ENDPOINT have the constant value CamelFailureEndpoint.

This allows for example you to fetch this information in your dead letter queue and use that for error reporting.
This is useable if the Camel route is a bit dynamic such as the dynamic Recipient List so you know which endpoints failed.

Notice: These information is kept on the Exchange even if the message was successfully processed by a given endpoint, and then later fails for example in a local Bean processing instead. So beware that this is a hint that helps pinpoint errors.

from("activemq:queue:foo")
    .to("http://someserver/somepath")
    .beanRef("foo");

Now suppose the route above and a failure happens in the foo bean. Then the Exchange.TO_ENDPOINT and Exchange.FAILURE_ENDPOINT will still contain the value of http://someserver/somepath.

Samples

The following example shows how to configure the Dead Letter Channel configuration using the DSL

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // using dead letter channel with a seda queue for errors
        errorHandler(deadLetterChannel("seda:errors"));

        // here is our route
        from("seda:a").to("seda:b");
    }
};

You can also configure the RedeliveryPolicy as this example shows

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        // configures dead letter channel to use seda queue for errors and use at most 2 redelveries
        // and exponential backoff
        errorHandler(deadLetterChannel("seda:errors").maximumRedeliveries(2).useExponentialBackOff());

        // here is our route
        from("seda:a").to("seda:b");
    }
};

How can I modify the Exchange before redelivery?

In Camel 1.6.0 we added support directly in Dead Letter Channel to set a Processor that is executed before each redelivery attempt.

When Dead Letter Channel is doing redeliver its possible to configure a Processor that is executed just before every redelivery attempt. This can be used for the situations where you need to alter the message before its redelivered.

Here we configure the Dead Letter Channel to use our processor MyRedeliveryProcessor to be executed before each redelivery.

// we configure our Dead Letter Channel to invoke
// MyRedeliveryProcessor before a redelivery is
// attempted. This allows us to alter the message before
errorHandler(deadLetterChannel("mock:error").maximumRedeliveries(5)
        .onRedelivery(new MyRedeliverProcessor())
        // setting delay to zero is just to make unit testing faster
        .redeliveryDelay(0L));

And this is the processor MyRedeliveryProcessor where we alter the message.

// This is our processor that is executed before every redelivery attempt
// here we can do what we want in the java code, such as altering the message
public class MyRedeliverProcessor implements Processor {

    public void process(Exchange exchange) throws Exception {
        // the message is being redelivered so we can alter it

        // we just append the redelivery counter to the body
        // you can of course do all kind of stuff instead
        String body = exchange.getIn().getBody(String.class);
        int count = exchange.getIn().getHeader(Exchange.REDELIVERY_COUNTER, Integer.class);

        exchange.getIn().setBody(body + count);

        // the maximum redelivery was set to 5
        int max = exchange.getIn().getHeader(Exchange.REDELIVERY_MAX_COUNTER, Integer.class);
        assertEquals(5, max);
    }
}

Using This Pattern

If 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.

  • Error Handler
  • Exception Clause

Guaranteed Delivery

Camel supports the Guaranteed Delivery from the EIP patterns using among others the following components:

  • File for using file systems as a persistent store of messages
  • JMS when using persistent delivery (the default) for working with JMS Queues and Topics for high performance, clustering and load balancing
  • JPA for using a database as a persistence layer, or use any of the many other database component such as SQL, JDBC, iBATIS/MyBatis, Hibernate
  • HawtDB for a lightweight key-value persistent store

Enterprise Integration Patterns_第7张图片

Using This Pattern

If 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.

Message Bus

Camel supports the Message Bus from the EIP patterns. You could view Camel as a Message Bus itself as it allows producers and consumers to be decoupled.

Enterprise Integration Patterns_第8张图片

Folks often assume that a Message Bus is a JMS though so you may wish to refer to the JMS component for traditional MOM support.
Also worthy of note is the XMPP component for supporting messaging over XMPP (Jabber)

Of course there are also ESB products such as Apache ServiceMix which serve as full fledged message busses.
You can interact with Apache ServiceMix from Camel in many ways, but in particular you can use the NMR or JBI component to access the ServiceMix message bus directly.

Using This Pattern

If 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.

Message Construction

Event Message

Camel supports the Event Message from the EIP patterns by supporting the Exchange Pattern on a Message which can be set to InOnly to indicate a oneway event message. Camel Components then implement this pattern using the underlying transport or protocols.

The default behaviour of many Components is InOnly such as for JMS, File or SEDA

Related
See the related Request Reply message.

Explicitly specifying InOnly

If you are using a component which defaults to InOut you can override the Exchange Pattern for an endpoint using the pattern property.

foo:bar?exchangePattern=InOnly

From 2.0 onwards on Camel you can specify the Exchange Pattern using the dsl.

Using the Fluent Builders

from("mq:someQueue").
  inOnly().
  bean(Foo.class);

or you can invoke an endpoint with an explicit pattern

from("mq:someQueue").
  inOnly("mq:anotherQueue");

Using the Spring XML Extensions


    "mq:someQueue"/>
    "bean:foo"/>


    "mq:someQueue"/>
    "mq:anotherQueue"/>

Using This Pattern

If 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.

Request Reply

Camel supports the Request Reply from the EIP patterns by supporting the Exchange Pattern on a Message which can be set to InOut to indicate a request/reply. Camel Components then implement this pattern using the underlying transport or protocols.

For example when using JMS with InOut the component will by default perform these actions

  • create by default a temporary inbound queue
  • set the JMSReplyTo destination on the request message
  • set the JMSCorrelationID on the request message
  • send the request message
  • consume the response and associate the inbound message to the request using the JMSCorrelationID (as you may be performing many concurrent request/responses).
Related
See the related Event Message message

Explicitly specifying InOut

When consuming messages from JMS a Request-Reply is indicated by the presence of the JMSReplyTo header.

You can explicitly force an endpoint to be in Request Reply mode by setting the exchange pattern on the URI. e.g.

jms:MyQueue?exchangePattern=InOut

You can specify the exchange pattern in DSL rule or Spring configuration.

// Send to an endpoint using InOut
from("direct:testInOut").inOut("mock:result");

// Send to an endpoint using InOut
from("direct:testInOnly").inOnly("mock:result");

// Set the exchange pattern to InOut, then send it from direct:inOnly to mock:result endpoint
from("direct:testSetToInOnlyThenTo")
    .setExchangePattern(ExchangePattern.InOnly)
    .to("mock:result");
from("direct:testSetToInOutThenTo")
    .setExchangePattern(ExchangePattern.InOut)
    .to("mock:result");

// Or we can pass the pattern as a parameter to the to() method
from("direct:testToWithInOnlyParam").to(ExchangePattern.InOnly, "mock:result");
from("direct:testToWithInOutParam").to(ExchangePattern.InOut, "mock:result");
from("direct:testToWithRobustInOnlyParam").to(ExchangePattern.RobustInOnly, "mock:result");

// Set the exchange pattern to InOut, then send it on
from("direct:testSetExchangePatternInOnly")
    .setExchangePattern(ExchangePattern.InOnly).to("mock:result");
"http://camel.apache.org/schema/spring">
  
  
    "direct:testInOut"/>
    "mock:result"/>
  

  
  
    "direct:testInOnly"/>
    "mock:result"/>
  


  
  
    "direct:testSetToInOnlyThenTo"/>
    "InOnly"/>
    "mock:result"/>      
  
  
    "direct:testSetToInOutThenTo"/>
    "InOut"/>
    "mock:result"/>
  
  
    "direct:testSetExchangePatternInOnly"/>
    "InOnly"/>
    "mock:result"/>
  


  
  
    "direct:testToWithInOnlyParam"/>
    "mock:result" pattern="InOnly"/>
  
  
    "direct:testToWithInOutParam"/>
    "mock:result" pattern="InOut"/>
  
  
    "direct:testToWithRobustInOnlyParam"/>
    "mock:result" pattern="RobustInOnly"/>
  
 

Using This Pattern

If 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.

Correlation Identifier

Camel supports the Correlation Identifier from the EIP patterns by getting or setting a header on a Message.

When working with the ActiveMQ or JMS components the correlation identifier header is called JMSCorrelationID. You can add your own correlation identifier to any message exchange to help correlate messages together to a single conversation (or business process).

Enterprise Integration Patterns_第9张图片

The use of a Correlation Identifier is key to working with the Camel Business Activity Monitoring Framework and can also be highly useful when testing with simulation or canned data such as with the Mock testing framework

Some EIP patterns will spin off a sub message, and in those cases, Camel will add a correlation id on the Exchange as a property with they key Exchange.CORRELATION_ID, which links back to the source Exchange. For example the Splitter, Multicast, Recipient List, and Wire Tap EIP does this.

See Also

  • BAM

Return Address

Camel supports the Return Address from the EIP patterns by using the JMSReplyTo header.

For example when using JMS with InOut the component will by default return to the address given in JMSReplyTo.

Requestor Code

getMockEndpoint("mock:bar").expectedBodiesReceived("Bye World");
template.sendBodyAndHeader("direct:start", "World", "JMSReplyTo", "queue:bar");

Route Using the Fluent Builders

from("direct:start").to("activemq:queue:foo?preserveMessageQos=true");
from("activemq:queue:foo").transform(body().prepend("Bye "));
from("activemq:queue:bar?disableReplyTo=true").to("mock:bar");

Route Using the Spring XML Extensions


  "direct:start"/>
  "activemq:queue:foo?preserveMessageQos=true"/>



  "activemq:queue:foo"/>
  
      Bye ${in.body}
  



  "activemq:queue:bar?disableReplyTo=true"/>
  "mock:bar"/>

For a complete example of this pattern, see this junit test case

Using This Pattern

If 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.

Message Routing

Content Based Router

The Content Based Router from the EIP patterns allows you to route messages to the correct destination based on the contents of the message exchanges.

Enterprise Integration Patterns_第10张图片

The following example shows how to route a request from an input seda:a endpoint to either seda:b, seda:c or seda:d depending on the evaluation of various Predicate expressions

Using the Fluent Builders

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("mock:error"));

        from("direct:a")
            .choice()
                .when(header("foo").isEqualTo("bar"))
                    .to("direct:b")
                .when(header("foo").isEqualTo("cheese"))
                    .to("direct:c")
                .otherwise()
                    .to("direct:d");
    }
};

Using the Spring XML Extensions

"errorHandler" xmlns="http://camel.apache.org/schema/spring">
    
        "direct:a"/>
        
            
                $foo = 'bar'
                "direct:b"/>
            
            
                $foo = 'cheese'
                "direct:c"/>
            
            
                "direct:d"/>
            
        
    

For further examples of this pattern in use you could look at the junit test case

Using This Pattern

If 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.

Message Filter

The Message Filter from the EIP patterns allows you to filter messages

The following example shows how to create a Message Filter route consuming messages from an endpoint called queue:a which if the Predicate is true will be dispatched to queue:b

Using the Fluent Builders

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("mock:error"));

        from("direct:a")
            .filter(header("foo").isEqualTo("bar"))
                .to("direct:b");
    }
};

You can of course use many different Predicate languages such as XPath, XQuery, SQL or various Scripting Languages. Here is an XPath example

from("direct:start").
        filter().xpath("/person[@name='James']").
        to("mock:result");

Here is another example of using a bean to define the filter behavior

from("direct:start")
    .filter().method(MyBean.class, "isGoldCustomer").to("mock:result").end()
    .to("mock:end");

public static class MyBean {
    public boolean isGoldCustomer(@Header("level") String level) { 
        return level.equals("gold"); 
    }
}

Using the Spring XML Extensions

"errorHandler" xmlns="http://camel.apache.org/schema/spring">
    
        "direct:a"/>
        
            $foo = 'bar'
            "direct:b"/>
        
    

filtered endpoint required inside tag
make sure you put the endpoint you want to filter (, etc.) before the closing tag or the filter will not be applied (in 2.8+, omitting this will result in an error)

For further examples of this pattern in use you could look at the junit test case

Using stop

Available as of Camel 2.0

Stop is a bit different than a message filter as it will filter out all messages and end the route entirely (filter only applies to its child processor). Stop is convenient to use in a Content Based Router when you for example need to stop further processing in one of the predicates.

In the example below we do not want to route messages any further that has the word Bye in the message body. Notice how we prevent this in the when predicate by using the .stop().

from("direct:start")
    .choice()
        .when(body().contains("Hello")).to("mock:hello")
        .when(body().contains("Bye")).to("mock:bye").stop()
        .otherwise().to("mock:other")
    .end()
    .to("mock:result");

Knowing if Exchange was filtered or not

Available as of Camel 2.5

The Message Filter EIP will add a property on the Exchange which states if it was filtered or not.

The property has the key Exchannge.FILTER_MATCHED which has the String value of CamelFilterMatched. Its value is a boolean indicating true or false. If the value is true then the Exchange was routed in the filter block.

Using This Pattern

If 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.

Dynamic Router

The Dynamic Router from the EIP patterns allows you to route messages while avoiding the dependency of the router on all possible destinations while maintaining its efficiency.

Enterprise Integration Patterns_第11张图片

In Camel 2.5 we introduced a dynamicRouter in the DSL which is like a dynamic Routing Slip which evaluates the slip on-the-fly.

Beware
You must ensure the expression used for the dynamicRouter such as a bean, will return null to indicate the end. Otherwise the dynamicRouter will keep repeating endlessly.

Options

Name Default Value Description
uriDelimiter , Delimiter used if the Expression returned multiple endpoints.
ignoreInvalidEndpoints false If an endpoint uri could not be resolved, should it be ignored. Otherwise Camel will thrown an exception stating the endpoint uri is not valid.

Dynamic Router in Camel 2.5 onwards

From Camel 2.5 the Dynamic Router will set a property (Exchange.SLIP_ENDPOINT) on the Exchange which contains the current endpoint as it advanced though the slip. This allows you to know how far we have processed in the slip. (It's a slip because the Dynamic Router implementation is based on top of Routing Slip).

Java DSL

In Java DSL you can use the dynamicRouter as shown below:

from("direct:start")
    // use a bean as the dynamic router
    .dynamicRouter(method(DynamicRouterTest.class, "slip"));

Which will leverage a Bean to compute the slip on-the-fly, which could be implemented as follows:

/**
 * Use this method to compute dynamic where we should route next.
 *
 * @param body the message body
 * @return endpoints to go, or null to indicate the end
 */
public String slip(String body) {
    bodies.add(body);
    invoked++;

    if (invoked == 1) {
        return "mock:a";
    } else if (invoked == 2) {
        return "mock:b,mock:c";
    } else if (invoked == 3) {
        return "direct:foo";
    } else if (invoked == 4) {
        return "mock:result";
    }

    // no more so return null
    return null;
}

Mind that this example is only for show and tell. The current implementation is not thread safe. You would have to store the state on the Exchange, to ensure thread safety, as shown below:

/**
 * Use this method to compute dynamic where we should route next.
 *
 * @param body the message body
 * @param properties the exchange properties where we can store state between invocations
 * @return endpoints to go, or null to indicate the end
 */
public String slip(String body, @Properties Map<String, Object> properties) {
    bodies.add(body);

    // get the state from the exchange properties and keep track how many times
    // we have been invoked
    int invoked = 0;
    Object current = properties.get("invoked");
    if (current != null) {
        invoked = Integer.valueOf(current.toString());
    }
    invoked++;
    // and store the state back on the properties
    properties.put("invoked", invoked);

    if (invoked == 1) {
        return "mock:a";
    } else if (invoked == 2) {
        return "mock:b,mock:c";
    } else if (invoked == 3) {
        return "direct:foo";
    } else if (invoked == 4) {
        return "mock:result";
    }

    // no more so return null
    return null;
}

You could also store state as message headers, but they are not guaranteed to be preserved during routing, where as properties on the Exchange are. Although there was a bug in the method call expression, see the warning below.

Using beans to store state
Mind that in Camel 2.9.2 or older, when using a Bean the state is not propagated, so you will have to use a Processor instead. This is fixed in Camel 2.9.3 onwards.

Spring XML

The same example in Spring XML would be:

"mySlip" class="org.apache.camel.processor.DynamicRouterTest"/>

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        
            
            "mySlip" method="slip"/>
        
    

    
        "direct:foo"/>
        Bye World
        "mock:foo"/>
    


@DynamicRouter annotation

You can also use the @DynamicRouter annotation, for example the Camel 2.4 example below could be written as follows. The route method would then be invoked repeatedly as the message is processed dynamically. The idea is to return the next endpoint uri where to go. Return null to indicate the end. You can return multiple endpoints if you like, just as the Routing Slip, where each endpoint is separated by a delimiter.

public class MyDynamicRouter {

    @Consume(uri = "activemq:foo")
    @DynamicRouter
    public String route(@XPath("/customer/id") String customerId, @Header("Location") String location, Document body) {
        // query a database to find the best match of the endpoint based on the input parameteres
        // return the next endpoint uri, where to go. Return null to indicate the end.
    }
}

Dynamic Router in Camel 2.4 or older

The simplest way to implement this is to use the RecipientList Annotation on a Bean method to determine where to route the message.

public class MyDynamicRouter {

    @Consume(uri = "activemq:foo")
    @RecipientList
    public List<String> route(@XPath("/customer/id") String customerId, @Header("Location") String location, Document body) {
        // query a database to find the best match of the endpoint based on the input parameteres
        ...
    }
}

In the above we can use the Parameter Binding Annotations to bind different parts of the Message to method parameters or use an Expression such as using XPath or XQuery.

The method can be invoked in a number of ways as described in the Bean Integration such as

  • POJO Producing
  • Spring Remoting
  • Bean component

Using This Pattern

If 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.

Recipient List

The Recipient List from the EIP patterns allows you to route messages to a number of dynamically specified recipients.

The recipients will receive a copy of the same Exchange, and Camel will execute them sequentially.

Options

Name Default Value Description
delimiter , Delimiter used if the Expression returned multiple endpoints.
strategyRef   An AggregationStrategy that will assemble the replies from recipients into a single outgoing message from the Recipient List. By default Camel will use the last reply as the outgoing message.
parallelProcessing false Camel 2.2: If enabled, messages are sent to the recipients concurrently. Note that the calling thread will still wait until all messages have been fully processed before it continues; it's the sending and processing of replies from recipients which happens in parallel.
executorServiceRef   Camel 2.2: A custom Thread Pool to use for parallel processing. Note that enabling this option implies parallel processing, so you need not enable that option as well.
stopOnException false Camel 2.2: Whether to immediately stop processing when an exception occurs. If disabled, Camel will send the message to all recipients regardless of any individual failures. You can process exceptions in an AggregationStrategy implementation, which supports full control of error handling.
ignoreInvalidEndpoints false Camel 2.3: Whether to ignore an endpoint URI that could not be resolved. If disabled, Camel will throw an exception identifying the invalid endpoint URI.
streaming false Camel 2.5: If enabled, Camel will process replies out-of-order - that is, in the order received in reply from each recipient. If disabled, Camel will process replies in the same order as specified by the Expression.
timeout   Camel 2.5: Specifies a processing timeout milliseconds. If the Recipient List hasn't been able to send and process all replies within this timeframe, then the timeout triggers and the Recipient List breaks out, with message flow continuing to the next element. Note that if you provide a TimeoutAwareAggregationStrategy, its timeout method is invoked before breaking out.
onPrepareRef   Camel 2.8: A custom Processor to prepare the copy of the Exchange each recipient will receive. This allows you to perform arbitrary transformations, such as deep-cloning the message payload (or any other custom logic).
shareUnitOfWork false Camel 2.8: Whether the unit of work should be shared. See the same option on Splitter for more details.

Static Recipient List

The following example shows how to route a request from an input queue:a endpoint to a static list of destinations

Using Annotations
You can use the RecipientList Annotation on a POJO to create a Dynamic Recipient List. For more details see the Bean Integration.

Using the Fluent Builders

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("mock:error"));

        from("direct:a")
            .multicast().to("direct:b", "direct:c", "direct:d");
    }
};

Using the Spring XML Extensions

"errorHandler" xmlns="http://camel.apache.org/schema/spring">
    
        "direct:a"/>
        
            "direct:b"/>
            "direct:c"/>
            "direct:d"/>
        
    

Dynamic Recipient List

Usually one of the main reasons for using the Recipient List pattern is that the list of recipients is dynamic and calculated at runtime. The following example demonstrates how to create a dynamic recipient list using an Expression (which in this case it extracts a named header value dynamically) to calculate the list of endpoints which are either of type Endpoint or are converted to a String and then resolved using the endpoint URIs.

Using the Fluent Builders

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("mock:error"));

        from("direct:a")
            .recipientList(header("foo"));
    }
};

The above assumes that the header contains a list of endpoint URIs. The following takes a single string header and tokenizes it

from("direct:a").recipientList(
        header("recipientListHeader").tokenize(","));
Iteratable value

The dynamic list of recipients that are defined in the header must be iteratable such as:

  • java.util.Collection
  • java.util.Iterator
  • arrays
  • org.w3c.dom.NodeList
  • Camel 1.6.0: a single String with values separated with comma
  • any other type will be regarded as a single value

Using the Spring XML Extensions

"errorHandler" xmlns="http://camel.apache.org/schema/spring">
    
        "direct:a"/>
        
            $foo
        
    

For further examples of this pattern in use you could look at one of the junit test case

Using delimiter in Spring XML

In Spring DSL you can set the delimiter attribute for setting a delimiter to be used if the header value is a single String with multiple separated endpoints. By default Camel uses comma as delimiter, but this option lets you specify a customer delimiter to use instead.


  "direct:a" />
  
  ",">
    
myHeader

So if myHeader contains a String with the value "activemq:queue:foo, activemq:topic:hello , log:bar" then Camel will split the String using the delimiter given in the XML that was comma, resulting into 3 endpoints to send to. You can use spaces between the endpoints as Camel will trim the value when it lookup the endpoint to send to.

Note: In Java DSL you use the tokenizer to archive the same. The route above in Java DSL:

    from("direct:a").recipientList(header("myHeader").tokenize(","));

In Camel 2.1 its a bit easier as you can pass in the delimiter as 2nd parameter:

    from("direct:a").recipientList(header("myHeader"), "#");

Sending to multiple recipients in parallel

Available as of Camel 2.2

The Recipient List now supports parallelProcessing that for example Splitter also supports. You can use it to use a thread pool to have concurrent tasks sending the Exchange to multiple recipients concurrently.

    from("direct:a").recipientList(header("myHeader")).parallelProcessing();

And in Spring XML its an attribute on the recipient list tag.

   
       "direct:a"/>
       "true">
           
myHeader

Stop continuing in case one recipient failed

Available as of Camel 2.2

The Recipient List now supports stopOnException that for example Splitter also supports. You can use it to stop sending to any further recipients in case any recipient failed.

    from("direct:a").recipientList(header("myHeader")).stopOnException();

And in Spring XML its an attribute on the recipient list tag.

   
       "direct:a"/>
       "true">
           
myHeader

Note: You can combine parallelProcessing and stopOnException and have them both true.

Ignore invalid endpoints

Available as of Camel 2.3

The Recipient List now supports ignoreInvalidEndpoints which the Routing Slip also supports. You can use it to skip endpoints which is invalid.

    from("direct:a").recipientList(header("myHeader")).ignoreInvalidEndpoints();

And in Spring XML its an attribute on the recipient list tag.

   
       "direct:a"/>
       "true">
           
myHeader

Then lets say the myHeader contains the following two endpoints direct:foo,xxx:bar. The first endpoint is valid and works. However the 2nd is invalid and will just be ignored. Camel logs at INFO level about, so you can see why the endpoint was invalid.

Using custom AggregationStrategy

Available as of Camel 2.2

You can now use you own AggregationStrategy with the Recipient List. However its not that often you need that. What its good for is that in case you are using Request Reply messaging then the replies from the recipient can be aggregated. By default Camel uses UseLatestAggregationStrategy which just keeps that last received reply. What if you must remember all the bodies that all the recipients send back, then you can use your own custom aggregator that keeps those. Its the same principle as with the Aggregator EIP so check it out for details.

    from("direct:a")
        .recipientList(header("myHeader")).aggregationStrategy(new MyOwnAggregationStrategy())
        .to("direct:b");

And in Spring XML its an attribute on the recipient list tag.

   
       "direct:a"/>
       "myStrategy">
           
myHeader
"direct:b"/>
"myStrategy" class="com.mycompany.MyOwnAggregationStrategy"/>

Using custom thread pool

Available as of Camel 2.2

A thread pool is only used for parallelProcessing. You supply your own custom thread pool via the ExecutorServiceStrategy (see Camel's Threading Model), the same way you would do it for the aggregationStrategy. By default Camel uses a thread pool with 10 threads (subject to change in a future version).

Using method call as recipient list

You can use a Bean to provide the recipients, for example:

from("activemq:queue:test").recipientList().method(MessageRouter.class, "routeTo");

And then MessageRouter:

public class MessageRouter {

    public String routeTo() {
        String queueName = "activemq:queue:test2";
        return queueName;
    }
}

When you use a Bean then do not also use the @RecipientList annotation as this will in fact add yet another recipient list, so you end up having two. Do not do like this.

public class MessageRouter {

    @RecipientList
    public String routeTo() {
        String queueName = "activemq:queue:test2";
        return queueName;
    }
}

Well you should only do like that above (using @RecipientList) if you route just route to a Bean which you then want to act as a recipient list.
So the original route can be changed to:

from("activemq:queue:test").bean(MessageRouter.class, "routeTo");

Which then would invoke the routeTo method and detect its annotated with @RecipientList and then act accordingly as if it was a recipient list EIP.

Using timeout

Available as of Camel 2.5

If you use parallelProcessing then you can configure a total timeout value in millis. Camel will then process the messages in parallel until the timeout is hit. This allows you to continue processing if one message is slow. For example you can set a timeout value of 20 sec.

For example in the unit test below you can see we multicast the message to 3 destinations. We have a timeout of 2 seconds, which means only the last two messages can be completed within the timeframe. This means we will only aggregate the last two which yields a result aggregation which outputs "BC".

from("direct:start")
    .multicast(new AggregationStrategy() {
            public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
                if (oldExchange == null) {
                    return newExchange;
                }

                String body = oldExchange.getIn().getBody(String.class);
                oldExchange.getIn().setBody(body + newExchange.getIn().getBody(String.class));
                return oldExchange;
            }
        })
        .parallelProcessing().timeout(250).to("direct:a", "direct:b", "direct:c")
    // use end to indicate end of multicast route
    .end()
    .to("mock:result");

from("direct:a").delay(1000).to("mock:A").setBody(constant("A"));

from("direct:b").to("mock:B").setBody(constant("B"));

from("direct:c").to("mock:C").setBody(constant("C"));
Timeout in other EIPs
This timeout feature is also supported by Splitter and both multicast and recipientList.

By default if a timeout occurs the AggregationStrategy is not invoked. However you can implement a specialized version

public interface TimeoutAwareAggregationStrategy extends AggregationStrategy {

    /**
     * A timeout occurred
     *
     * @param oldExchange  the oldest exchange (is null on first aggregation as we only have the new exchange)
     * @param index        the index
     * @param total        the total
     * @param timeout      the timeout value in millis
     */
    void timeout(Exchange oldExchange, int index, int total, long timeout);

This allows you to deal with the timeout in the AggregationStrategy if you really need to.

Timeout is total
The timeout is total, which means that after X time, Camel will aggregate the messages which has completed within the timeframe. The remainders will be cancelled. Camel will also only invoke the timeout method in the TimeoutAwareAggregationStrategy once, for the first index which caused the timeout.

Using onPrepare to execute custom logic when preparing messages

Available as of Camel 2.8

See details at Multicast

Using This Pattern

If 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.

Splitter

The Splitter from the EIP patterns allows you split a message into a number of pieces and process them individually

Enterprise Integration Patterns_第12张图片

As of Camel 2.0, you need to specify a Splitter as split(). In earlier versions of Camel, you need to use splitter().

Options

Name Default Value Description
strategyRef   Refers to an AggregationStrategy to be used to assemble the replies from the sub-messages, into a single outgoing message from the Splitter. See the defaults described below in What the Splitter returns.
parallelProcessing false If enables then processing the sub-messages occurs concurrently. Note the caller thread will still wait until all sub-messages has been fully processed, before it continues.
executorServiceRef   Refers to a custom Thread Pool to be used for parallel processing. Notice if you set this option, then parallel processing is automatic implied, and you do not have to enable that option as well.
stopOnException false Camel 2.2: Whether or not to stop continue processing immediately when an exception occurred. If disable, then Camel continue splitting and process the sub-messages regardless if one of them failed. You can deal with exceptions in the AggregationStrategy class where you have full control how to handle that.
streaming false If enabled then Camel will split in a streaming fashion, which means it will split the input message in chunks. This reduces the memory overhead. For example if you split big messages its recommended to enable streaming. If streaming is enabled then the sub-message replies will be aggregated out-of-order, eg in the order they come back. If disabled, Camel will process sub-message replies in the same order as they where splitted.
timeout   Camel 2.5: Sets a total timeout specified in millis. If the Recipient List hasn't been able to split and process all replies within the given timeframe, then the timeout triggers and the Splitter breaks out and continues. Notice if you provide a TimeoutAwareAggregationStrategy then the timeout method is invoked before breaking out.
onPrepareRef   Camel 2.8: Refers to a custom Processor to prepare the sub-message of the Exchange, before its processed. This allows you to do any custom logic, such as deep-cloning the message payload if that's needed etc.
shareUnitOfWork false Camel 2.8: Whether the unit of work should be shared. See further below for more details.

Exchange properties

The following properties are set on each Exchange that are split:

property type description
CamelSplitIndex int Camel 2.0: A split counter that increases for each Exchange being split. The counter starts from 0.
CamelSplitSize int Camel 2.0: The total number of Exchanges that was splitted. This header is not applied for stream based splitting. From Camel 2.9 onwards this header is also set in stream based splitting, but only on the completed Exchange.
CamelSplitComplete boolean Camel 2.4: Whether or not this Exchange is the last.

Examples

The following example shows how to take a request from the queue:a endpoint the split it into pieces using an Expression, then forward each piece to queue:b

Using the Fluent Builders

RouteBuilder builder = new RouteBuilder() {
    public void configure() {
        errorHandler(deadLetterChannel("mock:error"));

        from("direct:a")
            .split(body(String.class).tokenize("\n"))
                .to("direct:b");
    }
};

The splitter can use any Expression language so you could use any of the Languages Supported such as XPath, XQuery, SQL or one of the Scripting Languages to perform the split. e.g.

from("activemq:my.queue").split(xpath("//foo/bar")).convertBodyTo(String.class).to("file://some/directory")

Using the Spring XML Extensions

"errorHandler" xmlns="http://camel.apache.org/schema/spring">
    
        "direct:a"/>
        
            /invoice/lineItems
            "direct:b"/>
        
    

For further examples of this pattern in use you could look at one of the junit test case

Using Tokenizer from Spring XML Extensions*

Avaiaible as of Camel 2.0

You can use the tokenizer expression in the Spring DSL to split bodies or headers using a token. This is a common use-case, so we provided a special tokenizer tag for this.
In the sample below we split the body using a @ as separator. You can of course use comma or space or even a regex pattern, also set regex=true.

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        
            "@"/>
            "mock:result"/>
        
    

Splitting the body in Spring XML is a bit harder as you need to use the Simple language to dictate this


   ${body}
   "mock:result"/>

What the Splitter returns

Camel 2.2 or older:
The Splitter will by default return the last splitted message.

Camel 2.3 and newer
The Splitter will by default return the original input message.

For all versions
You can override this by suppling your own strategy as an AggregationStrategy. There is a sample on this page (Split aggregate request/reply sample). Notice its the same strategy as the Aggregator supports. This Splitter can be viewed as having a build in light weight Aggregator.

Parallel execution of distinct 'parts'

If you want to execute all parts in parallel you can use special notation of split() with two arguments, where the second one is a boolean flag if processing should be parallel. e.g.

XPathBuilder xPathBuilder = new XPathBuilder("//foo/bar"); 
from("activemq:my.queue").split(xPathBuilder, true).to("activemq:my.parts");

In Camel 2.0 the boolean option has been refactored into a builder method parallelProcessing so its easier to understand what the route does when we use a method instead of true|false.

XPathBuilder xPathBuilder = new XPathBuilder("//foo/bar"); 
from("activemq:my.queue").split(xPathBuilder).parallelProcessing().to("activemq:my.parts");

Stream based

Splitting big XML payloads
The XPath engine in Java and saxon will load the entire XML content into memory. And thus they are not well suited for very big XML payloads.
Instead you can use a custom Expression which will iterate the XML payload in a streamed fashion. From Camel 2.9 onwards you can use the Tokenizer language
which supports this when you supply the start and end tokens.

You can split streams by enabling the streaming mode using the streaming builder method.

    from("direct:streaming").split(body().tokenize(",")).streaming().to("activemq:my.parts");

You can also supply your custom splitter to use with streaming like this:

import static org.apache.camel.builder.ExpressionBuilder.beanExpression;
from("direct:streaming")
     .split(beanExpression(new MyCustomIteratorFactory(),  "iterator"))
     .streaming().to("activemq:my.parts")

Streaming big XML payloads using Tokenizer language

Available as of Camel 2.9
If you have a big XML payload, from a file source, and want to split it in streaming mode, then you can use the Tokenizer language with start/end tokens to do this with low memory footprint.

StAX component
The Camel StAX component can also be used to split big XML files in a streaming mode. See more details at StAX.

For example you may have a XML payload structured as follows


  
    
  
  
    
  
...
  
    
  

Now to split this big file using XPath would cause the entire content to be loaded into memory. So instead we can use the Tokenizer language to do this as follows:

  from("file:inbox")
    .split().tokenizeXML("order").streaming()
       .to("activemq:queue:order");

In XML DSL the route would be as follows:


  "file:inbox"/>
  "true">
    "order" xml="true"/>
    "activemq:queue:order"/>
  

Notice the tokenizeXML method which will split the file using the tag name of the child node, which mean it will grab the content between the and tags (incl. the tokens). So for example a splitted message would be as follows:

  
    
  

If you want to inherit namespaces from a root/parent tag, then you can do this as well by providing the name of the root/parent tag:


  "file:inbox"/>
  "true">
    "order" inheritNamespaceTagName="orders" xml="true"/>
    "activemq:queue:order"/>
  

And in Java DSL its as follows:

  from("file:inbox")
    .split().tokenizeXML("order", "orders").streaming()
       .to("activemq:queue:order");

Splitting files by grouping N lines together

Available as of Camel 2.10

The Tokenizer language has a new option group that allows you to group N parts together, for example to split big files into chunks of 1000 lines.

  from("file:inbox")
    .split().tokenize("\n", 1000).streaming()
       .to("activemq:queue:order");

And in XML DSL


  "file:inbox"/>
  "true">
    "\n" group="1000"/>
    "activemq:queue:order"/>
  

The group option is a number that must be a positive number that dictates how many groups to combine together. Each part will be combined using the token.
So in the example above the message being sent to the activemq order queue, will contain 1000 lines, and each line separated by the token (which is a new line token).
The output when using the group option is always a java.lang.String type.

Specifying a custom aggregation strategy

Available as of Camel 2.0

This is specified similar to the Aggregator.

Specifying a custom ThreadPoolExecutor

You can customize the underlying ThreadPoolExecutor used in the parallel splitter. In the Java DSL try something like this:

XPathBuilder xPathBuilder = new XPathBuilder("//foo/bar"); 

ExecutorService pool = ...

from("activemq:my.queue")
    .split(xPathBuilder).parallelProcessing().executorService(pool)
        .to("activemq:my.parts");

Using a Pojo to do the splitting

As the Splitter can use any Expression to do the actual splitting we leverage this fact and use a method expression to invoke a Bean to get the splitted parts.
The Bean should return a value that is iterable such as: java.util.Collection, java.util.Iterator or an array.
So the returned value, will then be used by Camel at runtime, to split the message.

Streaming mode and using pojo
When you have enabled the streaming mode, then you should return a Iterator to ensure streamish fashion. For example if the message is a big file, then by using an iterator, that returns a piece of the file in chunks, in the next method of the Iterator ensures low memory footprint. This avoids the need for reading the entire content into memory. For an example see the source code for the TokenizePair implementation.

In the route we define the Expression as a method call to invoke our Bean that we have registered with the id mySplitterBean in the Registry.

from("direct:body")
        // here we use a POJO bean mySplitterBean to do the split of the payload
        .split().method("mySplitterBean", "splitBody")
        .to("mock:result");
from("direct:message")
        // here we use a POJO bean mySplitterBean to do the split of the message 
        // with a certain header value
        .split().method("mySplitterBean", "splitMessage")
        .to("mock:result");

And the logic for our Bean is as simple as. Notice we use Camel Bean Binding to pass in the message body as a String object.

public class MySplitterBean {

    /**
     * The split body method returns something that is iteratable such as a java.util.List.
     *
     * @param body the payload of the incoming message
     * @return a list containing each part splitted
     */
    public List<String> splitBody(String body) {
        // since this is based on an unit test you can of cause
        // use different logic for splitting as Camel have out
        // of the box support for splitting a String based on comma
        // but this is for show and tell, since this is java code
        // you have the full power how you like to split your messages
        List<String> answer = new ArrayList<String>();
        String[] parts = body.split(",");
        for (String part : parts) {
            answer.add(part);
        }
        return answer;
    }
    
    /**
     * The split message method returns something that is iteratable such as a java.util.List.
     *
     * @param header the header of the incoming message with the name user
     * @param body the payload of the incoming message
     * @return a list containing each part splitted
     */
    public List splitMessage(@Header(value = "user") String header, @Body String body) {
        // we can leverage the Parameter Binding Annotations  
        // http://camel.apache.org/parameter-binding-annotations.html
        // to access the message header and body at same time, 
        // then create the message that we want, splitter will
        // take care rest of them.
        // *NOTE* this feature requires Camel version >= 1.6.1
        List answer = new ArrayList();
        String[] parts = header.split(",");
        for (String part : parts) {
            DefaultMessage message = new DefaultMessage();
            message.setHeader("user", part);
            message.setBody(body);
            answer.add(message);
        }
        return answer;
    }
}

Split aggregate request/reply sample

This sample shows how you can split an Exchange, process each splitted message, aggregate and return a combined response to the original caller using request/reply.

The route below illustrates this and how the split supports a aggregationStrategy to hold the in progress processed messages:

// 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")

And the OrderService bean is as follows:

public static class MyOrderService {

    private static int counter;

    /**
     * We just handle the order by returning a id line for the order
     */
    public String handleOrder(String line) {
        LOG.debug("HandleOrder: " + line);
        return "(id=" + ++counter + ",item=" + line + ")";
    }

    /**
     * We use the same bean for building the combined response to send
     * back to the original caller
     */
    public String buildCombinedResponse(String line) {
        LOG.debug("BuildCombinedResponse: " + line);
        return "Response[" + line + "]";
    }
}

And our custom aggregationStrategy that is responsible for holding the in progress aggregated message that after the splitter is ended will be sent to the buildCombinedResponse method for final processing before the combined response can be returned to the waiting caller.

/**
 * This is our own order aggregation strategy where we can control
 * how each splitted message should be combined. As we do not want to
 * loos any message we copy from the new to the old to preserve the
 * order lines as long we process them
 */
public static class MyOrderStrategy implements AggregationStrategy {

    public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
        // put order together in old exchange by adding the order from new exchange

        if (oldExchange == null) {
            // the first time we aggregate we only have the new exchange,
            // so we just return it
            return newExchange;
        }

        String orders = oldExchange.getIn().getBody(String.class);
        String newLine = newExchange.getIn().getBody(String.class);

        LOG.debug("Aggregate old orders: " + orders);
        LOG.debug("Aggregate new order: " + newLine);

        // put orders together separating by semi colon
        orders = orders + ";" + newLine;
        // put combined order back on old to preserve it
        oldExchange.getIn().setBody(orders);

        // return old as this is the one that has all the orders gathered until now
        return oldExchange;
    }
}

So lets run the sample and see how it works.
We send an Exchange to the direct:start endpoint containing a IN body with the String value: A@B@C. The flow is:

HandleOrder: A
HandleOrder: B
Aggregate old orders: (id=1,item=A)
Aggregate new order: (id=2,item=B)
HandleOrder: C
Aggregate old orders: (id=1,item=A);(id=2,item=B)
Aggregate new order: (id=3,item=C)
BuildCombinedResponse: (id=1,item=A);(id=2,item=B);(id=3,item=C)
Response to caller: Response[(id=1,item=A);(id=2,item=B);(id=3,item=C)]

Stop processing in case of exception

Available as of Camel 2.1

The Splitter will by default continue to process the entire Exchange even in case of one of the splitted message will thrown an exception during routing.
For example if you have an Exchange with 1000 rows that you split and route each sub message. During processing of these sub messages an exception is thrown at the 17th. What Camel does by default is to process the remainder 983 messages. You have the chance to remedy or handle this in the AggregationStrategy.

But sometimes you just want Camel to stop and let the exception be propagated back, and let the Camel error handler handle it. You can do this in Camel 2.1 by specifying that it should stop in case of an exception occurred. This is done by the stopOnException option as shown below:

    from("direct:start")
        .split(body().tokenize(",")).stopOnException()
            .process(new MyProcessor())
            .to("mock:split");

And using XML DSL you specify it as follows:

        
            "direct:start"/>
            "true">
                ","/>
                "myProcessor"/>
                "mock:split"/>
            
        

Using onPrepare to execute custom logic when preparing messages

Available as of Camel 2.8

See details at Multicast

Sharing unit of work

Available as of Camel 2.8

The Splitter will by default not share unit of work between the parent exchange and each splitted exchange. This means each sub exchange has its own individual unit of work.

For example you may have an use case, where you want to split a big message. And you want to regard that process as an atomic isolated operation that either is a success or failure. In case of a failure you want that big message to be moved into a dead letter queue. To support this use case, you would have to share the unit of work on the Splitter.

Here is an example in Java DSL

errorHandler(deadLetterChannel("mock:dead").useOriginalMessage()
        .maximumRedeliveries(3).redeliveryDelay(0));

from("direct:start")
    .to("mock:a")
    // share unit of work in the splitter, which tells Camel to propagate failures from
    // processing the splitted messages back to the result of the splitter, which allows
    // it to act as a combined unit of work
    .split(body().tokenize(",")).shareUnitOfWork()
        .to("mock:b")
        .to("direct:line")
    .end()
    .to("mock:result");

from("direct:line")
    .to("log:line")
    .process(new MyProcessor())
    .to("mock:line");

Now in this example what would happen is that in case there is a problem processing each sub message, the error handler will kick in (yes error handling still applies for the sub messages). But what doesn't happen is that if a sub message fails all redelivery attempts (its exhausted), then its not moved into that dead letter queue. The reason is that we have shared the unit of work, so the sub message will report the error on the shared unit of work. When the Splitter is done, it checks the state of the shared unit of work and checks if any errors occurred. And if an error occurred it will set the exception on the Exchange and mark it for rollback. The error handler will yet again kick in, as the Exchange has been marked as rollback and it had an exception as well. No redelivery attempts is performed (as it was marked for rollback) and the Exchange will be moved into the dead letter queue.

Using this from XML DSL is just as easy as you just have to set the shareUnitOfWork attribute to true:

"dlc" xmlns="http://camel.apache.org/schema/spring">

  
  "dlc" type="DeadLetterChannel" deadLetterUri="mock:dead" useOriginalMessage="true">
    "3" redeliveryDelay="0"/>
  

  
    "direct:start"/>
    "mock:a"/>
    
    "true">
      ","/>
      "mock:b"/>
      "direct:line"/>
    
    "mock:result"/>
  

  
  
    "direct:line"/>
    "log:line"/>
    "myProcessor"/>
    "mock:line"/>
  


Implementation of shared unit of work in Camel 2.x
The Camel team had to introduce a SubUnitOfWork to keep API compatible with the current UnitOfWork in Camel 2.x code base. So in reality the unit of work is not shared as a single object instance. Instead SubUnitOfWork is attached to their parent, and issues callback to the parent about their status (commit or rollback). This may be refactored in Camel 3.0 where larger API changes can be done.

Using This Pattern

If 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.

Aggregator

This 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.

Enterprise Integration Patterns_第13张图片

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 options

The aggregator supports the following options:

Option Default Description
correlationExpression   Mandatory Expression which evaluates the correlation key to use for aggregation. The Exchange which has the same correlation key is aggregated together. If the correlation key could not be evaluated an Exception is thrown. You can disable this by using the ignoreBadCorrelationKeys option.
aggregationStrategy   Mandatory AggregationStrategy which is used to merge the incoming Exchange with the existing already merged exchanges. At first call the oldExchange parameter is null. On subsequent invocations the oldExchange contains the merged exchanges and newExchange is of course the new incoming Exchange. From Camel 2.9.2 onwards the strategy can also be a TimeoutAwareAggregationStrategy implementation, supporting the timeout callback, see further below for more details.
strategyRef   A reference to lookup the AggregationStrategy in the Registry.
completionSize   Number of messages aggregated before the aggregation is complete. This option can be set as either a fixed value or using an Expression which allows you to evaluate a size dynamically - will use Integer as result. If both are set Camel will fallback to use the fixed value if the Expression result was null or 0.
completionTimeout   Time in millis that an aggregated exchange should be inactive before its complete. This option can be set as either a fixed value or using an Expression which allows you to evaluate a timeout dynamically - will use Long as result. If both are set Camel will fallback to use the fixed value if the Expression result was null or 0. You cannot use this option together with completionInterval, only one of the two can be used.
completionInterval   A repeating period in millis by which the aggregator will complete all current aggregated exchanges. Camel has a background task which is triggered every period. You cannot use this option together with completionTimeout, only one of them can be used.
completionPredicate   A Predicate to indicate when an aggregated exchange is complete.
completionFromBatchConsumer false This option is if the exchanges are coming from a Batch Consumer. Then when enabled the Aggregator2 will use the batch size determined by the Batch Consumer in the message header CamelBatchSize. See more details at Batch Consumer. This can be used to aggregate all files consumed from a File endpoint in that given poll.
forceCompletionOnStop false Camel 2.9 Indicates to complete all current aggregated exchanges when the context is stopped
eagerCheckCompletion false Whether or not to eager check for completion when a new incoming Exchange has been received. This option influences the behavior of the completionPredicate option as the Exchange being passed in changes accordingly. When false the Exchange passed in the Predicate is the aggregated Exchange which means any information you may store on the aggregated Exchange from the AggregationStrategy is available for the Predicate. When true the Exchange passed in the Predicate is the incoming Exchange, which means you can access data from the incoming Exchange.
groupExchanges false If enabled then Camel will group all aggregated Exchanges into a single combined org.apache.camel.impl.GroupedExchange holder class that holds all the aggregated Exchanges. And as a result only one Exchange is being sent out from the aggregator. Can be used to combine many incoming Exchanges into a single output Exchange without coding a custom AggregationStrategy yourself. Important: This option does not support persistant repository with the aggregator.
ignoreInvalidCorrelationKeys false Whether or not to ignore correlation keys which could not be evaluated to a value. By default Camel will throw an Exception, but you can enable this option and ignore the situation instead.
closeCorrelationKeyOnCompletion   Whether or not too late Exchanges should be accepted or not. You can enable this to indicate that if a correlation key has already been completed, then any new exchanges with the same correlation key be denied. Camel will then throw a closedCorrelationKeyException exception. When using this option you pass in a integer which is a number for a LRUCache which keeps that last X number of closed correlation keys. You can pass in 0 or a negative value to indicate a unbounded cache. By passing in a number you are ensured that cache won't grow too big if you use a log of different correlation keys.
discardOnCompletionTimeout false Camel 2.5: Whether or not exchanges which complete due to a timeout should be discarded. If enabled then when a timeout occurs the aggregated message will not be sent out but dropped (discarded).
aggregationRepository   Allows you to plugin you own implementation of org.apache.camel.spi.AggregationRepository which keeps track of the current inflight aggregated exchanges. Camel uses by default a memory based implementation.
aggregationRepositoryRef   Reference to lookup a aggregationRepository in the Registry.
parallelProcessing false When aggregated are completed they are being send out of the aggregator. This option indicates whether or not Camel should use a thread pool with multiple threads for concurrency. If no custom thread pool has been specified then Camel creates a default pool with 10 concurrent threads.
executorService   If using parallelProcessing you can specify a custom thread pool to be used. In fact also if you are not using parallelProcessing this custom thread pool is used to send out aggregated exchanges as well.
executorServiceRef   Reference to lookup a executorService in the Registry
timeoutCheckerExecutorService   Camel 2.9: If using either of the completionTimeout, completionTimeoutExpression, or completionInterval options a background thread is created to check for the completion for every aggregator. Set this option to provide a custom thread pool to be used rather than creating a new thread for every aggregator.
timeoutCheckerExecutorServiceRef   Camel 2.9: Reference to lookup a timeoutCheckerExecutorService in the Registry

Exchange Properties

The following properties are set on each aggregated Exchange:

header type description
CamelAggregatedSize int The total number of Exchanges aggregated into this combined Exchange.
CamelAggregatedCompletedBy String Indicator how the aggregation was completed as a value of either: predicate, size, consumer, timeout or interval.

About AggregationStrategy

The 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 completion

When 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:

  • completionTimeout - Is an inactivity timeout in which is triggered if no new exchanges have been aggregated for that particular correlation key within the period.
  • completionInterval - Once every X period all the current aggregated exchanges are completed.
  • completionSize - Is a number indicating that after X aggregated exchanges it's complete.
  • completionPredicate - Runs a Predicate when a new exchange is aggregated to determine if we are complete or not
  • completionFromBatchConsumer - Special option for Batch Consumer which allows you to complete when all the messages from the batch has been aggregated.
  • forceCompletionOnStop - Camel 2.9 Indicates to complete all current aggregated exchanges when the context is stopped

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.

Callbacks
See the TimeoutAwareAggregationStrategy and CompletionAwareAggregationStrategy extensions to AggregationStrategy that has callbacks when the aggregated Exchange was completed and if a timeout occurred.

Persistent AggregationRepository

The aggregator provides a pluggable repository which you can implement your own org.apache.camel.spi.AggregationRepository.
If you need persistent repository then you can use either Camel HawtDB or SQL Component components.

Examples

See some examples from the old Aggregator which is somewhat similar to this new aggregator.

Setting options in Spring XML
Many of the options are configurable as attributes on the tag when using Spring XML.

Using completionTimeout

In 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:

from("direct:start")
    // aggregate all exchanges correlated by the id header.
    // Aggregate them using the BodyInAggregatingStrategy strategy which
    // and after 3 seconds of inactivity them timeout and complete the aggregation
    // and send it to mock:aggregated
    .aggregate(header("id"), new BodyInAggregatingStrategy()).completionTimeout(3000)
        .to("mock:aggregated");

And the same example using Spring XML:

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        "aggregatorStrategy" completionTimeout="3000">
            
                header.id
            
            "mock:aggregated"/>
        
    


"aggregatorStrategy" class="org.apache.camel.processor.BodyInAggregatingStrategy"/>

Using TimeoutAwareAggregationStrategy

Available 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 CompletionAwareAggregationStrategy

Available 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.
You must not throw any exceptions from the onCompletion method.

Using completionSize

In 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:

from("direct:start")
    // aggregate all exchanges correlated by the id header.
    // Aggregate them using the BodyInAggregatingStrategy strategy which
    // and after 3 messages has been aggregated then complete the aggregation
    // and send it to mock:aggregated
    .aggregate(header("id"), new BodyInAggregatingStrategy()).completionSize(3)
        .to("mock:aggregated");

And the same example using Spring XML:

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        "aggregatorStrategy" completionSize="3">
            
                header.id
            
            "mock:aggregated"/>
        
    


"aggregatorStrategy" class="org.apache.camel.processor.BodyInAggregatingStrategy"/>

Using completionPredicate

In 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:

from("direct:start")
    // aggregate all exchanges correlated by the id header.
    // Aggregate them using the BodyInAggregatingStrategy strategy which
    // and when the aggregated body contains A+B+C then complete the aggregation
    // and send it to mock:aggregated
    .aggregate(header("id"), new BodyInAggregatingStrategy()).completionPredicate(body().contains("A+B+C"))
        .to("mock:aggregated");

And the same example using Spring XML:

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        "aggregatorStrategy">
            
                header.id
            
            
                ${body} contains 'A+B+C'
            
            "mock:aggregated"/>
        
    


"aggregatorStrategy" class="org.apache.camel.processor.BodyInAggregatingStrategy"/>

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:

from("direct:start")
    // aggregate all exchanges correlated by the id header.
    // Aggregate them using the BodyInAggregatingStrategy strategy
    // do eager checking which means the completion predicate will use the incoming exchange
    // which allows us to trigger completion when a certain exchange arrived which is the
    // END message
    .aggregate(header("id"), new BodyInAggregatingStrategy())
        .eagerCheckCompletion().completionPredicate(body().isEqualTo("END"))
        .to("mock:aggregated");

And the same example using Spring XML:

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        "aggregatorStrategy" eagerCheckCompletion="true">
            
                header.id
            
            
                ${body} == 'END'
            
            "mock:aggregated"/>
        
    


"aggregatorStrategy" class="org.apache.camel.processor.BodyInAggregatingStrategy"/>

Using dynamic completionTimeout

In 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:

from("direct:start")
    // aggregate all exchanges correlated by the id header.
    // Aggregate them using the BodyInAggregatingStrategy strategy which
    // and the timeout header contains the timeout in millis of inactivity them timeout and complete the aggregation
    // and send it to mock:aggregated
    .aggregate(header("id"), new BodyInAggregatingStrategy()).completionTimeout(header("timeout"))
        .to("mock:aggregated");

And the same example using Spring XML:

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        "aggregatorStrategy">
            
                header.id
            
            
                
timeout
"mock:aggregated"/> "aggregatorStrategy" class="org.apache.camel.processor.BodyInAggregatingStrategy"/>

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 completionSize

In 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:

from("direct:start")
    // aggregate all exchanges correlated by the id header.
    // Aggregate them using the BodyInAggregatingStrategy strategy which
    // and the header mySize determines the number of aggregated messages should trigger the completion
    // and send it to mock:aggregated
    .aggregate(header("id"), new BodyInAggregatingStrategy()).completionSize(header("mySize"))
        .to("mock:aggregated");

And the same example using Spring XML:

"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        "aggregatorStrategy">
            
                header.id
            
            
                
mySize
"mock:aggregated"/> "aggregatorStrategy" class="org.apache.camel.processor.BodyInAggregatingStrategy"/>

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 Pattern

If 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 Immediately

Available as of Camel 2.9
You can manually complete all current aggregated exchanges by sending in a message containing the header Exchange.AGGREGATION_COMPLETE_ALL_GROUPS set to true. The message is considered a signal message only, the message headers/contents will not be processed otherwise.

See also

  • The Loan Broker Example which uses an aggregator
  • Blog post by Torsten Mielke about using the aggregator correctly.
  • The old Aggregator
  • HawtDB or SQL Component for persistence support
  • Aggregate Example for an example application

Resequencer

The Resequencer from the EIP patterns allows you to reorganise messages based on some comparator. By default in Camel we use an Expression to create the comparator; so that you can compare by a message header or the body or a piece of a message etc.

Enterprise Integration Patterns_第14张图片

Change in Camel 2.7
The and tags in XML DSL in the Resequencer EIP must now be configured in the top, and not in the bottom. So if you use those, then move them up just below the EIP starts in the XML. If you are using Camel older than 2.7, then those configs should be at the bottom.

Camel supports two resequencing algorithms:

  • Batch resequencing collects messages into a batch, sorts the messages and sends them to their output.
  • Stream resequencing re-orders (continuous) message streams based on the detection of gaps between messages.

By default the Resequencer does not support duplicate messages and will only keep the last message, in case a message arrives with the same message expression. However in the batch mode you can enable it to allow duplicates.

Batch Resequencing

The following example shows how to use the batch-processing resequencer so that messages are sorted in order of the body() expression. That is messages are collected into a batch (either by a maximum number of messages per batch or using a timeout) then they are sorted in order and then sent out to their output.

Using the Fluent Builders

from("direct:start")
    .resequence().body()
    .to("mock:result");

This is equvalent to

from("direct:start")
    .resequence(body()).batch()
    .to("mock:result");

The batch-processing resequencer can be further configured via the size() and timeout() methods.

from("direct:start")
    .resequence(body()).batch().size(300).timeout(4000L)
    .to("mock:result")

This sets the batch size to 300 and the batch timeout to 4000 ms (by default, the batch size is 100 and the timeout is 1000 ms). Alternatively, you can provide a configuration object.

from("direct:start")
    .resequence(body()).batch(new BatchResequencerConfig(300, 4000L))
    .to("mock:result")

So the above example will reorder messages from endpoint direct:a in order of their bodies, to the endpoint mock:result.
Typically you'd use a header rather than the body to order things; or maybe a part of the body. So you could replace this expression with

resequencer(header("mySeqNo"))

for example to reorder messages using a custom sequence number in the header mySeqNo.

You can of course use many different Expression languages such as XPath, XQuery, SQL or various Scripting Languages.

Using the Spring XML Extensions

"camel" xmlns="http://camel.apache.org/schema/spring">
  
    "direct:start" />
    
      body
      "mock:result" />
      
      "300" batchTimeout="4000" />
    
  

Allow Duplicates

Available as of Camel 2.4

In the batch mode, you can now allow duplicates. In Java DSL there is a allowDuplicates() method and in Spring XML there is an allowDuplicates=true attribute on the you can use to enable it.

Reverse

Available as of Camel 2.4

In the batch mode, you can now reverse the expression ordering. By default the order is based on 0..9,A..Z, which would let messages with low numbers be ordered first, and thus also also outgoing first. In some cases you want to reverse order, which is now possible.

In Java DSL there is a reverse() method and in Spring XML there is an reverse=true attribute on the you can use to enable it.

Resequence JMS messages based on JMSPriority

Available as of Camel 2.4

It's now much easier to use the Resequencer to resequence messages from JMS queues based on JMSPriority. For that to work you need to use the two new options allowDuplicates and reverse.

from("jms:queue:foo")
    // sort by JMSPriority by allowing duplicates (message can have same JMSPriority)
    // and use reverse ordering so 9 is first output (most important), and 0 is last
    // use batch mode and fire every 3th second
    .resequence(header("JMSPriority")).batch().timeout(3000).allowDuplicates().reverse()
    .to("mock:result");

Notice this is only possible in the batch mode of the Resequencer.

Ignore invalid exchanges

Available as of Camel 2.9

The Resequencer EIP will from Camel 2.9 onwards throw a CamelExchangeException if the incoming Exchange is not valid for the resequencer - ie. the expression cannot be evaluated, such as a missing header. You can use the option ignoreInvalidExchanges to ignore these exceptions which means the Resequencer will then skip the invalid Exchange.

from("direct:start")
    .resequence(header("seqno")).batch().timeout(1000)
        // ignore invalid exchanges (they are discarded)
        .ignoreInvalidExchanges()
    .to("mock:result");

This option is available for both batch and stream resequencer.

Reject Old Exchanges

Available as of Camel 2.11

This option can be used to prevent out of order messages from being sent regardless of the event that delivered messages downstream (capacity, timeout, etc). If enabled using rejectOld(), the Resequencer will throw a MessageRejectedException when an incoming Exchange is "older" (based on the Comparator) than the last delivered message. This provides an extra level of control with regards to delayed message ordering.

from("direct:start")
    .onException(MessageRejectedException.class).handled(true).to("mock:error").end()
    .resequence(header("seqno")).stream().timeout(1000).rejectOld()
    .to("mock:result");

This option is available for the stream resequencer only.

Stream Resequencing

The next example shows how to use the stream-processing resequencer. Messages are re-ordered based on their sequence numbers given by a seqnum header using gap detection and timeouts on the level of individual messages.

Using the Fluent Builders

from("direct:start").resequence(header("seqnum")).stream().to("mock:result");

The stream-processing resequencer can be further configured via the capacity() and timeout() methods.

from("direct:start")
    .resequence(header("seqnum")).stream().capacity(5000).timeout(4000L)
    .to("mock:result")

This sets the resequencer's capacity to 5000 and the timeout to 4000 ms (by default, the capacity is 1000 and the timeout is 1000 ms). Alternatively, you can provide a configuration object.

from("direct:start")
    .resequence(header("seqnum")).stream(new StreamResequencerConfig(5000, 4000L))
    .to("mock:result")

The stream-processing resequencer algorithm is based on the detection of gaps in a message stream rather than on a fixed batch size. Gap detection in combination with timeouts removes the constraint of having to know the number of messages of a sequence (i.e. the batch size) in advance. Messages must contain a unique sequence number for which a predecessor and a successor is known. For example a message with the sequence number 3 has a predecessor message with the sequence number 2 and a successor message with the sequence number 4. The message sequence 2,3,5 has a gap because the sucessor of 3 is missing. The resequencer therefore has to retain message 5 until message 4 arrives (or a timeout occurs).

If the maximum time difference between messages (with successor/predecessor relationship with respect to the sequence number) in a message stream is known, then the resequencer's timeout parameter should be set to this value. In this case it is guaranteed that all messages of a stream are delivered in correct order to the next processor. The lower the timeout value is compared to the out-of-sequence time difference the higher is the probability for out-of-sequence messages delivered by this resequencer. Large timeout values should be supported by sufficiently high capacity values. The capacity parameter is used to prevent the resequencer from running out of memory.

By default, the stream resequencer expects long sequence numbers but other sequence numbers types can be supported as well by providing a custom expression.

public class MyFileNameExpression implements Expression {
    
    public String getFileName(Exchange exchange) {
        return exchange.getIn().getBody(String.class);
    }
    
    public Object evaluate(Exchange exchange) {
        // parser the file name with YYYYMMDD-DNNN pattern
        String fileName = getFileName(exchange);
        String[] files = fileName.split("-D");
        Long answer = Long.parseLong(files[0]) * 1000 + Long.parseLong(files[1]);
        return answer;
    }
    

    public  T evaluate(Exchange exchange, Class type) {
        Object result = evaluate(exchange);
        return exchange.getContext().getTypeConverter().convertTo(type, result);
    }

}
from("direct:start").resequence(new MyFileNameExpression()).stream().timeout(100).to("mock:result");

or custom comparator via the comparator() method

ExpressionResultComparator comparator = new MyComparator();
from("direct:start")
    .resequence(header("seqnum")).stream().comparator(comparator)
    .to("mock:result");

or via a StreamResequencerConfig object.

ExpressionResultComparator comparator = new MyComparator();
StreamResequencerConfig config = new StreamResequencerConfig(100, 1000L, comparator);

from("direct:start")
    .resequence(header("seqnum")).stream(config)
    .to("mock:result");

Using the Spring XML Extensions

"camel" xmlns="http://camel.apache.org/schema/spring">
  
    "direct:start"/>
    
      in.header.seqnum
      "mock:result" />
      "5000" timeout="4000"/>
    
  

Further Examples

For further examples of this pattern in use you could look at the batch-processing resequencer junit test case and the stream-processing resequencer junit test case

Using This Pattern

If 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.

Composed Message Processor

The Composed Message Processor from the EIP patterns allows you to process a composite message by splitting it up, routing the sub-messages to appropriate destinations and the re-aggregating the responses back into a single message.

Enterprise Integration Patterns_第15张图片

In Camel we have two solutions

  • using both a Splitter and Aggregator EIPs
  • using only a Splitter

The difference is when only using a Splitter then it aggregates back all the splitted messages into the samme aggregation group, eg like a fork/join pattern.
Where as using the Aggregator allows you group into multiple groups, and the pattern has more options.

Example using both Splitter and Aggregator

In this example we want to check that a multipart order can be filled. Each part of the order requires a check at a different inventory.

// split up the order so individual OrderItems can be validated by the appropriate bean
from("direct:start")
    .split().body()
    .choice() 
        .when().method("orderItemHelper", "isWidget")
            .to("bean:widgetInventory")
        .otherwise()
            .to("bean:gadgetInventory")
    .end()
    .to("seda:aggregate");

// collect and re-assemble the validated OrderItems into an order again
from("seda:aggregate")
    .aggregate(new MyOrderAggregationStrategy()).header("orderId").completionTimeout(1000L)
        .to("mock:result");

Using the Spring XML Extensions


  "direct:start"/>
  
    body
    
      
        "orderItemHelper" method="isWidget"/>
	"bean:widgetInventory"/>
      
      
	"bean:gadgetInventory"/>
      
    
    "seda:aggregate"/>
  



  "seda:aggregate"/>
  "myOrderAggregatorStrategy" completionTimeout="1000">
    
      header.orderId
    
    "mock:result"/>
  

To do this we split up the order using a Splitter. The Splitter then sends individual OrderItems to a Content Based Router which checks the item type. Widget items get sent for checking in the widgetInventory bean and gadgets get sent to the gadgetInventory bean. Once these OrderItems have been validated by the appropriate bean, they are sent on to the Aggregator which collects and re-assembles the validated OrderItems into an order again.

When an order is sent it contains a header with the order id. We use this fact when we aggregate, as we configure this .header("orderId") on the aggregate DSL to instruct Camel to use the header with the key orderId as correlation expression.

For full details, check the example source here:

camel-core/src/test/java/org/apache/camel/processor/ComposedMessageProcessorTest.java

Example using only Splitter

In this example we want to split an incoming order using the Splitter eip, transform each order line, and then combine the order lines into a new order message.

// 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")
Using XML
If you use XML, then the tag offers the strategyRef attribute to refer to your custom AggregationStrategy

The bean with the methods to transform the order line and process the order as well:

public static class MyOrderService {

    private static int counter;

    /**
     * We just handle the order by returning a id line for the order
     */
    public String handleOrder(String line) {
        LOG.debug("HandleOrder: " + line);
        return "(id=" + ++counter + ",item=" + line + ")";
    }

    /**
     * We use the same bean for building the combined response to send
     * back to the original caller
     */
    public String buildCombinedResponse(String line) {
        LOG.debug("BuildCombinedResponse: " + line);
        return "Response[" + line + "]";
    }
}

And the AggregationStrategy we use with the Splitter eip to combine the orders back again (eg fork/join):

/**
 * This is our own order aggregation strategy where we can control
 * how each splitted message should be combined. As we do not want to
 * loos any message we copy from the new to the old to preserve the
 * order lines as long we process them
 */
public static class MyOrderStrategy implements AggregationStrategy {

    public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
        // put order together in old exchange by adding the order from new exchange

        if (oldExchange == null) {
            // the first time we aggregate we only have the new exchange,
            // so we just return it
            return newExchange;
        }

        String orders = oldExchange.getIn().getBody(String.class);
        String newLine = newExchange.getIn().getBody(String.class);

        LOG.debug("Aggregate old orders: " + orders);
        LOG.debug("Aggregate new order: " + newLine);

        // put orders together separating by semi colon
        orders = orders + ";" + newLine;
        // put combined order back on old to preserve it
        oldExchange.getIn().setBody(orders);

        // return old as this is the one that has all the orders gathered until now
        return oldExchange;
    }
}

Using This Pattern

If 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.

Scatter-Gather

The Scatter-Gather from the EIP patterns allows you to route messages to a number of dynamically specified recipients and re-aggregate the responses back into a single message.

Enterprise Integration Patterns_第16张图片

Available in Camel 1.5.

Dynamic Scatter-Gather Example

In this example we want to get the best quote for beer from several different vendors. We use a dynamic Recipient List to get the request for a quote to all vendors and an Aggregator to pick the best quote out of all the responses. The routes for this are defined as:

"http://camel.apache.org/schema/spring">
  
    "direct:start"/>
    
      
listOfVendors
"seda:quoteAggregator"/> "aggregatorStrategy" completionTimeout="1000">
quoteRequestId
"mock:result"/>

So in the first route you see that the Recipient List is looking at the listOfVendors header for the list of recipients. So, we need to send a message like

Map<String, Object> headers = new HashMap<String, Object>();
headers.put("listOfVendors", "bean:vendor1, bean:vendor2, bean:vendor3");
headers.put("quoteRequestId", "quoteRequest-1");
template.sendBodyAndHeaders("direct:start", "beer\"/>", headers);

This message will be distributed to the following Endpoints: bean:vendor1, bean:vendor2, and bean:vendor3. These are all beans which look like

public class MyVendor {
    private int beerPrice;
    
    @Produce(uri = "seda:quoteAggregator")
    private ProducerTemplate quoteAggregator;
            
    public MyVendor(int beerPrice) {
        this.beerPrice = beerPrice;
    }
        
    public void getQuote(@XPath("/quote_request/@item") String item, Exchange exchange) throws Exception {
        if ("beer".equals(item)) {
            exchange.getIn().setBody(beerPrice);
            quoteAggregator.send(exchange);
        } else {
            throw new Exception("No quote available for " + item);
        }
    }
}

and are loaded up in Spring like

"aggregatorStrategy" class="org.apache.camel.spring.processor.scattergather.LowestQuoteAggregationStrategy"/>

"vendor1" class="org.apache.camel.spring.processor.scattergather.MyVendor">
  
    1
  


"vendor2" class="org.apache.camel.spring.processor.scattergather.MyVendor">
  
    2
  


"vendor3" class="org.apache.camel.spring.processor.scattergather.MyVendor">
  
    3
  

Each bean is loaded with a different price for beer. When the message is sent to each bean endpoint, it will arrive at the MyVendor.getQuote method. This method does a simple check whether this quote request is for beer and then sets the price of beer on the exchange for retrieval at a later step. The message is forwarded on to the next step using POJO Producing (see the @Produce annotation).

At the next step we want to take the beer quotes from all vendors and find out which one was the best (i.e. the lowest!). To do this we use an Aggregator with a custom aggregation strategy. The Aggregator needs to be able to compare only the messages from this particular quote; this is easily done by specifying a correlationExpression equal to the value of the quoteRequestId header. As shown above in the message sending snippet, we set this header to quoteRequest-1. This correlation value should be unique or you may include responses that are not part of this quote. To pick the lowest quote out of the set, we use a custom aggregation strategy like

public class LowestQuoteAggregationStrategy implements AggregationStrategy {
    public Exchange aggregate(Exchange oldExchange, Exchange newExchange) {
        // the first time we only have the new exchange
        if (oldExchange == null) {
            return newExchange;
        }

        if (oldExchange.getIn().getBody(int.class) < newExchange.getIn().getBody(int.class)) {
            return oldExchange;
        } else {
            return newExchange;
        }
    }
}

Finally, we expect to get the lowest quote of $1 out of $1, $2, and $3.

result.expectedBodiesReceived(1); // expect the lowest quote

You can find the full example source here:

camel-spring/src/test/java/org/apache/camel/spring/processor/scattergather/
camel-spring/src/test/resources/org/apache/camel/spring/processor/scattergather/scatter-gather.xml

Static Scatter-Gather Example

You can lock down which recipients are used in the Scatter-Gather by using a static Recipient List. It looks something like this

from("direct:start").multicast().to("seda:vendor1", "seda:vendor2", "seda:vendor3");

from("seda:vendor1").to("bean:vendor1").to("seda:quoteAggregator");
from("seda:vendor2").to("bean:vendor2").to("seda:quoteAggregator");
from("seda:vendor3").to("bean:vendor3").to("seda:quoteAggregator");

from("seda:quoteAggregator")
    .aggregate(header("quoteRequestId"), new LowestQuoteAggregationStrategy()).to("mock:result")

A full example of the static Scatter-Gather configuration can be found in the Loan Broker Example.

Using This Pattern

If 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.

Routing Slip

The Routing Slip from the EIP patterns allows you to route a message consecutively through a series of processing steps where the sequence of steps is not known at design time and can vary for each message.

Enterprise Integration Patterns_第17张图片

Options

Name Default Value Description
uriDelimiter , Delimiter used if the Expression returned multiple endpoints.
ignoreInvalidEndpoints false If an endpoint uri could not be resolved, should it be ignored. Otherwise Camel will throw an exception stating the endpoint uri is not valid.

Example

The following route will take any messages sent to the Apache ActiveMQ queue SomeQueue and pass them into the Routing Slip pattern.

from("activemq:SomeQueue").routingSlip("headerName");

Messages will be checked for the existance of the "headerName" header. The value of this header should be a comma-delimited list of endpoint URIs you wish the message to be routed to. The Message will be routed in a pipeline fashion (i.e. one after the other).

Note: In Camel 1.x the default header name routingSlipHeader has been @deprecated and is removed in Camel 2.0. We feel that the DSL needed to express, the header it uses to locate the destinations, directly in the DSL to not confuse readers. So the header name must be provided.

From Camel 2.5 the Routing Slip will set a property (Exchange.SLIP_ENDPOINT) on the Exchange which contains the current endpoint as it advanced though the slip. This allows you to know how far we have processed in the slip.

The Routing Slip will compute the slip beforehand which means, the slip is only computed once. If you need to compute the slip on-the-fly then use the Dynamic Router pattern instead.

Configuration options

Here we set the header name and the URI delimiter to something different.

Using the Fluent Builders

from("direct:c").routingSlip(header("aRoutingSlipHeader"), "#");

Using the Spring XML Extensions

"buildRoutingSlip" xmlns="http://activemq.apache.org/camel/schema/spring">
  
    "direct:c"/>
    "aRoutingSlipHeader" uriDelimiter="#"/>
  

Ignore invalid endpoints

Available as of Camel 2.3

The Routing Slip now supports ignoreInvalidEndpoints which the Recipient List also supports. You can use it to skip endpoints which are invalid.

    from("direct:a").routingSlip("myHeader").ignoreInvalidEndpoints();

And in Spring XML its an attribute on the recipient list tag.

   
       "direct:a"/>
       "myHeader" ignoreInvalidEndpoints="true"/>
   

Then lets say the myHeader contains the following two endpoints direct:foo,xxx:bar. The first endpoint is valid and works. However the 2nd is invalid and will just be ignored. Camel logs at INFO level, so you can see why the endpoint was invalid.

Expression supporting

Available as of Camel 2.4

The Routing Slip now supports to take the expression parameter as the Recipient List does. You can tell Camel the expression that you want to use to get the routing slip.

    from("direct:a").routingSlip(header("myHeader")).ignoreInvalidEndpoints();

And in Spring XML its an attribute on the recipient list tag.

   
       "direct:a"/>
       
       "true">
           
myHeader

Further Examples

For further examples of this pattern in use you could look at the routing slip test cases.

Using This Pattern

If 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.

Throttler

The Throttler Pattern allows you to ensure that a specific endpoint does not get overloaded, or that we don't exceed an agreed SLA with some external service.

Options

Name Default Value Description
maximumRequestsPerPeriod   Maximum number of requests per period to throttle. This option must be provided and a positive number. Notice, in the XML DSL, from Camel 2.8 onwards this option is configured using an Expression instead of an attribute.
timePeriodMillis 1000 The time period in millis, in which the throttler will allow at most maximumRequestsPerPeriod number of messages.
asyncDelayed false Camel 2.4: If enabled then any messages which is delayed happens asynchronously using a scheduled thread pool.
executorServiceRef   Camel 2.4: Refers to a custom Thread Pool to be used if asyncDelay has been enabled.
callerRunsWhenRejected true Camel 2.4: Is used if asyncDelayed was enabled. This controls if the caller thread should execute the task if the thread pool rejected the task.

Examples

Using the Fluent Builders

from("seda:a").throttle(3).timePeriodMillis(10000).to("log:result", "mock:result");

So the above example will throttle messages all messages received on seda:a before being sent to mock:result ensuring that a maximum of 3 messages are sent in any 10 second window. Note that typically you would often use the default time period of a second. So to throttle requests at 100 requests per second between two endpoints it would look more like this...

from("seda:a").throttle(100).to("seda:b");

For further examples of this pattern in use you could look at the junit test case

Using the Spring XML Extensions

Camel 2.7.x or older


  "seda:a" />
  "3" timePeriodMillis="10000">
    "mock:result" />
  

Camel 2.8 onwards

In Camel 2.8 onwards you must set the maximum period as an Expression as shown below where we use a Constant expression:


    "seda:a"/>
    
    "10000">
        3
        "mock:result"/>
    

Dynamically changing maximum requests per period

Available os of Camel 2.8
Since we use an Expression you can adjust this value at runtime, for example you can provide a header with the value. At runtime Camel evaluates the expression and converts the result to a java.lang.Long type. In the example below we use a header from the message to determine the maximum requests per period. If the header is absent, then the Throttler uses the old value. So that allows you to only provide a header if the value is to be changed:


    "direct:expressionHeader"/>
    "500">
        
        
throttleValue
"mock:result"/>

Asynchronous delaying

Available as of Camel 2.4

You can let the Throttler use non blocking asynchronous delaying, which means Camel will use a scheduler to schedule a task to be executed in the future. The task will then continue routing. This allows the caller thread to not block and be able to service other messages etc.

from("seda:a").throttle(100).asyncDelayed().to("seda:b");

Using This Pattern

If 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.

Sampling Throttler

Available as of Camel 2.1

A sampling throttler allows you to extract a sample of the exchanges from the traffic through a route.
It is configured with a sampling period during which only a single exchange is allowed to pass through. All other exchanges will be stopped.

Will by default use a sample period of 1 seconds.

Options

Name Default Value Description
messageFrequency   Samples the message every N'th message. You can only use either frequency or period.
samplePeriod 1 Samples the message every N'th period. You can only use either frequency or period.
units SECOND Time unit as an enum of java.util.concurrent.TimeUnit from the JDK.

Samples

You use this EIP with the sample DSL as show in these samples.

Using the Fluent Builders
These samples also show how you can use the different syntax to configure the sampling period:

from("direct:sample")
    .sample()
    .to("mock:result");

from("direct:sample-configured")
    .sample(1, TimeUnit.SECONDS)
    .to("mock:result");

from("direct:sample-configured-via-dsl")
    .sample().samplePeriod(1).timeUnits(TimeUnit.SECONDS)
    .to("mock:result");

from("direct:sample-messageFrequency")
    .sample(10)
    .to("mock:result");

from("direct:sample-messageFrequency-via-dsl")
    .sample().sampleMessageFrequency(5)
    .to("mock:result");

Using the Spring XML Extensions
And the same example in Spring XML is:


    "direct:sample"/>
    "1" units="seconds">
        "mock:result"/>
    
            

	"direct:sample-messageFrequency"/>
    "10">
        "mock:result"/>
    


    "direct:sample-messageFrequency-via-dsl"/>
    "5">
        "mock:result"/>
    

And since it uses a default of 1 second you can omit this configuration in case you also want to use 1 second


    "direct:sample"/>
    
    
        "mock:result"/>
    

Using This Pattern

If 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.

See Also

  • Throttler
  • Aggregator

Delayer

The Delayer Pattern allows you to delay the delivery of messages to some destination.

The Delayer in Camel 1.x works a bit differently than Camel 2.0 onwards.

In Camel 1.x the expression is used to calculate an absolute time in millis.
So if you want to wait 3 sec from now and want to use the expression for that you have to set the absolute time as currentTimeInMillis() + 3000.

In Camel 2.0 the expression is a value in millis to wait from the current time, so the expression should just be 3000.
However in both Camel 1.x and 2.0 you can use a long value for a fixed value to indicate the delay in millis.
See the Spring DSL samples for Delayer in Camel 1.x vs. Camel 2.0.

Using Delayer in Java DSL
See this ticket: https://issues.apache.org/jira/browse/CAMEL-2654

Options

Name Default Value Description
asyncDelayed false Camel 2.4: If enabled then delayed messages happens asynchronously using a scheduled thread pool.
executorServiceRef   Camel 2.4: Refers to a custom Thread Pool to be used if asyncDelay has been enabled.
callerRunsWhenRejected true Camel 2.4: Is used if asyncDelayed was enabled. This controls if the caller thread should execute the task if the thread pool rejected the task.

Using the Fluent Builders

from("seda:b").delay(1000).to("mock:result");

So the above example will delay all messages received on seda:b 1 second before sending them to mock:result.

You can of course use many different Expression languages such as XPath, XQuery, SQL or various Scripting Languages. You can just delay things a fixed amount of time from the point at which the delayer receives the message. For example to delay things 2 seconds

delayer(2000)

The above assume that the delivery order is maintained and that the messages are delivered in delay order. If you want to reorder the messages based on delivery time, you can use the Resequencer with this pattern. For example

from("activemq:someQueue").resequencer(header("MyDeliveryTime")).delay("MyRedeliveryTime").to("activemq:aDelayedQueue");

Camel 2.0 - Spring DSL

The sample below demonstrates the delay in Spring DSL:

"myDelayBean" class="org.apache.camel.processor.MyDelayCalcBean"/>

"http://camel.apache.org/schema/spring">
    
        "seda:a"/>
        
            
MyDelay
"mock:result"/> "seda:b"/> 1000 "mock:result"/> "seda:c"/> "myDelayBean" method="delayMe"/> "mock:result"/>

Camel 1.x - Spring DSL

The delayer is using slightly different names in Camel 1.x:


  3000
  

The empty tag is needed to fulfill the XSD validation as its an optional element and we use JAXB annotations to generated the XSD in Camel and some combinations is hard to auto generate with optional elements.

For further examples of this pattern in use you could look at the junit test case

Asynchronous delaying

Available as of Camel 2.4

You can let the Delayer use non blocking asynchronous delaying, which means Camel will use a scheduler to schedule a task to be executed in the future. The task will then continue routing. This allows the caller thread to not block and be able to service other messages etc.

From Java DSL

You use the asyncDelayed() to enable the async behavior.

from("activemq:queue:foo").delay(1000).asyncDelayed().to("activemq:aDelayedQueue");

From Spring XML

You use the asyncDelayed="true" attribute to enable the async behavior.


   "activemq:queue:foo"/>
   "true">
       1000
   
   "activemq:aDealyedQueue"/>

Creating a custom delay

You can use an expression to determine when to send a message using something like this

from("activemq:foo").
  delay().method("someBean", "computeDelay").
  to("activemq:bar");

then the bean would look like this...

public class SomeBean {
  public long computeDelay() { 
     long delay = 0;
     // use java code to compute a delay value in millis
     return delay;
 }
}

Using This Pattern

If 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.

See Also

  • Delay Interceptor

Load Balancer

The Load Balancer Pattern allows you to delegate to one of a number of endpoints using a variety of different load balancing policies.

Built-in load balancing policies

Camel provides the following policies out-of-the-box:

Policy Description
Round Robin The exchanges are selected from in a round robin fashion. This is a well known and classic policy, which spreads the load evenly.
Random A random endpoint is selected for each exchange.
Sticky Sticky load balancing using an Expression to calculate a correlation key to perform the sticky load balancing; rather like jsessionid in the web or JMSXGroupID in JMS.
Topic Topic which sends to all destinations (rather like JMS Topics)
Failover Camel 2.0: In case of failures the exchange will be tried on the next endpoint.
Weighted Round-Robin Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to the others. In addition to the weight, endpoint selection is then further refined using round-robin distribution based on weight.
Weighted Random Camel 2.5: The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others.In addition to the weight, endpoint selection is then further refined using random distribution based on weight.
Custom Camel 2.8: From Camel 2.8 onwards the preferred way of using a custom Load Balancer is to use this policy, instead of using the @deprecated ref attribute.
Load balancing HTTP endpoints
If you are proxying and load balancing HTTP, then see this page for more details.

Round Robin

The round robin load balancer is not meant to work with failover, for that you should use the dedicated failover load balancer. The round robin load balancer will only change to next endpoint per message.

The round robin load balancer is stateful as it keeps state of which endpoint to use next time.

Using the Fluent Builders

from("direct:start").loadBalance().
roundRobin().to("mock:x", "mock:y", "mock:z");

Using the Spring configuration

"camel" xmlns="http://camel.apache.org/schema/spring">
  
    "direct:start"/>
            
        
        "mock:x"/>        
        "mock:y"/>       
        "mock:z"/>                 
    
  

The above example loads balance requests from direct:start to one of the available mock endpoint instances, in this case using a round robin policy.
For further examples of this pattern look at this junit test case

Failover

Available as of Camel 2.0
The failover load balancer is capable of trying the next processor in case an Exchange failed with an exception during processing.
You can constrain the failover to activate only when one exception of a list you specify occurs. If you do not specify a list any exception will cause fail over to occur. This balancer uses the same strategy for matching exceptions as the Exception Clause does for the onException.

Enable stream caching if using streams
If you use streaming then you should enable Stream caching when using the failover load balancer. This is needed so the stream can be re-read after failing over to the next processor.

Failover offers the following options:

Option Type Default Description
inheritErrorHandler boolean true Camel 2.3: Whether or not the Error Handler configured on the route should be used. Disable this if you want failover to transfer immediately to the next endpoint. On the other hand, if you have this option enabled, then Camel will first let the Error Handler try to process the message. The Error Handler may have been configured to redeliver and use delays between attempts. If you have enabled a number of redeliveries then Camel will try to redeliver to the same endpoint, and only fail over to the next endpoint, when the Error Handler is exhausted.
maximumFailoverAttempts int -1 Camel 2.3: A value to indicate after X failover attempts we should exhaust (give up). Use -1 to indicate never give up and continuously try to failover. Use 0 to never failover. And use e.g. 3 to failover at most 3 times before giving up. This option can be used whether or not roundRobin is enabled or not.
roundRobin boolean false Camel 2.3: Whether or not the failover load balancer should operate in round robin mode or not. If not, then it will always start from the first endpoint when a new message is to be processed. In other words it restart from the top for every message. If round robin is enabled, then it keeps state and will continue with the next endpoint in a round robin fashion. When using round robin it will not stick to last known good endpoint, it will always pick the next endpoint to use.

Camel 2.2 or older behavior
The current implementation of failover load balancer uses simple logic which always tries the first endpoint, and in case of an exception being thrown it tries the next in the list, and so forth. It has no state, and the next message will thus always start with the first endpoint.

Camel 2.3 onwards behavior
The failover load balancer now supports round robin mode, which allows you to failover in a round robin fashion. See the roundRobin option.

Redelivery must be enabled
In Camel 2.2 or older the failover load balancer requires you have enabled Camel Error Handler to use redelivery. In Camel 2.3 onwards this is not required as such, as you can mix and match. See the inheritErrorHandler option.

Here is a sample to failover only if a IOException related exception was thrown:

from("direct:start")
    // here we will load balance if IOException was thrown
    // any other kind of exception will result in the Exchange as failed
    // to failover over any kind of exception we can just omit the exception
    // in the failOver DSL
    .loadBalance().failover(IOException.class)
        .to("direct:x", "direct:y", "direct:z");

You can specify multiple exceptions to failover as the option is varargs, for instance:

// enable redelivery so failover can react
errorHandler(defaultErrorHandler().maximumRedeliveries(5));

from("direct:foo").
    loadBalance().failover(IOException.class, MyOtherException.class)
        .to("direct:a", "direct:b");

Using failover in Spring DSL

Failover can also be used from Spring DSL and you configure it as:

   "myErrorHandler">
      "direct:foo"/>
      
          
              java.io.IOException
              com.mycompany.MyOtherException
          
          "direct:a"/>
          "direct:b"/>
      
    

Using failover in round robin mode

An example using Java DSL:

from("direct:start")
    // Use failover load balancer in stateful round robin mode
    // which mean it will failover immediately in case of an exception
    // as it does NOT inherit error handler. It will also keep retrying as
    // its configured to newer exhaust.
    .loadBalance().failover(-1, false, true).
        to("direct:bad", "direct:bad2", "direct:good", "direct:good2");

And the same example using Spring XML:


    "direct:start"/>
    
        
        "true"/>
        "direct:bad"/>
        "direct:bad2"/>
        "direct:good"/>
        "direct:good2"/>
    

Disabled inheritErrorHandler
You can configure inheritErrorHandler=false if you want to failover to the next endpoint as fast as possible. By disabling the Error Handler you ensure it does not intervene which allows the failover load balancer to handle failover asap. By also enabling roundRobin mode, then it will keep retrying until it success. You can then configure the maximumFailoverAttempts option to a high value to let it eventually exhaust (give up) and fail.

Weighted Round-Robin and Random Load Balancing

Available as of Camel 2.5

In many enterprise environments where server nodes of unequal processing power & performance characteristics are utilized to host services and processing endpoints, it is frequently necessary to distribute processing load based on their individual server capabilities so that some endpoints are not unfairly burdened with requests. Obviously simple round-robin or random load balancing do not alleviate problems of this nature. A Weighted Round-Robin and/or Weighted Random load balancer can be used to address this problem.

The weighted load balancing policy allows you to specify a processing load distribution ratio for each server with respect to others. You can specify this as a positive processing weight for each server. A larger number indicates that the server can handle a larger load. The weight is utilized to determine the payload distribution ratio to different processing endpoints with respect to others.

Disabled inheritErrorHandler
As of Camel 2.6, the Weighted Load balancer usage has been further simplified, there is no need to send in distributionRatio as a List. It can be simply sent as a delimited String of integer weights separated by a delimiter of choice.

The parameters that can be used are

In Camel 2.5

Option Type Default Description
roundRobin boolean false The default value for round-robin is false. In the absence of this setting or parameter the load balancing algorithm used is random.
distributionRatio List none The distributionRatio is a list consisting on integer weights passed in as a parameter. The distributionRatio must match the number of endpoints and/or processors specified in the load balancer list. In Camel 2.5 if endpoints do not match ratios, then a best effort distribution is attempted.

Available In Camel 2.6

Option Type Default Description
roundRobin boolean false The default value for round-robin is false. In the absence of this setting or parameter the load balancing algorithm used is random.
distributionRatio String none The distributionRatio is a delimited String consisting on integer weights separated by delimiters for example "2,3,5". The distributionRatio must match the number of endpoints and/or processors specified in the load balancer list.
distributionRatioDelimiter String , The distributionRatioDelimiter is the delimiter used to specify the distributionRatio. If this attribute is not specified a default delimiter "," is expected as the delimiter used for specifying the distributionRatio.

Using Weighted round-robin & random load balancing

In Camel 2.5

An example using Java DSL:

ArrayList distributionRatio = new ArrayList();
distributionRatio.add(4);
distributionRatio.add(2);
distributionRatio.add(1);

// round-robin
from("direct:start")
    .loadBalance().weighted(true, distributionRatio)
    .to("mock:x", "mock:y", "mock:z");

//random
from("direct:start")
    .loadBalance().weighted(false, distributionRatio)
    .to("mock:x", "mock:y", "mock:z");

And the same example using Spring XML:

    
      "direct:start"/>
      
        "false" distributionRatio="4 2 1"/>
          "mock:x"/>
          "mock:y"/>
          "mock:z"/>
      
    

Available In Camel 2.6

An example using Java DSL:

// round-robin
from("direct:start")
    .loadBalance().weighted(true, "4:2:1" distributionRatioDelimiter=":")
    .to("mock:x", "mock:y", "mock:z");

//random
from("direct:start")
    .loadBalance().weighted(false, "4,2,1")
    .to("mock:x", "mock:y", "mock:z");

And the same example using Spring XML:

    
      "direct:start"/>
      
        "false" distributionRatio="4-2-1" distributionRatioDelimiter="-" />
          "mock:x"/>
          "mock:y"/>
          "mock:z"/>
      
    

Custom Load Balancer

You can use a custom load balancer (eg your own implementation) also.

An example using Java DSL:

from("direct:start")
    // using our custom load balancer
    .loadBalance(new MyLoadBalancer())
    .to("mock:x", "mock:y", "mock:z");

And the same example using XML DSL:


"myBalancer" class="org.apache.camel.processor.CustomLoadBalanceTest$MyLoadBalancer"/>

"http://camel.apache.org/schema/spring">
  
    "direct:start"/>
    
      
      "myBalancer"/>
      
      "mock:x"/>
      "mock:y"/>
      "mock:z"/>
    
  

Notice in the XML DSL above we use which is only available in Camel 2.8 onwards. In older releases you would have to do as follows instead:

      "myBalancer">
        
        "mock:x"/>
        "mock:y"/>
        "mock:z"/>
      

To implement a custom load balancer you can extend some support classes such as LoadBalancerSupport and SimpleLoadBalancerSupport. The former supports the asynchronous routing engine, and the latter does not. Here is an example:

Custom load balancer implementation
public static class MyLoadBalancer extends LoadBalancerSupport {

    public boolean process(Exchange exchange, AsyncCallback callback) {
        String body = exchange.getIn().getBody(String.class);
        try {
            if ("x".equals(body)) {
                getProcessors().get(0).process(exchange);
            } else if ("y".equals(body)) {
                getProcessors().get(1).process(exchange);
            } else {
                getProcessors().get(2).process(exchange);
            }
        } catch (Throwable e) {
            exchange.setException(e);
        }
        callback.done(true);
        return true;
    }
}

Using This Pattern

If 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.

Multicast

The Multicast allows to route the same message to a number of endpoints and process them in a different way. The main difference between the Multicast and Splitter is that Splitter will split the message into several pieces but the Multicast will not modify the request message.

Options

Name Default Value Description
strategyRef   Refers to an AggregationStrategy to be used to assemble the replies from the multicasts, into a single outgoing message from the Multicast. By default Camel will use the last reply as the outgoing message.
parallelProcessing false If enables then sending messages to the multicasts occurs concurrently. Note the caller thread will still wait until all messages has been fully processed, before it continues. Its only the sending and processing the replies from the multicasts which happens concurrently.
executorServiceRef   Refers to a custom Thread Pool to be used for parallel processing. Notice if you set this option, then parallel processing is automatic implied, and you do not have to enable that option as well.
stopOnException false Camel 2.2: Whether or not to stop continue processing immediately when an exception occurred. If disable, then Camel will send the message to all multicasts regardless if one of them failed. You can deal with exceptions in the AggregationStrategy class where you have full control how to handle that.
streaming false If enabled then Camel will process replies out-of-order, eg in the order they come back. If disabled, Camel will process replies in the same order as multicasted.
timeout   Camel 2.5: Sets a total timeout specified in millis. If the Multicast hasn't been able to send and process all replies within the given timeframe, then the timeout triggers and the Multicast breaks out and continues. Notice if you provide a TimeoutAwareAggregationStrategy then the timeout method is invoked before breaking out.
onPrepareRef   Camel 2.8: Refers to a custom Processor to prepare the copy of the Exchange each multicast will receive. This allows you to do any custom logic, such as deep-cloning the message payload if that's needed etc.
shareUnitOfWork false Camel 2.8: Whether the unit of work should be shared. See the same option on Splitter for more details.

Example

The following example shows how to take a request from the direct:a endpoint , then multicast these request to direct:x, direct:y, direct:z.

Using the Fluent Builders

from("direct:a").multicast().to("direct:x", "direct:y", "direct:z");

By default Multicast invokes each endpoint sequentially. If parallel processing is desired, simply use

from("direct:a").multicast().parallelProcessing().to("direct:x", "direct:y", "direct:z");

In case of using InOut MEP, an AggregationStrategy is used for aggregating all reply messages. The default is to only use the latest reply message and discard any earlier replies. The aggregation strategy is configurable:

from("direct:start")
  .multicast(new MyAggregationStrategy())
  .parallelProcessing().timeout(500).to("direct:a", "direct:b", "direct:c")
  .end()
  .to("mock:result");

Stop processing in case of exception

Available as of Camel 2.1

The Multicast will by default continue to process the entire Exchange even in case one of the multicasted messages will thrown an exception during routing.
For example if you want to multicast to 3 destinations and the 2nd destination fails by an exception. What Camel does by default is to process the remainder destinations. You have the chance to remedy or handle this in the AggregationStrategy.

But sometimes you just want Camel to stop and let the exception be propagated back, and let the Camel error handler handle it. You can do this in Camel 2.1 by specifying that it should stop in case of an exception occurred. This is done by the stopOnException option as shown below:

    from("direct:start")
        .multicast()
            .stopOnException().to("direct:foo", "direct:bar", "direct:baz")
        .end()
        .to("mock:result");

        from("direct:foo").to("mock:foo");

        from("direct:bar").process(new MyProcessor()).to("mock:bar");

        from("direct:baz").to("mock:baz");

And using XML DSL you specify it as follows:

        
            "direct:start"/>
            "true">
                "direct:foo"/>
                "direct:bar"/>
                "direct:baz"/>
            
            "mock:result"/>
        

        
            "direct:foo"/>
            "mock:foo"/>
        

        
            "direct:bar"/>
            "myProcessor"/>
            "mock:bar"/>
        

        
            "direct:baz"/>
            "mock:baz"/>
        

Using onPrepare to execute custom logic when preparing messages

Available as of Camel 2.8

The Multicast will copy the source Exchange and multicast each copy. However the copy is a shallow copy, so in case you have mutateable message bodies, then any changes will be visible by the other copied messages. If you want to use a deep clone copy then you need to use a custom onPrepare which allows you to do this using the Processor interface.

Notice the onPrepare can be used for any kind of custom logic which you would like to execute before the Exchange is being multicasted.

Design for immutable
Its best practice to design for immutable objects.

For example if you have a mutable message body as this Animal class:

Animal
public class Animal implements Serializable {
    private static final long serialVersionUID = 1L;
    private int id;
    private String name;

    public Animal() {
    }

    public Animal(int id, String name) {
        this.id = id;
        this.name = name;
    }

    public Animal deepClone() {
        Animal clone = new Animal();
        clone.setId(getId());
        clone.setName(getName());
        return clone;
    }

    public int getId() {
        return id;
    }

    public void setId(int id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public String toString() {
        return id + " " + name;
    }
}

Then we can create a deep clone processor which clones the message body:

AnimalDeepClonePrepare
public class AnimalDeepClonePrepare implements Processor {

    public void process(Exchange exchange) throws Exception {
        Animal body = exchange.getIn().getBody(Animal.class);

        // do a deep clone of the body which wont affect when doing multicasting
        Animal clone = body.deepClone();
        exchange.getIn().setBody(clone);
    }
}

Then we can use the AnimalDeepClonePrepare class in the Multicast route using the onPrepare option as shown:

Multicast using onPrepare
from("direct:start")
    .multicast().onPrepare(new AnimalDeepClonePrepare()).to("direct:a").to("direct:b");

And the same example in XML DSL

Multicast using onPrepare
"http://camel.apache.org/schema/spring">
    
        "direct:start"/>
        
        "animalDeepClonePrepare">
            "direct:a"/>
            "direct:b"/>
        
    

    
        "direct:a"/>
        "processorA"/>
        "mock:a"/>
    
    
        "direct:b"/>
        "processorB"/>
        "mock:b"/>
    



"animalDeepClonePrepare" class="org.apache.camel.processor.AnimalDeepClonePrepare"/>


"processorA" class="org.apache.camel.processor.MulticastOnPrepareTest$ProcessorA"/>
"processorB" class="org.apache.camel.processor.MulticastOnPrepareTest$ProcessorB"/>

Notice the onPrepare option is also available on other EIPs such as Splitter, Recipient List, and Wire Tap.

Using This Pattern

If 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.

Loop

The Loop allows for processing a message a number of times, possibly in a different way for each iteration. Useful mostly during testing.

Default mode
Notice by default the loop uses the same exchange throughout the looping. So the result from the previous iteration will be used for the next (eg Pipes and Filters). From Camel 2.8 onwards you can enable copy mode instead. See the options table for more details.

Options

Name Default Value Description
copy false Camel 2.8: Whether or not copy mode is used. If false then the same Exchange will be used for each iteration. So the result from the previous iteration will be visible for the next iteration. Instead you can enable copy mode, and then each iteration restarts with a fresh copy of the input Exchange.

Exchange properties

For each iteration two properties are set on the Exchange. Processors can rely on these properties to process the Message in different ways.

Property Description
CamelLoopSize Total number of loops
CamelLoopIndex Index of the current iteration (0 based)

Examples

The following example shows how to take a request from the direct:x endpoint, then send the message repetitively to mock:result. The number of times the message is sent is either passed as an argument to loop(), or determined at runtime by evaluating an expression. The expression must evaluate to an int, otherwise a RuntimeCamelException is thrown.

Using the Fluent Builders

Pass loop count as an argument

from("direct:a").loop(8).to("mock:result");

Use expression to determine loop count

from("direct:b").loop(header("loop")).to("mock:result");

Use expression to determine loop count

from("direct:c").loop().xpath("/hello/@times").to("mock:result");

Using the Spring XML Extensions

Pass loop count as an argument


  "direct:a"/>
  
    8
    "mock:result"/>
  

Use expression to determine loop count


  "direct:b"/>
  
    
loop
"mock:result"/>

For further examples of this pattern in use you could look at one of the junit test case

Using copy mode

Available as of Camel 2.8

Now suppose we send a message to "direct:start" endpoint containing the letter A.
The output of processing this route will be that, each "mock:loop" endpoint will receive "AB" as message.

from("direct:start")
    // instruct loop to use copy mode, which mean it will use a copy of the input exchange
    // for each loop iteration, instead of keep using the same exchange all over
    .loop(3).copy()
        .transform(body().append("B"))
        .to("mock:loop")
    .end()
    .to("mock:result");

However if we do not enable copy mode then "mock:loop" will receive "AB", "ABB", "ABBB", etc. messages.

from("direct:start")
    // by default loop will keep using the same exchange so on the 2nd and 3rd iteration its
    // the same exchange that was previous used that are being looped all over
    .loop(3)
        .transform(body().append("B"))
        .to("mock:loop")
    .end()
    .to("mock:result");

The equivalent example in XML DSL in copy mode is as follows:


  "direct:start"/>
  
  "true">
    3
    
      ${body}B
    
    "mock:loop"/>
  
  "mock:result"/>

Using This Pattern

If 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.

Message Transformation

Content Enricher

Camel supports the Content Enricher from the EIP patterns using a Message Translator, an arbitrary Processor in the routing logic or using the enrich DSL element to enrich the message.

Enterprise Integration Patterns_第18张图片

Content enrichment using a Message Translator or a Processor

Using the Fluent Builders

You can use Templating to consume a message from one destination, transform it with something like Velocity or XQuery and then send it on to another destination. For example using InOnly (one way messaging)

from("activemq:My.Queue").
  to("velocity:com/acme/MyResponse.vm").
  to("activemq:Another.Queue");

If you want to use InOut (request-reply) semantics to process requests on the My.Queue queue on ActiveMQ with a template generated response, then sending responses back to the JMSReplyTo Destination you could use this:

from("activemq:My.Queue").
  to("velocity:com/acme/MyResponse.vm");

Here is a simple example using the DSL directly to transform the message body

from("direct:start").setBody(body().append(" World!")).to("mock:result");

In this example we add our own Processor using explicit Java code

from("direct:start").process(new Processor() {
    public void process(Exchange exchange) {
        Message in = exchange.getIn();
        in.setBody(in.getBody(String.class) + " World!");
    }
}).to("mock:result");

Finally we can use Bean Integration to use any Java method on any bean to act as the transformer

from("activemq:My.Queue").
  beanRef("myBeanName", "myMethodName").
  to("activemq:Another.Queue");

For further examples of this pattern in use you could look at one of the JUnit tests

  • TransformTest
  • TransformViaDSLTest

Using Spring XML


  "activemq:Input"/>
  "myBeanName" method="doTransform"/>
  "activemq:Output"/>

Content enrichment using the enrich DSL element

Camel comes with two flavors of content enricher in the DSL

  • enrich
  • pollEnrich

enrich is using a Producer to obtain the additional data. It is usually used for Request Reply messaging, for instance to invoke an external web service.
pollEnrich on the other hand is using a Polling Consumer to obtain the additional data. It is usually used for Event Message messaging, for instance to read a file or download a FTP file.

Enrich Options

Name Default Value Description
uri   The endpoint uri for the external service to enrich from. You must use either uri or ref.
ref   Refers to the endpoint for the external service to enrich from. You must use either uri or ref.
strategyRef   Refers to an AggregationStrategy to be used to merge the reply from the external service, into a single outgoing message. By default Camel will use the reply from the external service as outgoing message.

Using the Fluent Builders

AggregationStrategy aggregationStrategy = ...

from("direct:start")
.enrich("direct:resource", aggregationStrategy)
.to("direct:result");

from("direct:resource")
...

The content enricher (enrich) retrieves additional data from a resource endpoint in order to enrich an incoming message (contained in the original exchange). An aggregation strategy is used to combine the original exchange and the resource exchange. The first parameter of the AggregationStrategy.aggregate(Exchange, Exchange) method corresponds to the the original exchange, the second parameter the resource exchange. The results from the resource endpoint are stored in the resource exchange's out-message. Here's an example template for implementing an aggregation strategy:

public class ExampleAggregationStrategy implements AggregationStrategy {

    public Exchange aggregate(Exchange original, Exchange resource) {
        Object originalBody = original.getIn().getBody();
        Object resourceResponse = resource.getOut().getBody();
        Object mergeResult = ... // combine original body and resource response
        if (original.getPattern().isOutCapable()) {
            original.getOut().setBody(mergeResult);
        } else {
            original.getIn().setBody(mergeResult);
        }
        return original;
    }
    
}

Using this template the original exchange can be of any pattern. The resource exchange created by the enricher is always an in-out exchange.

Using Spring XML

The same example in the Spring DSL

"camel" xmlns="http://camel.apache.org/schema/spring">
  
    "direct:start"/>
    "direct:resource" strategyRef="aggregationStrategy"/>
    "direct:result"/>
  
  
    "direct:resource"/>
    ...
  


"aggregationStrategy" class="..." />

Aggregation strategy is optional

The aggregation strategy is optional. If you do not provide it Camel will by default just use the body obtained from the resource.

from("direct:start")
  .enrich("direct:resource")
  .to("direct:result");

In the route above the message sent to the direct:result endpoint will contain the output from the direct:resource as we do not use any custom aggregation.

And for Spring DSL just omit the strategyRef attribute:

  
    "direct:start"/>
    "direct:resource"/>
    "direct:result"/>
  

Content enrichment using pollEnrich

The pollEnrich works just as the enrich however as it uses a Polling Consumer we have 3 methods when polling

  • receive
  • receiveNoWait
  • receive(timeout)

PollEnrich Options

Name Default Value Description
uri   The endpoint uri for the external service to enrich from. You must use either uri or ref.
ref   Refers to the endpoint for the external service to enrich from. You must use either uri or ref.
strategyRef   Refers to an AggregationStrategy to be used to merge the reply from the external service, into a single outgoing message. By default Camel will use the reply from the external service as outgoing message.
timeout 0 Timeout in millis when polling from the external service. See below for important details about the timeout.

By default Camel will use the receiveNoWait.
If there is no data then the newExchange in the aggregation strategy is null.

You can pass in a timeout value that determines which method to use

  • if timeout is -1 or other negative number then receive is selected
  • if timeout is 0 then receiveNoWait is selected
  • otherwise receive(timeout) is selected

The timeout values is in millis.

Data from current Exchange not used
pollEnrich does not access any data from the current Exchange which means when polling it cannot use any of the existing headers you may have set on the Exchange. For example you cannot set a filename in the Exchange.FILE_NAME header and use pollEnrich to consume only that file. For that you must set the filename in the endpoint URI.

Example

In this example we enrich the message by loading the content from the file named inbox/data.txt.

from("direct:start")
  .pollEnrich("file:inbox?fileName=data.txt")
  .to("direct:result");

And in XML DSL you do:

  
    "direct:start"/>
    "file:inbox?fileName=data.txt"/>
    "direct:result"/>
  

If there is no file then the message is empty. We can use a timeout to either wait (potentially forever) until a file exists, or use a timeout to wait a certain period.

For example to wait up to 5 seconds you can do:

  
    "direct:start"/>
    "file:inbox?fileName=data.txt" timeout="5000"/>
    "direct:result"/>
  

Using This Pattern

If 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.

Content Filter

Camel supports the Content Filter from the EIP patterns using one of the following mechanisms in the routing logic to transform content from the inbound message.

  • Message Translator
  • invoking a Java bean
  • Processor object

A common way to filter messages is to use an Expression in the DSL like XQuery, SQL or one of the supported Scripting Languages.

Using the Fluent Builders

Here is a simple example using the DSL directly

from("direct:start").setBody(body().append(" World!")).to("mock:result");

In this example we add our own Processor

from("direct:start").process(new Processor() {
    public void process(Exchange exchange) {
        Message in = exchange.getIn();
        in.setBody(in.getBody(String.class) + " World!");
    }
}).to("mock:result");

For further examples of this pattern in use you could look at one of the JUnit tests

  • TransformTest
  • TransformViaDSLTest

Using Spring XML


  "activemq:Input"/>
  "myBeanName" method="doTransform"/>
  "activemq:Output"/>

You can also use XPath to filter out part of the message you are interested in:


  "activemq:Input"/>
  "org.w3c.dom.Document">//foo:bar
  "activemq:Output"/>
 

Using This Pattern

If 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.

Claim Check

The Claim Check from the EIP patterns allows you to replace message content with a claim check (a unique key), which can be used to retrieve the message content at a later time. The message content is stored temporarily in a persistent store like a database or file system. This pattern is very useful when message content is very large (thus it would be expensive to send around) and not all components require all information.

It can also be useful in situations where you cannot trust the information with an outside party; in this case, you can use the Claim Check to hide the sensitive portions of data.

Enterprise Integration Patterns_第19张图片

Available in Camel 1.5.

Example

In this example we want to replace a message body with a claim check, and restore the body at a later step.

Using the Fluent Builders

from("direct:start").to("bean:checkLuggage", "mock:testCheckpoint", "bean:dataEnricher", "mock:result");

Using the Spring XML Extensions


    "direct:start"/>
    
        "bean:checkLuggage"/>
        "mock:testCheckpoint"/>
        "bean:dataEnricher"/>
        "mock:result"/>
    


The example route is pretty simple - its just a Pipeline. In a real application you would have some other steps where the mock:testCheckpoint endpoint is in the example.

The message is first sent to the checkLuggage bean which looks like

public static final class CheckLuggageBean {        
    public void checkLuggage(Exchange exchange, @Body String body, @XPath("/order/@custId") String custId) {   
        // store the message body into the data store, using the custId as the claim check
        dataStore.put(custId, body);
        // add the claim check as a header
        exchange.getIn().setHeader("claimCheck", custId);
        // remove the body from the message
        exchange.getIn().setBody(null);
    }
}    

This bean stores the message body into the data store, using the custId as the claim check. In this example, we're just using a HashMap to store the message body; in a real application you would use a database or file system, etc. Next the claim check is added as a message header for use later. Finally we remove the body from the message and pass it down the pipeline.

The next step in the pipeline is the mock:testCheckpoint endpoint which is just used to check that the message body is removed, claim check added, etc.

To add the message body back into the message, we use the dataEnricher bean which looks like

public static final class DataEnricherBean {
    public void addDataBackIn(Exchange exchange, @Header("claimCheck") String claimCheck) { 
        // query the data store using the claim check as the key and add the data
        // back into the message body
        exchange.getIn().setBody(dataStore.get(claimCheck));
        // remove the message data from the data store
        dataStore.remove(claimCheck);
        // remove the claim check header
        exchange.getIn().removeHeader("claimCheck");
    }
}    

This bean queries the data store using the claim check as the key and then adds the data back into the message. The message body is then removed from the data store and finally the claim check is removed. Now the message is back to what we started with!

For full details, check the example source here:

camel-core/src/test/java/org/apache/camel/processor/ClaimCheckTest.java

Using This Pattern

If 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.

Normalizer

Camel supports the Normalizer from the EIP patterns by using a Message Router in front of a number of Message Translator instances.

Enterprise Integration Patterns_第20张图片

Example

This example shows a Message Normalizer that converts two types of XML messages into a common format. Messages in this common format are then filtered.

Using the Fluent Builders

// we need to normalize two types of incoming messages
from("direct:start")
    .choice()
        .when().xpath("/employee").to("bean:normalizer?method=employeeToPerson")
        .when().xpath("/customer").to("bean:normalizer?method=customerToPerson")
    .end()
    .to("mock:result");

In this case we're using a Java bean as the normalizer. The class looks like this

public class MyNormalizer {
    public void employeeToPerson(Exchange exchange, @XPath("/employee/name/text()") String name) {
        exchange.getOut().setBody(createPerson(name));            
    }

    public void customerToPerson(Exchange exchange, @XPath("/customer/@name") String name) {
        exchange.getOut().setBody(createPerson(name));
    }        
    
    private String createPerson(String name) {
        return "" + name + "\"/>";
    }
}    

Using the Spring XML Extensions

The same example in the Spring DSL

"http://camel.apache.org/schema/spring">
  
    "direct:start"/>
    
      
        /employee
        "bean:normalizer?method=employeeToPerson"/>
      
      
        /customer
        "bean:normalizer?method=customerToPerson"/>
      
    
    "mock:result"/>
   


"normalizer" class="org.apache.camel.processor.MyNormalizer"/>

See Also

  • Message Router
  • Content Based Router
  • Message Translator

Using This Pattern

If 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.

Sort

Available as of Camel 2.0

Sort can be used to sort a message. Imagine you consume text files and before processing each file you want to be sure the content is sorted.

Sort will by default sort the body using a default comparator that handles numeric values or uses the string representation. You can provide your own comparator, and even an expression to return the value to be sorted. Sort requires the value returned from the expression evaluation is convertible to java.util.List as this is required by the JDK sort operation.

Options

Name Default Value Description
comparatorRef   Refers to a custom java.util.Comparator to use for sorting the message body. Camel will by default use a comparator which does a A..Z sorting.

Using from Java DSL

In the route below it will read the file content and tokenize by line breaks so each line can be sorted.

from("file://inbox").sort(body().tokenize("\n")).to("bean:MyServiceBean.processLine");

You can pass in your own comparator as a 2nd argument:

from("file://inbox").sort(body().tokenize("\n"), new MyReverseComparator()).to("bean:MyServiceBean.processLine");

Using from Spring DSL

In the route below it will read the file content and tokenize by line breaks so each line can be sorted.

Camel 2.7 or better

  "file://inbox"/>
  
    body
  
  "myServiceBean" method="processLine"/>

Camel 2.6 or older

  "file://inbox"/>
  
    
      body
    
  
  "myServiceBean" method="processLine"/>

And to use our own comparator we can refer to it as a spring bean:

Camel 2.7 or better

  "file://inbox"/>
  "myReverseComparator">
    body
  
  "MyServiceBean" method="processLine"/>


"myReverseComparator" class="com.mycompany.MyReverseComparator"/>
Camel 2.6 or older

  "file://inbox"/>
  "myReverseComparator">
    
      body
    
  
  "MyServiceBean" method="processLine"/>


"myReverseComparator" class="com.mycompany.MyReverseComparator"/>

Besides , you can supply an expression using any language you like, so long as it returns a list.

Using This Pattern

If 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.

Messaging Endpoints

Messaging Mapper

Camel supports the Messaging Mapper from the EIP patterns by using either Message Translator pattern or the Type Converter module.

Enterprise Integration Patterns_第21张图片

See also

  • Message Translator
  • Type Converter
  • CXF for JAX-WS support for binding business logic to messaging & web services
  • Pojo
  • Bean

Using This Pattern

If 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.

Event Driven Consumer

Camel supports the Event Driven Consumer from the EIP patterns. The default consumer model is event based (i.e. asynchronous) as this means that the Camel container can then manage pooling, threading and concurrency for you in a declarative manner.

Enterprise Integration Patterns_第22张图片

The Event Driven Consumer is implemented by consumers implementing the Processor interface which is invoked by the Message Endpoint when a Message is available for processing.

For more details see

  • Message
  • Message Endpoint

Using This Pattern

If 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.

Polling Consumer

Camel supports implementing the Polling Consumer from the EIP patterns using the PollingConsumer interface which can be created via the Endpoint.createPollingConsumer() method.

Enterprise Integration Patterns_第23张图片

So in your Java code you can do

Endpoint endpoint = context.getEndpoint("activemq:my.queue");
PollingConsumer consumer = endpoint.createPollingConsumer();
Exchange exchange = consumer.receive();

The ConsumerTemplate (discussed below) is also available.

There are 3 main polling methods on PollingConsumer

Method name Description
receive() Waits until a message is available and then returns it; potentially blocking forever
receive(long) Attempts to receive a message exchange, waiting up to the given timeout and returning null if no message exchange could be received within the time available
receiveNoWait() Attempts to receive a message exchange immediately without waiting and returning null if a message exchange is not available yet

ConsumerTemplate

The ConsumerTemplate is a template much like Spring's JmsTemplate or JdbcTemplate supporting the Polling Consumer EIP. With the template you can consume Exchanges from an Endpoint.

The template supports the 3 operations above, but also including convenient methods for returning the body, etc consumeBody.
The example from above using ConsumerTemplate is:

Exchange exchange = consumerTemplate.receive("activemq:my.queue");

Or to extract and get the body you can do:

Object body = consumerTemplate.receiveBody("activemq:my.queue");

And you can provide the body type as a parameter and have it returned as the type:

String body = consumerTemplate.receiveBody("activemq:my.queue", String.class);

You get hold of a ConsumerTemplate from the CamelContext with the createConsumerTemplate operation:

ConsumerTemplate consumer = context.createConsumerTemplate();

Using ConsumerTemplate with Spring DSL

With the Spring DSL we can declare the consumer in the CamelContext with the consumerTemplate tag, just like the ProducerTemplate. The example below illustrates this:

"http://camel.apache.org/schema/spring">