There is a simple syntax available for specifying pipeline, by simple putting to or → between the different steps in the pipeline.
For more advanced use cases, you can also use a block-based syntax, where every step in the pipeline starts with either to or →.
For a message filter, use the when() method with a parameter of type The Exchange ⇒ Boolean. In the example below, we use a Scala convenience method named in to access the 'in' message body; only messages where the 'in' message is <hello/> will arrive at the mock:a endpoint.
Once again, if you need to specify a more advanced route, you can use the more elaborate syntax.
The aggregator EIP aggregates messages based on some message correlation criteria. In the Scala DSL, the aggregate method takes a function Exchange ⇒ Any to determine the correlation value for the exchange. In the sample below, message are being aggregated if the first 7 letters in the message body are the same.
Similar to the Filter , the content based router uses when methods with Exchange ⇒ Boolean function literals and an optional otherwise. The function literal can contain plain Scala code as well as any of the supported languages . The example below routes a given message based on the language of the message body.
Unlike a throttler, which only slows down messages if the rate exceeds a treshold, a delayer delays every messages with a fixed amount of time. An example: to delay every message going from seda:a to mock:a with 1 second, you write...
Our second example will delay the entire block (containing mock:c) without doing anything to mock:b
To distribute the message handling load over multiple endpoints, we add a loadbalance to our route definition. You can optionally specify a load balancer strategy, like roundrobin
Multicast allows you to send a message to multiple endpoints at the same time. In a simple route, you can specify multiple targets in the to or → method call:
You can handle a static recipient list with a multicast or pipeline , but this EIP is usually applied when you want to dynamically determine the name(s) of the next endpoint(s) to route to. Use the recipients() method with a function literal (Exchange => Any) that returns the endpoint name(s). In the example below, the target endpoint name can be found in the String message starting at position 21.
Because the recipients() method just takes a function literal, you can basically use any kind of valid Scala code to determine the endpoint name. Have a look at the next example which uses pattern matching to figure out where to send the message:
Again, we can also use the same thing in a more block-like syntax. For this example, we use the Scala DSL's support for JXPath to determine the target.
Use the resequence method to add a resequencer to the RouteBuilder. The method takes a function (Exchange ⇒ Unit) that determines the value to resequence on. In this example, we resequence messages based on the 'in' message body.
The same EIP can also be used with a block-like syntax...
... and with configurable batch size. In this last example, messages will be send to mock:e whenever a batch of 5 messages is available.
To handle large message in smaller chunks, you can write a Scala Exchange ⇒ Any* method and add it to your route with the splitter method. As with many other EIPs, we support a short, in-line version as well as a more elaborate block based one.
The above examples also show you how other languages like XPath can be within the Scala DSL.
The throttler allows you to slow down messages before sending them along. The throttle methods allows you to specify the maximum throughput rate of message:
It can also be used in front of block to throttle messages at that point. In the example below, message are passed on to mock:b in a normal rate (i.e. as fast as possible), but a maximum 3 messages/2 seconds will arrive at the mock:c endpoint.
Using a processor function (Exchange → Unit), you can alter/enrich the message content. This example uses a simple function literal to append " says Hello" to the message content:
However, you can also define a separate method/function to handle the transformation and pass that to the process method instead. The example below uses pattern matching to enrich the message content:
Off course, you can also use any other Camel component (e.g. Velocity) to enrich the content and add it to a pipeline