Chapter 1. Building Blocks for Route Definitions


Apache Camel supports two alternative Domain Specific Languages (DSL) for defining routes: a Java DSL and a Spring XML DSL. The basic building blocks for defining routes are endpoints and processors, where the behavior of a processor is typically modified by expressions or logical predicates. Apache Camel enables you to define expressions and predicates using a variety of different languages.

1.1. Implementing a RouteBuilder Class


To use the Domain Specific Language (DSL), you extend the RouteBuilder class and override its configure() method (where you define your routing rules).

You can define as many RouteBuilder classes as necessary. Each class is instantiated once and is registered with the CamelContext object. Normally, the lifecycle of each RouteBuilder object is managed automatically by the container in which you deploy the router.

RouteBuilder classes

As a router developer, your core task is to implement one or more RouteBuilder classes. There are two alternative RouteBuilder classes that you can inherit from:

  • org.apache.camel.builder.RouteBuilder — this is the generic RouteBuilder base class that is suitable for deploying into any container type. It is provided in the camel-core artifact.
  • org.apache.camel.spring.SpringRouteBuilder — this base class is specially adapted to the Spring container. In particular, it provides extra support for the following Spring specific features: looking up beans in the Spring registry (using the beanRef() Java DSL command) and transactions (see the Transactions Guide for details). It is provided in the camel-spring artifact.

The RouteBuilder class defines methods used to initiate your routing rules (for example, from(), intercept(), and exception()).

Implementing a RouteBuilder

Example 1.1, “Implementation of a RouteBuilder Class” shows a minimal RouteBuilder implementation. The configure() method body contains a routing rule; each rule is a single Java statement.

Example 1.1. Implementation of a RouteBuilder Class

import org.apache.camel.builder.RouteBuilder;

public class MyRouteBuilder extends RouteBuilder {

public void configure() {
  // Define routing rules here:

  // More rules can be included, in you like.
  // ...

The form of the rule from(URL1).to(URL2) instructs the router to read files from the directory src/data and send them to the directory target/messages. The option ?noop=true instructs the router to retain (not delete) the source files in the src/data directory.


When you use the contextScan with Spring or Blueprint to filter RouteBuilder classes, by default Apache Camel will look for singleton beans. However, you can turn on the old behavior to include prototype scoped with the new option includeNonSingletons.

1.2. Basic Java DSL Syntax

What is a DSL?

A Domain Specific Language (DSL) is a mini-language designed for a special purpose. A DSL does not have to be logically complete but needs enough expressive power to describe problems adequately in the chosen domain. Typically, a DSL does not require a dedicated parser, interpreter, or compiler. A DSL can piggyback on top of an existing object-oriented host language, provided DSL constructs map cleanly to constructs in the host language API.

Consider the following sequence of commands in a hypothetical DSL:


You can map these commands to Java method invocations, as follows:


You can even map blocks to Java method invocations. For example:


The DSL syntax is implicitly defined by the data types of the host language API. For example, the return type of a Java method determines which methods you can legally invoke next (equivalent to the next command in the DSL).

Router rule syntax

Apache Camel defines a router DSL for defining routing rules. You can use this DSL to define rules in the body of a RouteBuilder.configure() implementation. Figure 1.1, “Local Routing Rules” shows an overview of the basic syntax for defining local routing rules.

Figure 1.1. Local Routing Rules

Local routing rules

A local rule always starts with a from("EndpointURL") method, which specifies the source of messages (consumer endpoint) for the routing rule. You can then add an arbitrarily long chain of processors to the rule (for example, filter()). You typically finish off the rule with a to("EndpointURL") method, which specifies the target (producer endpoint) for the messages that pass through the rule. However, it is not always necessary to end a rule with to(). There are alternative ways of specifying the message target in a rule.


You can also define a global routing rule, by starting the rule with a special processor type (such as intercept(), exception(), or errorHandler()). Global rules are outside the scope of this guide.

Consumers and producers

A local rule always starts by defining a consumer endpoint, using from("EndpointURL"), and typically (but not always) ends by defining a producer endpoint, using to("EndpointURL"). The endpoint URLs, EndpointURL, can use any of the components configured at deploy time. For example, you could use a file endpoint, file:MyMessageDirectory, an Apache CXF endpoint, cxf:MyServiceName, or an Apache ActiveMQ endpoint, activemq:queue:MyQName. For a complete list of component types, see Apache Camel Component Reference.


An exchange object consists of a message, augmented by metadata. Exchanges are of central importance in Apache Camel, because the exchange is the standard form in which messages are propagated through routing rules. The main constituents of an exchange are, as follows:

  • In message — is the current message encapsulated by the exchange. As the exchange progresses through a route, this message may be modified. So the In message at the start of a route is typically not the same as the In message at the end of the route. The org.apache.camel.Message type provides a generic model of a message, with the following parts:

    • Body.
    • Headers.
    • Attachments.

    It is important to realize that this is a generic model of a message. Apache Camel supports a large variety of protocols and endpoint types. Hence, it is not possible to standardize the format of the message body or the message headers. For example, the body of a JMS message would have a completely different format to the body of a HTTP message or a Web services message. For this reason, the body and the headers are declared to be of Object type. The original content of the body and the headers is then determined by the endpoint that created the exchange instance (that is, the endpoint appearing in the from() command).

  • Out message — is a temporary holding area for a reply message or for a transformed message. Certain processing nodes (in particular, the to() command) can modify the current message by treating the In message as a request, sending it to a producer endpoint, and then receiving a reply from that endpoint. The reply message is then inserted into the Out message slot in the exchange.

    Normally, if an Out message has been set by the current node, Apache Camel modifies the exchange as follows before passing it to the next node in the route: the old In message is discarded and the Out message is moved to the In message slot. Thus, the reply becomes the new current message. For a more detailed discussion of how Apache Camel connects nodes together in a route, see Section 2.1, “Pipeline Processing”.

    There is one special case where an Out message is treated differently, however. If the consumer endpoint at the start of a route is expecting a reply message, the Out message at the very end of the route is taken to be the consumer endpoint’s reply message (and, what is more, in this case the final node must create an Out message or the consumer endpoint would hang) .

  • Message exchange pattern (MEP) — affects the interaction between the exchange and endpoints in the route, as follows:

    • Consumer endpoint — the consumer endpoint that creates the original exchange sets the initial value of the MEP. The initial value indicates whether the consumer endpoint expects to receive a reply (for example, the InOut MEP) or not (for example, the InOnly MEP).
    • Producer endpoints — the MEP affects the producer endpoints that the exchange encounters along the route (for example, when an exchange passes through a to() node). For example, if the current MEP is InOnly, a to() node would not expect to receive a reply from the endpoint. Sometimes you need to change the current MEP in order to customize the exchange’s interaction with a producer endpoint. For more details, see Section 1.4, “Endpoints”.
  • Exchange properties — a list of named properties containing metadata for the current message.

Message exchange patterns

Using an Exchange object makes it easy to generalize message processing to different message exchange patterns. For example, an asynchronous protocol might define an MEP that consists of a single message that flows from the consumer endpoint to the producer endpoint (an InOnly MEP). An RPC protocol, on the other hand, might define an MEP that consists of a request message and a reply message (an InOut MEP). Currently, Apache Camel supports the following MEPs:

  • InOnly
  • RobustInOnly
  • InOut
  • InOptionalOut
  • OutOnly
  • RobustOutOnly
  • OutIn
  • OutOptionalIn

Where these message exchange patterns are represented by constants in the enumeration type, org.apache.camel.ExchangePattern.

Grouped exchanges

Sometimes it is useful to have a single exchange that encapsulates multiple exchange instances. For this purpose, you can use a grouped exchange. A grouped exchange is essentially an exchange instance that contains a java.util.List of Exchange objects stored in the Exchange.GROUPED_EXCHANGE exchange property. For an example of how to use grouped exchanges, see Section 8.5, “Aggregator”.


A processor is a node in a route that can access and modify the stream of exchanges passing through the route. Processors can take expression or predicate arguments, that modify their behavior. For example, the rule shown in Figure 1.1, “Local Routing Rules” includes a filter() processor that takes an xpath() predicate as its argument.

Expressions and predicates

Expressions (evaluating to strings or other data types) and predicates (evaluating to true or false) occur frequently as arguments to the built-in processor types. For example, the following filter rule propagates In messages, only if the foo header is equal to the value bar:


Where the filter is qualified by the predicate, header("foo").isEqualTo("bar"). To construct more sophisticated predicates and expressions, based on the message content, you can use one of the expression and predicate languages (see Part II, “Routing Expression and Predicate Languages”).

1.3. Router Schema in a Spring XML File


The router schema — which defines the XML DSL — belongs to the following XML schema namespace:

Specifying the schema location

The location of the router schema is normally specified to be, which references the latest version of the schema on the Apache Web site. For example, the root beans element of an Apache Camel Spring file is normally configured as shown in Example 1.2, “Specifying the Router Schema Location”.

Example 1.2. Specifying the Router Schema Location

<beans xmlns=""

  <camelContext id="camel" xmlns="">
    <!-- Define your routing rules here -->

Runtime schema location

At run time, Apache Camel does not download the router schema from schema location specified in the Spring file. Instead, Apache Camel automatically picks up a copy of the schema from the root directory of the camel-spring JAR file. This ensures that the version of the schema used to parse the Spring file always matches the current runtime version. This is important, because the latest version of the schema posted up on the Apache Web site might not match the version of the runtime you are currently using.

Using an XML editor

Generally, it is recommended that you edit your Spring files using a full-feature XML editor. An XML editor’s auto-completion features make it much easier to author XML that complies with the router schema and the editor can warn you instantly, if the XML is badly-formed.

XML editors generally do rely on downloading the schema from the location that you specify in the xsi:schemaLocation attribute. In order to be sure you are using the correct schema version whilst editing, it is usually a good idea to select a specific version of the camel-spring.xsd file. For example, to edit a Spring file for the 2.3 version of Apache Camel, you could modify the beans element as follows:

<beans xmlns=""

Change back to the default, camel-spring.xsd, when you are finished editing. To see which schema versions are currently available for download, navigate to the Web page,

1.4. Endpoints


Apache Camel endpoints are the sources and sinks of messages in a route. An endpoint is a very general sort of building block: the only requirement it must satisfy is that it acts either as a source of messages (a consumer endpoint) or as a sink of messages (a producer endpoint). Hence, there are a great variety of different endpoint types supported in Apache Camel, ranging from protocol supporting endpoints, such as HTTP, to simple timer endpoints, such as Quartz, that generate dummy messages at regular time intervals. One of the major strengths of Apache Camel is that it is relatively easy to add a custom component that implements a new endpoint type.

Endpoint URIs

Endpoints are identified by endpoint URIs, which have the following general form:


The URI scheme identifies a protocol, such as http, and the contextPath provides URI details that are interpreted by the protocol. In addition, most schemes allow you to define query options, queryOptions, which are specified in the following format:


For example, the following HTTP URI can be used to connect to the Google search engine page:

The following File URI can be used to read all of the files appearing under the C:\temp\src\data directory:


Not every scheme represents a protocol. Sometimes a scheme just provides access to a useful utility, such as a timer. For example, the following Timer endpoint URI generates an exchange every second (=1000 milliseconds). You could use this to schedule activity in a route.


Working with Long Endpoint URIs

Sometimes endpoint URIs can become quite long due to all the accompanying configuration information supplied. In JBoss Fuse 6.2 onwards, there are two approaches you can take to make your working with lengthy URIs more manageable.

Configure Endpoints Separately

You can configure the endpoint separately, and from the routes refer to the endpoints using their shorthand IDs.

<camelContext ...>

  <endpoint id="foo" uri="ftp://foo@myserver">
    <property name="password" value="secret"/>
    <property name="recursive" value="true"/>
    <property name="ftpClient.dataTimeout" value="30000"/>
    <property name="ftpClient.serverLanguageCode" value="fr"/>

    <from uri="ref:foo"/>

You can also configure some options in the URI and then use the property attribute to specify additional options (or to override options from the URI).

<endpoint id="foo" uri="ftp://foo@myserver?recursive=true">
  <property name="password" value="secret"/>
  <property name="ftpClient.dataTimeout" value="30000"/>
  <property name="ftpClient.serverLanguageCode" value="fr"/>
Split Endpoint Configuration Across New Lines

You can split URI attributes using new lines.

  <from uri="ftp://foo@myserver?password=secret&amp;
  <to uri="bean:doSomething"/>

You can specify one or more options on each line, each separated by &amp;.

Specifying time periods in a URI

Many of the Apache Camel components have options whose value is a time period (for example, for specifying timeout values and so on). By default, such time period options are normally specified as a pure number, which is interpreted as a millisecond time period. But Apache Camel also supports a more readable syntax for time periods, which enables you to express the period in hours, minutes, and seconds. Formally, the human-readable time period is a string that conforms to the following syntax:


Where each term in square brackets, [], is optional and the notation, (A|B), indicates that A and B are alternatives.

For example, you can configure timer endpoint with a 45 minute period as follows:


You can also use arbitrary combinations of the hour, minute, and second units, as follows:


Specifying raw values in URI options

By default, the option values that you specify in a URI are automatically URI-encoded. In some cases this is undesirable behavior. For example, when setting a password option, it is preferable to transmit the raw character string without URI encoding.

It is possible to switch off URI encoding by specifying an option value with the syntax, RAW(RawValue). For example,


In this example, the password value is transmitted as the literal value, se+re?t&23.

Case-insensitive enum options

Some endpoint URI options get mapped to Java enum constants. For example, the level option of the Log component, which can take the enum values, INFO, WARN, ERROR, and so on. This type conversion is case-insensitive, so any of the following alternatives could be used to set the logging level of a Log producer endpoint:

<to uri="log:foo?level=info"/>
<to uri="log:foo?level=INfo"/>
<to uri="log:foo?level=InFo"/>

Specifying URI Resources

From Camel 2.17, the resource based components such as XSLT, Velocity can load the resource file from the Registry by using ref: as prefix.

For example, ifmyvelocityscriptbean and mysimplescriptbean are the IDs of two beans in the registry, you can use the contents of these beans as follows:

Velocity endpoint:

Language endpoint (for invoking a scripting language):
 Where Camel implicitly converts the bean to a String.

Apache Camel components

Each URI scheme maps to an Apache Camel component, where an Apache Camel component is essentially an endpoint factory. In other words, to use a particular type of endpoint, you must deploy the corresponding Apache Camel component in your runtime container. For example, to use JMS endpoints, you would deploy the JMS component in your container.

Apache Camel provides a large variety of different components that enable you to integrate your application with various transport protocols and third-party products. For example, some of the more commonly used components are: File, JMS, CXF (Web services), HTTP, Jetty, Direct, and Mock. For the full list of supported components, see the Apache Camel component documentation.

Most of the Apache Camel components are packaged separately to the Camel core. If you use Maven to build your application, you can easily add a component (and its third-party dependencies) to your application simply by adding a dependency on the relevant component artifact. For example, to include the HTTP component, you would add the following Maven dependency to your project POM file:

<!-- Maven POM File -->


The following components are built-in to the Camel core (in the camel-core artifact), so they are always available:

  • Bean
  • Browse
  • Dataset
  • Direct
  • File
  • Log
  • Mock
  • Properties
  • Ref
  • SEDA
  • Timer
  • VM

Consumer endpoints

A consumer endpoint is an endpoint that appears at the start of a route (that is, in a from() DSL command). In other words, the consumer endpoint is responsible for initiating processing in a route: it creates a new exchange instance (typically, based on some message that it has received or obtained), and provides a thread to process the exchange in the rest of the route.

For example, the following JMS consumer endpoint pulls messages off the payments queue and processes them in the route:


Or equivalently, in Spring XML:

<camelContext id="CamelContextID"
    <from uri="jms:queue:payments"/>
    <process ref="someProcessorId"/>
    <to uri="TargetURI"/>

Some components are consumer only — that is, they can only be used to define consumer endpoints. For example, the Quartz component is used exclusively to define consumer endpoints. The following Quartz endpoint generates an event every second (1000 milliseconds):


If you like, you can specify the endpoint URI as a formatted string, using the fromF() Java DSL command. For example, to substitute the username and password into the URI for an FTP endpoint, you could write the route in Java, as follows:

fromF("", username, password)

Where the first occurrence of %s is replaced by the value of the username string and the second occurrence of %s is replaced by the password string. This string formatting mechanism is implemented by String.format() and is similar to the formatting provided by the C printf() function. For details, see java.util.Formatter.

Producer endpoints

A producer endpoint is an endpoint that appears in the middle or at the end of a route (for example, in a to() DSL command). In other words, the producer endpoint receives an existing exchange object and sends the contents of the exchange to the specified endpoint.

For example, the following JMS producer endpoint pushes the contents of the current exchange onto the specified JMS queue:


Or equivalently in Spring XML:

<camelContext id="CamelContextID" xmlns="">
    <from uri="SourceURI"/>
    <process ref="someProcessorId"/>
    <to uri="jms:queue:orderForms"/>

Some components are producer only — that is, they can only be used to define producer endpoints. For example, the HTTP endpoint is used exclusively to define producer endpoints.


If you like, you can specify the endpoint URI as a formatted string, using the toF() Java DSL command. For example, to substitute a custom Google query into the HTTP URI, you could write the route in Java, as follows:

  .toF("", myGoogleQuery);

Where the occurrence of %s is replaced by your custom query string, myGoogleQuery. For details, see java.util.Formatter.

1.5. Processors


To enable the router to do something more interesting than simply connecting a consumer endpoint to a producer endpoint, you can add processors to your route. A processor is a command you can insert into a routing rule to perform arbitrary processing of messages that flow through the rule. Apache Camel provides a wide variety of different processors, as shown in Table 1.1, “Apache Camel Processors”.

Table 1.1. Apache Camel Processors

Java DSLXML DSLDescription



Section 8.5, “Aggregator”: Creates an aggregator, which combines multiple incoming exchanges into a single exchange.



Use Aspect Oriented Programming (AOP) to do work before and after a specified sub-route.

bean(), beanRef()


Process the current exchange by invoking a method on a Java object (or bean). See Section 2.4, “Bean Integration”.



Section 8.1, “Content-Based Router”: Selects a particular sub-route based on the exchange content, using when and otherwise clauses.



Converts the In message body to the specified type.



Section 8.9, “Delayer”: Delays the propagation of the exchange to the latter part of the route.



Creates a try/catch block for handling exceptions, using doCatch, doFinally, and end clauses.



Ends the current command block.



Section 10.1, “Content Enricher”: Combines the current exchange with data requested from a specified producer endpoint URI.



Section 8.2, “Message Filter”: Uses a predicate expression to filter incoming exchanges.



Section 11.8, “Idempotent Consumer”: Implements a strategy to suppress duplicate messages.



Boolean option that can be used to disable the inherited error handler on a particular route node (defined as a sub-clause in the Java DSL and as an attribute in the XML DSL).



Either sets the current exchange’s MEP to InOnly (if no arguments) or sends the exchange as an InOnly to the specified endpoint(s).



Either sets the current exchange’s MEP to InOut (if no arguments) or sends the exchange as an InOut to the specified endpoint(s).



Section 8.10, “Load Balancer”: Implements load balancing over a collection of endpoints.



Logs a message to the console.



Section 8.16, “Loop”: Repeatedly resends each exchange to the latter part of the route.



(Transactions) Marks the current transaction for rollback only (no exception is raised). In the XML DSL, this option is set as a boolean attribute on the rollback element. See Apache Karaf Transaction Guide.



(Transactions) If one or more transactions have previously been associated with this thread and then suspended, this command marks the latest transaction for rollback only (no exception is raised). In the XML DSL, this option is set as a boolean attribute on the rollback element. See Apache Karaf Transaction Guide.



Transforms into a low-level or binary format using the specified data format, in preparation for sending over a particular transport protocol.



Section 8.13, “Multicast”: Multicasts the current exchange to multiple destinations, where each destination gets its own copy of the exchange.



Defines a sub-route (terminated by end() in the Java DSL) that gets executed after the main route has completed. See also Section 2.14, “OnCompletion”.



Defines a sub-route (terminated by end() in the Java DSL) that gets executed whenever the specified exception occurs. Usually defined on its own line (not in a route).



Section 5.4, “Pipes and Filters”: Sends the exchange to a series of endpoints, where the output of one endpoint becomes the input of the next endpoint. See also Section 2.1, “Pipeline Processing”.



Apply a policy to the current route (currently only used for transactional policies — see Apache Karaf Transaction Guide.



Section 10.1, “Content Enricher”: Combines the current exchange with data polled from a specified consumer endpoint URI.



Execute a custom processor on the current exchange. See the section called “Custom processor” and Part III, “Advanced Camel Programming”.



Section 8.3, “Recipient List”: Sends the exchange to a list of recipients that is calculated at runtime (for example, based on the contents of a header).



Removes the specified header from the exchange’s In message.



Removes the headers matching the specified pattern from the exchange’s In message. The pattern can have the form, prefix\* — in which case it matches every name starting with prefix — otherwise, it is interpreted as a regular expression.



Removes the specified exchange property from the exchange.



Removes the properties matching the specified pattern from the exchange. Takes a comma separated list of 1 or more strings as arguments. The first string is the pattern (see removeHeaders() above). Subsequent strings specify exceptions - these properties remain.



Section 8.6, “Resequencer”: Re-orders incoming exchanges on the basis of a specified comparotor operation. Supports a batch mode and a stream mode.



(Transactions) Marks the current transaction for rollback only (also raising an exception, by default). See Apache Karaf Transaction Guide.



Section 8.7, “Routing Slip”: Routes the exchange through a pipeline that is constructed dynamically, based on the list of endpoint URIs extracted from a slip header.



Creates a sampling throttler, allowing you to extract a sample of exchanges from the traffic on a route.



Sets the message body of the exchange’s In message.



Sets the current exchange’s MEP to the specified value. See the section called “Message exchange patterns”.



Sets the specified header in the exchange’s In message.



Sets the specified header in the exchange’s Out message.



Sets the specified exchange property.



Sorts the contents of the In message body (where a custom comparator can optionally be specified).



Section 8.4, “Splitter”: Splits the current exchange into a sequence of exchanges, where each split exchange contains a fragment of the original message body.



Stops routing the current exchange and marks it as completed.



Creates a thread pool for concurrent processing of the latter part of the route.



Section 8.8, “Throttler”: Limit the flow rate to the specified level (exchanges per second).



Throw the specified Java exception.



Send the exchange to one or more endpoints. See Section 2.1, “Pipeline Processing”.



Send the exchange to an endpoint, using string formatting. That is, the endpoint URI string can embed substitutions in the style of the C printf() function.



Create a Spring transaction scope that encloses the latter part of the route. See Apache Karaf Transaction Guide.



Section 5.6, “Message Translator”: Copy the In message headers to the Out message headers and set the Out message body to the specified value.



Transforms the In message body from a low-level or binary format to a high-level format, using the specified data format.



Takes a predicate expression to test whether the current message is valid. If the predicate returns false, throws a PredicateValidationException exception.



Section 12.3, “Wire Tap”: Sends a copy of the current exchange to the specified wire tap URI, using the ExchangePattern.InOnly MEP.

Some sample processors

To get some idea of how to use processors in a route, see the following examples:


The choice() processor is a conditional statement that is used to route incoming messages to alternative producer endpoints. Each alternative producer endpoint is preceded by a when() method, which takes a predicate argument. If the predicate is true, the following target is selected, otherwise processing proceeds to the next when() method in the rule. For example, the following choice() processor directs incoming messages to either Target1, Target2, or Target3, depending on the values of Predicate1 and Predicate2:


Or equivalently in Spring XML:

<camelContext id="buildSimpleRouteWithChoice" xmlns="">
    <from uri="SourceURL"/>
        <!-- First predicate -->
        <simple> = 'bar'</simple>
        <to uri="Target1"/>
        <!-- Second predicate -->
        <simple> = 'manchu'</simple>
        <to uri="Target2"/>
        <to uri="Target3"/>

In the Java DSL, there is a special case where you might need to use the endChoice() command. Some of the standard Apache Camel processors enable you to specify extra parameters using special sub-clauses, effectively opening an extra level of nesting which is usually terminated by the end() command. For example, you could specify a load balancer clause as loadBalance().roundRobin().to("mock:foo").to("mock:bar").end(), which load balances messages between the mock:foo and mock:bar endpoints. If the load balancer clause is embedded in a choice condition, however, it is necessary to terminate the clause using the endChoice() command, as follows:



The filter() processor can be used to prevent uninteresting messages from reaching the producer endpoint. It takes a single predicate argument: if the predicate is true, the message exchange is allowed through to the producer; if the predicate is false, the message exchange is blocked. For example, the following filter blocks a message exchange, unless the incoming message contains a header, foo, with value equal to bar:


Or equivalently in Spring XML:

<camelContext id="filterRoute" xmlns="">
    <from uri="SourceURL"/>
      <simple> = 'bar'</simple>
      <to uri="TargetURL"/>


The throttle() processor ensures that a producer endpoint does not get overloaded. The throttler works by limiting the number of messages that can pass through per second. If the incoming messages exceed the specified rate, the throttler accumulates excess messages in a buffer and transmits them more slowly to the producer endpoint. For example, to limit the rate of throughput to 100 messages per second, you can define the following rule:


Or equivalently in Spring XML:

<camelContext id="throttleRoute" xmlns="">
    <from uri="SourceURL"/>
    <throttle maximumRequestsPerPeriod="100" timePeriodMillis="1000">
      <to uri="TargetURL"/>

Custom processor

If none of the standard processors described here provide the functionality you need, you can always define your own custom processor. To create a custom processor, define a class that implements the org.apache.camel.Processor interface and overrides the process() method. The following custom processor, MyProcessor, removes the header named foo from incoming messages:

Example 1.3. Implementing a Custom Processor Class

public class MyProcessor implements org.apache.camel.Processor {
public void process(org.apache.camel.Exchange exchange) {
  inMessage = exchange.getIn();
  if (inMessage != null) {

To insert the custom processor into a router rule, invoke the process() method, which provides a generic mechanism for inserting processors into rules. For example, the following rule invokes the processor defined in Example 1.3, “Implementing a Custom Processor Class”:

org.apache.camel.Processor myProc = new MyProcessor();