Pipeline

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

image

With Camel, you can separate your processing across multiple independent Endpoint's which can then be chained together.

Options

The Pipeline eip supports 1 options, which are listed below.

Name Description Default Type

disabled

Whether to disable this EIP from the route during build time. Once an EIP has been disabled then it cannot be enabled later at runtime.

false

Boolean

description

Sets the description of this node.

DescriptionDefinition

Using pipeline

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

from("activemq:cheese")
    .pipeline()
        .to("bean:foo")
        .to("bean:bar")
        .to("acitvemq:wine");

And in XML:

<route>
    <from uri="activemq:cheese"/>
    <pipeline>
        <to uri="bean:foo"/>
        <to uri="bean:bar"/>
        <to uri="activemq:wine"/>
    </pipeline>
</route>

Though pipeline is the default mode of operation when you specify multiple outputs in Camel. Therefore, it’s much more common to see this with Camel:

from("activemq:SomeQueue")
    .to("bean:foo")
    .to("bean:bar")
    .to("acitvemq:OutputQueueu");

And in XML:

<route>
    <from uri="activemq:cheese"/>
    <to uri="bean:foo"/>
    <to uri="bean:bar"/>
    <to uri="activemq:wine"/>
</route>

Pipeline vs Multicast

The opposite to pipeline is multicast. A Multicast EIP routes a copy of the same message into each of its outputs, where these messages are processed independently. Pipeline EIP however, will route the same message sequentially in the pipeline where the output from the previous step is input to the next. The same principle from the Linux shell with chaining commands together with pipe (|).

When using pipeline is necessary

Using pipeline becomes necessary when you need to group together a series of steps into a single logical step. For example in the example below where Multicast EIP is in use, to process the same message in two different pipelines. The first pipeline calls the something bean, and the second pipeline calls the foo and bar beans and then route the message to another queue.

Notice how we have to use end() in the Java DSL to mark the end of the blocks:

from("activemq:SomeQueue")
    .multicast()
        .pipeline()
            .to("bean:something")
            .to("log:something")
        .end()
        .pipeline()
            .to("bean:foo")
            .to("bean:bar")
            .to("acitvemq:OutputQueueu")
        .end()
    .end() // ends multicast
    .to("log:result");

In XML its intuitive where you do not need to use end:

<route>
  <from uri="activemq:SomeQueue"/>
  <multicast>
    <pipeline>
      <to uri="bean:something"/>
      <to uri="log:Something"/>
    </pipeline>
    <pipeline>
      <to uri="bean:foo"/>
      <to uri="bean:bar"/>
      <to uri="activemq:OutputQueue"/>
    </pipeline>
  </multicast>
  <to uri="log:result"/>
</route>
Back to top